Besides window, buffer, and global wouldn’t a client scope be super useful? E.g. having options and triggers limited to the context of a certain client. What I do currently is using global and then I have to run a shell script ̵to check the name of %val{client} which is really cumbersome.
Isn’t the Window scope pretty much the same as a client scope? If not then I’m not sure how it would even differ.
Yeah, the wording is a bit confusing. [1]:
What is the
windowscope? It is actually not a window from a client, but a view of a buffer
and [2]:
There is a N:1 relationship between windows and buffers; once a
window is linked to a buffer, the window’s buffer never changes.
Windows store a set of selections and the scroll position.
1 Like
Oh ok, thanks for clarifying. In this case I agree a Client scope would be useful.
According to this issue https://github.com/mawww/kakoune/issues/2659, @alexherbo2 agrees on this proposal.
The thing about the current scopes, global, buffer and window is that they’re hierarchical. When you do echo %opt{some_opt} it looks first in window, then buffer and then global. Client scopes don’t really fit in this hierarchy, if an option is defined in both client and buffer, which one takes precedence?
1 Like
@occivink It’s a good point.
I understand the window scope as “a buffer in a window” (client); there is multiple occasions for a buffer to be seen in a window, but only one for a client, so I think a client is more specific.
This would need a major refactoring of how scope works, as they would now have dynamic parents (a client scope parent scope (likely buffer) would need to change when we change the current buffer). Luckily, this is the same issue that is currently blocking the “named scope” feature I referred to many times, so if we fix it to introduce client scopes, we can then get named scopes easily.