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

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
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: Mon, 02 Nov 2020 14:59:14 +0100

Hi Maxim,

Apologies for not following up earlier on this one…

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?

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.

Thanks,
Ludo’.

Previous Next

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