resolve() on Windows breaking change
40 views
Skip to first unread message
Mike Williams
Jun 4, 2019, 1:00:56 PM6/4/19
to vim_dev
Hi,
It looks like the change to Windows for resolve() in 8.1.1417 was a
breaking change. I use the NERDtree plugin and any build after than
change results in NERDtree reports plain files on Windows as links. See
attached image.
I guess the question is. is this wrong in VIM or a bad assumption in
NERDtree in what resolve() returns? Since it is a breaking change in
VIM I thought I would start the ball rolling here.
TTFN
Mike
--
The search for happiness is one of the chief sources of unhappiness.
[Break through to drupa 2020 - find out more]<https://blog.globalgraphics.com/breakthrough-to-drupa/>
It looks like the change to Windows for resolve() in 8.1.1417 was a
breaking change. I use the NERDtree plugin and any build after than
change results in NERDtree reports plain files on Windows as links. See
attached image.
I guess the question is. is this wrong in VIM or a bad assumption in
NERDtree in what resolve() returns? Since it is a breaking change in
VIM I thought I would start the ball rolling here.
TTFN
Mike
--
The search for happiness is one of the chief sources of unhappiness.
[Break through to drupa 2020 - find out more]<https://blog.globalgraphics.com/breakthrough-to-drupa/>
Bram Moolenaar
Jun 4, 2019, 2:18:54 PM6/4/19
to vim...@googlegroups.com, Mike Williams
Mike Williams wrote:
> It looks like the change to Windows for resolve() in 8.1.1417 was a
> breaking change. I use the NERDtree plugin and any build after than
> change results in NERDtree reports plain files on Windows as links. See
> attached image.
>
> I guess the question is. is this wrong in VIM or a bad assumption in
> NERDtree in what resolve() returns? Since it is a breaking change in
> VIM I thought I would start the ball rolling here.
Assuming you still have the older Vim version, compare the output of
resolve() for some simple files, is it different?
The docs say:
On MS-Windows, when {filename} is a shortcut (a .lnk file),
returns the path the shortcut points to in a simplified form.
When {filename} is a symbolic link or junction point, return
the full path to the target. If the target of junction is
removed, return {filename}.
It says some more about a simplified result. But that wasn't changed.
--
From "know your smileys":
<>:-) Bishop
/// 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 ///
Mike Williams
Jun 4, 2019, 4:25:13 PM6/4/19
to Bram Moolenaar, vim...@googlegroups.com
On 04/06/2019 19:18, Bram Moolenaar wrote:
>
> Mike Williams wrote:
>
>> It looks like the change to Windows for resolve() in 8.1.1417 was a
>> breaking change. I use the NERDtree plugin and any build after than
>> change results in NERDtree reports plain files on Windows as links. See
>> attached image.
>>
>> I guess the question is. is this wrong in VIM or a bad assumption in
>> NERDtree in what resolve() returns? Since it is a breaking change in
>> VIM I thought I would start the ball rolling here.
>
> Perhaps NERDtree checks if the returned path is a full path?
> Assuming you still have the older Vim version, compare the output of
> resolve() for some simple files, is it different?
It is different. 8.1.1416 does not return a full path for simple files
>
> Mike Williams wrote:
>
>> It looks like the change to Windows for resolve() in 8.1.1417 was a
>> breaking change. I use the NERDtree plugin and any build after than
>> change results in NERDtree reports plain files on Windows as links. See
>> attached image.
>>
>> I guess the question is. is this wrong in VIM or a bad assumption in
>> NERDtree in what resolve() returns? Since it is a breaking change in
>> VIM I thought I would start the ball rolling here.
>
> Perhaps NERDtree checks if the returned path is a full path?
> Assuming you still have the older Vim version, compare the output of
> resolve() for some simple files, is it different?
while 8.1.1417 onwards does.
> The docs say:
> On MS-Windows, when {filename} is a shortcut (a .lnk file),
> returns the path the shortcut points to in a simplified form.
> When {filename} is a symbolic link or junction point, return
> the full path to the target. If the target of junction is
> removed, return {filename}.
>
> It says some more about a simplified result. But that wasn't changed.
between a simple file and a symbolic link or junction point, getftype()
does not help on Windows. But perhaps that does not matter.
Spelunking in NERDtree the root cause of the problem is directory
separators. It seems a bit free in always using '/' when building
paths. Now that resolve() returns a full path filepath checks based on
string comparison fails. A local hack^wfix confirms this but NERDtree
is still able to detect symbolic links so there must some other method
to distinguish that I am not aware of.
I'll bounce over to GitHub to report this.
TTFN
Mike
--
Never use a long word when a diminutive one will do.
Ken Takata
Jun 5, 2019, 6:56:35 AM6/5/19
to vim_dev
Mike Williams
Jun 6, 2019, 6:31:37 AM6/6/19
to vim...@googlegroups.com
Hi Ken
Many thanks for this. Bonus points for extending getftype() to work
under Windows for consistency with what resolve() returns ;-)
TTFN
Mike
--
If nodding means yes, why doesn't yesding mean no?
under Windows for consistency with what resolve() returns ;-)
TTFN
Mike
--
If nodding means yes, why doesn't yesding mean no?
Reply all
Reply to author
Forward
0 new messages