home_replace() does not work with short path name on windows.

[mattn]

Hi.

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.

https://gist.github.com/2412113

Please check and include.

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

Thanks, I'll check it out later.

--
The early bird gets the worm. If you want something else for
breakfast, get up later.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Bram Moolenaar]

Yasuhiro Matsumoto 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.

--
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

[mattn]

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.

[Bram Moolenaar]

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.

[mattn]

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.

[Bram Moolenaar]

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

[mattn]

What sign of modifier do you want against :8 ? :l ?
Or new function?

[Bram Moolenaar]

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.

[John Beckett]

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".

John

[mattn]

> If :p (on Windows) always produced the expanded long name, then
> :p:8 could be used if someone wanted the short full path.

No.

:echo fnamemodify('C:\Program Files', ':8:p')
C:\PROGRA~1

> 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".

Do you prefer :9 or :) ?

[John Beckett]

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.
>
> No.
>
> :echo fnamemodify('C:\Program Files', ':8:p')
> C:\PROGRA~1

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

[mattn]

> 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.

:let shortname = fnamemodify('~/.vimrc', ':p:8')
:echo shortname
c:/docume~1/mattn/VIMRC~1

:echo fnamemodify(shortname, ':p')
c:/docume~1/mattn/VIMRC~1

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.

Bram, how do you think?

[Bovy, Stephen]

There must be some assumptions here

Or I am missing some context

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"

--
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

[Bram Moolenaar]

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?

[mattn]

> So we can just change :p to expand 8.3 names to their long name and
> that's it.

Sorry for delay.

https://gist.github.com/2832022

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.

So I suggest one more another patch.

https://gist.github.com/2831996

This is new modifier ":f". User can manually handing "8.3" path names.
If you allow this, I'll add patch for doc.

Thanks.

[Bram Moolenaar]

Yasuhiro Matsumoto wrote:

> > So we can just change :p to expand 8.3 names to their long name and
> > that's it.
>
> Sorry for delay.
>
> https://gist.github.com/2832022
>
> 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.

> So I suggest one more another patch.
>
> https://gist.github.com/2831996
>
> 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.

[mattn]

> 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.

I updated patch.

https://gist.github.com/2936050

Previous were broken memory.