GNU bug report logs - #70577
[PATCH] New command other-project-prefix

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: 70577 <at> debbugs.gnu.org
Subject: bug#70577: [PATCH] New command other-project-prefix
Date: Tue, 14 May 2024 23:02:51 +0300

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

Previous Next

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