Optional vi-like cursor behavior when leaving insert mode.

[boomlinde]

This addresses #42 in a non-intrusive way. When the vicursor option is set, the cursor will move one column to the left upon exiting insert mode. Since newlines are addressable and appear before the first column of the next line, the exception to this behavior is when insert mode is left while the cursor is on the first column of a line.

I am not sure that putting this functionality in config.def.h is the right approach, but it works for me.

[martanne]

Thanks! If possible I would like to avoid introducing options like vicursor. Instead if this is what people expect then we should probably make it the default and only behavior.

Having said that, why do you prefer it? What is the reason vi(m) did it that way?

Intuitively leaving insert mode and then entering it again should not change the cursor position.

[greduan]

No idea why they would do it that way, but it's muscle memory to expect it to go left one after leaving insert. :)

I'm fine with this setting being available, but I don't care if it isn't implemented either.

[trengrj]

Since newlines are not addressable in vim, when you are appending to a line in vim the cursor is temporarily over an invalid character (and hence the move back after an insert / append). See http://stackoverflow.com/a/17975729.

The newline addressability decision makes the vim / vis interfaces diverge.

On a single empty line, in vis a moves cursor to the next line (operates like ji), while in vim a operates like i.

The '$' operator in vis can actually move you left if you are on a newline.

If newline addressiablity is kept, vicursor isn't strictly needed. However I'm not sold on newline addressibility as it adds clutter to the line (an additional character), breaks the meaning of a, and will probably cause more issues with vim / vis differences in core editing commands.

[rychipman]

The original impetus for raising issue #42 was that it did not match my expectations coming from vim (a muscle-memory thing, as @greduan said).

The more I think about it though, I don't need or even really particular care about that UX nuance.

As @trengrj mentioned, newline addressability does introduce other interface divergences, and those divergences are the ones that worry me a bit more. For example:

• a at the end of a line does the same thing as i (doesn't move the cursor forward) which is a bit uncomfortable.
• being able to delete a newline with x. except for the final newline of a file, which is addressable, but cannot be deleted.
• related to the previous item, dd on the last line of a file removing its contents but not the line itself.
• text editors in general (not just vim) have conditioned me to expect that end-of-line whitespace will not be a newline character.
• related to the previous item, it feels weird that the visual representation of a newline is the same as a space.

Those are just a handful of edge cases that I was able to find in about 5 minutes of playing around. Now it may be entirely possible to resolve these inconsistencies while maintaining newline addressability, but it does seem to be a common cause of a number of these UX 'bugs'.

[martanne]

I agree that the newline addressability causes some differences compared to vim. The question then is whether they are harmful or not. I'm yet undecided and in general quite like it. It certainly is a controversial thing, even one of the first comments after the public announcement of vis was about it.

On a single empty line, in vis a moves cursor to the next line (operates like ji), while in vim a operates like i

Is this a bad thing? a always does the same thing not depending on whether the line is empty or not. Why would you even use a when you expect the same thing to happen as for i? vis seems to give you more options in this specific case.

The '$' operator in vis can actually move you left if you are on a newline.

True, but does it really matter? Why would you use $ if you are already at the end of the line (on a newline)?

a at the end of a line does the same thing as i (doesn't move the cursor forward) which is a bit uncomfortable.

a moves the cursor forward, the complain from @trengrj was that it even does it for empty lines / when the cursor is on a newline character.

it feels weird that the visual representation of a newline is the same as a space.

I tend to agree, that is why I implemented :set show newlines=1. If you enable this setting you will see that you can in fact delete the last newline of a file. What you are probably refering to is the (illegal) position after the end of file where you would insert new text. I agree that in this case x should probably delete the last valid character of the file. Also dd should probably not place the cursor at this EOF position but at the start of the last line.

It is the way it is because I wanted to avoid special cases. Another reason might be that I rarely edit files at the end and therefore it didn't bother me too much so far.

[martanne]

Changing the cursor position when leaving insert mode would break the the dot command which is implemented by replaying an implicit macro which might repeatedly switch in and out of insert mode (see also #44).

I still like newline addressability and I'm thus closing this. If someone sends an updated patch which works with the repetition code, this can be reconsidered.

[martanne]

Because this pull request is regularly referenced when discussing newline addressability related issues, here a quick update:

The '$' operator in vis can actually move you left if you are on a newline.

This is no longer the case.

On a single empty line, in vis a moves cursor to the next line (operates like ji), while in vim a operates like i

Due to popular demand (e.g. #287, #295) this was changed to match the vim behavior.

Repeatedly switching in and out of insert mode is still idempotent in the sense that the cursor position remains unchanged. This is the desired behavior for vis and there currently exist no plans to change it.

The same applies for newlines which are still directly addressable.

[unrealapex]

This is the desired behavior for vis and there currently exist no plans to change it.

I would love for this feature to be implemented. This behavior is the only reason feel the urge to switch to nvi.