bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-proje


From: Juri Linkov
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]