GNU bug report logs - #43627
[PATCH core-updates]: Add a 'append-separator?' field to the <search-path-specification> record.

Previous Next

Package: guix-patches;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Sat, 26 Sep 2020 06:10:02 UTC

Severity: normal

Tags: patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43627 <at> debbugs.gnu.org
Subject: Re: [bug#43627] [PATCH core-updates]: Add a 'append-separator?'
 field to the <search-path-specification> record.
Date: Sun, 08 Nov 2020 00:49:32 -0500
Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Maxim,
>
> Apologies for not following up earlier on this one…

No worries!

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>>> Hi,
>>>
>>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>>
>>>> These three commits extend our search-path-specification record with a
>>>> new field, that can be used to produce a trailing separator, which can
>>>> be useful at least with Emacs (I can think of at least another place
>>>> where it could be used: the INFOPATH variable).
>>>>
>>>> It was motivated to allow defining the Emacs search path in a more
>>>> robust way.
>>>
>>> I’m skeptical since we have only one (or two?) use cases.  I think we
>>> should weigh the added complexity, both in terms of implementation and
>>> of semantic clarity, compared to reduced complexity elsewhere.  It seems
>>> to me that the costs outweigh the benefits here.
>>
>> I too was skeptical at first (which explains why this commit was not
>> submitted for inclusion for 3 years :-)), but recent events surrounding
>> emacs-next and the bump to Emacs 27 have put its value back into light.
>
> Do you know if there are other use cases than Emacs for this?

The three environment variables that I know that make use of it in this
way are EMACSLOADPATH, INFOPATH and MANPATH.  There may be others, but
it's hard to search for that.

> I vaguely remember that ‘EMACSLOADPATH’ unusual handling of the empty
> entry is why we didn’t have it in ‘native-search-paths’ initially, and
> why Alex Kost had come up with a different mechanism instead.

I'm not sure what this was about, but if there was an issue with using
EMACSLOADPATH, I think we would have found out by now :-).

Thanks,

Maxim




This bug report was last modified 4 years ago.

Previous Next


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