I always set $HOME as 'c:/docume~1/mattn' to avoid strange behavior of unix like tools on windows. But it make a bug that fnamemodify(expand('~/vimfiles'), ':p:8') don't return '~/vimfiles'. About argument 'src' in home_replace, it will be passed as full path. So homedir_env should be converted full path before comparing.
Yasuhiro Matsumoto wrote: > I always set $HOME as 'c:/docume~1/mattn' to avoid strange behavior of > unix like tools on windows. > But it make a bug that fnamemodify(expand('~/vimfiles'), ':p:8') don't > return '~/vimfiles'. > About argument 'src' in home_replace, it will be passed as full path. So homedir_env should be converted full path before comparing.
Yasuhiro Matsumoto wrote: > I always set $HOME as 'c:/docume~1/mattn' to avoid strange behavior of unix like tools on windows. > But it make a bug that fnamemodify(expand('~/vimfiles'), ':p:8') don't return '~/vimfiles'. > About argument 'src' in home_replace, it will be passed as full path. So homedir_env should be converted full path before comparing.
Why use the GetLongPathName function? It's not used anywhere in Vim. Can we use vim_FullName() with the force argument set to TRUE?
I suppose this is only needed for MS-Windows. Since expanding a path is expensive we might first check if the "~" character appears in the string.
-- ARTHUR: Listen, old crone! Unless you tell us where we can buy a shrubbery, my friend and I will ... we will say "Ni!" CRONE: Do your worst! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
On Friday, April 20, 2012 11:13:40 PM UTC+9, Bram Moolenaar wrote: > Why use the GetLongPathName function? It's not used anywhere in Vim. > Can we use vim_FullName() with the force argument set to TRUE?
> I suppose this is only needed for MS-Windows. Since expanding a path is > expensive we might first check if the "~" character appears in the > string.
Yasuhiro Matsumoto wrote:
> On Friday, April 20, 2012 11:13:40 PM UTC+9, Bram Moolenaar wrote:
> > Why use the GetLongPathName function? It's not used anywhere in Vim.
> > Can we use vim_FullName() with the force argument set to TRUE?
> > I suppose this is only needed for MS-Windows. Since expanding a path is
> > expensive we might first check if the "~" character appears in the
> > string.
> You are right. Thanks.
I have not received an update patch yet. Are you still working on this?
-- Friends? I have lots of friends! In fact, I have all episodes ever made.
'c:/docume~1/mattn' is full path. And GetFullPathName don't expand short name. I had another issue even if my patch is included.
If user make Dictionary that has keys of loaded script filename, I guess the user hope to normalize filename, i.e. key of the dict. They will use ":scriptnames" show up messages. But it's relative names from ~/. And, <sfile> return full path (but not long path). Currently vim doesn't provide way to convert short filename to long filename. Then, it may duplicate entries.
On Saturday, May 19, 2012 12:03:31 AM UTC+9, Bram Moolenaar wrote: > Yasuhiro Matsumoto wrote:
> > On Friday, April 20, 2012 11:13:40 PM UTC+9, Bram Moolenaar wrote: > > > Why use the GetLongPathName function? It's not used anywhere in Vim. > > > Can we use vim_FullName() with the force argument set to TRUE?
> > > I suppose this is only needed for MS-Windows. Since expanding a path is > > > expensive we might first check if the "~" character appears in the > > > string.
> > You are right. Thanks.
> I have not received an update patch yet. Are you still working on this?
> -- > Friends? I have lots of friends! In fact, I have all episodes ever made.
Yasuhiro Matsumoto wrote:
> I'm working this but I can't get solved yet.
> vim_FullName can't get original filename.
> 'c:/docume~1/mattn' is full path. And GetFullPathName don't expand short name.
> I had another issue even if my patch is included.
> If user make Dictionary that has keys of loaded script filename, I
> guess the user hope to normalize filename, i.e. key of the dict. They
> will use ":scriptnames" show up messages. But it's relative names from
> ~/. And, <sfile> return full path (but not long path). Currently vim
> doesn't provide way to convert short filename to long filename. Then,
> it may duplicate entries.
> I'm finding way to fix this problem.
I see. The intention of vim_FullName() is that the result is a file
name that can be compared. Since we don't want it to return 8.3 names,
it should expand 8.3 names into their long name. That avoids editing a
file once by its short name and once by its long name ends up with two
buffers for the wrong file, we don't want that.
There could be a separate function to short filenames to their 8.3 form,
although it's for a very limited audience and only works on some file
systems. Thus I would not encourage using that.
-- FIRST VILLAGER: We have found a witch. May we burn her?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
On Monday, May 21, 2012 1:50:15 AM UTC+9, Bram Moolenaar wrote: > Yasuhiro Matsumoto wrote:
> > I'm working this but I can't get solved yet.
> > vim_FullName can't get original filename.
> > 'c:/docume~1/mattn' is full path. And GetFullPathName don't expand short name. > > I had another issue even if my patch is included.
> > If user make Dictionary that has keys of loaded script filename, I > > guess the user hope to normalize filename, i.e. key of the dict. They > > will use ":scriptnames" show up messages. But it's relative names from > > ~/. And, <sfile> return full path (but not long path). Currently vim > > doesn't provide way to convert short filename to long filename. Then, > > it may duplicate entries.
> > I'm finding way to fix this problem.
> I see. The intention of vim_FullName() is that the result is a file > name that can be compared. Since we don't want it to return 8.3 names, > it should expand 8.3 names into their long name. That avoids editing a > file once by its short name and once by its long name ends up with two > buffers for the wrong file, we don't want that.
> There could be a separate function to short filenames to their 8.3 form, > although it's for a very limited audience and only works on some file > systems. Thus I would not encourage using that.
> -- > FIRST VILLAGER: We have found a witch. May we burn her? > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Yasuhiro Matsumoto wrote:
> What sign of modifier do you want against :8 ? :l ?
> Or new function?
Currently :p turns any path into a full path, so that when two names are
expanded with :p they can be compared to find out if they are equal.
Except for symlinks, that requires using resolve().
So we could change :p to also expand 8.3 names to their full name, and
add a new modifier that does not do that. How about :f, for Full name.
-- Never under any circumstances take a sleeping pill
and a laxative on the same night.
Bram Moolenaar wrote:
>> What sign of modifier do you want against :8 ? :l ?
>> Or new function?
> Currently :p turns any path into a full path, so that when
> two names are expanded with :p they can be compared to find
> out if they are equal.
> Except for symlinks, that requires using resolve().
> So we could change :p to also expand 8.3 names to their full
> name, and add a new modifier that does not do that. How
> about :f, for Full name.
Is that needed?
If :p (on Windows) always produced the expanded long name, then
:p:8 could be used if someone wanted the short full path.
I can't see a reason someone would need an 8.3 name expanded
to anything other than its full long path (with :p), or its
full short path (with :p:8).
At any rate, :f does not sound a good mnemonic for "short".
> I can't see a reason someone would need an 8.3 name expanded > to anything other than its full long path (with :p), or its > full short path (with :p:8).
What we want is full long path. Currentl, :p don't return long full long path.
> At any rate, :f does not sound a good mnemonic for "short".
If there is a problem, please spell it out as the above is
correct.
>> I can't see a reason someone would need an 8.3 name expanded to
>> anything other than its full long path (with :p), or its full short
>> path (with :p:8).
> What we want is full long path. Currentl, :p don't return
> long full long path.
That's why I said *if* :p always produced the expanded long
name, then :p:8 would be all that was needed to produce the
equivalent short name.
If :p produced the expanded long path, would there be a need for
any further changes? Why?
> If there is a problem, please spell it out as the above is correct.
I don't know how many bugs about short name in vim. I found a bug about home_replace() in the first, In next, I found fnamemodify().
home_replace() is used in :scriptnames, or fnamemodify(x, ':~') or etc.
Or do you mean "You should change subject of this thread" ?
> > What we want is full long path. Currentl, :p don't return > > long full long path.
> That's why I said *if* :p always produced the expanded long > name, then :p:8 would be all that was needed to produce the > equivalent short name.
We need long path, not short name. In some times, file name has an important thing about `What is this`. Short name break them. For example,
:let filename = s:get_vimrc_filename_from_somewhere() :if filename =~ '[/\][._]vimrc$' " is .vimrc or _vimrc ? : call s:do_something_about_vimrc() :endif
If `s:get_vimrc_filename_from_somewhere` return short path name(for example output from external program), We can't expand long path. Please try following.
Then, the code above don't pass into doing `s:do_something_about_vimrc`. And also, we can't know .vimrc become 'vimrc~1' or 'vimrc~2' or others in 8.3 format rules.
> If :p produced the expanded long path, would there be a need for > any further changes? Why?
I didn't answer for bram's question yet(About whether need to add new modifier or not).
I don't want to change behavior of :p. And I want to add new modifier to expand short name. We can call resolve() in manually, we can call fnamemodify() too.
It seems to me that the below example p:8 can only work if you know your path name only consists of one-node ???
What happens if your path name is "c:\lets have some fun\with silly mickey-soft windows"
-----Original Message-----
From: vim_dev@googlegroups.com [mailto:vim_dev@googlegroups.com] On Behalf Of John Beckett
Sent: Monday, May 21, 2012 8:24 PM
To: vim_dev@googlegroups.com
Subject: RE: home_replace() does not work with short path name on windows.
mattn wrote:
>> If :p (on Windows) always produced the expanded long name, then
>> :p:8 could be used if someone wanted the short full path.
If there is a problem, please spell it out as the above is correct.
>> I can't see a reason someone would need an 8.3 name expanded to >> anything other than its full long path (with :p), or its full short >> path (with :p:8).
> What we want is full long path. Currentl, :p don't return long full > long path.
That's why I said *if* :p always produced the expanded long name, then :p:8 would be all that was needed to produce the equivalent short name.
If :p produced the expanded long path, would there be a need for any further changes? Why?
John
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
John Beckett wrote:
> Bram Moolenaar wrote:
> >> What sign of modifier do you want against :8 ? :l ?
> >> Or new function?
> > Currently :p turns any path into a full path, so that when
> > two names are expanded with :p they can be compared to find
> > out if they are equal.
> > Except for symlinks, that requires using resolve().
> > So we could change :p to also expand 8.3 names to their full
> > name, and add a new modifier that does not do that. How
> > about :f, for Full name.
> Is that needed?
> If :p (on Windows) always produced the expanded long name, then
> :p:8 could be used if someone wanted the short full path.
> I can't see a reason someone would need an 8.3 name expanded
> to anything other than its full long path (with :p), or its
> full short path (with :p:8).
> At any rate, :f does not sound a good mnemonic for "short".
True, you can use :p:8 in nearly all cases where you would use the new
:f modifier. Can't really think of a situation where one would want to
keep existing 8.3 names but not change long names to 8.3 names.
So we can just change :p to expand 8.3 names to their long name and
that's it.
-- If the Universe is constantly expanding, why can't I ever find a parking space?
I wonder whether we should change :p behavior. I'm thinking there are some cases to use "8.3". For example, 8.3 don't have spaces in the path. So it's useful to avoid any bugs when executing external program. I applied this patch above, But some vim plugins occur error. That beleave fnamemodify(tempname(), ':p') dont contains any spaces.
> I wonder whether we should change :p behavior. I'm thinking there are
> some cases to use "8.3". For example, 8.3 don't have spaces in the
> path. So it's useful to avoid any bugs when executing external
> program.
> I applied this patch above, But some vim plugins occur error. That
> beleave fnamemodify(tempname(), ':p') dont contains any spaces.
Well, I think plugins should be able to handle file names with spaces,
as they occur quite frequently on MS-Windows.
When I look at the documentation for GetLongPathName it mentions
restrictions when using the ANSI version. We have the usual problems
with 'encoding', thus we should use the wide version GetLongPathNameW
when possible, with the encoding conversion when needed.
Putting the function in os_win32.c would be appropriate, using
GetFullPathNameW() is also there.
> This is new modifier ":f". User can manually handing "8.3" path names.
> If you allow this, I'll add patch for doc.
We discussed this previously. I think it's simpler to use :p to get the
full path and when someone needs the 8.3 name use :8 after that. No
need for a new modifier.
-- hundred-and-one symptoms of being an internet addict:
13. You refer to going to the bathroom as downloading.
> We discussed this previously. I think it's simpler to use :p to get the > full path and when someone needs the 8.3 name use :8 after that. No > need for a new modifier.
