Example commands with this issue: replace, carve, and chuck. The reason for this behavior is that we are attempting to remove the whitespace to the left of the deleted text, so that there isn't extra spacing left over. For example, if removing "is" from "this is a test", we don't want two spaces between "this" and "a" after the command completes. Another example is with replace: suppose we are replacing "coma" with "," in "to be coma or not to be", we wouldn't want to be left with a space to the left of the ",".
Currently the code that handles this assumes that if OCR didn't detect any characters to the left of the word in question, then we are either adjacent to whitespace that can be deleted or we are at the beginning of a text field. In either case, it's fine to move the anchor of the selection one to the left. The case where this breaks is if we are just after a newline -- we don't want to delete that newline.
In order to keep this separation, we would need to pass in an interface or function into the Controller constructor that performs this peeking. This would need to be separate from the keyboard and mouse interfaces, so that it can be properly app-agnostic (e.g. for nonstandard apps like Emacs).
I'm open to other ideas on how to handle this. A simple example that illustrates why this is nontrivial to solve visually is deleting a word that's in the middle of paragraph but happens to be present just after the line wraps. There is really no way to know whether the previous character is a newline or a space, without actually checking.
Example commands with this issue: replace, carve, and chuck. The reason for this behavior is that we are attempting to remove the whitespace to the left of the deleted text, so that there isn't extra spacing left over. For example, if removing "is" from "this is a test", we don't want two spaces between "this" and "a" after the command completes. Another example is with replace: suppose we are replacing "coma" with "," in "to be coma or not to be", we wouldn't want to be left with a space to the left of the ",".
Currently the code that handles this assumes that if OCR didn't detect any characters to the left of the word in question, then we are either adjacent to whitespace that can be deleted or we are at the beginning of a text field. In either case, it's fine to move the anchor of the selection one to the left. The case where this breaks is if we are just after a newline -- we don't want to delete that newline.
One way to fix this is to do something like dictation_peek_left in knausj: we could select the character adjacent, examine it with the clipboard, and only delete it if it is a simple space (" "). Currently, however, the code in question is far abstracted from Talon: https://github.com/wolfmanstout/talon-gaze-ocr/blob/fea18d46cbad9e6fd1db14b39fae387bf3cbefc8/.subtrees/gaze-ocr/gaze_ocr/_gaze_ocr.py#L351-L355
In order to keep this separation, we would need to pass in an interface or function into the Controller constructor that performs this peeking. This would need to be separate from the keyboard and mouse interfaces, so that it can be properly app-agnostic (e.g. for nonstandard apps like Emacs).
I'm open to other ideas on how to handle this. A simple example that illustrates why this is nontrivial to solve visually is deleting a word that's in the middle of paragraph but happens to be present just after the line wraps. There is really no way to know whether the previous character is a newline or a space, without actually checking.
@nriley FYI