search

mawww / kakoune

mawww's experiment for a better code editor
http://kakoune.org
The Unlicense
9.97k stars 714 forks source link

Add a client scope #2659

Open alexherbo2 opened 5 years ago

alexherbo2 commented 5 years ago

Use case is to close portals when the client switches to a buffer.

Same for macros which are client scoped.

alexherbo2 commented 5 years ago

@occivink came with a good point here.

https://discuss.kakoune.com/t/client-scope-would-be-useful/737/6

alexherbo2 commented 3 years ago

Use case for color schemes (faces) and windowing (a client in tmux, kitty, X11…) instead of startup detection.

alexherbo2 commented 3 years ago

I would also like to have read-only clients.

Vincent-Carrier commented 2 years ago

Bumping this. My personal use case would be to clear the modeline on my toolsclient. Right now I just rely on regex, i.e.

hook global WinDisplay ^\*.*\*$ %{
  set window modelinefmt ""
}
raiguard commented 2 years ago

I am bumping this as well. My usecase it to create client-specific location lists (loli.kak).

I have the following things that I would like to have scoped to each client:

declare-option str-list loli_client_list
declare-option int loli_client_index

(Edit, I realized that the highlighter and ranges option will still need to be per window)

Without a client scope, I have to create a separate set of options for each client and keep track of them. This creates a sort of "leak", because you cannot delete options, so I cannot clean up the options for clients that no longer exist. Adding a client scope would allow me to greatly simplify the logic of my plugin.

I think in terms of precedence, the scope should live in between global and buffer. So global -> client -> buffer -> window.