Why does gvim --remote change order of files?

Question

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.

Answer 1

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.