statusline: Provide overwrite mode indicator by JoeKar · Pull Request #3620 · micro-editor/micro (original) (raw)
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
JoeKar marked this pull request as draft
We can store the
overwritestate in thecursorinstead of thebufpane
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.
we can just store it in
Buffer(but not inSharedBuffer, that's the key).
Good point, works like a charm!
JoeKar marked this pull request as ready for review
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.
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.
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.
Ok, how to proceed?
Shall we make a vote for a shorter indicator text first?
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.
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.)
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.
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
statusformatloption.
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 likestatus.vcolhave 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].
Ok, so [ovwrt] only (nothing for the usual insert) or [ins] + [ovr], where we've [ins] displayed the most of the time?
[...] or
[ins]+[ovr], where we've[ins]displayed the most of the time?
Updated with this, because it doesn't resize the statusline...less flickering.
Updated with this, because it doesn't resize the
statusline...less flickering.
So now it adds [ins] (arguably not very useful most of the time) to the statusline by default?
Sorry, I should have specified what I meant. I also realized there may be problems when using [ins] in any way. There at least seems to be no objections with [ovr].
Updated with this, because it doesn't resize the
statusline...less flickering.So now it adds
[ins](arguably not very useful most of the time) to the statusline by default?
Overwrite mode is not usually enabled, so I agree too that it wouldn't be useful much (and wastes limited space). If there are no use cases where overwrite mode would be toggled fast a lot, then I don't think anyone will mind the status line flickering.
Maybe [ov]? Same number of characters as [ro]. :)
Or [ovwr]...
Both and [ovwrt] seems fine, but at this point I don't have good reasons to choose a particular string. I have mentioned a lot of what I think, so I think I'll now just leave the string to be decided.
So now it adds
[ins](arguably not very useful most of the time) to the statusline by default?
Yes.
Overwrite mode is not usually enabled, so I agree too that it wouldn't be useful much (and wastes limited space). If there are no use cases where overwrite mode would be toggled fast a lot, then I don't think anyone will mind the status line flickering.
But it doesn't seem to bother anyone but me.
So if we really don't need [ins] then we can remove it and stay with something short for overwrite only.
The main thing is that we close this PR soon.
I don't really care what it says in overwrite mode as that is not visible under normal circumstances, but I don't like taking away space on the statusline in normal input mode with [ins]. [ins] can also be misinterpreted as "Insert has been pressed, so overwrite mode is active".
The latest version (with [ov]) looks good to me. But I don't really care whether it would be [ov], [ovr], [ovwr], [ovwrt] or [overwrite], so perhaps someone prefers to change it to something else from this list, before we merge it?
Actually after a bit more thinking, [ovwr] seems better (more explanatory) than [ov]?
Then we go with the first two letters of over and write [ovwr].
Hopefully the last change here 🙏.
JoeKar deleted the feature/cursor-overwrite-indicator branch
Better to add a status line configuration option. Like I use "statusformatl": "$(icons.FileIcon)$(filename) <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">(</mo><mi>m</mi><mi>o</mi><mi>d</mi><mi>i</mi><mi>f</mi><mi>i</mi><mi>e</mi><mi>d</mi><mo stretchy="false">)</mo><mo stretchy="false">(</mo></mrow><annotation encoding="application/x-tex">(modified)(</annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:1em;vertical-align:-0.25em;"></span><span class="mopen">(</span><span class="mord mathnormal">m</span><span class="mord mathnormal">o</span><span class="mord mathnormal">d</span><span class="mord mathnormal">i</span><span class="mord mathnormal" style="margin-right:0.10764em;">f</span><span class="mord mathnormal">i</span><span class="mord mathnormal">e</span><span class="mord mathnormal">d</span><span class="mclose">)</span><span class="mopen">(</span></span></span></span>(line),$(col))" Would be great to wrap ($(line),$(col))" with something like $(insert.inverted$(line),$(col))" so the line and colon numbers part would invert or colored red when insert mode is enabled. Also, this way you could define any characters you want.
Btw, there is a line $(overwrite) available. It does nothing for me, what is it for then?
Btw, there is a line
$(overwrite)available. It does nothing for me, what is it for then?
With this merged PR $(overwrite) can and is used to mark the [ovwr] being active after the ins-key was pressed.
Great, but maybe allow to select any part of the status line to indicate it? The same would be also great for $(modified), a + sign is ok, but ability to change the color of the $(filename) when modified would be better.
Maybe, but please then as a different feature request.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})