bug#57102: 29.0.50; Peculiar file-name-split edge case

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (file-name-split "/a/b")
>> => '("a" "b")
>
> This should return '("/" "a" "b"), or '("/a" "b")  I think.
>
>> (file-name-split "//a////b////")
>> => '("a" "b")
>
> And this should return '("/" "a" "b" "/"), or '("/a" "b/").
>
>> I'm not sure what
>> 
>> (file-name-split "c:/a/b")
>> 
>> on Windows should return in that case, though.
>
> If you agree with the above, then '("c:/" "a" "b").
>
> If you don't care about the root directory, then '("a" "b")
> (a.k.a. "leave the interpretation to the caller").

I'm not at all sure, and perhaps we should have two different functions
here for the two different use cases that I think this function has.

The use cases, as I see it, are

1) "I just want to know which bits are in the path".  This is used by
dabbrev, which wants to add "a" and "b" here to the abbrevs.  In that
case, "c:/" is not what it wants.

2) "I need to perform some operation on each segment and then put the
file name back together again".  This is what browse-url does -- it
wants to %-encode each segment, but not the "/"s, so it wants to
preserve the absolute/relative distinction.  (But it needs to know that
the "c:/" part is not something to be encoded anyway.)  In that case, I
think we want '("/" "a" "b") and '("c:/" "a" "b").

So perhaps file-name-split should keep the current semantics (but the
bugs identified should be fixed) for 2), but we could add a new function
(or optional parameter) for 1) which would leave "/"/"c:/" off.