helix-editor / helix

A post-modern modal text editor.
https://helix-editor.com
Mozilla Public License 2.0
32.9k stars 2.43k forks source link

Helix in unfocused window should appear differently than in a focused window #1187

Open dannasessha opened 2 years ago

dannasessha commented 2 years ago

At a glance it is impossible to determine if a helix instance is in focus (actively being used) or not. Often users will have more than one instance of a text editor open right next to each other on their screen. They should be able to see from some visual cue which instance is in focus.

I imagine an inactive helix window being slightly desaturated (colors all shifted to be more grey), or, minimally, having a clear indication of which cursor(s) are in an active in-focus window.

dannasessha commented 2 years ago

1154 may be relevant.

sudormrfbin commented 2 years ago

Do you mean split windows inside the editor itself or different terminal windows running separate hx instances ? For the latter it would be the responsibility of the window manager or desktop environment to dim inactive windows if required though. ~I remember an issue being opened about differentiating between active and inactive splits, can't find it right now~ Ah that was a comment in https://github.com/helix-editor/helix/pull/1154#issuecomment-977973500 not a separate issue.

dannasessha commented 2 years ago

Do you mean split windows inside the editor itself or different terminal windows running separate hx instances ? For the latter it would be the responsibility of the window manager or desktop environment to dim inactive windows if required though.

I meant really, both, in the sense that the active cursor could look different than an inactive one - or that the whole buffer or pane that is in focus, and, therefore, ready to be interacted with by a user, would look different than other buffers, panes, windows, and so on.

I see your point about the window manager. I don't have a completely specific vision for this yet. I think having something in the helix UI that says 'ready!' would be nice, again, due to the fact that many users including myself can have a number of windows, buffers, splits, panes etc all open at once.

archseer commented 2 years ago

For determining the active split I've been relying on the statusline (there's an inactive style). I've been missing some sort of indicator when the editor isn't in focus though, but this isn't possible since we get no such events from the terminal. It's more visual in vim because the terminal cursor will move out of the editor, but ours are "hand-drawn" due to multiple selections and are always present, Kakoune has the same behavior.

sudormrfbin commented 2 years ago

1154 uses the terminal cursor, so the cursor becomes hollowed (works on alacritty, kitty, wezterm, etc) which is what I rely on with vim:

terminal-cursor-shape-change-on-focus

dannasessha commented 2 years ago

This looks good! I think it would be great to use, even as an option.

If this is the best way to go, but needs something for configurability or implementation, I'd be interested in trying to make it work. I'll also keep my eye on #1154.

reissbaker commented 2 years ago

Do you mean split windows inside the editor itself or different terminal windows running separate hx instances ? For the latter it would be the responsibility of the window manager or desktop environment to dim inactive windows if required though. ~I remember an issue being opened about differentiating between active and inactive splits, can't find it right now~ Ah that was a comment in #1154 (comment) not a separate issue.

FWIW, I think for tmux users this would be extremely difficult: tmux is a terminal multiplexer, so it just renders the output from hx. Theoretically maybe tmux could support doing color math on all output from a program in an inactive pane, but... it doesn't, and it looks like both vim and neovim just natively support tmux and its focus events.

Also, unfortunately due to hx drawing its own block cursor, specifically for block cursors tmux's ordinary behavior of hiding cursors from inactive panes doesn't work: as long as there's a block "cursor" drawn onscreen for hx, it'll show up regardless of pane activity, because it's not a real cursor and is just a box drawn by hx, so tmux can't know to hide it.

archseer commented 2 years ago

Okay I was wrong, some terminals do support this feature:

xterm-focus-event Some terminals including xterm support the focus event tracking feature. If this feature is enabled by the 't_fe' sequence, special key sequences are sent from the terminal to Vim every time the terminal gains or loses focus. Vim fires focus events (FocusGained|/|FocusLost) by handling them accordingly. Focus event tracking is disabled by a 't_fd' sequence when exiting "raw" mode. If you would like to disable this feature, add the following to your .vimrc: set t_fd= set t_fe= If your terminal does support this but Vim does not recognize the terminal, you may have to set the options yourself: let &t_fe = "\[?1004h" let &t_fd = "\[?1004l" execute "set =\[I" execute "set =\[O" If this causes garbage to show when Vim starts up then it doesn't work.

Using these two events we should be able to detect focus and change cursor styling

estin commented 2 years ago

Hi! another tmux user Cursor in file picker hides on pane switching (or on inactive window), but not in current buffer. FilePicker handle focus events? Can't find where it does to pass this logic to buffer

helix-cursor-2022-06-30_15 58 46

$ tmux -V
tmux 3.3a

$ alacritty --version
alacritty 0.10.1 ()

$ hx --version
helix 22.05 (d06800f1)

$ cat ~/.config/helix/config.toml
theme = "onelight"

[editor]
line-number = "relative"
mouse = false

[editor.file-picker]
hidden = false

[editor.cursor-shape]
normal = "block"
insert = "bar"
select = "underline
the-mikedavis commented 2 years ago

The primary cursor in helix is the terminal emulator's cursor which is switching between panes when you switch tmux windows. It might be possible to handle this case by drawing a block where the cursor was but we would need to handle focus events (we don't currently) and it would be inconsistent with the behavior when you switch between splits within helix (although that could be improved too).

mo8it commented 1 year ago

If you use Zellij (similar to Tmux) and don't hide the pane frames, then the frame will help you until Helix implements a solution :)

pickfire commented 1 year ago

I tested the CrosstermEvent::FocusGained event and it seemed to work, but the thing is I don't quite know how to make the cursor become blank again, neovim somehow did this but I couldn't figure it out yet. I realized I opened https://github.com/mawww/kakoune/issues/3652 but how neovim did it wasn't discussed.

archseer commented 1 year ago

Neovim doesn't render multiple fake cursors, it just positions the terminal cursor. I have a branch that has this working locally, but it's the same problem, the cursor disappears.

pickfire commented 1 year ago

Should we render the main primary cursor using the real terminal cursor then we can keep the rest as fake cursors?

nalply commented 1 year ago

Here what I watched: The file picker cursor disappears if I focus a different Zellij pane and becomes hollow if I focus a different application. Using sway and foot.

It looks like Zellij takes away the main cursor from helix.

I think helix should handle focus events: from the window manager and from terminal multiplexer, no idea whether this is doable, in my opinion no need to discern these two cases, but the status bar should switch to inactive when:

I also think, helix should use a fake cursor in the pickers and give the possibility to style the cursor for inactive splits and pickers differently.

Edit I tried that while in insert mode (where I have a bar cursor). It disappears when I switch to a different Zellij pane and reappears when returning. It stays when I switch to a different application. Since helix leaves the insert mode when switching to a different split, we can ignore that for helix.