statusline: Provide overwrite mode indicator

[JoeKar]

We can store the overwrite state in the Buffer instead of the BufPane, which makes it easier to be accessed from the statusline via the statusformatl option.

Closes #3155

[dmaluka]

"Delete" is not exactly what the overwrite mode is about. It is about overwrite aka replace, right?

I'm not sure which string should we display here.

I'm also wondering: can we be space-saving here and display a string only when in overwrite mode (similarly to $(modified))? Then maybe we could even add $(overwrite) to the default value of statusformatl.

Although again, I'm not sure which string should we display then. [overwrite] ? Anything shorter?

[JoeKar]

Even we find something, which we think it fits the needs...there is the one who likes to customize it anyway. 😉

[niten94]

I cannot come up with a better string, but I usually see "INS" displayed on the status bar when overwrite mode is enabled in GUI text editors. I don't think there could be a string with only symbols that can be recognized without confusion.

[dmaluka]

Yeah, I thought about [ins] too. I'm not entirely opposed to it, although arguably it would be a lie, since it is not the "insert mode" but the opposite of it (but hey, we can always say that it is "the mode that is triggered by pressing Insert, hence [ins]).

For reference, what some other editors display in their status lines, FWICS:

• vim: -- REPLACE -- in overwrite mode, -- INSERT -- in normal insert mode
• emacs: Ovwrt in overwrite mode, nothing in normal mode
• geany: OVR in overwrite mode, INS in normal mode
• nano doesn't seem to implement overwrite mode at all, the Insert key triggers something different

[JoeKar]

I'd prefer to keep the normal and default insert mode unmarked, as it is right now and only mark the replace/overwrite mode.
Unfortunately you don't like [>], because it is not self-explaining. 😉

How about [ow]...it is similar to [ro] or shall it be more explicit, but possibly longer?

[dmaluka]

"ow" sounds like "ouch" or something.

[ovr]?

[JoeKar]

over what?
I'm not really convinced.

[I]/[O] or [I]/[R], but then [I] needs to be displayed by default, otherwise [O] or [R] doesn't self explain.
Or as suggested by you initially just [overwrite], which is a bit longer, but explicit and really self explaining.

[dmaluka]

[overwrite] is ok for me.

One more thought: maybe let's make [ro] and [overwrite] mutually exclusive? Since when the buffer is readonly, there is little point in informing the user that we are in overwrite mode, since the user cannot edit (either insert or overwrite) anything anyway.

i.e. a trivial change:

--- a/internal/display/statusline.go
+++ b/internal/display/statusline.go
@@ -48,7 +48,7 @@ var statusInfo = map[string]func(*buffer.Buffer) string{
 		return ""
 	},
 	"overwrite": func(b *buffer.Buffer) string {
-		if b.OverwriteMode {
+		if b.OverwriteMode && !b.Type.Readonly {
 			return "[overwrite] "
 		}
 		return ""

[dmaluka]

since the user cannot edit (either insert or overwrite) anything anyway.

Well, actually currently the user can overwrite characters in a readonly buffer (try it: open help, press Insert and start typing characters), but that's a nasty bug to be fixed (#1805).

[JoeKar]

Good catch, thanks.
#1805 needs to be fixed on its own.

[dmaluka]

We can store the overwrite state in the cursor instead of the bufpane

I think abusing Cursor for that is hacky and wrong, and on top of that completely unnecessary, since we can just store it in Buffer (but not in SharedBuffer, that's the key).

That's the trick we use with LastSearch or HighlightSearch, for example. They are provided by buffer, not by bufpane, so they can be used by display, and yet they are effectively per bufpane, i.e. each bufpane has its own search state even if it shares its buffer with other bufpanes.

[JoeKar]

we can just store it in Buffer (but not in SharedBuffer, that's the key).

Good point, works like a charm!

[matthias314]

Sorry for chiming in late, and please ignore this comment if you think it just makes things more complicated.

I personally find that [overwrite] takes up quite a lot of space in the statusline, at least for a terminal window that is, say, 80 characters wide. What about shortening it to [over]? Something completely different that came to my mind would be to display the cursor position is reverse (foreground and background color exchanged) if in overwrite more.

[JoeKar]

I personally find that [overwrite] takes up quite a lot of space in the statusline

We're aware of the fact that it actually requires a lot space within the statusline and discussed it here:
#3620 (comment)

Unfortunately we didn't came up with a better, shorter and self explaining suggestion.

Something completely different that came to my mind would be to display the cursor position is reverse (foreground and background color exchanged) if in overwrite more.

Hm, something to consider.

[niten94]

Something completely different that came to my mind would be to display the cursor position is reverse (foreground and background color exchanged) if in overwrite more.

There are cases where the cursor is displayed as a box so relying only on cursor appearance to indicate overwrite mode cannot be done, but it is an additional feature that may be good with other cursor styles.

[JoeKar]

Ok, how to proceed?
Shall we make a vote for a shorter indicator text first?

[niten94]

I do not know if it is better to make a poll, but I think we shouldn't change the text or add a feature like @matthias314 said if there is no clear agreement. I am not good with decisions, so I will just leave what I think in this comment and let others or just maintainers decide (once again).

Overwrite mode being indicated in the status line may be already enough, so I think it is better to display box cursor on overwrite mode only if there is demand. (misunderstanding)

I am fine with the indicator text being changed to [ins] or [over] ([ovr] seems weird). Someone may be confused a bit at first if short indicator text is used and overwrite is accidentally enabled. However, I think micro users can usually realize with such text that overwrite mode was enabled and remember the meaning.

It is just nice if the string could be short, but the important part to me is that anyone can easily realize it and remember the meaning.

[matthias314]

relying only on cursor appearance to indicate overwrite mode cannot be done

Just to clarify: I didn't mean to change the cursor itself, but rather the way the cursor position is displayed in the statusline. (There seems to be a consensus now to go in a different direction, and that's fine.)

[dmaluka]

Another option is [ovwrt] like in emacs. A bit shorter than [overwrite], and rather unambiguous.

Regarding changing the way the cursor position is displayed in the statusline, the problem is (at least) that the user can arbitrarily override the format of the statusline by changing the statusformatl option. So it may not include $(line),$(col) at all, or for example it may not include $(line) at all but may include $(col) 15 times (why not?), and so on.

[niten94]

Just to clarify: I didn't mean to change the cursor itself, but rather the way the cursor position is displayed in the statusline. (There seems to be a consensus now to go in a different direction, and that's fine.)

Ah... I am sorry that I did not read properly.

Regarding changing the way the cursor position is displayed in the statusline, the problem is (at least) that the user can arbitrarily override the format of the statusline by changing the statusformatl option.

I may have caused a misunderstanding so I'll restate the suggested feature, but it was displaying the cursor position with the background and foreground color exchanged. Thinking about specific problems:

• It may look weird if done only with $(line) and $(col), and functions like status.vcol have to be supported.
• Probably excessive if the start and end of the part displayed like such is set in statusformatl.

---

The only action to do now probably remains with deciding or voting on a shorter string.

My perspective may be unusal so please ignore this part if not useful, but "over" is used in text structure and not abbreviated so [over] looks weird to me now. The only suggested text that look fine to me are [ins] and [ovr].

[JoeKar]

Ok, so [ovwrt] only (nothing for the usual insert) or [ins] + [ovr], where we've [ins] displayed the most of the time?