Bram Moolenaar wrote:
Alexei Alexandrov wrote;
Hi Bram Moolenaar, you wrote:
Patch 7.0.193
Problem: Using --remote or --remote-tab with an argument that matches
'wildignore' causes a crash.
Solution: Check the argument count before using ARGLIST[0].
Files: src/ex_cmds.c
After applying a patch I still observe differnt behavior between
gvim.exe <some file matching 'wildignore'>
and
gvim.exe --remote-tab-silent <some file matching 'wildignore'>
The first opens the file just fine, while the second says "No match"
error message.
Yes, well, there is a bit of a conflict about what Vim should do. You
told Vim to ignore files with a certain extension, and then you tell it
to edit such a file. In a new Vim this results in editing the file
anyway, since there is nothing else to do. In an existing Vim you get
an error message, and keep the file you were working on. I would think
this is OK. Is there a specific situation where you need Vim to edit
the file you wanted ignored?
According to ":help 'wildignore'", «A file that matches with one of these
patterns is ignored when completing file or directory names.» According to the
name, I would expect matching files to be ignored when expanding wildcards.
When specifying just a file name, with no wildcards and no completion, I would
expect Vim to edit the file if it exists, regardless of any 'wildignore'
setting. For instance if I want to salvage a previous version of a file from a
backup: Let's say 'wildignore' is set to "~,.bak"; then ":args foobar.*" or
":e foobar.<Tab>" should ignore foobar.bak but IMO ":e foobar.bak" shouldn't.
Similarly on the command-line: gvim foobar.* should ignore it but gvim
foobar.bak should edit it, regardless of whether "--remote-tab-silent" is on
the command line or not.
Best regards,
Tony.
--
Academic politics is the most vicious and bitter form of politics,
because the stakes are so low.
-- Wallace Sayre
