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

[Dmitry Gutov <dmitry@gutov.dev>]

On 27/10/2023 09:50, Juri Linkov wrote:
>>>> +         ;; 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'?

You would still need to change project-switch-commands, right? Or what 
would the option be called?

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

It didn't wrap for me. But if it's too long, how would you like it 
changed? Remove everything? Just keep [executing in ...]?

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

It shouldn't be hard to migrate in either direction, as long as the 
logic to choose which variable to modify is the same. This approach 
(with read-key-sequence, etc) looks a little shorter, but if any 
problems crop up, this is changeable.