Skip to content

Add hidecursor option#2632

Open
dmaluka wants to merge 1 commit intomicro-editor:masterfrom
dmaluka:hidecursor
Open

Add hidecursor option#2632
dmaluka wants to merge 1 commit intomicro-editor:masterfrom
dmaluka:hidecursor

Conversation

@dmaluka
Copy link
Collaborator

@dmaluka dmaluka commented Nov 13, 2022

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.

Add `hidecursor` option for disabling displaying the cursor in the
current buffer. This option is useful for plugins which may want to
disable displaying the cursor for a readonly buffer in various cases.
@cutelisp
Copy link
Contributor

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.

@Andriamanitra
Copy link
Contributor

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.

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.

@cutelisp
Copy link
Contributor

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.

@dmaluka
Copy link
Collaborator Author

dmaluka commented Jul 21, 2025

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.

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.)

@cutelisp
Copy link
Contributor

cutelisp commented Jul 22, 2025

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 = true or 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.

@dmaluka
Copy link
Collaborator Author

dmaluka commented Jul 22, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants