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 ?
> 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
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)
> On 16/09/12 15:18, 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.
>> 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
> 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.
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
> 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.
> On 09/16/2012 07:34 PM, Tony Mechelynck wrote:
>> On 16/09/12 15:18, 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.
>>> 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
>> 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.
> 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
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.
> 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
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
> 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).
>> 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
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.
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"
> 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.
> 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.
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 29 2012 16:49:50)
Included patches: 1-645
Compiled by <volke...@slackware.com>
Huge version without GUI. Features included (+) or not (-):
....
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...
