Changes introducing a couple of events to enable the 'vis-line-numbers' plugin #525
Conversation
|
A couple of comments:
Thanks. |
|
Thanks for the comments. Will address them and update. |
|
What is the state of this? Did you encounter any problems, or are you just busy with other things? Should I take care of these changes? |
|
I have it almost done. I had to fix/modify a few things. I'll upload the
updated changes with comments soon.
…On Tue, Apr 4, 2017 at 12:47 AM Marc André Tanner ***@***.***> wrote:
What is the state of this? Did you encounter any problems, or are you just
busy with other things? Should I take care of these changes?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#525 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADnYauWfe7P8UQrCuQFGfMhvKICihtPnks5rsfV8gaJpZM4Mrzjc>
.
|
By default commands still execute for the active window. But the target window can now be specified as an argument, both in the vis internal code and from Lua.
Use `vis_window_focus` instead.
To reproduce the issue addressed, start with an empty `visrc.lua`, and three file with some content. Open a file and set line numbers. Then open two files with one split command `:sp file_2 file_3`. The view options were only propagated to the last file opened.
Until now, vis was focusing on a window before it was open.
Now the process is:
- A window is opened, and the `WIN_OPEN` event is fired.
- Some more configuration of the window may happen.
- Vis focuses on the window.
Note that it implies that when `WIN_OPEN` is fired, the active window is *not*
the newly created window. So lua code suscribing to the event may want to
specify the window as a parameter to `vis:command`.
vis.events.subscribe(vis.events.WIN_OPEN, function(new_win)
-- This command applies to the currently active window, *not* to the newly
-- created window.
vis:command('set numbers')
-- This command applies to the newly created window.
vis:command('set numbers', new_win)
end)
This even is fired when a wndow gains focus, and can be acted upon by the user like any other event.
This even is fired when the vis mode changes, and can be acted upon by the user like any other event.
|
PTAL. We may need to discuss a few things. Here are a few notes for the updated request:
|
| @@ -1162,7 +1164,8 @@ enum SamError sam_cmd(Vis *vis, const char *s) { | |||
| break; | |||
| } | |||
| } | |||
| vis_mode_switch(vis, completed ? VIS_MODE_NORMAL : VIS_MODE_VISUAL); | |||
| if (!completed) | |||
| vis_mode_switch(vis, VIS_MODE_VISUAL); | |||
There was a problem hiding this comment.
Still not to sure about this. It passes the tests, but I did not take time to investigate fully.
There is a potential issue here with recursive events being fired on mode switch
|
I fixed up a few things and pushed the result to the events branch. And yes, recursive events will probably need to be handled somehow. Otherwise users will shoot themselves in the foot. I also moved the mode change event into |
|
I rebased the branch. Not really happy with the implementation, but it should now work? Can you please try it? For your use case you can probably ignore the |
|
One use case is broken.:
The new split should have relative line numbers, but with your changes it does not. The problem is that the UIOptions are copied from the original split after the event is fired. That is why I was splitting the window opening process into creation/configure/focus. |
|
@rnpnr Is this PR still relevant at all? |
It seems super out of date. The ideas here could be revisited in the future with fresh eyes but this stale version isn't much help. |
Hi there,
My goal was to create a 'vis-line-numbers' plugin to have the line numbers as I like them. See https://github.com/arames/vis-line-numbers.
Please let me know if the changes to vis look sensible.