Visual cue to distinguish modes

[timjs]

In vanilla Kakoune and also in Dance I tend to mix up which mode I'm in. I know the status bar shows me "Normal" or "Insert", but it is usually far away from the cursor, where my eyes are, and I have to search for the text between all the other information VSCode shows in the status bar.

I love how in Vim you can spot the difference just by looking at the cursor: a block for normal mode, and a line for insert mode. However, this is not an option for Dance, because of the (very well founded!) choice to support zero width selections.

I was thinking about other ways to visually distinguish normal mode and insert mode. Till now, I've come up with two ideas:

• Change the way the current line is highlighted:
  • while in insert mode highlight it: "editor.renderLineHighlight": "line"
  • while in normal mode remove the highlighting: "editor.renderLineHighlight": "none"
• Change the color of the status bar (don't know if this is easily doable).

What do you think of these options?

[71]

Hey, and thanks for the feedback!

I also find the difference between the two modes too hard to notice and often try to run commands in normal mode and vice-versa. However anything that changes settings is slow, and not the best user experience (in some cases it will create a .vscode/settings.json file in the current workspace).
I initially changed the highlighting of the current line through decorations but deactivated this feature due to a bug. I actually discovered yesterday that the bug originated from somewhere else so I can try working on this again, but I'm not sure the rendering will be much more obvious. I'm welcome to hearing more ideas.

FYI changing the color of the status bar is possible, but also requires changing user preferences, so it has the problems I cited above.

[71]

I just noticed that we can change the line cursor from Line to LineThin. The difference is very subtle though.

[71]

There are several other changes we can make:

Changing the border color:

Changing the background color:

If we do this (and I'm completely okay with that), we need a change that's obvious enough to notice and that's consistent across all editors (support for dark mode, light mode, high contrast, custom themes).

[timjs]

Good to know I'm not the only one suffering to remember in which mode I'm working 😆

The difference between a thin and a thick cursor line is too subtile indeed. Let's not go that way.

For my understanding:

• Turning line highlighting on/off makes UX slow but changing the background colour by hand doesn't suffer from the same performance lags?
• Is it possible to change the background colour to a colour value provided by the current theme? I did a quick scan of the theming options but did not find a way to do this. Coming up with our own background or border colour will for sure bit someone using a theme we did not anticipate on.

[timjs]

Another idea:

• Change the cursor blinking mode:
  • solid in normal mode
  • blink (or smooth) in insert mode

[71]

Turning line highlighting on/off makes UX slow but changing the background colour by hand doesn't suffer from the same performance lags?

Any change to the user preferences (e.g changing the theme, changing the accent color of the status bar) is slow. However we can apply "decorations" to the editor, which are somewhat limited but much faster. Those can be used to change the background or border color of a line, for instance.

Is it possible to change the background colour to a colour value provided by the current theme? I did a quick scan of the theming options but did not find a way to do this. Coming up with our own background or border colour will for sure bit someone using a theme we did not anticipate on.

It is possible by using decorations. But we'd need a subtle, yet clear color to distinguish the two modes.

Change the cursor blinking mode

It looks like changing the blinking mode will also slow things down.

[timjs]

I think the only way we can choose a subtle, yet clear colour is to use one of the predefined theme colours.

I'd say we just decorate the current line with the theme background colour editor.lineHighlightBackground and possibly the border of the current line with editor.lineHighlightBorder. Although I think the background colour would be enough.

Or use diffEditor.insertedTextBackground, but that may be too invasive.

[71]

I tested this with a few colors:

editor.hoverHighlightBackground (multiple selections on the same line increase opacity)

editor.hoverHighlightBackground (multiple selections on the same line do not increase opacity)

editor.selectionHighlightBackground (multiple selections on the same line do not increase opacity)

Insert mode

Insert mode (main selection is empty)

Some more words

In my case, editor.lineHighlightBackground doesn't change anything.

I personally have a strong preference for editor.hoverHighlightBackground. In light+ (because why not), this looks like this.

versus insert mode

[timjs]

Then editor.hoverHighlightBackground it is!

Do you think it is better to have a highlighted background during normal mode or insert mode? My first thought was during insert mode, because selections would pop out more.

[71]

Oh, you're right about that!

I personally went with the highlight on normal mode because IMO, insert mode is closer to "normal editing" and therefore should have a color scheme closer to "normal VS Code," but making selections pop out more by inverting this choice is a very good alternative.

[timjs]

I understand your reasoning, but after trying out the new version I really think enabling the highlight in insert mode is cleaner.

In Noctis Lux for example, it is quite hard to keep track of the difference between a selection, an active line and a search hit:

[timjs]

And then just use the editor.lineHighlightBackground. It is intended as the background of a line when editing and softer than editor.hoverHighlightBackground:

[timjs]

Selecting a whole line using x also looks funny now:

[71]

editor.lineHighlightBackground doesn't seem to be set for the default dark theme, so in my case it doesn't change anything. We could make this a preference.

For me x behavior makes sense since the selection ends on the second line, but if you think it's better to act like it doesn't, I'll add a special case for it.

I'll try to push a change that goes in your way. A preference could be added for this too.

[timjs]

editor.lineHighlightBackground is not set for the default dark theme indeed, but editor.lineHighlightBorder is, see below. Means we should set both, in case a theme only sets on of the two.

Making this a preference is fine with me.

About the x behaviour: I'm totally fine with the way selections are made. It is perfectly clear what the selection is, and that the end-of-line is included. Please do not make a special case for it, it will only complicate the code. I only raised it to make a point for highlighting the current lines in insert mode instead of normal mode, because I think the background colour interferes with the selection colour. Because selections are not possible in insert mode, this problem will never occur.

[hedning]

Would it make sense to use a block cursor when there's no selection in normal mode? I've been experimenting with a kakoune like system in emacs (after trying vscode with dance) and quickly hit the same problem, using a block cursor on empty selections stopped the mistakes for me at least.

Ie. use a block cursor as a pseduo-selection. The main problem I can see with this is deciding how commands should interact with empty selections. Eg. should backspace kill the character within the block or the char behind it etc.

[timjs]

Using a block cursor would imply that there is always a selection of 1 character, which does not fit nicely with the VSCode of working.

• How would we represent the selection of a whole line? Now it is clear, because the line cursor is on the start of the next line.
• What should we do when the cursor is past the last char of a line? Now it it just a line. Otherwise, would it select the “end of line” implicitly or not? (Kakoune does this.)
• The usage of x becomes inconsistent. When the cursor is on an empty line or at the end of a line, you should just use d to delete the line end. xd would delete two lines. Using a line cursor, xd always deletes one line.

We still could try to swap from a thick line in normal mode to a thin line cursor in insert mode. Although it is subtiel, I found out my eyes notice the difference quickly.

_{Sent with GitHawk}

[hedning]

I mocked up a prototype: hedning@9c78ba5 (here's a compiled version: dance-0.1.6.vsix)

To be clear, I'm suggesting only using a block cursor when there's no selection. Ie. the case where it's currently not clear if you're in insert or normal mode.

Using a block cursor would imply that there is always a selection of 1 character

Yes, and there's certainly a few edge cases which are trickier with that model. Eg. should b extend the whole cursor? And the first shift+l would need to move two chars, and how would ctrl+backspace work etc.?

The upshot is two visually distinct modes, insert and selection. That might just be me though, I'm really accustomed having line cursor mean insert mode, and doubt any coloring etc. will do as good as showing a selection/block.

How would we represent the selection of a whole line?

In that case there's a non-empty selection, so a line cursor would be used.

What should we do when the cursor is past the last char of a line?

I'd guess implementation wise it's easiest to treat it as a selection of the newline char, so eg. d would merge the lines (like kakoune). However I don't see anything wrong with having eg. d not do anything at the end of line either. The idea that newlines are regular characters doesn't really make much sense to me tbh.

xd would delete two lines

We'd get a selection, so would use a line cursor after x. Should work the same.

[71]

About using a block character -- why not, but I want this behind an optional preference, and this isn't high priority for me (but I'll try to accept a PR that implements it if you want to submit one).

It will definitely require some changes in the existing code, but something nice about this is that this is the way Kakoune originally works, so this option will increase compatibility with Kakoune, and any of the choices we make regarding its implementation can be made by looking at the way Kakoune does it.

Regarding the line highlight -- I've been using the current config for a few days now as a long time Vim user (so I'm used to looking at the cursor to find out if I'm in normal or insert), and I no longer confuse the two modes. I do understand your preference, and suggest putting this behind a user preference. How about adding dance.{normal,insert}Mode.lineHighlight which can be false, an hex color, or a theme color name?

[timjs]

I like your suggestion on the dance.{normal,insert}Mode.lineHighlight option!

_{Sent with GitHawk}

[timjs]

Thanks for implementing this! I'm using it with the options:

    "dance.normalMode.lineHighlight": null,
    "dance.insertMode.lineHighlight": "editor.lineHighlightBackground",

and I really like the outcome. Selections are clear in normal mode, and switching to insert mode gives me cues of where my cursors are. Awesome!

[71]

Note: lineHighlight is ignored now, and decorations.backgroundColor should be used instead (see #204 (comment) for an example).