GNU bug report logs - #78166
30.1; describe-input-method does not respect help-window-select

Previous Next

Full log

Message #23 received at 78166 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Devlin <spd <at> toadstyle.org>
Cc: 78166 <at> debbugs.gnu.org
Subject: Re: bug#78166: 30.1; describe-input-method does not respect
 help-window-select
Date: Thu, 22 May 2025 13:10:47 +0300

> From: Sean Devlin <spd <at> toadstyle.org>
> Date: Mon, 19 May 2025 12:41:00 -0400
> Cc: 78166 <at> debbugs.gnu.org
> 
> I think I see three possible approaches we could take:
> 
> 1 As described above, set up the help window using with-help-window in the describe-input-method
>  command and remove any help window setup from the subroutines. This could cause issues for
>  downstream packages.
> 2 Instead, we could make a fix directly in quail-help. This would work, but it wouldn’t benefit other
>  implementations of describe-current-input-method-function.
> 3 We could introduce an alternative to describe-current-input-method-function and call it when it is non-nil.
>  Otherwise, we would continue to call describe-current-input-method-function.
> 
> To expand on the third item, suppose we introduced a new variable called (for example)
> describe-input-method-body-function. It would be responsible for generating the body of the help buffer, but
> not for the basic setup of the help buffer or window.
> 
> In describe-input-method, we’d have some code like the following (simplified):
> 
> (cond
>  ((and (symbolp describe-input-method-body-function)
>        (fboundp describe-input-method-body-function))
>   (with-help-window (help-buffer)
>     (funcall describe-input-method-body-function)))
>  ((and (symbolp describe-current-input-method-function)
>        (fboundp describe-current-input-method-function))
>   (funcall describe-current-input-method-function))
>  (t …))
> 
> This way, we could preserve the existing behavior for third-party packages while also making the help
> window setup more uniform for in-tree implementations (and for any third-party packages that choose to
> adopt the new variable).
> 
> Any advice on which approach to take would be greatly appreciated!

I think I'd prefer #2.

> As to the bugs I mentioned above, they are mainly around the management of help-setup-xref. If
> describe-current-input-method is invoked directly (instead of as a subroutine of describe-input-method), help
> xrefs will not be set up at all.
> 
> To reproduce:
> 
> 1 Emacs -Q
> 2 Invoke a couple help commands, e.g.
> 
> 1 C-h k C-h k
> 2 C-h k C-h c
> 
> 3 Check that you can use l and r to go back and forwards between the two buffers
> 4 In the scratch buffer, C-\ japanese RET
> 5 Mouse-3 on the mode line indicator for the input method
> 6 In the help buffer, use l and r and see that it doesn’t work correctly:
> 
> 1 Pressing l will skip back to the first help buffer
> 2 Pressing r will then bring you back to the second help buffer
> 3 The input method help buffer is not on the stack at all, so you cannot retrieve it by any combination of l or
>  r inputs
> 
> There is a related bug in the error-handling path of describe-input-method where the help xrefs are set up
> twice, but I’m not sure of a good way to trigger this path.
> 
> Should I file a separate bug for these, or just roll a fix into this change?

It depends: if the fix can be naturally included in the modifications
for quail-help, it should be okay to do it together.  Otherwise,
please submit a separate bug report, and we can take it from there.

Thanks.

Previous Next

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