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

Previous Next

To reply to this bug, email your comments to 78166 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Devlin <spd <at> toadstyle.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; describe-input-method does not respect help-window-select
Date: Wed, 30 Apr 2025 16:29:42 -0400

Hi folks,

It seems that describe-input-method does not respect
help-window-select. Here is a recipe:

1. Emacs -Q
2. Evaluate:

(setq help-window-select t)

3. C-h I japanese RET

Observe that the help window is not selected.

In contrast, if you do C-h v help-window-select RET, the help window is
selected.

Thanks!

In GNU Emacs 30.1 (build 1, aarch64-apple-darwin21.6.0, NS
appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2025-02-24 built on
armbob.lan
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.5

Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'

Configured features:
ACL GLIB GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp
cl-print byte-opt gv bytecomp byte-compile thingatpt cl-extra help-fns
radix-tree japan-util kkc ja-dic-utl quail help-mode cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 63336 10444) (symbols 48 6466 0) (strings 32 19628 2196)
(string-bytes 1 470258) (vectors 16 12702)
(vector-slots 8 170578 7344) (floats 8 27 2) (intervals 56 267 20)
(buffers 992 14))

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

From: Sean Devlin <spd <at> toadstyle.org>
To: 78166 <at> debbugs.gnu.org
Subject: bug#78166: 30.1; describe-input-method does not respect
 help-window-select
Date: Wed, 30 Apr 2025 17:01:11 -0400

I see now that the documentation for help-window-select says:

This option has effect if and only if the help window was created
by ‘with-help-window’.

So maybe this is not a bug per se.

Should we improve quail-help to use with-help-window?

Thanks!

Message #11 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, 01 May 2025 20:45:14 +0300

> From: Sean Devlin <spd <at> toadstyle.org>
> Date: Wed, 30 Apr 2025 17:01:11 -0400
> 
> I see now that the documentation for help-window-select says:
> 
> This option has effect if and only if the help window was created
> by ‘with-help-window’.
> 
> So maybe this is not a bug per se.
> 
> Should we improve quail-help to use with-help-window?

Yes, if we want it to heed help-window-select, we should.

Patches welcome.  But please be careful and test the changes
thoroughly: AFAIR input-method help has several features thyat we
would not like to lose.

Thanks.

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

From: Sean Devlin <spd <at> toadstyle.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78166 <at> debbugs.gnu.org
Subject: Re: bug#78166: 30.1;
 describe-input-method does not respect help-window-select
Date: Thu, 1 May 2025 21:52:14 -0400

> On May 1, 2025, at 1:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> 
>> 
>> From: Sean Devlin <spd <at> toadstyle.org>
>> Date: Wed, 30 Apr 2025 17:01:11 -0400
>> 
>> I see now that the documentation for help-window-select says:
>> 
>> This option has effect if and only if the help window was created
>> by ‘with-help-window’.
>> 
>> So maybe this is not a bug per se.
>> 
>> Should we improve quail-help to use with-help-window?
> 
> Yes, if we want it to heed help-window-select, we should.
> 
> Patches welcome.  But please be careful and test the changes
> thoroughly: AFAIR input-method help has several features thyat we
> would not like to lose.

Sounds good. I will give it a try. I’ll mail back here if I run into problems.

Thanks!

> 
> Thanks.

Message #17 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: Sat, 17 May 2025 11:03:16 +0300

> From: Sean Devlin <spd <at> toadstyle.org>
> Date: Thu, 1 May 2025 21:52:14 -0400
> Cc: 78166 <at> debbugs.gnu.org
> 
> 
> 
> > On May 1, 2025, at 1:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> > 
> >> 
> >> From: Sean Devlin <spd <at> toadstyle.org>
> >> Date: Wed, 30 Apr 2025 17:01:11 -0400
> >> 
> >> I see now that the documentation for help-window-select says:
> >> 
> >> This option has effect if and only if the help window was created
> >> by ‘with-help-window’.
> >> 
> >> So maybe this is not a bug per se.
> >> 
> >> Should we improve quail-help to use with-help-window?
> > 
> > Yes, if we want it to heed help-window-select, we should.
> > 
> > Patches welcome.  But please be careful and test the changes
> > thoroughly: AFAIR input-method help has several features thyat we
> > would not like to lose.
> 
> Sounds good. I will give it a try. I’ll mail back here if I run into problems.

Did you have an opportunity to make some progress with this issue?

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

From: Sean Devlin <spd <at> toadstyle.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78166 <at> debbugs.gnu.org
Subject: Re: bug#78166: 30.1; describe-input-method does not respect
 help-window-select
Date: Mon, 19 May 2025 12:41:00 -0400

[Message part 1 (text/plain, inline)]

> On May 17, 2025, at 4:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Sean Devlin <spd <at> toadstyle.org>
>> Date: Thu, 1 May 2025 21:52:14 -0400
>> Cc: 78166 <at> debbugs.gnu.org
>> 
>> 
>> 
>>> On May 1, 2025, at 1:45 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> 
>>> 
>>>> 
>>>> From: Sean Devlin <spd <at> toadstyle.org>
>>>> Date: Wed, 30 Apr 2025 17:01:11 -0400
>>>> 
>>>> I see now that the documentation for help-window-select says:
>>>> 
>>>> This option has effect if and only if the help window was created
>>>> by ‘with-help-window’.
>>>> 
>>>> So maybe this is not a bug per se.
>>>> 
>>>> Should we improve quail-help to use with-help-window?
>>> 
>>> Yes, if we want it to heed help-window-select, we should.
>>> 
>>> Patches welcome.  But please be careful and test the changes
>>> thoroughly: AFAIR input-method help has several features thyat we
>>> would not like to lose.
>> 
>> Sounds good. I will give it a try. I’ll mail back here if I run into problems.
> 
> Did you have an opportunity to make some progress with this issue?

Hi Eli,

I did look at this bit, but I think I need some advice on how best to proceed.

I also found a couple other bugs in this code, which I’ll describe below.

As the code stands today, We have the command describe-input-method and its subroutine describe-current-input-method. These functions do some basic setup (e.g. binding help-buffer-under-preparation and calling help-setup-xref), but they delegate the main work to a funcall to describe-current-input-method-function.

The variable describe-current-input-method-function is set by the input method. For example, the function quail-activate sets this to quail-help, so all quail-derived input methods share a common implementation. There are a few other implementations in the Emacs source in hangul.el, robin.el, and uni-input.el. It seems possible there could be third-party packages defining input methods that provide yet more implementations for describe-current-input-method-function, but I haven’t checked.

Since these implementations are all invoked by the common wrapper code in describe-input-method, it seems like it would be good if that function could handle more of the common setup, e.g. by wrapping the funcall to describe-current-input-method-function in a with-help-window stanza. This way, all implementations of that subroutine would benefit, i.e. help-window-select would work correctly for all of them.

The drawback is that this could be a breaking change. Any work the describe-current-input-method-function implementations are doing to set up the help window would become redundant, and it could cause bugs. Obviously, we can fix the implementations that are in-tree, but I’m not sure how it would affect third-party packages.

I think I see three possible approaches we could take:

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

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:

Emacs -Q
Invoke a couple help commands, e.g.
C-h k C-h k
C-h k C-h c
Check that you can use l and r to go back and forwards between the two buffers
In the scratch buffer, C-\ japanese RET
Mouse-3 on the mode line indicator for the input method
In the help buffer, use l and r and see that it doesn’t work correctly:
Pressing l will skip back to the first help buffer
Pressing r will then bring you back to the second help buffer
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?

Thanks!

[Message part 2 (text/html, inline)]

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.

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

From: Sean Devlin <spd <at> toadstyle.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78166 <at> debbugs.gnu.org
Subject: Re: bug#78166: 30.1; describe-input-method does not respect
 help-window-select
Date: Sat, 24 May 2025 10:42:18 -0400

> On May 22, 2025, at 6:10 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> 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.

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.

Previous Next

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