Text manipulation commands: bug reports, features suggestions, and other discussion

[alexboche]

Please report bugs, suggest changes, and discuss other issues relating to the new text manipulation commands that just merged from PR #485.

Check the known issues/bugs here first before reporting a new bug.

Contributions would be welcome in a number of areas, the link above also lists desired features. Somebody that understands regular expressions well could solve a few of the bugs easily (see the link above). Please consider discussing here before making a pull request.

[kendonB]

In Word, starting here:

and saying "go sauce before equals" ends up here:

[kendonB]

To improve the speed, could we use Ctrl-Right/Ctrl-Left for cursor movements to speed things up? The rules for what types of characters get skipped or stopped at seem the same in most editors. We could also (in-principle) use the up/down arrows for fixed width editors without line wrapping by detecting end line characters, I think.

[alexboche]

Sometimes people will want to search for more than just one letter because there are a lot of occurrences of say "a"so e.g. one might want to say something like "go lease sierra mike". I tried implementing that here by making the choice object the set of sequences up to length 2 of the characters (alphabet and punctuation).
There are two problems with this, both of which would be solved if these commands were not CCR (though I think that making these CCR has a lot of advantages). First,
I encountered the grammar complexity error even with sequences of length 2. If we made the commands non-CCR, I'm guessing we could get up to sequences of length 4 without hitting grammar complexity error. Second, there is ambiguity about whether "go lease sierra mike" means go to the nearest occurrence of "sm" or go to the nearest occurrence of "m" and then press s. Both interpretations have situations in which they would be desirable.

[kendonB]

What if we had another word before these so it knows to look for length 2 characters? Like "go sauce 2 double mike sierra" would search for "ms" and "go sauce 2 mike sierra" would search for "m" then type "s"?

[alexboche]

To improve the speed, could we use Ctrl-Right/Ctrl-Left for cursor movements to speed things up? The rules for what types of characters get skipped or stopped at seem the same in most editors. We could also (in-principle) use the up/down arrows for fixed width editors without line wrapping by detecting end line characters, I think.

Good idea. I don't know when I'll have time to implement that. Would anybody else have time soon?

[kendonB]

I found differences in Ctrl-Right/Left behavior across Notepad++, GitHub on Chrome, and TexStudio (all 3 different). Small sample but it seems like there will be a lot of edge cases to deal with

[alexboche]

In the meantime, people could try turning down the keypress wait time in settings.toml though that doesn't seem to be the bottleneck in some places (e.g. in gitter chat)

[kendonB]

I did some quick profiling and found that whenever there's a decent lag it's because of the navigation using the arrow keys.

[LexiconCode]

@alexboche mentioned he was going to be busy for the next few weeks. Therefore I might unpin this issue if no one has a preference.

[kendonB]

It would be neat to be able to integrate these with aliases. Imagine you've got a piece of code with a particular phrase/variable that you have an alias for. For example in the thing I'm currently writing, I have aliased g_{C} with "GC". It would be nice to be able to say "go lease before GC".

[alexboche]

I found differences in Ctrl-Right/Left behavior across Notepad++, GitHub on Chrome, and TexStudio (all 3 different). Small sample but it seems like there will be a lot of edge cases to deal with

Perhaps this could be implemented just for when the target object is dictation rather than characters. If everything is just words, then it should be pretty simple--basically one just counts the number of spaces. (with possibly a few exceptions). characters (e.g. in a programming context) would be much more complicated. I'm not sure how to let the function know that the target object is dictation rather than characters, but there must be a way. In fact, that is something we should be doing anyways because it influences what regular expression is used. Right now, there is a very crude method for determining what regular expression is used, namely if the target object is less than a certain number of characters it is guessed to be characters rather than dictation and then the regular expression is determined accordingly.

The functions have the ability to do different stuff for each application, so one could start by implementing the Ctrl-Right/Left for a particular application and then having the functions do the regular arrow key method for all other applications until those are implemented.