Subject: bug#78166: 30.1; describe-input-method does not respect help-window-select

From: Sean Devlin <[email-masked]>
Date: Sat, 24 May 2025 10:42:18 -0400

> On May 22, 2025, at 6:10 AM, Eli Zaretskii <[email-masked]> wrote:
> 
>> From: Sean Devlin <[email-masked]>
>> Date: Mon, 19 May 2025 12:41:00 -0400
>> Cc: [email-masked]
>> 
>> 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.

Sounds good. I’ll make an attempt in this direction.

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

Thanks, I’ll see how it goes and proceed from there.