GNU bug report logs - #21104
25.0.50; relative paths are added to load-path without -nsl

Previous Next

Package: emacs;

Reported by: sds <at> gnu.org

Date: Tue, 21 Jul 2015 17:27:01 UTC

Severity: normal

Merged with 21353

Found in version 25.0.50

Done: Anders Lindgren <andlind <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #71 received at 21104 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Andreas Schwab <schwab <at> suse.de>, Eli Zaretskii <eliz <at> gnu.org>,
 Keith David Bershatsky <esq <at> lawlist.com>, 21104 <at> debbugs.gnu.org
Subject: Re: bug#21104: 25.0.50;
 relative paths are added to load-path without -nsl (bug#21104)
Date: Tue, 08 Dec 2015 14:21:20 -0500
Anders Lindgren wrote:

> Yes, this works.
>
>
> However, I think it's a better solution to correct `decode_env_path' so
> that it returns nil when the string is empty and the `empty' parameter is 1.

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.

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




This bug report was last modified 9 years and 164 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.