bug#70577: [PATCH] New command other-project-prefix

[Dmitry Gutov]

On 14/05/2024 09:23, Juri Linkov wrote:
> > > > Speaking of the implementation strategy, though, I think the current
> > > > other-project-prefix implementation still doesn't work well together
> > > > with project-other-*-command.
> > > I suppose we could just blacklist some known prefix commands (*) in the
> > > same form where we now compare (eq this-command 'other-project-prefix),
> > > but it would be nice to distinguish prefix commands from "real" ones
> > > somehow.
> > > (*) project-other-window-command, project-other-frame-command,
> > > project-other-tab-command, some others?
> >
> > This can look like the attached.
> >
> > Though I suppose we would use some global registry, or symbol properties,
> > or etc.
> >
> > +(defvar other-project-prefix-transient-commands '(project-other-window-command
> > +                                                  project-other-frame-command
> > +                                                  project-other-tab-command
> > +                                                  other-window-prefix
> > +                                                  other-frame-prefix
> > +                                                  other-tab-prefix)
> > +  "List of commands that `other-project-prefix' does not apply to.
>
> This doesn't yet support such things as 'C-x 5 p p'?

I'm not sure that other-project-prefix can do that.

How does other-frame-prefix work? display-buffer-override-next-command 
sets up hooks in the very familiar fashion, so that the next command 
(and only the next command) is affected by a number of changed 
variables, which get restored after.

I suppose other-project-prefix could learn all the new variables it 
needs to "carry on", look up their values, and set them additionally for 
the next command. But that seems very ad-hoc.

It seems the "proper" way to fix that would be a cross-codebase change 
where all similar "prefix" commands themselves check whether the next 
command is a "prefix" command as well, and if so, keep the variables and 
hooks in place for the command after it. This would also mean moving the 
information from other-project-prefix-transient-commands to symbol 
properties (the alternative I've mentioned previously).