Support Plan9 position specs
Closed this issue · 9 comments
From neovim/neovim#1281 (comment), by @fmoralesc:
plan9's sam (which plan9-for-vimspace) has addresses like
main.c#23(basically, byte 23 atmain.c) andmain.c/void main/(search forvoid mainatmain.c) , but iirc vim won't accept#or/in filenames (it is hardcoded in the source, and the second will even throw an error which can't be catched).I think this format is not common enough to make it worth supporting at vim-fetch, though, but if you are interested, you can check p9fv's address compiler and address handler.
@fmoralesc: not sure about the / search syntax: nice, but outside the scope of what the plug-in currently does, and maybe really too uncommon a use case to embrace.
Supporting the #line number syntax OTOH seems easy, but I want to get this right: according to the Plan 9 plumb(6) man page, the correct syntax is actually
proto://path/to/file.ext:#lnum
meaning there needs to be a separating colon (and # is actually optional, according to the same source). The address handler code you linked to seems to point in the same direction, but I might be missing or misunderstanding something…
Vim seems to handle # in paths just fine BTW, at least in recent versions: my MacVim 7.4.560 opens them without complaining. As to /, I’d be amazed if that had ever caused an exception, considering it is the path hierarchy separator on *nix-ish systems :).
@kopischke When I do
:e ~/.vimrc:#12
(which was my use-case) it throws error 194 ('no alternate file'). I'm on vim 7.4.567 under linux.
Likewise, for
:e ~/.vimrc:/function/
vim says "illegal file name". This is not a catchable error. It will open the file, though.
The actual address spec is at http://plan9.bell-labs.com/magic/man2html/1/sam (see "Addresses").
I agree this address syntax can be out-of-spec, which is why I didn't open an issue here.
@fmoralesc yeah, I get the exception with the :#: # is the alternate file token (see :h cmdline-special), you need to escape it to use it literally, i.e. do
:e ~/.vimrc:\#12
to get a new file ~/.vimrc:#12 (I didn’t notice the issue at first because I tested with an existing file and Vim will automatically escape special characters when autocompleting filenames).
As to the / exception, I get
E172: only one file name allowed
whatever I do – apparently, Vim splits the file path at :/, and no amount of escaping seems to help.
TL;DR: provided the user thinks of escaping #, supporting Plan 9 type line specs is no biggie, but the search syntax is a no go. I’ll see what I can whip up :).
@fmoralesc if I understand sam(1) correctly, a null is used a the separator between file name and line number. As Vim uses null-terminated strings, this amounts to omitting the separator.
The way I see it, vim-fetch would need to support both /path/to/file.ext:#lnum and /path/to/file.ext#lnum (besides /path/to/file.ext:lnum, which it already does) to handle Plan 9 type jumps, correct?
I believe the : should start the address, I don't think path#char is ever used.
apparently, Vim splits the file path at :/, and no amount of escaping seems to help.
There must be some differences between path handling on OSX and linux, because that is not the behavior I get. :/
@fmoralesc added in newest release.
Cool! ;)
On Mac OS 9 (at least) : was the path separator char. Vim (not Neovim) has handling for this, not sure how it would behave on OS X.
@justinmk Vim on OS X uses what Apple terms Posix notation for paths, e.g. bog standard *nix / path separators (I should know, vim-fetch was developed in MacVim, and colon specs work just fine). As to “classic” MacOS, which did indeed use : (HFS notation in Apple parlance), I can’t test on it, but the way the plug-in works, colon specs should still work as long as there isn't a subdirectory with the same numeric name.