bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

[Knut Anders Hatlen]

With emacs -Q:

(icomplete-mode 1)
(setopt completion-auto-select t)
C-x C-f TAB TAB

The following error message is displayed in the minibuffer:

Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument integer-or-marker-p nil)


In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0)
 of 2022-05-29 built on dell
Repository revision: aa955dc569b361771e4d2b3b1d7b90c1ceea8b6a
Repository branch: master
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure --with-json --with-xml2 --with-modules
 --prefix=/usr/local/stow/emacs-master --with-pgtk --without-x
 CC=gcc-12'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3
ZLIB

Important settings:
  value of $LANG: nn_NO.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  icomplete-mode: t
  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
  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 rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils cus-edit pp cus-start cus-load wid-edit icomplete cl-loaddefs
cl-lib term/xterm xterm gv subr-x byte-opt bytecomp byte-compile cconv
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win 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
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 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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 73863 6888)
 (symbols 48 7496 2)
 (strings 32 19656 1982)
 (string-bytes 1 597351)
 (vectors 16 10036)
 (vector-slots 8 119240 6882)
 (floats 8 34 23)
 (intervals 56 1281 68)
 (buffers 992 12))

-- 
Knut Anders

bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

[Juri Linkov]

> (icomplete-mode 1)
> (setopt completion-auto-select t)
> C-x C-f TAB TAB
>
> The following error message is displayed in the minibuffer:
>
> Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument integer-or-marker-p nil)

I confirm the problem, I have seen it a few times, but
it seems the root of the problem is in the way how buffer-local
hooks are fired.  icomplete-post-command-hook is a hook
local in the minibuffer.  But when the command switches
from the minibuffer to the Completions buffer, then for an unknown
reason the minibuffer post-command hook is still fired in another buffer -
in the Completions buffer that has no local post-command hook.

bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

>> (icomplete-mode 1)
>> (setopt completion-auto-select t)
>> C-x C-f TAB TAB
>>
>> The following error message is displayed in the minibuffer:
>>
>> Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument integer-or-marker-p nil)
>
> I confirm the problem, I have seen it a few times, but
> it seems the root of the problem is in the way how buffer-local
> hooks are fired.  icomplete-post-command-hook is a hook
> local in the minibuffer.  But when the command switches
> from the minibuffer to the Completions buffer, then for an unknown
> reason the minibuffer post-command hook is still fired in another buffer -
> in the Completions buffer that has no local post-command hook.

Actually, this problem started to appear after the recent addition
of completion-auto-select that calls switch-to-completions in two
different places that fail for two different reasons.  Each of both
cases messes up buffers and windows in such a way that after the end
of the command the current buffer is " *Minibuf-1*", but the selected
window is "*Completions*":

1. when completion-auto-select is t, minibuffer-completion-help
temporarily switches buffers using ‘(with-current-buffer-window "*Completions*"’,
then display-completion-list calls completion-setup-hook and completion-setup-function
that uses switch-to-completions to select another window.  Then
minibuffer-completion-help restores the original buffer, i.e. the minibuffer,
but the selected window remains "*Completions*".

2. when completion-auto-select is 'second-tab', completion--in-region-1
uses ‘(with-current-buffer (window-buffer window)’.  Then
switch-to-completions selects another window, after that
the original buffer is restored, i.e. the minibuffer,
but the selected window remains "*Completions*".

So the solution for both cases is to move the window selection
outside from switching buffers:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: switch-to-completions.patch --]
[-- Type: text/x-diff, Size: 2108 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6ae25b8def..a34a1ddad0 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1422,9 +1503,9 @@ completion--in-region-1
     (let ((window minibuffer-scroll-window))
       (with-current-buffer (window-buffer window)
         (cond
-         ;; Here this is possible only when second-tab, so jump now.
-         (completion-auto-select
-          (switch-to-completions))
+         ;; Here this is possible only when second-tab, but switch
+         ;; to completions below, outside of `with-current-buffer'.
+         ((eq completion-auto-select 'second-tab))
          ;; Reverse tab
          ((equal (this-command-keys) [backtab])
           (if (pos-visible-in-window-p (point-min) window)
@@ -1439,7 +1520,9 @@ completion--in-region-1
               (set-window-start window (point-min) nil)
             ;; Else scroll down one screen.
             (with-selected-window window (scroll-up)))))
-        nil)))
+        nil)
+      (when (eq completion-auto-select 'second-tab)
+        (switch-to-completions))))
    ;; If we're cycling, keep on cycling.
    ((and completion-cycling completion-all-sorted-completions)
     (minibuffer-force-complete beg end)
@@ -2421,7 +2504,9 @@ minibuffer-completion-help
 
                       (display-completion-list completions nil group-fun)))))
           nil)))
-    nil))
+    nil)
+  (when (eq completion-auto-select t)
+    (switch-to-completions)))
 
 (defun minibuffer-hide-completions ()
   "Get rid of an out-of-date *Completions* buffer."
diff --git a/lisp/simple.el b/lisp/simple.el
index d6b7045432..99ac7b812d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9826,9 +9826,7 @@ completion-setup-function
 	    (insert "Click on a completion to select it.\n"))
 	(insert (substitute-command-keys
 		 "In this buffer, type \\[choose-completion] to \
-select the completion near point.\n\n")))))
-  (when (eq completion-auto-select t)
-    (switch-to-completions)))
+select the completion near point.\n\n"))))))
 
 (add-hook 'completion-setup-hook #'completion-setup-function)
 

bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

[Knut Anders Hatlen]

Juri Linkov <juri@linkov.net> writes:

>>> (icomplete-mode 1)
>>> (setopt completion-auto-select t)
>>> C-x C-f TAB TAB
>>>
>>> The following error message is displayed in the minibuffer:
>>>
>>> Error in post-command-hook (icomplete-post-command-hook): (wrong-type-argument integer-or-marker-p nil)
>>
>> I confirm the problem, I have seen it a few times, but
>> it seems the root of the problem is in the way how buffer-local
>> hooks are fired.  icomplete-post-command-hook is a hook
>> local in the minibuffer.  But when the command switches
>> from the minibuffer to the Completions buffer, then for an unknown
>> reason the minibuffer post-command hook is still fired in another buffer -
>> in the Completions buffer that has no local post-command hook.
>
> Actually, this problem started to appear after the recent addition
> of completion-auto-select that calls switch-to-completions in two
> different places that fail for two different reasons.  Each of both
> cases messes up buffers and windows in such a way that after the end
> of the command the current buffer is " *Minibuf-1*", but the selected
> window is "*Completions*":
>
> 1. when completion-auto-select is t, minibuffer-completion-help
> temporarily switches buffers using ‘(with-current-buffer-window "*Completions*"’,
> then display-completion-list calls completion-setup-hook and completion-setup-function
> that uses switch-to-completions to select another window.  Then
> minibuffer-completion-help restores the original buffer, i.e. the minibuffer,
> but the selected window remains "*Completions*".
>
> 2. when completion-auto-select is 'second-tab', completion--in-region-1
> uses ‘(with-current-buffer (window-buffer window)’.  Then
> switch-to-completions selects another window, after that
> the original buffer is restored, i.e. the minibuffer,
> but the selected window remains "*Completions*".
>
> So the solution for both cases is to move the window selection
> outside from switching buffers:

Thanks! The patch seems to be working fine in my setup.

-- 
Knut Anders

bug#55712: 29.0.50; Bad interaction between icomplete and completion-auto-select.

[Juri Linkov]

close 55712 29.0.50
thanks

>> So the solution for both cases is to move the window selection
>> outside from switching buffers:
>
> Thanks! The patch seems to be working fine in my setup.

Thanks for confirming.  Now pushed to master.

bug#55712: the fix for this broke the ability to paste into gmail plain text

[Tom Gillespie]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

I have a bug where emacs can no longer paste into gmail
compose windows that are set to plain text, and the fix for
this bug 03b780e387e54c23ac9322e329aca6e5ab4f18e6
bisected as the bad commit. Reverting the commit resolves
the issue.

The issue is on linux under X11 on master at all points after
03b780. To reproduce, copy some text from emacs and try
to paste it into a gmail compose window that is set to plain
text mode.

I do not know exactly which part of the changes induced the
behavior, but reverting the commit clearly fixes the issue and
allows me to paste into plain text mode compose again.

[-- Attachment #2: Type: text/html, Size: 784 bytes --]

bug#55712: the fix for this broke the ability to paste into gmail plain text

[Eli Zaretskii]

> From: Tom Gillespie <tgbugs@gmail.com>
> Date: Tue, 9 Aug 2022 21:10:00 -0700
> 
> I have a bug where emacs can no longer paste into gmail
> compose windows that are set to plain text, and the fix for
> this bug 03b780e387e54c23ac9322e329aca6e5ab4f18e6
> bisected as the bad commit. Reverting the commit resolves
> the issue.
> 
> The issue is on linux under X11 on master at all points after
> 03b780. To reproduce, copy some text from emacs and try
> to paste it into a gmail compose window that is set to plain
> text mode.
> 
> I do not know exactly which part of the changes induced the
> behavior, but reverting the commit clearly fixes the issue and
> allows me to paste into plain text mode compose again.

Hard to understand how completion could be related to pasting.

Could you please run the modified code under Edebug, put a breakpoint
where that commit made changes, and show the Lisp backtrace when that
breakpoint is hit?  Maybe that will give us some hints.

Thanks.