Improvement to how backspace works

[ttlnow]

Delete is problematic- there's nothing that can be done about that, but Backspace could work better with overtype mode: it would be best if it shifted the cursor left and overwrote the character with a space but kept the line length as-is (i.e. no deletion of characters). This would work nicely when editing Markdown tables and keeping the "cells" the same size.

[Endemoniada]

I think this differs a lot between use cases, but perhaps have a simple configuration page to select the expected backspace/delete behaviour?

This could also include an option to set the keyboard shortcut, since Mac users don't have an insert key whatsoever (not even virtual). I had to change the shortcut in the package files for it to work at all.

[CheeseSucker]

@ttlnow
Thank you for your suggestion.

I definitely see the value in having this, but at the same time I think we should be careful about adding non-standard behaviour by default.

Are there any major editors with this functionality? I've Tested in Notepad++, VS 2015 and Word, and they all delete the character.

Since this is (probably) non-standard behaviour, we would need to add a configuration variable to enable it as @Endemoniada suggests.

[JamesCoyle]

To me it makes sense that pressing backspace should replace the character deleted with a space character (being the best stand in for a blank character). In my opinion it wouldn't really hurt to replace the standard behavior as you can still easily remove the space characters with the delete key while in overtype mode but you cant add them without overwriting text you intended to keep. I feel other implementations get the functionality wrong.

[Asc2011]

I worked on this. So that a backspace replaces the char left from the current caret-position with a space.
With the only exception, if the caret is at the beginning of the line, then no change to the buffer is performed.
I'd like to merge that in, as soon as the other changes/additions are ready for prime time.
Among these is handling of paste-from-clipboard etc. see issues-#14/15
I'd wee happy to learn if there are any wishes on such topics, as I have some time on my hands to spend on this. So I'd like your opinions on pasting-from-clipboard or other 'destructive' operations during overtype-mode.

greets Andreas

[l-cornelius-dol]

I agree with other comments that having overtype backspace replace with a space is the better behavior. Though few editors do this, it is always the more useful behavior. Usually, when I am overtyping it's to replace code that has a columnar alignment which I want to retain, and if I backspace, it's to correct a typo; therefore I do not want to shift the text left.

A major editor that does this is TextPad. And a major terminal that does this is IBM 5250.

[Asc2011]

this is IBM 5250

welcome to COBOL & friends :-)
Concerning backspace, I agree, the most useful behavior to me would be overwriting with a space to the left followed by a caret-move to the left. Does TextPad behave like so ? As s special-case, caret stands at the-beginning-of-line, then nothing happens ? So preserving the line-structure ? What do you think ?

And here again, having a selection and triggering backspace on the selection, to me overwriting the selection with space and moving the caret to the beginning, seems to be the behavior of the least surprise ?

Do you make use of multiple cursors/selections regularly ? Cos' I don't and i'm not sure if I should care/support it ?

greets andreas

[l-cornelius-dol]

I use multi-cursors and multi-selection all the time and overtype works when typing. It should work when pasting as well.

Backspace at the beginning of a line should, I think, just delete the last character of the previous line, so, yes, preserving the line structure. TextPad does this and I find it intuitive. Backspace in TextPad elsewhere in the line moves the caret (block cursor) left and overwrites with a space.

Overwriting a selection with spaces in overtype mode is I think the most intuitive behavior on any action that would delete (remove) the selection in insert mode, so backspace, typing, etc. Except, perhaps DELETE and CTL-X, which should actually delete it?

[Asc2011]

@lawrence-dol

multi-cursors and multi-selection ... should work when pasting as well.

agreed on this and backspace-behaviour a'la TextPad fits my picture. Slowly i get an idea what the overwrite-mode could be a about. As a guiding thought, i'd say 'Return & Line-feeds are preserved - to not manipulate the text-structure.' What should happen when the return-key is pressed ? Following that idea, the caret would then hop to the beginning of the next line (maybe indent-pos), without inserting a line-feed. Basically doing a carriage-return instead of a new-line.
I've tried a backspace-implementation that moves-left until it finds a character and then overwrites that with a space. In case of three empty-lines behind the caret, it jumps four-lines back :-). It does not however delete return-chars, it walks them over. It's funny, but maybe too much.
When DELETE is pressed, without a selection it erases the char under the caret, without pulling the rest of the line to the left. When one/more selections are active, i'd expect to 'clear/erase' the contents of the selection(s) by writing spaces. Thus keeping the surroundings stable. Maybe even leaving the selection alive, not clearing it - not sure. The current implementation places the caret to the beginning of the selection. Assuming the users intent might be to continue typing input from there ?

DELETE and CTL-X, which should actually delete it

Maybe backspace on a selection keeps it with repositoning the caret, and DELETE/Ctrl-x completely kills it. Otherwise the effects of BS and DEL would be nearly identical. Anyhow, i'm testing and plan to put as much as possible into the settings-section. So one can at least enable/disable such behaviors
on a feature basis.
Atoms'-API seems quite rich and feature-complete cursor.hasPrecedingCharactersOnLine() did the backspace-trick.

[l-cornelius-dol]

ENTER => Non-destructively moving to the first character of the next line would be my preference. I think all choices erring on the side of "stable surroundings" will be the right option, with configuration for behavior where's there are more than one reasonable expectation of outcome.

I think, though, I still would consider that DELETE/CTRL-X (especially CTRL-X) should erase a selection; and DELETE should be the same as in insert-mode. But I would not lose sleep over it and if it were configurable, then everyone can be happy.

Thank you for doing this.

[Asc2011]

DELETE as implemented now, is a compromise : On first hit it will overwrite a char with SPACE. If char is a SPACE, then the standard-delete happens. Line-feeds-chars will not be touched at all.
There is a separate file actions.coffee that holds the behaviors/actions which makes it quite simple to edit or add stuff.
ENTER moves without inserting a new-line(s).
same with BACKSPACE, overwrites and moves over line-feeds.

greets