GNU bug report logs - #79026
30.1; TAB in Minibuffer when using a quail input-method should complete the longest common suffix of candidates

Previous Next

Package: emacs;

Reported by: Cass Alexandru <g.cassian.alexandru <at> posteo.eu>

Date: Tue, 15 Jul 2025 12:30:02 UTC

Severity: wishlist

Found in version 30.1

Full log


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

From: Visuwesh <visuweshm <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: arash <at> gnu.org, 79026 <at> debbugs.gnu.org, g.cassian.alexandru <at> posteo.eu,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79026: 30.1; TAB in Minibuffer when using a quail
 input-method should complete the longest common suffix of candidates
Date: Thu, 17 Jul 2025 18:29:33 +0530
[வியாழன் ஜூலை 17, 2025] Eli Zaretskii wrote:

>> From: Visuwesh <visuweshm <at> gmail.com>
>> Cc: arash <at> gnu.org,  g.cassian.alexandru <at> posteo.eu,  79026 <at> debbugs.gnu.org,
>>   monnier <at> iro.umontreal.ca
>> Date: Thu, 17 Jul 2025 13:16:54 +0530
>> 
>> [வியாழன் ஜூலை 17, 2025] Eli Zaretskii wrote:
>> 
>> > IOW, the request here is to make quail-completion work as minibuffer
>> > completion works elsewhere.  If you can come up with a patch to do
>> > that (probably optionally, given how quail-completion's original
>> > behavior was very different), that'd be appreciated.
>> 
>> If there is only one translation for the current key, it should just
>> insert it?  I.e., typing TAB after \alph should insert α.
>> 
>> If there is more than one, it should complete to the longest possible
>> common key i.e., typing TAB after \app should complete to \approx and
>> the Quail loop would be active.  Another TAB from here on would pop up
>> the *Quail Completions* buffer?
>
> Yes, I think so.
>
>> Did I get it right?  I wonder if we can reuse the completion facility
>> for this.
>
> That's the question, yes.

OK, I will see if I can achieve the desired behaviour.

For now, can someone confirm if the double-insertion bug in
quail-mouse-choose-completion is fixed with the patch at the end?  It
seems that setting _both_ quail-current-str and choose-completion leads
to the double insertion.  The code was last changed in

    commit 35fffde1df8d896c964b6d3b42fff70f4dd1c49b
    Author: Dave Love <fx <at> gnu.org>
    Date:   Sat Dec 15 16:40:33 2001 +0000

        (quail-keyboard-layout-alist): Add
        pc105-uk.
        (quail-keyboard-layout-type): Fix :type.
        (quail-choose-completion-string): Simplify.
        (quail-update-leim-list-file): Don't get fooled by commented-out
        code.
        (quail-input-string-to-events): Run events through
        translation-table-for-input.

where the extra choose-completion-string seems to have added.  Before,
the comment in quail-choose-completion-string said:

      ;; Store the completion in `quail-current-str', which will later
      ;; be converted to a character event list, then inserted into
      ;; the buffer where completion was requested.

and only quail-current-str was set, so I wonder if the call to
choose-completion-string is necessary.

Here's the promised patch:

diff --git a/lisp/international/quail.el b/lisp/international/quail.el
index 2b66a0bc0f7..e6fcc2b0cb8 100644
--- a/lisp/international/quail.el
+++ b/lisp/international/quail.el
@@ -2316,10 +2316,6 @@ quail-mouse-choose-completion
     ;;   (select-window owindow))
     (quail-delete-region)
     (setq quail-current-str choice)
-    ;; FIXME: We need to pass `base-position' here.
-    ;; FIXME: why do we need choose-completion-string with all its
-    ;; completion-specific logic?
-    (choose-completion-string choice buffer)
     (quail-terminate-translation)))
 
 (defun quail-build-decode-map (map-list key decode-map num




This bug report was last modified 4 days ago.

Previous Next


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