GNU bug report logs - #63648
29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands

Previous Next

Full log

Message #331 received at 63648-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63648-done <at> debbugs.gnu.org,
 sbaugh <at> catern.com
Subject: Re: bug#63648: 29.0.90; project.el: with switch-use-entire-map,
 switch-project errors on non-project commands
Date: Tue, 7 Nov 2023 00:49:49 +0200

On 06/11/2023 09:16, Juri Linkov wrote:
>>> I proposed a new option project-switch-use-global-map.
>>
>> I didn't know how the reconcile the existence of both
>> project-switch-use-entire-map and project-switch-use-global-map. Saying in
>> both docstrings that one takes priority over the other (and possibly
>> repeating that in the doc for project-switch-commands) would be awkward.
> 
> Then another variant would be to allow a new value 'global'
> in the existing 'project-switch-use-entire-map'.

Ah indeed. That could also look sensible.

>>> But when project-switch-commands should be customized instead of new option,
>>> then I'd prefer to use function names like `project-prefix-or-any-command'
>>> instead of symbols `short-or-any' and `short-keys'.
>>>
>>>> Unifying all three alternatives in one option seems like the logical choice.
>>> To avoid obsoleting `project-switch-use-entire-map', `short-keys'
>>> could be removed.  Then `short-or-any' could be replaced by
>>> `project-prefix-or-any-command'.  This will introduce minimal changes.
>>
>> All right, that sounds like a mix between v4 and v5.
>>
>> I've pushed 41e801fea1c to master, please take a look.
> 
> Thanks, I tested and it works great.
> 
>> In the future, perhaps we'd want to obsolete the option
>> project-switch-use-entire-map anyway, replacing it with a separate command
>> to be used in the same way as the newly-added one.  But for now the change
>> is maximally backward-compatible.
> 
> Indeed, this is the safest change for now.  More changes either will
> bring trouble to users requiring to migrate from the obsolete variable,
> or will make code more complicated.

I guess it's time to close this bug? Thank you all for participation, 
and thanks for testing.

Previous Next

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