Add support for overwrite-mode to replace content with actual input#137
Add support for overwrite-mode to replace content with actual input#137lordnik22 wants to merge 4 commits into
Conversation
The bug #84 is really hard to solve. There is a workaround needed. When overwrite-mode is active it tries to untabify tabs by replacing the it with spaces. So when a tab is 4 spaces and overwrite-mode deletes one tab, then it inserts 4 spaces and moves one space forward. The problem: we aren't deleting any tabs so this logic should not be triggered but it's triggered by the insertion of old-text while old-text contains nothing whitespace related. The question persists why is untabify-logic applied? Right, it's a bug... Add workaround by setting deactivating overwrite-mode when calling delete-forward/backward Consolidate overwrite-mode handling by extracting a predicate Handle only self-insert-commands specially in overwrite-mode End-of-line has to handled specially because we consider spaces valid input for newlines. overwrite-mode should not replace newlines with spaces not should it insert additional spaces. Test: + Add newline and tab insertion to default case + Generalize test using random
lordnik22
force-pushed
the
132-replace-characters-overwrite-mode
branch
from
43c8d28 to
27c9c57
Compare
|
Well now, much complexity added, needs more testing... |
|
It's hard to test something with |
|
Backspace causes error, the session does not break. |
|
This feature is cool but it needs further good testing because it tangles quite a bit of the code when overwrite-mode is inactive. It modifies the "core"-logic . It adds a new principle to the core, namley "swap-char" in the change-function. This swap-logic is processed when overwrite-mode is inactive due to simplicity (less branching, more consistency, less hidden edge cases). Refining it further with AI, describing this new core-principle and why it works, may help understand the "inner working" more clearly. A better understanding will lead to a better system. I gives a better understanding which "combinations" to test. It's also a bit of a hassle because of the emacs-features we want to support alongside, namely undo, killing and yanking. We could also step down from them but this wouldn't lead to a more consistent system long-term rather a simplistic one with hard edges. Because speed-type is more of a game, a package as such complete, not a library or concept for further extension per se. This goes of course a bit against the general emacs mentality but that's at least my current understanding of speed-type. Maybe this feature is added to early. Maybe additional things need to shape the code more into something where this feature will have a better fitting place. Maybe at a later stage, it is more easily decidable how it must act to be correct. Maybe certain checks or actions get obsolete. |
1 participant
Fixes #132
Fixes #101