Florian Fischer: 1
allow proper transparent WIN_OPEN event handling
1 files changed, 19 insertions(+), 3 deletions(-)
Hi,
I do not typically interact with refs - vis-quickfix(I think)allows me to
":make" & gives bindings to go through the make-produced refs from there.
Selecting in a terminal "file.c:111:1:" to then remove the :111:1 is a
pain in the ass & I still do it sometimes.
here's what you want - omitting file_exists:
vis.events.subscribe(vis.events.WIN_OPEN, function(win)
if win.file == nil or win.file.path == nil then return end
local ref = win.file.path
local _, _, path, line = string.find(ref, "^(.+):(%d+)$")
if path == nil or line == nil or line == 0 or not file_exists(path) then
return
end
win:close()
vis:command("e "..path)
vis:command("+"..line-1)
end)
The `-a` may cause trouble with vis-cursors(plugin that saves cursor
position). If you have vis-cursors provide "-a ...:<n>" - how does the
cursor know who to trust????
Yes, even this snippet clashes with vis-cursors (which is pity,
because it is a very useful plugin). This functionality should be
probably incorporated into the plugin itself.
Best,
Matěj
On the other hand, if they are both plugins(vis-cursors &
vis-colon-file-?) that subscribe to the same event, then presumably
I can change the order of import(I haven't verified this).
Jeremy
Actually, how is it done? Is it just the order of `require` lines
in ~/.config/vis/visrc.lua?
So, if I put that snippet of code before `require` for
`vis-cursors`, would the opening process continue with modified
command line?
Best,
Matěj
That was my initial assumption.
Looking more into this, we(vis-colon-line) call win:close in the WIN_OPEN
event. Then on WIN_OPEN, vis-cursors nil-checks win, and then nil-checks
win.file, which throws an error.
I'm guessing this is a bug.
If a subscriber to WIN_OPEN calls win:close, should the rest of the
WIN_OPEN subscribers be called as well?
I have not followed your conversation thoughtfully. Therefore, I do not really know
what you guys want to accomplish.
But vis stops executing subscribed event handlers, after one returned a non 'nil'
value.
I have tried to create the plugin at
https://git.cepl.eu/cgit/vis/vis-open-extend/tree/init.lua but it
seems that win.file.path is read/only. Is it?
It is. But you can write a path to win.file to change the displayed file
of a window (which is currently not documented).
win.file = path
vis:feedkeys(tostring(line).."G")
This seems to do something, at least the editorconfig
plugin is happy, but then the other plugin
(https://git.sr.ht/~mcepl/vis-filetype-settings) fails with
```
...matej/.config/vis/plugins/vis-filetype-settings/init.lua:132: bad argument #1 to 'index' (invalid object reference)
```
I still don't know what do with this.
Also, I have added
https://git.cepl.eu/cgit/vis/vis-open-extend/commit/?id=7e1eceeb9c8c
to make the plugin work even when the file with a weird
colon-containing name exists.
Best,
Matěj
and I don’t see anything too strange at
https://git.sr.ht/~mcepl/vis-filetype-settings/tree/devel/item/init.lua#L132
This has the problem that, the file type detection will not work for paths
ending with ":line".
And you end up in a file without syntax highlighting.
Emitting the event again does not help either because then vis-cursors will
change the line to the last cursor position.
Yes, that's the prevoius question: either merge vis-cursors
functionality with my plugin, or find some kind of signal which
could be sent between two plugins.
Best,
Matěj
I see two possible ways out of this:
1. Put this functionality into vis-cursor itself (or other
way around, merging vis-cursor functionality into my
vis-open-extend plugin). After all, skipping to a particular
line is the shared action of both plugins, and if I decide to
determine this line number one way, I won’t do it the other
way around.
2. One plugin somehow sends a signal to the other one, telling it
not to jump. Returning non-null terminates ALL subsequent
plugins (including for example editorconfig or syntax plugins).
When I started to write this message, I preferred the second
option, but right now I think that the first one is not so bad
after all. And the second one seems to be impossible for now, so
I will probably have to merge vis-cursor inside my one.
What do you think?
Matěj
Flo
Any help?
Matěj
See: lua/vis.lua:241 [1]
This can be verified by simply including this in your visrc.lua file:
vis.events.subscribe(vis.events.WIN_OPEN, function()
vis:message("win open 1")
return false -- return a non nil value
end)
vis.events.subscribe(vis.events.WIN_OPEN, function()
vis:message("win open 2") -- this handler is not executed
end)
Cheers Flo
[1]: https://git.sr.ht/~martanne/vis/tree/master/item/lua/vis.lua#L241
Jeremy
Hi Matěj,