Closed kopischke closed 9 years ago
@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.
From https://github.com/neovim/neovim/issues/1281#issuecomment-69914236, by @fmoralesc: