Buffer name changed after :edit command

[Timothy Madden]

Hello

In some situation if I try to edit a file like with
:edit plugin/script.vim
I may end up with a buffer name like '../.vim/plugin/script.vim'

Note though two paths are equivalent, assuming the current directory is
named ".vim", still the buffer names are not the same in a literal sense.

This will happen when I already have the file opened (or listed) with
the long name (../.vim/plugin/script.vim), then I try to :edit it in a
different window with the short name.

In my script I would like to use :MkVimball command plugin from the
standard vimball plugin, and if I ran into this problem than MkVimball
will create for example a file like ../../src/vim/plugin/scriptname.vim
in the vimball archive. Even if the filename I pass to MkVimball really
is the right one, plugin/scriptname.vim.

For this to trigger, the MkVimball command should be seen from within a
:source'd script, and not directly from the command line. Anyway, I
think this should not happen (actually, I find this a bug in the
standard vimballPlugin, but that is another problem).

Is there a way to know if a file is already loaded/listed in a buffer,
with a modified path name like ../dir/script.vim instead of script.vim ?

Are there other cases where such a different path name may exist ?

Thank you,
Timothy Madden

[Tony Mechelynck]

Vim identifies files by their full path, but displays them (e.g. on the
statusline) by a shorter path if possible. If you have several windows
on a single buffer, but with different "local current directories", it
may happen that Vim can shorten the name in one window but not in the
other. However it should display all statuslines relative to what is the
current directory now: if you change windows, and the LCDs are
different, statuslines may change.

Normally any single file is opened in only one buffer, regardless of in
how many windows (zero or more) it is displayed. If you type

:ls

Vim will tell you which buffers are opened; add an exclamation mark if
you want to see also the so-called "unlisted" buffers. No file should
appear more than once in the list, even under different paths; if it
does, it is probably a bug.

Different paths may exist if there are soft or hard links: in the case
of soft links, IIUC Vim will resolve them and store the path after
resolving all the soft links; if there are hard links (different
directory entries, possibly in different directories, pointing to a
single data area on disk) it is not always obvious which path has
priority, and I don't know what Vim does. Hard links are a
well-documented feature of Unix-like systems; on Windows they exist
also, at least on NTFS filesystems, but the feature is poorly documented
if at all. On Unix the . and .. directory entries are implemented as
hard links; OTOH on DOS these entries were present as an exception to
the fact that on FAT filesystems, different paths pointing to the same
data cluster were a case of "crossed paths" error usually leading to
data corruption.


Best regards,
Tony.
--
ARTHUR: You fight with the strength of many men, Sir knight.
I am Arthur, King of the Britons. [pause]
I seek the finest and the bravest knights in the land to join me
in my Court of Camelot. [pause]
You have proved yourself worthy; will you join me? [pause]
You make me sad. So be it. Come, Patsy.
BLACK KNIGHT: None shall pass.
The Quest for the Holy Grail (Monty
Python)

[Timothy Madden]

I have the same file, the same directory, two windows with no local
directory, and the same file name in both (in other words, one buffer
with two windows).

The problem is the file name is ../.vim/plugin/script.vim, and I want to
open plugin/script.vim

Thank you,
Timothy Madden

[Timothy Madden]

On 09/16/2012 04:18 PM, Timothy Madden wrote:
> Hello
>
> In some situation if I try to edit a file like with
> :edit plugin/script.vim
> I may end up with a buffer name like '../.vim/plugin/script.vim'
>
> Note though two paths are equivalent, assuming the current directory is
> named ".vim", still the buffer names are not the same in a literal sense.
>
> This will happen when I already have the file opened (or listed) with
> the long name (../.vim/plugin/script.vim), then I try to :edit it in a
> different window with the short name.
>
> In my script I would like to use :MkVimball command plugin from the
> standard vimball plugin, and if I ran into this problem than MkVimball
> will create for example a file like ../../src/vim/plugin/scriptname.vim
> in the vimball archive. Even if the filename I pass to MkVimball really
> is the right one, plugin/scriptname.vim.

I find that Vim will modify the arguments so as to match existing
buffers or previous arguments. Thus

:args ../dir/script.vim script.vim

becomes:

:args
../dir/script.vim ../dir/script.vim

That is, the second argument is modified to match the first one. The
same thing happens on the command line, too.

Is there a way to prevent this ?

Thank you,
Timothy Madden

[Tony Mechelynck]

When I have a file opened in a window with the long name, and then I use
:sv or :new with the short name as argument, then both statuslines
display the short name from then on, howsoever I switch windows among
them. Example:

:pwd
/root/.mozilla/seamonkey/nexrdon9.default
:sv ../nexrdon9.default/chrome/userChrome.css
statusline says: ../nexrdon9.default/chrome/userChrome.css
:sv chrome/userChrome.css
_both_ statuslines say: chrome/userChrome.css
Ctrl-W p
both statuslines still say: chrome/userChrome.css

Similarly with
../../seamonkey/nexrdon9.default/chrome/userContent-example.css : as
soon as I supply the short name, _both_ windows for that file get (and
keep) the short name in their statusline.


What happens if you open the file in a window with the short name first,
and then pass expand('%') to MkVimball?


FWIW, I'm using gvim 7.3.661 (Huge) with GTK2-GNOME GUI.


Best regards,
Tony.
--
In Blythe, California, a city ordinance declares that a person must own
at least two cows before he can wear cowboy boots in public.

[Tony Mechelynck]

Which Vim version and patchlevel are you using? I think there was a fix
about that, but it was a long time ago.

Best regards,
Tony.
--
"You are old, father William," the young man said,
"And your hair has become very white;
And yet you incessantly stand on your head --
Do you think, at your age, it is right?"

"In my youth," father William replied to his son,
"I feared it might injure the brain;
But, now that I'm perfectly sure I have none,
Why, I do it again and again."
-- Lewis Carrol

[Timothy Madden]

> When I have a file opened in a window with the long name, and then I use
> :sv or :new with the short name as argument, then both statuslines
> display the short name from then on, howsoever I switch windows among
> them. Example:
>
> :pwd
> /root/.mozilla/seamonkey/nexrdon9.default
> :sv ../nexrdon9.default/chrome/userChrome.css
> statusline says: ../nexrdon9.default/chrome/userChrome.css
> :sv chrome/userChrome.css
> _both_ statuslines say: chrome/userChrome.css
> Ctrl-W p
> both statuslines still say: chrome/userChrome.css
>
> Similarly with
> ../../seamonkey/nexrdon9.default/chrome/userContent-example.css : as
> soon as I supply the short name, _both_ windows for that file get (and
> keep) the short name in their statusline.
>
>
> What happens if you open the file in a window with the short name first,
> and then pass expand('%') to MkVimball?
>
>
> FWIW, I'm using gvim 7.3.661 (Huge) with GTK2-GNOME GUI.

In my case (Vim 7.3.154, Huge version with GTK2 GUI, Slackware 13.37),
both windows display the original (long name).

A simple `:cd .` refreshes them both to use the short name, but not in a
script that is sourced or run with `vim -e` (not even with :redraw).

Is there way to check in advance that this would happen, so I can wipe
the damn buffer (and load if later) ?

About using expand('%'), Vimball documentation says the files should
always be relative (unless I intend to distribute some file like
/etc/opt/plugin-config) that is meant to be absolute).

Thank you,
Timothy Madden

[Tony Mechelynck]

Well, expand('%:.') then. But expand('%') (without :p) ought to be good
enough.


Patch 7.3.154 was released on 2 April 2011. I recommend that you upgrade.

See http://ftp.vim.org/pub/vim/patches/7.3/README for a one-line summary
of each patch to Vim 7.3.


If Slackware distributes no version of Vim later than 7.3.154, then see

http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

about how to compile your own Vim on Unix-like systems. (The former of
these web pages obsoletes the part of the latter about getting and
patching the source.)


Best regards,
Tony.
--
The Ruffed Pandanga of Borneo and Rotherham spreads out his feathers in
his courtship dance and imitates Winston Churchill and Tommy Cooper on
one leg. The padanga is dying out because the female padanga doesn't
take it too seriously.
-- Mike Harding, "The Armchair Anarchist's Almanac"

[Timothy Madden]

On 09/16/2012 10:48 PM, Tony Mechelynck wrote:
> On 16/09/12 21:14, Timothy Madden wrote:

[...]

>> About using expand('%'), Vimball documentation says the files should
>> always be relative (unless I intend to distribute some file like
>> /etc/opt/plugin-config) that is meant to be absolute).
>>
>> Thank you,
>> Timothy Madden
>>
>
> Well, expand('%:.') then. But expand('%') (without :p) ought to be good
> enough.
>
>
> Patch 7.3.154 was released on 2 April 2011. I recommend that you upgrade.
>
> See http://ftp.vim.org/pub/vim/patches/7.3/README for a one-line summary
> of each patch to Vim 7.3.
>
>
> If Slackware distributes no version of Vim later than 7.3.154, then see
>
> http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial
> http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
>
> about how to compile your own Vim on Unix-like systems. (The former of
> these web pages obsoletes the part of the latter about getting and
> patching the source.)

Slackware-current has a new version, and I am now running 7.3.645.
The behavior has been fixed in some cases, but not in others, so it did
not help me much.

bash-4.2$ vim -V1 -nNes -i NONE -c 'version | echo "" | qall!'

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 29 2012 16:49:50)
Included patches: 1-645
Compiled by <volk...@slackware.com>
Huge version without GUI. Features included (+) or not (-):
....

bash-4.2$ vim -V1 -nNes -i NONE -c 'args | echo "" | qall!' \
/home/adrian/.profile ../../.profile
"~/.profile"
"~/.profile" 16L, 376C
[/home/adrian/.profile] /home/adrian/.profile
bash-4.2$
bash-4.2$ vim -V1 -nNes -i NONE -c 'args | echo "" | qall!' \
../../.profile /home/adrian/.profile
"../../.profile"
"../../.profile" 16L, 376C
[../../.profile] ../../.profile


I believe this behavior is intentional, the help files do say the
arguments are added to the buffers list.

About expand(), it does return the relative file name as expected, but
the presence of an already opend buffer with the long ../../ name still
breaks MkVimball...

I believe all I can do in this case is to open each file as returned by
fnamemodify() (that is, expand()) and if the buffer name is not the
requested one, wipe it...

Thank you,
Timothy Madden