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

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 63648 <at> debbugs.gnu.org, sbaugh <at> catern.com
Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands
Date: Fri, 27 Oct 2023 09:50:35 +0300

>>> +         ;; Variation: could be a separate command, or an option.
>>> +         ;; (command (let ((overriding-local-map project-prefix-map))
>>> +         ;;            (key-binding (read-key-sequence
>>> +         ;;                          (format "[execute in %s]:" (project-root pr)))
>>> +         ;;                         t)))
>> Thanks, it works nicely.
>> Any reason not to use this by default?
>
> Nothing critical, but it might not fit the expectations without additional
> instructions in the prompt, or it can be unnecessary if the user had
> reached this command through 'C-x p o'.

Indeed, this is needed only for 'C-x p p' that supports the global map.

> In the latter case there is also a small chance that the user had set up
> some advanced sub-maps inside project-prefix-map which would shadow some
> global bindings. So maybe a separate command is best. Please see how you
> like the attached new version together with
>
>   (setq project-switch-commands #'project-prefix-or-any-command)

A separate command that is not used anywhere looks strange.
Why not a simple option like 'project-switch-use-entire-map'?

> I'm not sure about project-prefix-or-any-command's prompt, though (phrasing
> feels awkward). Improvements welcome.

I'm not a fan of the long prompt especially that wraps to the second line.

> BTW, let me know if you prefer the "prefix command" style from your last
> patch for this command. My main sticking point with it was the change of
> logic used to indicate a different project root, but it can just as well be
> transplanted there. So if the prefix command approach is better for some
> scenarios, we can switch to it.

Also I'm not a fan of ad-hoc reimplementation of the command loop
with read-key-sequence and call-interactively.  In my last patch
this is avoided by using post-command-hook and set-transient-map.
OTOH, since migrating from the former to the latter makes code
more complicated, I'm fine with dropping my last patch as long as
the former still can do everything that was supported by the latter.

Previous Next

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