2

When I open multiple files in gvim with no options, they are assigned to buffers in the order I specify on the command line:

gvim foo.cpp foo.h bar.cpp bar.h

Doing :ls then yields:

1 %a   "foo.cpp"                  line 1
2      "foo.h"                    line 0
3      "bar.cpp"                  line 0
4      "bar.h"                    line 0

However, when I am using --servername and --remote to have only one instance of gvim, the files are loaded in a different order:

gvim --servername gvim 

// Later ...

gvim --servername gvim --remote foo.cpp foo.h bar.cpp bar.h

Then :ls yields:

2 %a   "foo.cpp"                  line 1
3      "bar.cpp                   line 0
4      "foo.h"                    line 0
5      "bar.h"                    line 0

(Note that buffer 1 is not missing. It's a hidden empty buffer named [No Name] that was created by the first call to gvim with no file arguments)

It looks like maybe the --remote option causes the files to be grouped by extension. Is there a way to make --remote load the files into buffers in the same order specified on the command line?

BTW, this is with stock gvim 7.4, on CentOS 6.9, with no .vimrc or .gvimrc, and no plugins installed.

Update:

It looks like whatever gvim is doing here has to do with the fact that it recognizes the extensions .cpp and .h as special in some way. If I replace .cpp with .cat and .h with .dog, the files are loaded in the same order specified on the command line, as expected.

Mike Holt
  • 278
  • 2
  • 6
  • I am wondering what happened to buffer one? Can you reproduce this with an uptodate Vim? – Christian Brabandt Sep 12 '19 at 19:05
  • Did you try this on a different server to confirm your assumption of extension grouping? Or are you trying to draw an inference from one server, however many times? Maybe the order is by file read completion. Maybe some sort of handshake? – wbogacz Sep 12 '19 at 19:07
  • @ChristianBrabandt Buffer 1 is a hidden buffer from when I did the first gvim --servername gvim, with no file args. It creates an empty buffer (1) which it subsequently marks hidden when some files are opened. Doing :ls! to also show hidden buffers shows buffer 1 as [No Name]. – Mike Holt Sep 12 '19 at 19:27
  • @wbogacz I'm not making any assumptions. That's just what it looks like it's doing. Hence why I said maybe. And this isn't actually on a separate server. This is all on the local machine. I'm just using --servername to maintain a single instance of gvim. – Mike Holt Sep 12 '19 at 19:30
  • @wbogacz Also, ordering by read completion can't be the explanation for this, because these are all non-existent (new) files. – Mike Holt Sep 12 '19 at 19:47
  • 1
    It seems the order is (incorrectly?) influenced by the suffixes option if you use the --remote command line parameter. According to :help 'suffixes' this option should only have an effect on file names with wildcards. Maybe you can file a bug report at the Vim repository, if others come to the same conclusion. – Jürgen Krämer Sep 17 '19 at 07:19
  • @BLayer Sorry for the delayed response, and thanks for taking the time to find the answer. – Mike Holt Oct 17 '19 at 17:19
  • @MikeHolt No worries. Glad I could provide the information you needed. – B Layer Oct 17 '19 at 18:50

1 Answers1

2

I don't think --remote is the issue here. I can reproduce what you observed with a normal vim instance and the args command (e.g. args a.c a.h b.h b.c then args will show he two .h files at the end).

I went through the code a bit last night (disclaimer: it's been years since I used C with any regularity) and it looks like expand_wildcards() followed by gen_expand_wildcards() are called from do_arglist() for any args <filelist> command. That is, when setting/overwriting the args values (versus appending) and regardless of whether wildcards are present.

So we get to gen_expand_wildcards() which is summarized in the function comment which includes this: 

If there are no wildcards: Add the file name if it exists or when EW_NOTFOUND is given.

Well, EW_NOTFOUND is passed in from do_arglist() so that accounts for this happening with files that have yet to be created.

Okay so gen_expand_wildcards() returns the original file list we specified to expand_wildcards(). That's where we find the culprit: the code under this comment is executed unconditionally:

Move the names where 'suffixes' match to the end.

As Jürgen Krämer correctly surmised in his comment the root cause is related to an apparently undocumented application of the value in 'suffixes'.

Is it a bug? Probably only against the documentation as the code suggests the intent was always to do what is currently being done. The good news is you can work around the behavior if you'd like by modifying (temporarily) the value of 'suffixes'...set suffixes-=.h for instance.

B Layer
  • 19,834
  • 2
  • 30
  • 57