zyedidia
Add `hidecursor` option
Add hidecursor option for disabling displaying the cursor in the current buffer. This option is useful for plugins that may want to disable displaying the cursor for a readonly buffer in various cases.
I'm using this option in my viewmode plugin (I'm yet to clean up and upload it) which allows using Micro as a less-like pager. The absence of cursor serves as an easy indication for the user that the current buffer is in "viewer" mode and cannot be edited.
Seems a great addition but looks odd on a non read-only buffers, I wonder if we could make it a common option strictly for read-only buffers. So the user have an option to hide the cursor in every read-only buffer.
Seems a great addition but looks odd on a non read-only buffers, I wonder if we could make it a
common optionstrictly for read-only buffers. So the user have an option to hide the cursor in every read-only buffer.
Being able to change the setting individually for each buffer means you can still have the cursor visible in some read-only buffers (so you can eg. select some text to copy to another buffer). And I don't think there's any harm in having the option available for all buffers.
Being able to change the setting individually for each buffer means you can still have the cursor visible in some read-only buffers (so you can eg. select some text to copy to another buffer).
That's right, with my suggestion that's still possible since it would be a common option and you can setlocal.
Note: In fact, it's possible to declare a default value for a local-only setting globally by pasting it into settings.json (intended?). I keep my opinion about common option tho.
And I don't think there's any harm in having the option available for all buffers.
I agree. But since the feature likely has no use case in non–read-only buffers, the setting could be made "smart" enabling "the user have an option to hide the cursor in every read-only buffer" without requiring lua.
Seems a great addition but looks odd on a non read-only buffers, I wonder if we could make it a
common optionstrictly for read-only buffers. So the user have an option to hide the cursor in every read-only buffer.
Sounds reasonable.
That said, even for readonly buffers, just allowing to hide the cursor is kind of odd too. The cursor is still there, just invisible. So, for example, cursor movements are still working. So, for example, when the user presses the up arrow key, the resulting behavior is unpredictable: if the cursor is in the middle of the view, nothing will happen (from the user perspective), but if the cursor is at the top of the view, the view will scroll up. And the user doesn't know which of these 2 outcomes to expect, since the user has no idea where the invisible cursor is.
So, this hidecursor option is only gonna work well if the user (or a plugin), besides just setting hidecursor, has made sure to override the behavior of cursor actions, e.g. by binding their keys to some other actions, or by using callbacks preCursorUp, preCursorDown etc (my hacky viewmode plugin is doing the latter).
Another example: the user presses Ctrl-f and types text to find. The search starts from the cursor position. But the cursor position is who knows where, since the cursor is invisible. So it is unpredictable where the first search result will be found. To prevent that, the user (or, more likely a plugin) could, for example, use custom versions of Find, FindNext, FindPrevious actions, implemented in lua, which search from the top of the view regardless of the cursor position. Or, for example, force the cursor position to be always at the top of the view (that is what my hacky viewmode plugin is trying to do; also for this reason it is forcing setting scrollmargin to 0...)
So, I'm not so sure if hidecursor as such would be that great an addition. It is basically a low-level hack. (We might still merge it though, if we have no better ideas anyway.)
Nice POV, perhaps the call is to make possible for plugins to hide buffer's cursor as you suggested.
[...] could be better provide a more direct programmatic way for them to disable the cursor, e.g.
Buf.HideCursor = trueor something like that. [...]
Originally posted by @dmaluka in #3811
And shift this idea more into a "viewer mode" i.e. hidecursor but handle those odd behaviours, not sure if worth to make it on go side.
And shift this idea more into a "viewer mode" i.e. hidecursor but handle those odd behaviours, not sure if worth to make it on go side.
I thought about that too, yeah. That would mean introducing another bunch of extra logic and special cases in lots of places throughout the code, but maybe it's actually worth it, as it might allow to implement it in a better way than it could be implemented in a plugin.
For instance, with my hacky plugin, I have an unsolvable problem: when I open a file at a specified location, e.g. with micro foo.c:100:20, I'd like the cursor to be initially (temporarily) visible (despite the "pager mode" enabled), to be able to easily see this location. The plugin could easily detect if the initial cursor position is not at the beginning of the file, and temporarily make the cursor visible in this case. The problem is that I also like to use the savecursor option. And the plugin is not able to determine whether the initial cursor position is not at the beginning because I explicitly specified this position when opening the file (in this case I'm interested in seeing the cursor at this position) or just because savecursor is enabled and this is just the remembered position from the last time when the file was opened (in this case I'm not interested in seeing the cursor).
If the "pager mode" logic was integrated in micro itself, micro itself could easily distinguish these 2 cases.
...I think I'll probably finally upload my hacky plugin soon, why not (so others might try it out). And eventually we might implement the same in micro itself, in a more general and flexible way.