Hi,

On Tue, Dec 8, 2015 at 8:21 PM, Glenn Morris <rgm@gnu.org> wrote:

> I think you've jumped outside the scope of this report.
> I would suggest just going with the simple solution, absent evidence of
> some other problem.
>

I have attached a simple solution that solves this specific problem. I'll
push it if it looks like an OK solution for you.


> Also, I haven't investigated the cases where there is nothing between path
> > separators, as in "foo::bar" (or when the string starts or ends with a
> > separator). Today, it looks like it returns either `("foo" "." "bar)' or
> > `("foo" nil "bar")' -- although I haven't verified this. A better
> solution
> > would be to simply return `("foo" "bar")' -- path separators without
> > anything in between are often simply a user mistake, we don't want to
> > pollute system variables like `load-path' because of them.
>
> The feature is intentional, see 17e0445be4a.
>
> I won't claim it's perfect, but IIRC I did test such things at the time.
>

Apparently, there is more to the code than I initially understood. I agree
with you, I no longer think we should change anything here on the short
term.

However, I think it behaves strange:

For example (on a Linux machine):
    env EMACSPATH=::/home::/bar:: emacs -q --batch --eval '(print
exec-path)'
   ("/usr/lib/lightdm/lightdm" "/usr/local/sbin" "/usr/local/bin"
"/use/sbin" "/usr/bin" "/sbin" "/bin" "/usr/games" "." "." "/home" "." "."
"/bar" "." ".")

Here, I don't think the ".":s should be included.

Another example (again on Linux):
    env EMACSLOADPATH=::/home::/bar:: emacs -q --batch --eval '(print
load-path)'
    The result is too long to print, as it duplicates the standard load
path five times.

Here, wouldn't it suffice to add the default load path once?

    -- Anders