Hi,
I pipe the output of such commands to a buffer in vis, and use the following snippet to open them:
--------------------------------------------------------------------------------
-- Activate open-file-on-enter mode in this window
vis:map(vis.modes.NORMAL, ";e", function()
vis.win:map(vis.modes.NORMAL, "<Enter>", function()
local line = vis.win.file.lines[vis.win.selection.line]
local filename = string.find(line, ':')
local linenumber = string.find(line, ':', filename + 1)
local column = string.find(line, ':', linenumber + 1)
vis:command(string.format('open "%s"', string.sub(line, 0, filename - 1)))
vis.win.selection:to(tonumber(string.sub(line, filename + 1, linenumber - 1)), tonumber(string.sub(line, linenumber + 1, column - 1)))
end)
end)
--------------------------------------------------------------------------------
This assumes the column is also present.
Cheers,
Felix
On Wed Sep 11, 2024 at 8:11 AM CEST, Felix Van der Jeugt wrote:
> I pipe the output of such commands to a buffer in vis, and use the following snippet to open them:
Yeah, but that works only on :e command in already started vis,
right? I am more interested in the argument when starting new vis.
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Revenge is the misguided attempt to transform shame and pain
into pride.
-- Oceanbreeze7 in the summary of the story “Antithesis”
(on FFN)
I could see adding a command line flag that would interpret the
next file name as containing an address. For example:
-a filename: try to interpret filename as being of the form
'file[:line_number[:column_number]]' and start vis
at that location in the file. If ':line_number' is
not present the path is opened as given.
I don't think it makes sense for this to be the default behaviour
though; what if your filename contains ':number' at the end?
I do have a plugin[0] with a function that takes a string
containing lines of that form, parses it, and creates two
iterators which I bind to 'gn' and 'gp' for jumping to the next
and previous element in the list. I then have a separate run build
script keybinding which takes the output of a build script and
passes it to the previous function.
I can understand wanting to do this externally though.
- Randy
[0]: https://rnpnr.xyz/git/dotfiles/file/.config/vis/goto-ref.lua.html
--
https://rnpnr.xyz/
GPG Fingerprint: B8F0 CF4C B6E9 415C 1B27 A8C4 C8D2 F782 86DF 2DC5
On Wed Sep 11, 2024 at 2:39 PM CEST, Randy Palamar wrote:
> -a filename: try to interpret filename as being of the form> 'file[:line_number[:column_number]]' and start vis> at that location in the file. If ':line_number' is> not present the path is opened as given.>> I don't think it makes sense for this to be the default behaviour> though; what if your filename contains ':number' at the end?
Is this correct command to check that I have none of these on my whole $HOME directory?
$ find ~/ -type f 2>/dev/null|wc -l
2802147
$ find ~/ -name '*:+([0-9])' 2>/dev/null
$
(yes, on whole disk I have few of these in /run and /sys, also
two files in /var/lib/bluetooth/).
So, perhaps, if you insist, we can make it optional. However,
could we then go all in and add also
vis -a filename:/RE
for opening on the first line matching RE (or just a string instead of RE)?
> [0]: https://rnpnr.xyz/git/dotfiles/file/.config/vis/goto-ref.lua.html
Interesting.
Best,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
I was quite depressed two weeks ago when I spent an afternoon at
Brentano's Bookshop in New York and was looking at the kind of
books most people read. Once you see that you lose all hope.
-- Friedrich August von Hayek
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????
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
On Thu Sep 12, 2024 at 11:58 PM CEST, Jeremy wrote:
> 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
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
May you come to the attention of those in authority.
May you find what you are looking for.
May you live in interesting times.
-- claimed to be a Chinese proverb, but its origin is disputed
first documented use: Frederic R. Coudert,
Proceedings of the Academy of Political Science, 1939
On Thu Sep 12, 2024 at 11:58 PM CEST, Jeremy wrote:
> 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).
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
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Every true American would rather see this land face war than see
her flag lowered in dishonor.
-- The Episcopal bishop of New York, William Manning, 1916
On 09/16/24 01:16AM, Matěj Cepl wrote:
> On Thu Sep 12, 2024 at 11:58 PM CEST, Jeremy wrote:> Actually, how is it done? Is it just the order of `require` lines> in ~/.config/vis/visrc.lua?
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?
Jeremy
On Tue Sep 17, 2024 at 6:37 PM CEST, Jeremy wrote:
> On 09/16/24 01:16AM, Matěj Cepl wrote:> > On Thu Sep 12, 2024 at 11:58 PM CEST, Jeremy wrote:> > Actually, how is it done? Is it just the order of `require` lines> > in ~/.config/vis/visrc.lua?>> 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.
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
On Wed Sep 18, 2024 at 3:31 PM CEST, Florian Fischer wrote:
> 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?
Any help?
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Every true American would rather see this land face war than see
her flag lowered in dishonor.
-- The Episcopal bishop of New York, William Manning, 1916
> 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 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.
Flo
On Thu Sep 19, 2024 at 9:57 AM CEST, Florian Fischer wrote:
> Emitting the event again does not help either because then vis-cursors will> change the line to the last cursor position.
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
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
My point was simply that such tax proposals [for Pigovian taxes
compensating for the transaction costs] are the stuff that dreams
are made of. In my youth it was said, that what was too silly to
be said may be sung. In modern economics it may be put into
mathematics.
-- Ronald Coase
Notes on the Problem of Social Cost
On Thu Sep 19, 2024 at 9:57 AM CEST, Florian Fischer wrote:
> 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
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)
```
and I don’t see anything too strange at
https://git.sr.ht/~mcepl/vis-filetype-settings/tree/devel/item/init.lua#L132> 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
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Q: What is the chief end of man?
A: The chief end of man is to glorify God and to enjoy him
forever.
-- The Westminster Shorter Catechism
On Sat Sep 21, 2024 at 12:09 PM CEST, Matěj Cepl wrote:
> On Thu Sep 19, 2024 at 9:57 AM CEST, Florian Fischer wrote:>> 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>> 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
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Freedom is the freedom to say that two plus two make four.
If that is granted, all else follows.
-- George Orwell: 1984
Simply changing the file in a single WIN_OPEN event has one of two
possible problems.
1. Problem: We keep the current window
Then all previously ran WIN_OPEN event handlers have observed a wrong
file path, leading to broken syntax highlighting for example.
2. Problem: Use a new window
This solves the 1. Problem by emitting a new WIN_OPEN event with
the correct file path. However, this leads to plugins like vis-cursors
to jump to a possibly different line rendering vis-open-extend useless.
The solution to both problems is to split our event handling in two
parts:
On the original event detect the file and the specified line.
Change to the file in a new window, remember the line and stop
the event handling for the first event.
On the second WIN_OPEN event for the correct file path simply
jump to the remembered line.
This allows both plugins vis-open-extend and vis-cursors to work,
if vis-open-extend is loaded after vis-cursors, so our event handler
runs after the one from vis-cursors.
---
init.lua | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/init.lua b/init.lua
index 2bb477c..3d46b89 100644
--- a/init.lua+++ b/init.lua
@@ -7,22 +7,38 @@ local function file_exists(path)
return out
end
+--- Store the paths we opened to change their line in the second WIN_OPEN event+local paths = {}+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
+ -- If this is a file we opened, simply go to the saved line.+ if paths[ref] then+ vis:feedkeys(tostring(paths[ref]).."G")+ paths[ref] = nil+ return+ end+ -- if the file with colon actually exists, don't do anything
if file_exists(ref) then
return
end
local _, _, path, line = string.find(ref, "^(.+):(%d+)$")
- if path == nil or line == nil or line == 0 or not file_exists(path) then+ if path == nil or line == nil or line == 1 or not file_exists(path) then return
end
++ -- Store the file's path to go to line in the next WIN_OPEN event+ paths[path] = line win:close()
win.file = path
+ -- Open the actual file path. This creates a new window and emits a new+ -- WIN_OPEN event, which we use to set the correct line. vis:command("e "..path)
- vis:command("+"..line-1)--- or vis:feedkeys(tostring(line).."G") + -- Prevent other WIN_OPEN event handlers from running after we closed the window.+ return trueend)
+
--
2.46.2
On Thu Sep 26, 2024 at 4:13 PM CEST, Florian Fischer wrote:
> + -- Prevent other WIN_OPEN event handlers from running after we closed the window.> + return true
This is not a good idea, because there are other plugins which
have WIN_OPEN handlers we want to have working:
```
vis-cursors/init.lua
vis-editorconfig/edconf.lua
vis-filetype-settings/init.lua
vis-lspc/init.lua
vis-pairs/init.lua
vis-title/init.lua
vis-lockfiles/init.lua
```
`return true` is too heavy tool for what this plugin needs: we
would need some kind of more advanced inter-plugin communication,
otherwise I will just for vis-cursors and insert it into my plugin.
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
May you come to the attention of those in authority.
May you find what you are looking for.
May you live in interesting times.
-- claimed to be a Chinese proverb, but its origin is disputed
first documented use: Frederic R. Coudert,
Proceedings of the Academy of Political Science, 1939
On Thu Sep 26, 2024 at 4:43 PM CEST, Matěj Cepl wrote:
> On Thu Sep 26, 2024 at 4:13 PM CEST, Florian Fischer wrote:> > + -- Prevent other WIN_OPEN event handlers from running after we closed the window.> > + return true>> This is not a good idea, because there are other plugins which> have WIN_OPEN handlers we want to have working:>> ```> vis-cursors/init.lua> vis-editorconfig/edconf.lua> vis-filetype-settings/init.lua> vis-lspc/init.lua> vis-pairs/init.lua> vis-title/init.lua> vis-lockfiles/init.lua> ```>> `return true` is too heavy tool for what this plugin needs: we> would need some kind of more advanced inter-plugin communication,> otherwise I will just for vis-cursors and insert it into my plugin.
They do work! Have you tried my patch?
All handlers run for the second WIN_OPEN event with the proper file name.
Actually, I think we have to stop the event handling to prevent further handlers
from seeing the wrong path.
Simple timeline for what happens:
WIN_OPEN(file:line)
|
... prior handler run for file:line
| open the actual file
| WIN_OPEN(file)
|
... prior handlers run for file
| We jump to the correct line
... subsequent handlers run for file
| we stop the handling of the WIN_OPEN(file:line event)
But removing the event handling termination, still works on my configuration.
Flo
On Thu Sep 26, 2024 at 4:58 PM CEST, Florian Fischer wrote:
> They do work! Have you tried my patch?
Actually, they do! Weird …
See https://git.cepl.eu/cgit/vis/vis-open-extend/tree/init.lua
(and it depends on having
https://lists.sr.ht/~martanne/devel/patches/55192 included in
your vis for vis:file_exists function).
Thank you so much for leading me through this maze, but it could
really use some better documentation.
Best,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Never, never, never believe any war will be smooth and easy, or
that anyone who embarks on the strange voyage can measure the
tides and hurricanes he will encounter. The statesman who yields
to war fever must realise that once the signal is given, he is no
longer the master of policy but the slave of unforeseeable and
uncontrollable events.
-- Winston Churchill, 1930
On Thu Sep 26, 2024 at 4:13 PM CEST, Florian Fischer wrote:
> Simply changing the file in a single WIN_OPEN event has one of two> possible problems.
This was humbling experience: just for fun I have presented
the last version we developed to ChatGPT for review. And even
on this rather trivial and simple code, it manage to find some
improvements [1]. Most improvements are only cosmetic and better
language, but that conversion to number is actually not a bad
idea. Some suggestions I have rejected:
--- init.lua 2024-10-05 21:52:16.996356875 +0200
+++ openai_init.lua 2024-10-05 21:52:32.339774905 +0200
@@ -1,7 +1,7 @@
local paths = {}
vis.events.subscribe(vis.events.WIN_OPEN, function(win)
- if win.file == nil or win.file.path == nil then return end
+ if not win.file or not win.file.path then return end
local file_ref = win.file.path
-- Directly go to saved line if the file is already opened
@@ -16,7 +16,7 @@
return
end
- local path, line = file_ref:match("^(.+):(%d+)$")
+ local path, line = file_ref:match("^(.-):(%d+)$")
if not path or not line or tonumber(line) == 1 or not vis:file_exists(path) then
return
end
Best,
Matěj
[1] https://git.cepl.eu/cgit/vis/vis-open-extend/commit/?id=65abc1c0e32e
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
This is a signature anti-virus.
Please stop the spread of signature viruses!
Hi Matěj,
> This was humbling experience: just for fun I have presented> the last version we developed to ChatGPT for review. And even> on this rather trivial and simple code, it manage to find some> improvements [1]. Most improvements are only cosmetic and better> language, but that conversion to number is actually not a bad> idea. Some suggestions I have rejected:
I stumbled upon your/ChatGPT's changes.
Though, I am also no native speaker, I am pretty sure ChatGPT changed
the meaning of most comments it touched.
- -- If this is a file we opened, simply go to the saved line.
+ -- Directly go to saved line if the file is already opened
It is important that the plugin has opened the file, not that the file
is currently open.
Maybe my comment was not precise enough in the first place but better than
what ChatGPT did.
- -- Store the file's path to go to line in the next WIN_OPEN event
+ -- Store the line number for the next open event
This has better language but a less precise event name.
- -- Prevent other WIN_OPEN event handlers from running after we closed the window.
+ -- Prevent further WIN_OPEN event handlers from running
Here we lose context again. It is important that other WIN_OPEN handlers do not
run because we closed the window triggering the event in the first place.
- Flo
On Fri Nov 1, 2024 at 1:25 PM CET, Florian Fischer wrote:
> I stumbled upon your/ChatGPT's changes.> Though, I am also no native speaker, I am pretty sure ChatGPT changed> the meaning of most comments it touched.
You are right, changes to comments reverted.
Thank you,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
A conclusion is simply the place where someone got tired of
thinking.
On Fri Nov 1, 2024 at 1:25 PM CET, Florian Fischer wrote:
> I stumbled upon your/ChatGPT's changes.> Though, I am also no native speaker, I am pretty sure ChatGPT changed> the meaning of most comments it touched.
I hope I have no real users ;), because I have rewritten the
commit as
https://git.cepl.eu/cgit/vis/vis-open-extend/commit/?id=4e41eb033f7e
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Every developer’s hunt for the best editor ends up with Vim,
Emacs or a management position.
-- Rolf Bjaanes