From unknown Thu Jun 19 14:10:13 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#48674 <48674@debbugs.gnu.org> To: bug#48674 <48674@debbugs.gnu.org> Subject: Status: Frames and minibuffer bug Reply-To: bug#48674 <48674@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:10:13 +0000 retitle 48674 Frames and minibuffer bug reassign 48674 emacs submitter 48674 Iris Garc=C3=ADa severity 48674 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed May 26 10:41:29 2021 Received: (at submit) by debbugs.gnu.org; 26 May 2021 14:41:29 +0000 Received: from localhost ([127.0.0.1]:49703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lluiu-0000Dx-GY for submit@debbugs.gnu.org; Wed, 26 May 2021 10:41:29 -0400 Received: from lists.gnu.org ([209.51.188.17]:34876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llrdn-0007CO-AG for submit@debbugs.gnu.org; Wed, 26 May 2021 07:23:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53916) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llrdn-0002Lq-3s for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 07:23:59 -0400 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:36828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1llrdk-0003et-LM for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 07:23:58 -0400 Received: by mail-ej1-x62b.google.com with SMTP id c20so1851932ejm.3 for ; Wed, 26 May 2021 04:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uDatIJ8kXHGL4mevZRzrVhXb26zGVZmpTF6qiLsztb4=; b=N/DyIG3t8IGy/Te2ibzfsw0sY+Rqk3DOs6iUhEOylMWCdbdWfXanc6WAC5f3VWJxdi /aMWsPa5vw1dDbHk/LLlbZmHBRp7+GkBmuRmCtv+VHyHAbHLCEhNU5ivaCtP6b65dCdS S1GibAJ19x87uRRWszxljFdKUQ4uSjBwxXqaoZX6/u/cyfrIwW0niSUasSam4XgC7ggQ lPGKXz8BGYGjvgcUkt12mVDtvzrMePqcKHY8h8U6ELsIXFM3RnvgWx5pxD5fEFzIcfkQ s3PNEZENT0Y5bP9a5YhMAKnXqZ5jEmdE+E7WMFxt0fhoXH5hd6Nmvq0vOP3P0Jql5Baq l4CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uDatIJ8kXHGL4mevZRzrVhXb26zGVZmpTF6qiLsztb4=; b=mLy/irzd2rpMFvI0OgSBKsI7cYt0k2uBcaq5s4PKy6W88ntfhvFo2eXHX/L3/5iAQ+ PgS59aZLIM5KsNjL88JbFheXh3l4bWaSdB/PmG3h7kyuiKRxj/ogl3x9Jio23dcjVy1j q52JyysyoAIlKaShJiAZ/MCt2ez2NXd8B5h/vBDrU/JOJnwvhPGLB2DBobHJk5zASmZH 5mXvY2BsIpsjv634PKPGZZ/IiOcF/BxQV/AJpcBcAvHslV+DbaMZsg2miQn8jLdnMT7Z FU8e13bOQsOZr9BlAPqNeHyQHBqUQj9Nv46o7yN9GNo1IWe2UW3sI5yA/raFzch1M0QL CjGg== X-Gm-Message-State: AOAM533Sesmlz6EaJAdIzjX9wt4SBXi+VkaiVOqjfq1Ew2ChRP3gny9+ 7tj9o4nwzT2eYjo/Ho/9BfS91h2AyMmEqFVZ2WRsa6H2qaBxdQ== X-Google-Smtp-Source: ABdhPJxLj5x4O5HyZD4xPVotBe2POm3xtf7m4wlevc/U3pR1gCw8tJq6twOL7o7hiFp4MDnbrXtmbl9iR2K+7FSI+U4= X-Received: by 2002:a17:906:33d3:: with SMTP id w19mr122810eja.399.1622028234048; Wed, 26 May 2021 04:23:54 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?SXJpcyBHYXJjw61h?= Date: Wed, 26 May 2021 13:23:42 +0200 Message-ID: Subject: Frames and minibuffer bug To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000b4c6fe05c339e09e" Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=imdabuti@gmail.com; helo=mail-ej1-x62b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 26 May 2021 10:41:08 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000b4c6fe05c339e09e Content-Type: text/plain; charset="UTF-8" Hi everyone, this is the first time I report a bug. In order to reproduce the bug I did exactly the following: 1. Start emacs: emacs -Q 2. Paste the following code in the scratch buffer: (defvar box-cursor t) (defun test/set-cursor() "Set cursor in all frames depending on the active state." (interactive) (dolist (frame (frame-list)) (with-selected-frame frame (if box-cursor (progn (modify-frame-parameters frame (list (cons 'cursor-type 'box))) (modify-frame-parameters frame (list (cons 'cursor-color "#00A9FE")))) (progn (modify-frame-parameters frame (list (cons 'cursor-type 'hbar))) (modify-frame-parameters frame (list (cons 'cursor-color "green"))) ))))) (defun test/enter-minibuffer() (setq box-cursor nil) (test/set-cursor)) (defun test/exit-minibuffer() (setq box-cursor t) (test/set-cursor)) (add-hook 'minibuffer-setup-hook #'test/enter-minibuffer) (add-hook 'minibuffer-exit-hook #'test/exit-minibuffer) (server-start) (make-frame) ;; Call M-x (execute-extended-command) and you will see: ;; It is not possible to write in the minibuffer ;; Killing the previously created frame seems to solve the issue. 3. M-x -> eval-buffer -> RET 4. M-x (The bug appears, it is not possible to write in the minibuffer) Note: As soon as the new frame is destroyed, it is possible again to write in the minibuffer. Info: In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4) of 2021-05-26 built on ryzen9 Repository revision: f4dc646e0d7fb673f3149836bb7299fba9539e80 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Arch Linux Configured using: 'configure --with-native-compilation --with-mailutils --with-pop --with-x --with-json --with-xwidgets --with-imagemagick --with-cairo' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_CTYPE: C value of $LC_MESSAGES: C 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 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 auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs password-cache json map text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils server iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-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 cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads xwidget-internal dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 88884 6685) (symbols 48 7886 1) (strings 32 22435 3140) (string-bytes 1 860986) (vectors 16 15992) (vector-slots 8 273880 13488) (floats 8 30 175) (intervals 56 499 0) (buffers 992 13)) --000000000000b4c6fe05c339e09e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone, this is the first time I report a bug.
In order to reproduce the bug I did exactly the following:
1. Start emacs: emacs -Q
2. Paste the following code in the sc= ratch buffer:
(defvar box-cursor t)

(defun test/set-cursor= ()
=C2=A0 "Set cursor in all frames depending on the active state.&= quot;
=C2=A0 (interactive)
=C2=A0 (dolist (frame (frame-list))
=C2= =A0 =C2=A0 (with-selected-frame frame
=C2=A0 =C2=A0 =C2=A0 (if box-curso= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (modify-frame-parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0frame (list (cons 'cursor-type 'box)))
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-parameters
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons 'cursor-colo= r "#00A9FE"))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-parameters
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons 'cursor-type 'hbar)))
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-parameters
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons 'cursor-color "gr= een")))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )))))

(defun test= /enter-minibuffer()
=C2=A0 (setq box-cursor nil)
=C2=A0 (test/set-cur= sor))

(defun test/exit-minibuffer()
=C2=A0 (setq box-cursor t)=C2=A0 (test/set-cursor))


(add-hook 'minibuffer-setup-hook = #'test/enter-minibuffer)
(add-hook 'minibuffer-exit-hook #'t= est/exit-minibuffer)

(server-start)
(make-frame)

;; Call M= -x (execute-extended-command) and you will see:
;; It is not possible to= write in the minibuffer
;; Killing the previously created frame seems t= o solve the issue.

3. M-x -> eval-buffer -> = RET
4. M-x (The bug appears, it is not possible to write in the m= inibuffer)

Note:
As soon as the new fram= e is destroyed, it is possible again to write in the minibuffer.
<= div>
Info:
In GNU Emacs 28.0.50 (build 2, x86_6= 4-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4)
=C2=A0of 2= 021-05-26 built on ryzen9
Repository revision: f4dc646e0d7fb673f3149836b= b7299fba9539e80
Repository branch: master
Windowing system distributo= r 'The X.Org Foundation', version 11.0.12011000
System Descripti= on: Arch Linux

Configured using:
=C2=A0'configure --with-nati= ve-compilation --with-mailutils --with-pop
=C2=A0--with-x --with-json --= with-xwidgets --with-imagemagick --with-cairo'

Configured featur= es:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZIMAGEMAGICK JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOT= IFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_B= ARS X11 XDBE XIM XPM XWIDGETS GTK3 ZLIB

Important settings:
=C2= =A0 value of $LC_ALL: en_US.UTF-8
=C2=A0 value of $LC_CTYPE: C
=C2=A0= value of $LC_MESSAGES: C
=C2=A0 value of $LANG: en_US.UTF-8
=C2=A0 l= ocale-coding-system: utf-8-unix

Major mode: Lisp Interaction

= Minor modes in effect:
=C2=A0 tooltip-mode: t
=C2=A0 global-eldoc-mod= e: t
=C2=A0 eldoc-mode: t
=C2=A0 electric-indent-mode: t
=C2=A0 mo= use-wheel-mode: t
=C2=A0 tool-bar-mode: t
=C2=A0 menu-bar-mode: t
= =C2=A0 file-name-shadow-mode: t
=C2=A0 global-font-lock-mode: t
=C2= =A0 font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-composi= tion-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0 auto-compression-m= ode: t
=C2=A0 line-number-mode: t
=C2=A0 transient-mark-mode: t
Load-path shadows:
None found.

Features:
(shadow sort mail-e= xtr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec ep= a derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source eiei= o eieio-core eieio-loaddefs
password-cache json map text-property-search= time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev g= mm-utils mailheader
sendmail comp comp-cstr warnings subr-x rx cl-seq cl= -macs cl-extra
help-mode seq byte-opt gv cl-loaddefs cl-lib bytecomp byt= e-compile cconv
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils= server
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hookslisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bardnd fontset image regexp-opt fringe tabulated-list replace newcomment
t= ext-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
r= fn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-= lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham g= eorgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean= japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european e= thiopic indian cyrillic chinese composite charscript charprop
case-table= epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice = button loaddefs faces cus-face macroexp files
window text-properties ove= rlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-= print-readable backquote threads
xwidget-internal dbusbind inotify lcms2= dynamic-setting
system-font-setting font-render-setting cairo move-tool= bar gtk x-toolkit
x multi-tty make-network-process native-compile emacs)=

Memory information:
((conses 16 88884 6685)
=C2=A0(symbols 48= 7886 1)
=C2=A0(strings 32 22435 3140)
=C2=A0(string-bytes 1 860986)<= br>=C2=A0(vectors 16 15992)
=C2=A0(vector-slots 8 273880 13488)
=C2= =A0(floats 8 30 175)
=C2=A0(intervals 56 499 0)
=C2=A0(buffers 992 13= ))
--000000000000b4c6fe05c339e09e-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 26 13:45:22 2021 Received: (at 48674) by debbugs.gnu.org; 26 May 2021 17:45:22 +0000 Received: from localhost ([127.0.0.1]:49846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llxas-00051P-3L for submit@debbugs.gnu.org; Wed, 26 May 2021 13:45:22 -0400 Received: from mout.gmx.net ([212.227.17.21]:60135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1llxaq-000516-EE; Wed, 26 May 2021 13:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622051112; bh=Zu0s8haeSe02xmZJjrDnEOsLr0o1C3MVFR3695OaM5U=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=JOufpzsnioNzuOvM40fXcKoPhQ89ymbrC95hqRurpmYOLMv5E5+tt0G41ilWr0iF3 8yrLE7h8fzCn3nPadPHsYQ9cKomMlJZAgDZGRRM4R9pDnu8P2rQ3mA8VISlFhYmMdq hEtmDWskl8RAjnJ0q0IfbGLXsZgSAGTQHabLulg0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.103] ([212.95.5.132]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N79yG-1lMdnw0iDc-017Y4K; Wed, 26 May 2021 19:45:12 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: =?UTF-8?Q?Iris_Garc=c3=ada?= , 48674@debbugs.gnu.org References: From: martin rudalics Message-ID: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> Date: Wed, 26 May 2021 19:45:11 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:lqcX5pHtkxiIiL/V9uY6ImSaY2EcyNXH7Lwzx1KaSH2Rbe4aj1K V5/FZng7lHz7SDca4z6X7AJWlfELCACx/M8tb2mACGncY12svHZwSQIt/QxmKU75aoV8kPk WwWTcqFbek/N0q9Lub91DPd03lPgzzwT3CZSvyTQ7mg4LfyiCxlDnrVncURuYZeOOLdsWAa VuCmhYir15gGU3a1WdcSA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:wZ+ztv8l50s=:VlTvsBOKL9MS0eaALC6vHL yooP85kcbOv+vyXrJaHl58tARPpbnKkjLKXJc3Bs2S5OV17tX6OgHE1bOqf4eHLVa4HT40CeZ fOYz7aGSQPphoMLhnkPhXWw5agdNz5kTkKNAJb2TZcTp4J24tLl0Xi5r5Lvwgxbaf7g+W6QrT eVmlAAf3+pdqIAue7awPHKMhGzide/RX4Wj9LkpI5tUSIBkWBk2JP4KXVuKaww76iFYSTh3Qh XcRh09YnN3TrZ9CNSZR1jL/zQuI3A+bOkrTPO6KOeEnsMxUjS+X2CVpZfeyq6LPuwImWzVYBV K/puuE7Bi3VX593+R6OXXr6FDPOEuRnuFGaVPpx1rTgqTgQY1CMd20OgTR2B8bTAjrfs2LcT5 n/b/9+tv1KPbZo53KQwRuibrob+1/9Ep4YG6XInOwTNCZ/x0XqZ8GB6vZunJEg12zH7B06f5N RgaaEq90iA8IVGrlmgfnE1BnMTtRGjSJvAv0ETB4TcLHsB/K8FJOaLx1AW+oQvd2QrD+73wao rbuFfcKT/XbHNZg8M+tlsnju9oFp92wBU4zjgEOWFezwKFFWlomshTxv08ROgxqOukOy5Ug6D +WpimbMnnySNjVLOS4xYQ34pta5F/yN3Byh3Qa/QoUGKq8zFXUsI+GsaJclWzjrrrqK1vvTNT 7IzW7U/NSCEOozcDLKTvFQ5Qrx+H8hjddxMKb0kmqTp3EEi4wllRkA9uYF21X5RwtDgCbDlOP P25tY5qZWSplbOkCzIVuzD1kNMJ2hJYG98Y96OmCszxH7N1PI0PVkPuY1dNw8spQi7QICT0Vz PqcxVV38SBiOah+T8S8i9CU7UD0qRsD5E8kG6wTc8NCM6JcdLi0sXTmqnQFtbMU7O0iWzyOL1 iZ7nT/j+IF/Duy1em/LIPi8tKYHibchI7xYqSXhJkd99af/mtUoOol6qWzRxfe1E+OThpElMJ D4S+2iKuyIZxGlZhEiJFixuRTmlVN1m/ypJi9QZOs3qlaqUXbvbD3x6e3uZFBUQ5lmDKewURP ZfhprSa0eFjag2pAmR5cnWujMlSBbl8fBquxrxwOMPRHwkjGCuBgktC1rVGQldDLU+WndkXB2 LDqYzJFK9iqmyGBJZUDbRM6ny9u2y2xf5Xa1/gRm4X+astoHICMiu/miR/8I56KCqqZwn4B/0 xlJA37oNFgXT2nBCMzJ1xTJcFIhE8uZFST21sAbO8qMhtO/qBxOIFy6vhUk28TJ8Le0Nc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 48674 48675 quit Thanks for the report. I've just tried to merge this with the following one. > 4. M-x (The bug appears, it is not possible to write in the minibuffer) The crucial part is the (dolist (frame (frame-list)) (with-selected-frame frame setting the cursor is not necessary to reproduce it. Since the bug does not appear with Emacs 27, this could be due to Alan's minibuffer window changes. > Note: > As soon as the new frame is destroyed, it is possible again to write in the > minibuffer. Right but as soon as I make another frame and type M-x I get completing-read-default: Command attempted to use minibuffer while in minibuffer so I'm at the same time in the active minibuffer and a normal buffer. martin From debbugs-submit-bounces@debbugs.gnu.org Thu May 27 06:34:46 2021 Received: (at 48674) by debbugs.gnu.org; 27 May 2021 10:34:46 +0000 Received: from localhost ([127.0.0.1]:50711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmDLi-0000zU-4h for submit@debbugs.gnu.org; Thu, 27 May 2021 06:34:46 -0400 Received: from colin.muc.de ([193.149.48.1]:49792 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmDLf-0000zD-LT for 48674@debbugs.gnu.org; Thu, 27 May 2021 06:34:44 -0400 Received: (qmail 81671 invoked by uid 3782); 27 May 2021 10:34:36 -0000 Received: from acm.muc.de (p4fe1599a.dip0.t-ipconnect.de [79.225.89.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 27 May 2021 12:34:36 +0200 Received: (qmail 5780 invoked by uid 1000); 27 May 2021 10:34:36 -0000 Date: Thu, 27 May 2021 10:34:36 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Iris and Martin. Iris, thanks for taking the trouble to report this bug, and thanks even more for cutting the test case down to the absolute minimum, making the bug easier to diagnose. On Wed, May 26, 2021 at 19:45:11 +0200, martin rudalics wrote: > merge 48674 48675 > quit > Thanks for the report. I've just tried to merge this with the following > one. > > 4. M-x (The bug appears, it is not possible to write in the minibuffer) > The crucial part is the > (dolist (frame (frame-list)) > (with-selected-frame frame > setting the cursor is not necessary to reproduce it. Since the bug does > not appear with Emacs 27, this could be due to Alan's minibuffer window > changes. Sort of, almost. What is happening is that the with-selected-frame invocation is selecting (temporarily) a different frame from the minibuffer's frame. This has the (intended) side effect of making the MB no longer selected in that frame. When the MB's frame becomes selected again, nothing makes the mini-window the selected window. This needs fixing. I think it likely that this bug could be triggered in Emacs 27 by putting something into minibuffer-setup-hook that selects a different window in the MB's frame, though I haven't tried this. > > Note: > > As soon as the new frame is destroyed, it is possible again to write in the > > minibuffer. > Right but as soon as I make another frame and type M-x I get > completing-read-default: Command attempted to use minibuffer while in minibuffer > so I'm at the same time in the active minibuffer and a normal buffer. Yes. I think the following patch should fix the trouble. Iris, could you please apply the patch (in directory ..../emacs/src) and rebuild your Emacs-28, then try it out on your real lisp source code. Should you want any help with the patching or building, feel free to send me private email. Then please confirm that the problem is fixed, or tell us what's still not working. Thanks! Martin, that Qt in the Fselect_window call (the NORECORD argument) - would it be perhaps be better as Qnil? diff --git a/src/minibuf.c b/src/minibuf.c index cffb7fe787..3468643a7e 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, run_hook (Qminibuffer_setup_hook); + /* If the above hook has made the mini-window no longer the selected + window, restore it. */ + if (!EQ (selected_window, minibuf_window)) + Fselect_window (minibuf_window , Qt); + /* Don't allow the user to undo past this point. */ bset_undo_list (current_buffer, Qnil); > martin -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Thu May 27 12:34:00 2021 Received: (at 48674) by debbugs.gnu.org; 27 May 2021 16:34:00 +0000 Received: from localhost ([127.0.0.1]:52682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmIxM-0002TQ-JS for submit@debbugs.gnu.org; Thu, 27 May 2021 12:34:00 -0400 Received: from mout.gmx.net ([212.227.17.20]:41889) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmIxK-0002TC-Ey for 48674@debbugs.gnu.org; Thu, 27 May 2021 12:33:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622133231; bh=YFCtMKrQ1f/ZTj3WR3O6/WefstlO1OjT0SS9OQkMuME=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=dpq7yPs22g2reILbDKI5rR0l9sRUROVpJj1IPYtWvUiKsHT3R4fYY1QL0m4C1/vvU TmSriCEO4Y1SdjCF3IzG/b81x6n4DQ3MYC9CUlsaAoU66QkyPvgC/r/N6bxeSUsrtm 8BreqYxiB2uxUuJY7wnThIIiqe/AyIttKH8hU1To= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.167]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MUosT-1lunFP4BDl-00QnLn; Thu, 27 May 2021 18:33:51 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> From: martin rudalics Message-ID: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> Date: Thu, 27 May 2021 18:33:45 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:pBPVYIdGEZfTEA6xapRkgrS+ZP4ZMfQ7fGYFN+iJeTHGFDS9pe5 2YayrpHpcL2YaoaH/vnZ6wHoBRiqFWcPrs6gqINfygsr/5K5hCG0lI4oKOV1hko1RX3pM/z H5baMg5TudzY/ZKLlus37amAjeVOJuEiVlUabWkHpmHqLEbusrBX/ASJUPEA1NeuVqK797S /IGLPPjgm07trrNLG4Ogw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:FFggQkC1XQ4=:Coo1GvPkj4kaB8K0jGmAlp jkIyHAvRHpfXqm6JxvKbsq/ATOGYlf+XCYD/cuCB96Hw6fa5EhobaDyjmyiFgO/hO2T4Fw2TP Kc+mjr151snDtsNsNGuUblBqSgos76RWp1Im0y0nReD74u+gRDircTD4rJbFK2OY267ShEr4T tXzDWNViONNqwNL5wZXjGWzPJ9eu7Uij4JK6h0ygs0nWHmEC2mfdsKQExS/FSHGLxqsMU+QRe whSUMyGMN6HLRDYlZVza+Eed0+kmrRPWnKZgr/vigzYzlsqvvGiZhmbKi1/+hXjczvwy9fbWn K8ed/y/Vz2Trcg/VT8eMB0AQngt4wC2nF4q7OVJ/gTthMdulh0OqouxTavK+1axz/dNOTDupu L/0uy0GnWAdwFe9gVAZ4A8xp/5aGSN/l+7r6Kt8/2hka/vETuY3oVoD3648L+NEVjMt6K3d4B fW0bIlqBlKoCZFbM7QvYZqQB3KUAS28PV/KZKtRx1Ai064k2Fj9fT4JyvQqR/YxNXbJnhC85B ICoA4wfsEamfFVNX4UJEMfKr65Sg1eVoTDSn+HSjaYGhiBRxeTj+TYXI5/KamoJEa5BiGvxc0 jm0MDd1ZXLJgacJcF6v/REwM/6pwD77FGMgWrqRFp58Vj5g6Fhx7f0I21U8dgDRIJtqQ1CkwD I/+dtn1knLnJwYV+7aTNZSXZQI9IMiuibsjp/PAWKTcdbXeIn6ePY4Zyrh0jnemBygeT7xGP8 v+Oy1RfHUdzneQmcE8BfV4FdT+CkbrzycKwmihQPs3dBPJsMRfhX4c/IrD78w8VlYZSBD1Atd lsdzxf8Rgpk5cSC3+0QVMV8h78T0ZmxwZpd7FBrATFwJNLMKm7npUNrpOBNOM0Ta/uceYgss3 filskay39vmAI/gLS0sFPhF35dbPHkWD9P72Kam5LXO8ur/+4o5AdFV4c5VZtonq3Vc1Dy69G lTPbFGfwPlJigmGPnD+GUxatobnLRHtfg/HGkv+CYcGNDMzpViBrCrKRIKALv23z0mDfB2Q3O OzBUniiTOd05ejHaAmA2XUk+/0LzpJqaN8xwwUFOeWHzxY0IJGvMIuBzrALviGeFRwUopxqaf /7BTF3ijPYAq7GHHkLKtYm5b3eyBweMDbkR X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, =?UTF-8?Q?Iris_Garc=c3=ada?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > What is happening is that the with-selected-frame invocation is > selecting (temporarily) a different frame from the minibuffer's frame. > This has the (intended) side effect of making the MB no longer selected > in that frame. When the MB's frame becomes selected again, nothing > makes the mini-window the selected window. This needs fixing. Does this mean that the Fselect_window (f->selected_window, norecord); in do_switch_frame fails? If so, why? Do we anywhere violate the (eq (selected-window) (frame-selected-window (selected-frame))) invariant? That might be fatal. Both, `with-selected-frame' and `with-selected-window', should leave no traces behind. > Martin, that Qt in the Fselect_window call (the NORECORD argument) - > would it be perhaps be better as Qnil? > > > diff --git a/src/minibuf.c b/src/minibuf.c > index cffb7fe787..3468643a7e 100644 > --- a/src/minibuf.c > +++ b/src/minibuf.c > @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > > run_hook (Qminibuffer_setup_hook); > > + /* If the above hook has made the mini-window no longer the selected > + window, restore it. */ > + if (!EQ (selected_window, minibuf_window)) > + Fselect_window (minibuf_window , Qt); > + Are we sure that we want to disallow a function on `minibuffer-setup-hook' to change the selected window? With Emacs 27 (defun foo () (select-window (frame-first-window))) (add-hook 'minibuffer-setup-hook 'foo) works without any problems here. The NORECORD argument is important only if you need it - so far, the previous buffers of the minibuffer window were largely ignored. martin From debbugs-submit-bounces@debbugs.gnu.org Thu May 27 15:56:16 2021 Received: (at 48674) by debbugs.gnu.org; 27 May 2021 19:56:16 +0000 Received: from localhost ([127.0.0.1]:52845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmM76-0001Kh-0d for submit@debbugs.gnu.org; Thu, 27 May 2021 15:56:16 -0400 Received: from mail-ed1-f48.google.com ([209.85.208.48]:37652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmM74-0001KS-0W for 48674@debbugs.gnu.org; Thu, 27 May 2021 15:56:14 -0400 Received: by mail-ed1-f48.google.com with SMTP id g7so2227259edm.4 for <48674@debbugs.gnu.org>; Thu, 27 May 2021 12:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4goG+eWSRWxvrQy6OclfQlG/oTmSNFp0erpEOgV8X/Q=; b=TOV6bpFR3mq0XpIPHvQDnzGc+QFpvrsZsXmzuyHxb5A0ocJMCKG1IrDCi7irHL6FZ/ T1AxI/CdSwsQgNRzfjVLa0JY7pAKed+WeHKtQhRx0hWdxAu+lJTjhC+FCyuSLIJ6hI6N BBouB3LtBh90PfISwi/WxWmm8lftviYAh5Zezk+bFPf7pMFAy5rAoZSp/GqReF1J5idx Xoppg4ARVeObJdqDvVuxUshGWjC3eJy10cpqA8LyVJf3CFKJi4KSsqLWkVEdhZ7yKfM7 YPYiOyGQua32mOYdhWv7/u5nuK3frC/xUQbFJvuHQ4O3FrZjMM3Ow9B6+08gEqB8hUyV 7UNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4goG+eWSRWxvrQy6OclfQlG/oTmSNFp0erpEOgV8X/Q=; b=qiHLS/6Vx/1DztiZHt2XTdd7DLeoGQGRt+fiTuoqiJ4Qng/4Zh3rnBXmpMDh6iHd2U VqK1fCyzhiioCT+am5PhSYrtSwbrIVKXUPSasTv+QvplpgasHVPuWazRpKRDi33EX+c2 o2K/n7oZx0pFaa+5koyIeRLrJCB4lEv8LLGGnWaAqVO71zOu+vY82a3LXimXRYIl6BXf 3dKtGjBkVCHZvRdLOMeWfHjfK3rELLjtYyDAs5EsLW+h7HI/rqITUhCW9Bvaye64WGeE 0nLtI85fvTe+DDGULW6X/2tVQO0fR0I05OE+pSVP0mjolzwbgOQ+IkBBsc0i0PjeLXzu oltw== X-Gm-Message-State: AOAM5319arz5pQrit+xlsHqKUEtjc7Kbjq7WTPqjqAp0iLrBO81NEuys LD/Y6yhuQP6elOo8ZKXHxdQPl0tn0RkKsXoxqi4= X-Google-Smtp-Source: ABdhPJwTELI94QrUlxPDxn2nt8WqqZko5MPs5sosn5EKGGlIFOnY0NIkMZIjeqfKPJ4d9arucp3b02Bi0pJxAnRDLV4= X-Received: by 2002:a05:6402:50cd:: with SMTP id h13mr6110691edb.111.1622145367994; Thu, 27 May 2021 12:56:07 -0700 (PDT) MIME-Version: 1.0 References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> In-Reply-To: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> From: =?UTF-8?B?SXJpcyBHYXJjw61h?= Date: Thu, 27 May 2021 19:56:03 +0000 Message-ID: Subject: Re: bug#48674: Frames and minibuffer bug To: martin rudalics Content-Type: multipart/alternative; boundary="0000000000006ef69205c3552641" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000006ef69205c3552641 Content-Type: text/plain; charset="UTF-8" Hi Martin, I forgot to include you in my last mail where I said: I think I have found the new issue (it is related to the former one), my > code this time was the following: > > (defvar box-cursor t) > > (defun test/set-cursor() > "Set cursor in all frames depending on the active state." > (interactive) > (dolist (frame (frame-list)) > (with-selected-frame frame > (if box-cursor > (progn > (modify-frame-parameters > frame (list (cons 'cursor-type 'box))) > (modify-frame-parameters > frame (list (cons 'cursor-color "#00A9FE")))) > (progn > (modify-frame-parameters > frame (list (cons 'cursor-type 'hbar))) > (modify-frame-parameters > frame (list (cons 'cursor-color "green"))) > ))))) > > (defun test/enter-minibuffer() > (setq box-cursor nil) > (test/set-cursor)) > > (defun test/exit-minibuffer() > (setq box-cursor t) > (test/set-cursor)) > > > (add-hook 'window-state-change-hook #'test/enter-minibuffer) > (add-hook 'window-state-change-hook #'test/exit-minibuffer) > > (server-start) > (make-frame > > The only difference is the add-hook, this time using > window-state-change-hook instead of minibuffer-... > This leads to the same bug. > > Regards, > > Iris. > On Thu, 27 May 2021 at 16:33, martin rudalics wrote: > > What is happening is that the with-selected-frame invocation is > > selecting (temporarily) a different frame from the minibuffer's frame. > > This has the (intended) side effect of making the MB no longer selected > > in that frame. When the MB's frame becomes selected again, nothing > > makes the mini-window the selected window. This needs fixing. > > Does this mean that the > > Fselect_window (f->selected_window, norecord); > > in do_switch_frame fails? If so, why? Do we anywhere violate the > > (eq (selected-window) (frame-selected-window (selected-frame))) > > invariant? That might be fatal. Both, `with-selected-frame' and > `with-selected-window', should leave no traces behind. > > > Martin, that Qt in the Fselect_window call (the NORECORD argument) - > > would it be perhaps be better as Qnil? > > > > > > diff --git a/src/minibuf.c b/src/minibuf.c > > index cffb7fe787..3468643a7e 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object > initial, Lisp_Object prompt, > > > > run_hook (Qminibuffer_setup_hook); > > > > + /* If the above hook has made the mini-window no longer the selected > > + window, restore it. */ > > + if (!EQ (selected_window, minibuf_window)) > > + Fselect_window (minibuf_window , Qt); > > + > > Are we sure that we want to disallow a function on > `minibuffer-setup-hook' to change the selected window? With Emacs 27 > > > (defun foo () > (select-window (frame-first-window))) > > (add-hook 'minibuffer-setup-hook 'foo) > > > works without any problems here. > > The NORECORD argument is important only if you need it - so far, the > previous buffers of the minibuffer window were largely ignored. > > martin > > --0000000000006ef69205c3552641 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

I forgot to inclu= de you in my last mail where I said:

I think I have found the new iss= ue (it is related to the former one), my code this time was the following:<= /div>

(defvar box-cursor t)

(defun test/set-curso= r()
=C2=A0 "Set cursor in all frames depending on the active state.= "
=C2=A0 (interactive)
=C2=A0 (dolist (= frame (frame-list))
=C2=A0 =C2=A0 (with-selected-frame frame
= =C2=A0 =C2=A0 =C2=A0 (if box-cursor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= progn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-parameters=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons '= cursor-type 'box)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modif= y-frame-parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame= (list (cons 'cursor-color "#00A9FE"))))
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (progn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-param= eters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons 'cu= rsor-type 'hbar)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (modify-frame-= parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frame (list (cons &#= 39;cursor-color "green")))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = )))))

(defun test/enter-minibuffer()
=C2=A0 (setq box-cursor nil)=
=C2=A0 (test/set-cursor))

(defun test/exit-minibuffer()
=C2= =A0 (setq box-cursor t)
=C2=A0 (test/set-cursor))


(add-hook &= #39;window-state-change-hook #'test/enter-minibuffer)
(add-hook '= ;window-state-change-hook #'test/exit-minibuffer)

(server-start)=
(make-frame

The only difference is the add-hook, this= time using window-state-change-hook instead of minibuffer-...
Th= is leads to the same bug.

Regards,

<= /div>
Iris.

On Thu, 27 May 2021 at 16:33, marti= n rudalics <rudalics@gmx.at> w= rote:
=C2=A0>= What is happening is that the with-selected-frame invocation is
=C2=A0> selecting (temporarily) a different frame from the minibuffer= 9;s frame.
=C2=A0> This has the (intended) side effect of making the MB no longer s= elected
=C2=A0> in that frame.=C2=A0 When the MB's frame becomes selected ag= ain, nothing
=C2=A0> makes the mini-window the selected window.=C2=A0 This needs fixi= ng.

Does this mean that the

=C2=A0 =C2=A0Fselect_window (f->selected_window, norecord);

in do_switch_frame fails?=C2=A0 If so, why?=C2=A0 Do we anywhere violate th= e

=C2=A0 =C2=A0(eq (selected-window) (frame-selected-window (selected-frame))= )

invariant?=C2=A0 That might be fatal.=C2=A0 Both, `with-selected-frame'= and
`with-selected-window', should leave no traces behind.

=C2=A0> Martin, that Qt in the Fselect_window call (the NORECORD argumen= t) -
=C2=A0> would it be perhaps be better as Qnil?
=C2=A0>
=C2=A0>
=C2=A0> diff --git a/src/minibuf.c b/src/minibuf.c
=C2=A0> index cffb7fe787..3468643a7e 100644
=C2=A0> --- a/src/minibuf.c
=C2=A0> +++ b/src/minibuf.c
=C2=A0> @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object = initial, Lisp_Object prompt,
=C2=A0>
=C2=A0>=C2=A0 =C2=A0 =C2=A0run_hook (Qminibuffer_setup_hook);
=C2=A0>
=C2=A0> +=C2=A0 /* If the above hook has made the mini-window no longer = the selected
=C2=A0> +=C2=A0 =C2=A0 =C2=A0window, restore it.=C2=A0 */
=C2=A0> +=C2=A0 if (!EQ (selected_window, minibuf_window))
=C2=A0> +=C2=A0 =C2=A0 Fselect_window (minibuf_window , Qt);
=C2=A0> +

Are we sure that we want to disallow a function on
`minibuffer-setup-hook' to change the selected window?=C2=A0 With Emacs= 27


(defun foo ()
=C2=A0 =C2=A0(select-window (frame-first-window)))

(add-hook 'minibuffer-setup-hook 'foo)


works without any problems here.

The NORECORD argument is important only if you need it - so far, the
previous buffers of the minibuffer window were largely ignored.

martin

--0000000000006ef69205c3552641-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 27 16:01:30 2021 Received: (at 48674) by debbugs.gnu.org; 27 May 2021 20:01:30 +0000 Received: from localhost ([127.0.0.1]:52857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmMC9-0001UI-Pp for submit@debbugs.gnu.org; Thu, 27 May 2021 16:01:30 -0400 Received: from colin.muc.de ([193.149.48.1]:10195 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmMC7-0001Tz-FV for 48674@debbugs.gnu.org; Thu, 27 May 2021 16:01:28 -0400 Received: (qmail 65627 invoked by uid 3782); 27 May 2021 20:01:20 -0000 Received: from acm.muc.de (p4fe1599a.dip0.t-ipconnect.de [79.225.89.154]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 27 May 2021 22:01:20 +0200 Received: (qmail 8451 invoked by uid 1000); 27 May 2021 20:01:19 -0000 Date: Thu, 27 May 2021 20:01:19 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin. On Thu, May 27, 2021 at 18:33:45 +0200, martin rudalics wrote: > > What is happening is that the with-selected-frame invocation is > > selecting (temporarily) a different frame from the minibuffer's > > frame. This has the (intended) side effect of making the MB no > > longer selected in that frame. When the MB's frame becomes selected > > again, nothing makes the mini-window the selected window. This > > needs fixing. > Does this mean that the > Fselect_window (f->selected_window, norecord); > in do_switch_frame fails? If so, why? For some values of "fails", yes. When we're in frame F1's minibuffer, and do (with-selected-frame F2 (foo)): (i) Frame F2 becomes selected. (ii) The current window in F1 ceases to be the mini-window, becoming some other window. (iii) The minibuffer is moved from F1 to F2. (iv) We evaluate (foo). (v) Frame F1 becomes selected again. (vi) The current window in F1 doesn't revert to being the mini-window. > Do we anywhere violate the > (eq (selected-window) (frame-selected-window (selected-frame))) > invariant? No. The variables selected-\(window\|frame\) are not set directly anywhere in minibuf.c, only by calling functions like Fselect_window. > That might be fatal. Both, `with-selected-frame' and > `with-selected-window', should leave no traces behind. This is what has preoccupied me over the last few hours. It seems we want do_switch_frame to do different things for (i) a "permanent" frame switch (e.g. C-x 5 o) and (i) a "temporary" frame switch (e.g. with-selected-frame). If the selected window in F1 is the mini-window, we want it to select a different window in (i), but stay the same in (ii). Or perhaps we want a variant of select-frame which wouldn't move a stack of minibuffers from F1 to F2. Something like Ftemporarily_select_frame, which would come with discouragement from use in its doc string, and wouldn't be interactive. with-selected-frame would use this. Something like (untested): DEFUN ("temporarily-select-frame", Ftemporarily_select_frame, Stemporarily_select_frame, 1, 1, null, doc: /* Temporarily select FRAME. More doc string....... This function returns FRAME, or nil if FRAME has been deleted. */) (Lisp_Object frame) { struct frame *f; CHECK_LIVE_FRAME (frame); f = XFRAME (frame); if (FRAME_TOOLTIP_P (f)) /* Do not select a tooltip frame (Bug#47207). */ error ("Cannot select a tooltip frame"); else return do_switch_frame (frame, 1, 0, Qt, 1); <==== Extra argument here. } (This is all with minibuffer-follows-selected-frame set to t.) > > Martin, that Qt in the Fselect_window call (the NORECORD argument) - > > would it be perhaps be better as Qnil? > > diff --git a/src/minibuf.c b/src/minibuf.c > > index cffb7fe787..3468643a7e 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -893,6 +893,11 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, > > > > run_hook (Qminibuffer_setup_hook); > > > > + /* If the above hook has made the mini-window no longer the selected > > + window, restore it. */ > > + if (!EQ (selected_window, minibuf_window)) > > + Fselect_window (minibuf_window , Qt); > > + > Are we sure that we want to disallow a function on > `minibuffer-setup-hook' to change the selected window? With Emacs 27 > (defun foo () > (select-window (frame-first-window))) > (add-hook 'minibuffer-setup-hook 'foo) > works without any problems here. Are you sure? For me, that setup makes C-x C-f open a minibuffer, but leave point in the same window, not the miniwindow. That was a quick try with the emacs-27 branch, not Emacs 27.{1,2}, and was on a GUI. I think we should disallow selecting windows in minibuffer-setup-hook. This hook is run after the mini-window has been selected in read_minibuf, just before the recursive edit. > The NORECORD argument is important only if you need it - so far, the > previous buffers of the minibuffer window were largely ignored. Thanks. I'll think about that when my head's a bit clearer. > martin From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 04:25:44 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 08:25:44 +0000 Received: from localhost ([127.0.0.1]:53560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmXoO-0004SU-IT for submit@debbugs.gnu.org; Fri, 28 May 2021 04:25:44 -0400 Received: from mout.gmx.net ([212.227.17.21]:36415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmXoL-0004SE-VC for 48674@debbugs.gnu.org; Fri, 28 May 2021 04:25:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622190333; bh=Sk1iWfvSQnIt7VfMXe1lWfaAJG3CFCueqoqRC0zBtrc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Es3QzdOw+IQwYY4dvIYmEfFyQ9XimHHFrHHJvDa1aQkebeuIdhhCDcmejtweYij// Qvjv789NZwVVZFLMlNIs1NONx1HXba86iHt/XW2VEI/G+p5klMmFJjjVzSoKI+oKhp De3kKjhefiFVXk4kFnl90gjot4nni6eyFkcuxkLE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.65]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGQj7-1lctoe0rML-00GpMk; Fri, 28 May 2021 10:25:33 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: =?UTF-8?Q?Iris_Garc=c3=ada?= References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> From: martin rudalics Message-ID: Date: Fri, 28 May 2021 10:25:31 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:c42gOAArqxn1Dygusirr9mbFi2cYFYm5yn/0wDuCdiZ83+CqXo5 GY59K7jCVHHrjtgzAbAzyvCRikf3vnI1n6U4Vp5rdJjU7KzLGJAUVDPt1tDtcwraf66mVY1 XYu2jnKmwWss8yaqQBj+wfDThVzoFNIgHBcEGB64RAllylAq/0ktuQqEQJmOmFVNWDgweCa zYWyaxYh/x8PV2O4GIC3g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:VDvR3hzcwdQ=:NT3IRiG4phitnFNXTMZuFl Rk7bys5TsBGKU3sZv0+bBFpik4DB4IUZQ0nVO9GaBrJA+7klG2EF/f5tDAzX3NRTiHK8VcfSn HKyOABdSRSjMhcKiODInt4+O+RzjnznLtNrk2PVHb7CME7auvm439jSb62QSrAW+YeymzOFJX NP9RnF+6DTOdLLJOzcAY1Ld7LAakxVwi6a3MdUco6pxNkRKkNxqEpP/capv+UixNUzZt1zrKH 1zNbOhi/hH0QBgGlOl/rTp63HlUjogXT8vX0zdkVM6AmEnJonwAA+KsYeEX9xzhRbzuz1pXtA jub6YKVUt9+dVFSMcc/oup2QuLHfDTA8EecgAtfzGiSC4YTnOa8YB3lp7LBihwZ7P3xXG2zDX T9pjhkBYBtyL4GkZ8AmJ/Q9+sHVJbOkW3qkyFGOI+pht/g+RH30hT4lUV1jcHPbgfB/MGZPTf gSHrrqAXi0NYcLl/cFfnI3G5KJT272IkMPb05QlwZhxuezXYmBbQbyAZpfLKVTSGmHc8/SINR ird7WLm28dAVsyjB+6gA9zNbqUOSzFmflmyCDYkazVsS2tM+CVq9qsC2l5XKeiqru+ZXHotbh EKs256QyFS4V92AHvgYB1Rw9uKAFbKvEwBrp0568qJNHn5zVhjqfXQOJwZ5O+WPPMqKRLiLDU c9u32xDz7lSsiMPTGlC4KTTghQhD7/7e+ZdnS0v437rDXOR2EDNBr0FCJRD0w2TPp7nwWhSd0 z7lEU8RxytWm6dEqsNoXUt6bKN8vXl0oHVx+MN4gj388qQhDbQ8n1d1VWU8vNSbsE5akLJhwG rkc94lN8X3fe6t/otFsf2JByoOlbuD2WYiq2e/gwh1TomiiPPLc9Z+G32gi88+ddO05g/ibjA E/nr6OYRcoXZrepleedfm7CFtKlceqMTq0QuQ8e7yELT7DW42fPUg3JlQX/D1v3mehqyyXeq7 422K+PF+oA5sdxQUCHdkPxNrVeRv19qGC2IcTVTHmw+bys25VPjFPwqYITe6Z/v0qd6r3eTjz WpnwA4CfZp8K6OavjTrNfGZyIawXdvwvdSmA1RDJv3F2OV69J2kSqB6DZ97++25GbbuPFcbaz E2HCzDvh/uLsyuovF6S8vT1vpybysWGIkwmF+2r35ML6sKD37ZHNsWh09Apt1itwUnIMdNmQt 4QonJ65Oy/wqFpMI6UH/o3d+/x0w3c/W1E8P7aFXwHEp60snS83MUnPWc9EMlpulLglxI= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> The only difference is the add-hook, this time using >> window-state-change-hook instead of minibuffer-... >> This leads to the same bug. It's still the same bug. No matter what happens, evaluating (let ((window (selected-window))) (dolist (frame (frame-list)) (with-selected-frame frame)) (eq window (selected-window))) must always yield t. Note, however, that the `with-selected-frame' in your function is not needed. `modify-frame-parameters' works without selecting the frame whose parameter you want to modify. Also I do not understand why you want to modify the cursor in all windows when you enter the minibuffer. Consider the following snippet to set the background of the minibuffer window when it is active (hopefully `active-minibuffer-window' always returns the right value when exiting the minibuffer). (defun foo () (with-current-buffer (window-buffer (active-minibuffer-window)) (set (make-local-variable 'face-remapping-alist) '((default (:background "yellow") default))))) (defun bar () (with-current-buffer (window-buffer (active-minibuffer-window)) (set (make-local-variable 'face-remapping-alist) nil))) (add-hook 'minibuffer-setup-hook #'foo) (add-hook 'minibuffer-exit-hook #'bar) I never tried to remap the cursor color in a buffer-local way, but I think you can figure out how to do that in a similar fashion. martin From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 04:26:42 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 08:26:42 +0000 Received: from localhost ([127.0.0.1]:53564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmXpJ-0004U1-Rw for submit@debbugs.gnu.org; Fri, 28 May 2021 04:26:42 -0400 Received: from mout.gmx.net ([212.227.17.20]:41041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmXpJ-0004Tq-4f for 48674@debbugs.gnu.org; Fri, 28 May 2021 04:26:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622190393; bh=RFg2FgJISvoqlEfiTww/wlX4ewkJnIbpoHPr1oXq0bI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=DjO/BknqKXGOHqFh+5g8a472/7pHgijOSex200gS7jPTXH5CQff9w/+sqULKbaXiH D45e8WussZut3cuICEjHRRwZDBU6FWSiCRMAUj5++cVhw3bFy1J0Mc5NoAeZXMbVjX GU49hLBXNg3QLE2Xdvr9OQT9Omx4hfJpNrhXw+T0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.65]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MulqN-1lVhhC2KEV-00rnQl; Fri, 28 May 2021 10:26:33 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> From: martin rudalics Message-ID: Date: Fri, 28 May 2021 10:26:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:CLkTnGBQS89C8AWlazeFIoBYm9MBK+g1LJnwIUlHWG/ENV1LvHo 9GheXMr9y+oCLTszqtmji0R1xoyNR/60vD//OG1JS5B7SJmNZvDIodjLusz5wITtKPboXzn 2ys6GlfwkYEfHJOlXDAJxdKpk7GIZYQJpZbFKAb05vjhPTJB9Azf/qXEa3wk2jxbF1Ynb66 4ncdT3/LkEHWVLyf72N5Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:wC0vMko5Du8=:/SDN5ktRnb19OMEePobNOv iZ2iMw75ZmJa2J9gX+kXY80MlGKH+jnwhmbcjeip705uhwjrz5dgxYoqoPT7tUeEqWXcbIwdF Jnyx6jUV2xhZJizZDlMHotXQ8dOMYlnigtZv9jl4ymVzkopXZt89QxAwDVWp90X0TPlI5UoNI ZbqtXLCwSyciapg00W7qm1tw+yIxRIIRRNbvZmuCHb/OUqKtKlrQJ49vkbwkgQvK9XU3bVf/r 3un+tafr8gyk7cqyg+SwZDtgw+AbzabQ7qD6XDVqr8gQzepglE+zxM3nRF95OgGLPPA4uNkQ3 n8TIcIBII8OoYweUUDHMxI0HJR2N4qBIkx8Gi5YQG9BmeYRmeTVmBQPuzI2pK2GJgfTZrk5Bf gqPky2Ls2zXXt1LmESQQtVxBrCkXD6+Fk06lCEukMhkPs5SvTj32NxrOVCQD73cN56mBtzWpT KIZHPAlcFVGFbuGLtNUUkae7lqR9v4qCn3RrSOtkY2GAN79AGmbN6E4S7tmDfE833NWyz+J9y p69T/Kv4nsOjqyqSzJl91DxGRTe+lWpUVk41oROzgMcoYNcQ4TNz5eYy/2nuLf5jmTLNkS82X 62bLsM4RaDxAX8f/X7InxDekzDX5pZEmXUso/Wb6XlBEgGEN0u79MQs7BxwJtRljXbZhw70FM 4xsCyzwE+0R6GqS7eHPzqfj9riVWDWQpi8XmicluEAtCcPKViCWu7RFnGeVzJzVRlPcOSqq6P Ty4c8Og6GihgpG/w1xEI1rovRXPTi9lREmsg+p7cZ6nCcZ+wz9z/7XaeTO0UIInWWQeTGqIbN jxK+WldVBNV6mpaLfe50ZfzCktas70MmZfX1iTWh9LQKahfF3ZQ/xD1ZnoY+/ANsVYCfL9ANc VgeaA8kSqb+QkGKgxt/0CbWBnARDH3Uj5C/0uCmNrVX1dtHI3U4fb2BFxhdsr9qhamV+zVPO8 2tooGVnp56iV10b6pm0BU8htBHMMwZ30j90Wu74tt6UWN2FQkPR74Yc6FRtvmHIuPM9Lw29K3 +wDt/ekgW2XnB6m6+oAfnoSCam31pd0IWuYTsI+MikJmUwwpibdlh4pGcM2shQuK2F/hfSPTJ yDouNWh50i+C0ScGCJNrZVgLnB+np56Ejtz X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, =?UTF-8?Q?Iris_Garc=c3=ada?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Does this mean that the > >> Fselect_window (f->selected_window, norecord); > >> in do_switch_frame fails? If so, why? > > For some values of "fails", yes. When we're in frame F1's minibuffer, > and do (with-selected-frame F2 (foo)): > (i) Frame F2 becomes selected. > (ii) The current window in F1 ceases to be the mini-window, becoming some > other window. > (iii) The minibuffer is moved from F1 to F2. > > (iv) We evaluate (foo). > > (v) Frame F1 becomes selected again. > (vi) The current window in F1 doesn't revert to being the mini-window. But why precisely does Fselect_window fail here? > This is what has preoccupied me over the last few hours. It seems we > want do_switch_frame to do different things for (i) a "permanent" frame > switch (e.g. C-x 5 o) and (i) a "temporary" frame switch (e.g. > with-selected-frame). If the selected window in F1 is the mini-window, > we want it to select a different window in (i), but stay the same in > (ii). Be careful in one additional regard: The display engine calls Fselect_window too for its own purposes. >> Are we sure that we want to disallow a function on >> `minibuffer-setup-hook' to change the selected window? With Emacs 27 > > >> (defun foo () >> (select-window (frame-first-window))) > >> (add-hook 'minibuffer-setup-hook 'foo) > > >> works without any problems here. > > Are you sure? For me, that setup makes C-x C-f open a minibuffer, but > leave point in the same window, not the miniwindow. That was a quick try > with the emacs-27 branch, not Emacs 27.{1,2}, and was on a GUI. Yes. But this is an effect the user/application might want - explicitly select some other window to, for example (I'm purely speculating), select a completion window right away. Iris OTOH never wants to select another window explicitly. > I think we should disallow selecting windows in minibuffer-setup-hook. > This hook is run after the mini-window has been selected in read_minibuf, > just before the recursive edit. We cannot disallow it. We can only undo its effect. And that would constitute an incompatible change - do you really want to go for it? martin From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 05:34:33 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 09:34:33 +0000 Received: from localhost ([127.0.0.1]:53632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmYsy-00026u-U1 for submit@debbugs.gnu.org; Fri, 28 May 2021 05:34:33 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:46995) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmYsw-00026g-RK for 48674@debbugs.gnu.org; Fri, 28 May 2021 05:34:31 -0400 Received: by mail-ej1-f48.google.com with SMTP id b9so4315454ejc.13 for <48674@debbugs.gnu.org>; Fri, 28 May 2021 02:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f2CnCB1/d/haWmEh/XV0bNUuVFD0cQsdoqMYmZoF0+U=; b=WY0Xpk1gc3Rn8cUi6KW1Ry/0QAE2RxbijPgxdPFgSTfyHnVyzLu7RzgDps9u1HYPG/ 3irXEs0cCEmB/D0XmtYiYSkIANZULBcCeNIqKVOGqhNMfN0pFAgtDJFLvtP4VHF+a6lg kdoG1thIePkT/Zy6aQ6m02kgj9omTDKxMO2+tcv2yHcf4t3O78Lnt2VQcsMXUwJ84P1T AQRvMbzEMZRp4nN2vtOExkH0LujySarEM1pkEh3qIZQQrEJ8Up1Ln0Zn3WENtVySSMN3 dRkJza6NNiKVIMAUyId3zFolK+ORmFfbiHZcE2R+XvlHC1vhYBctfeR8XX2iPnEa3Dve rEww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f2CnCB1/d/haWmEh/XV0bNUuVFD0cQsdoqMYmZoF0+U=; b=o+6mO9H8wTLpPEf97wLg3FpfyqmPUK8002baspzLpn/xT5ZvxYCWTIFB2UX98SgzNh /nFzFL5DtCtM6dCNcXDyg0wyObc/oOOr5MsFWLURGISfHVnv8VT/jxTUiAUFfH0pSJkP g0qPN5oth5BVuWiUM8e6SWzgvXVgLht5qCZRkHukgCA3KuVGKIKYQN+k1ei/xx5oU+fj ZojqBqQNqAzZKAwMkQbtwAdBuuPNM1Ft3MdeNqIz0bxHm1Oh5SzDStCBICN8PNmPIJ68 9oaUbvELYatyxdAG3TXZUx1bKGu22v2bQ6368zqGEuBp+DnPsSNi0BgGbxNQat/beGWt O93w== X-Gm-Message-State: AOAM530eifEl7oWxsvKxpi0dd4fvHvgpkNslUeENn9qzxbH0XgtMsHU7 nYBZrGxHTWwoykh9UhAbcrjYZ9pGMDasoEKjj4E= X-Google-Smtp-Source: ABdhPJwhSg5arXz+4sqeIUvTE1HpudQnrW8SXZ9APrnN/5p95pLWnrEe6KnnLet7mvZMnA68N0fWMcT0KRs82ncbiws= X-Received: by 2002:a17:907:1c20:: with SMTP id nc32mr8278774ejc.105.1622194464907; Fri, 28 May 2021 02:34:24 -0700 (PDT) MIME-Version: 1.0 References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> In-Reply-To: From: =?UTF-8?B?SXJpcyBHYXJjw61h?= Date: Fri, 28 May 2021 11:34:13 +0200 Message-ID: Subject: Re: bug#48674: Frames and minibuffer bug To: martin rudalics Content-Type: multipart/alternative; boundary="000000000000d6673205c36094a2" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d6673205c36094a2 Content-Type: text/plain; charset="UTF-8" Hi Martin, Thanks for the comments, to be honest, my elisp knowledge is very limited and I wanted to learn by doing a modal editing package. This package has two modes: normal and insert, I like to change the cursor color and type according to the active editing mode. For this reason, I have a hook in the minibuffer, so everytime I open the minibuffer I want to switch to insert mode and this triggers the cursor update in every frame then when the minibufer is closed go back to normal mode and again update the cursor in every frame. I'm pretty sure there are better ways to achieve this, but this was the one I got working in Emacs 27. I'm happy to share the entire code if that helps but I think the point here is the bug is real and should be fixed no? In the meantime, I'll take your snippet (thanks for that) and try to edit my package to workaround the bug. Regards, Iris. On Fri, 28 May 2021 at 10:25, martin rudalics wrote: > >> The only difference is the add-hook, this time using > >> window-state-change-hook instead of minibuffer-... > >> This leads to the same bug. > > It's still the same bug. No matter what happens, evaluating > > (let ((window (selected-window))) > (dolist (frame (frame-list)) > (with-selected-frame frame)) > (eq window (selected-window))) > > must always yield t. > > Note, however, that the `with-selected-frame' in your function is not > needed. `modify-frame-parameters' works without selecting the frame > whose parameter you want to modify. Also I do not understand why you > want to modify the cursor in all windows when you enter the minibuffer. > > Consider the following snippet to set the background of the minibuffer > window when it is active (hopefully `active-minibuffer-window' always > returns the right value when exiting the minibuffer). > > > (defun foo () > (with-current-buffer (window-buffer (active-minibuffer-window)) > (set (make-local-variable 'face-remapping-alist) > '((default (:background "yellow") default))))) > > (defun bar () > (with-current-buffer (window-buffer (active-minibuffer-window)) > (set (make-local-variable 'face-remapping-alist) nil))) > > (add-hook 'minibuffer-setup-hook #'foo) > (add-hook 'minibuffer-exit-hook #'bar) > > > I never tried to remap the cursor color in a buffer-local way, but I > think you can figure out how to do that in a similar fashion. > > martin > --000000000000d6673205c36094a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for the co= mments, to be honest, my elisp knowledge is very limited and I wanted to le= arn by doing a modal editing package.

This package= has two modes: normal and insert, I like to change the cursor color and ty= pe according to the active editing mode.

For this = reason, I have a hook in the minibuffer, so everytime I open the minibuffer= I want to switch to insert mode and this triggers the
cursor upd= ate in every frame then when the minibufer is closed go back to normal mode= and again update the cursor in every frame.

I'= ;m pretty sure there are better ways to achieve this, but this was the one = I got working in Emacs 27.

I'm happy to share = the entire code if that helps but I think the point here is the bug is real= and should be fixed no?

In the meantime, I'll= take your snippet (thanks for that) and try to edit my package to workarou= nd the bug.

Regards,

Iris= .

On Fri, 28 May 2021 at 10:25, martin rudalics <rudalics@gmx.at> wrote:
=C2=A0>> The only difference is t= he add-hook, this time using
=C2=A0>> window-state-change-hook instead of minibuffer-...
=C2=A0>> This leads to the same bug.

It's still the same bug.=C2=A0 No matter what happens, evaluating

(let ((window (selected-window)))
=C2=A0 =C2=A0(dolist (frame (frame-list))
=C2=A0 =C2=A0 =C2=A0(with-selected-frame frame))
=C2=A0 =C2=A0(eq window (selected-window)))

must always yield t.

Note, however, that the `with-selected-frame' in your function is not needed.=C2=A0 `modify-frame-parameters' works without selecting the fra= me
whose parameter you want to modify.=C2=A0 Also I do not understand why you<= br> want to modify the cursor in all windows when you enter the minibuffer.

Consider the following snippet to set the background of the minibuffer
window when it is active (hopefully `active-minibuffer-window' always returns the right value when exiting the minibuffer).


(defun foo ()
=C2=A0 =C2=A0(with-current-buffer (window-buffer (active-minibuffer-window)= )
=C2=A0 =C2=A0 =C2=A0(set (make-local-variable 'face-remapping-alist) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'((default (:background "yellow&= quot;) default)))))

(defun bar ()
=C2=A0 =C2=A0(with-current-buffer (window-buffer (active-minibuffer-window)= )
=C2=A0 =C2=A0 =C2=A0(set (make-local-variable 'face-remapping-alist) ni= l)))

(add-hook 'minibuffer-setup-hook #'foo)
(add-hook 'minibuffer-exit-hook #'bar)


I never tried to remap the cursor color in a buffer-local way, but I
think you can figure out how to do that in a similar fashion.

martin
--000000000000d6673205c36094a2-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 05:52:04 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 09:52:05 +0000 Received: from localhost ([127.0.0.1]:53663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmZ9w-0002c8-Pa for submit@debbugs.gnu.org; Fri, 28 May 2021 05:52:04 -0400 Received: from mout.gmx.net ([212.227.17.22]:58931) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmZ9v-0002bd-Mq for 48674@debbugs.gnu.org; Fri, 28 May 2021 05:52:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622195516; bh=QFHvNXbEa0JujJQMsWW+MyIMtFRd84ToF3StZtDIu/w=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=HFHUYeQAQsqTvTZlbicovCJOZC2fzcpf+Bfp4FIq525HuaWWbekVDQqR0apGasaQj i7jr2pY0zfvAJI5OEi1mddNnPxSyzoi/cGko9gSFZyCi7tdzQ8UHrp3/OFJM+X3hO9 GDgVeaz4ymEeFpnNCiIkUh6PqeeoqZlzZ1UIL9to= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.5.98]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MOiDX-1m3viG3sdj-00QD3E; Fri, 28 May 2021 11:51:56 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: =?UTF-8?Q?Iris_Garc=c3=ada?= References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> From: martin rudalics Message-ID: Date: Fri, 28 May 2021 11:51:54 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:k9u8b+VF5z+6r0rp0SY+7aQL8cYa1I2nm7PEMLQ994a9iSyDHSN 2dlu3M5HQ7DfLDjISy7kxyBkAIn/eY/3FivW73U7AscS4d3D/1BWQdWptRizfKuoHHSJuQK Bdit330ZoF8uFWxyWCD6EBRSM57J1jz5IohsBLA1vNiL2OGZGfhGt5NFaBME0eoC8+ADMq5 VN+NqF8XLstsyk0nNKPPw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:NeAtMFe4PyI=:wZlIc69HDVUkHqsvZdZIaT AnOG2uv2jUnsEmfJ9oNYexwK75NavxJGvaiBasNVIapE3UPSXEO9aGtOshs1kJ8xpYlPCXyqd fII7lxRaLOFmNLobj/yflD35Wwg/msf3P3e0yTAJH/Ipb9wg85sbFo795PtAFmD90X5PmLRTt w8lgIWwhIOZ3Gie3Xs8ydnm5ANkaerq3UOf9xwQEK6V86gCLWcHxY1MUnK+AYP9+CHNmEjrKW o34iqqUalIFgXbmIEFd5wQ05YBsJrZiBE8niCYEROMp92yF58C6MVihF//nQDbkI26hWa+g5W nZcOixfOfip9YL3w4nvMyjlQ4P/v43He0BlHZ275BUClMFB4hLF5T5cwd69qAqJK+fCsxOKt2 qUEuazmJdr/cY/KsVLt6MprEsirzBalaRr27vzX89V4kAhUrYhGeiZnaiPxA+6+RQJefc+tbJ vjhXpQxevSNEhA33ELTeaGRieKMc/gmPQwfycdarQsy/g5nmRnGlaMihT8h6UrV8GAOCTKQJq WOQv3DFd4cSSqyar2S9EXA90znI7JySiT+wfuZy4FK5pvaYBk8IxsqTWM+PQrkXOIf7nEW08S y4N4yvRvT1AetJDksdIaVpCYyc7wS5sO+Cg9Xgj0x4kPvmQFbBQgGr9VJnS5VwicWHiH0ii2C xJHMksrf4R0FOO+qxYX65kQk3SbFxjeRZSd2JyOalWH8gAxD+Nudm+5q057+2TSuF6XHXkSC3 xHSd+vyzrMJ7BCYtYulmpT0bOM4B0CXsM6St4VSTOFpRkakpHaaeLDOaZPWZSF2VuYjEcjgRu yv5yxHREepHk/1nFtDH/WZDrU9Sl3nQ/flkytuAQVe6pmF9xv5ZHzgpJHVEI3QYspWoAes9yw 4QO4L51nkt9cvPB6voU7cEdkAyfOC9JnmjXLefkNz8IHbXuOqeM3visFTh6FBjTw0lRFCheqQ M3a/XHkOPECCUveziYd+tpoCbfBR5mJZ60N+XGiHWDsz8+y8tfJW4Br4b4NZQzHVInzjPKNsV l3CgHYKlJ3dpHT5y+HlDCsKBN9LOTtXA1cAZaXLEdTwNjhB9Q0xAkPZPkNZchH9SHmmevd2pQ ayTzsu4/d2YQMVHz8eD8yw+vrEyEKUvhB/XiJYv6IMz5wDrVEUlAjmlOCn0o9MniTBOIDE8cn KS/5T8whfn7w6Sxa+0KF4NLbIEPIttDa1/9NQKc7IZDmkDs4APtyLorVx3vxgW25zqX46Uu6+ QwjrjzI6p1WN4Z8JS X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Alan Mackenzie X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I'm happy to share the entire code if that helps but I think the point here > is the bug is real and should be fixed no? The bug is real and should be fixed. martin From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 13:15:46 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 17:15:46 +0000 Received: from localhost ([127.0.0.1]:55267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmg5K-0008Pl-Gr for submit@debbugs.gnu.org; Fri, 28 May 2021 13:15:46 -0400 Received: from colin.muc.de ([193.149.48.1]:44182 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmg5I-0008PY-R2 for 48674@debbugs.gnu.org; Fri, 28 May 2021 13:15:45 -0400 Received: (qmail 22149 invoked by uid 3782); 28 May 2021 17:15:37 -0000 Received: from acm.muc.de (p4fe155b9.dip0.t-ipconnect.de [79.225.85.185]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 28 May 2021 19:15:37 +0200 Received: (qmail 8528 invoked by uid 1000); 28 May 2021 17:15:37 -0000 Date: Fri, 28 May 2021 17:15:37 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin. On Fri, May 28, 2021 at 10:26:32 +0200, martin rudalics wrote: > >> Does this mean that the > >> Fselect_window (f->selected_window, norecord); > >> in do_switch_frame fails? If so, why? > > For some values of "fails", yes. When we're in frame F1's minibuffer, > > and do (with-selected-frame F2 (foo)): > > (i) Frame F2 becomes selected. > > (ii) The current window in F1 ceases to be the mini-window, becoming some > > other window. > > (iii) The minibuffer is moved from F1 to F2. > > (iv) We evaluate (foo). > > (v) Frame F1 becomes selected again. > > (vi) The current window in F1 doesn't revert to being the mini-window. > But why precisely does Fselect_window fail here? Sorry, my last night's reply wasn't very clear. That Fselect_window in do_switch_frame will fail when a later Fselect_window (or more precisely, Fset_frame_selected_window) in move_minibuffers_onto_frame selects a different window for that frame. That happens when with-selected-frame selects a different frame, moving the minibuffers onto that other frame. I have another idea for solving this problem. Suppose when we switch from F1 to F2, and F1's selected window is the mini-window, we allow F1 to remain in the MW. The minibuffer stack gets moved to F2. Some sort of commands or Lisp runs in F2, then we return to F1. Should any minibuffer come back to F1, we allow the MW to remain selected. Otherwise we select a different window in F1. I think this would work better that what I proposed last night. I'll try and formulate a patch for this this evening. > > This is what has preoccupied me over the last few hours. It seems > > we want do_switch_frame to do different things for (i) a "permanent" > > frame switch (e.g. C-x 5 o) and (i) a "temporary" frame switch (e.g. > > with-selected-frame). If the selected window in F1 is the > > mini-window, we want it to select a different window in (i), but > > stay the same in (ii). > Be careful in one additional regard: The display engine calls > Fselect_window too for its own purposes. .... and Fselect_window calls Fselect_frame, if needed. This hits the same problem. > >> Are we sure that we want to disallow a function on > >> `minibuffer-setup-hook' to change the selected window? With Emacs 27 > >> (defun foo () > >> (select-window (frame-first-window))) > >> (add-hook 'minibuffer-setup-hook 'foo) > >> works without any problems here. > > Are you sure? For me, that setup makes C-x C-f open a minibuffer, > > but leave point in the same window, not the miniwindow. That was a > > quick try with the emacs-27 branch, not Emacs 27.{1,2}, and was on a > > GUI. > Yes. But this is an effect the user/application might want - explicitly > select some other window to, for example (I'm purely speculating), select > a completion window right away. Iris OTOH never wants to select another > window explicitly. OK. > > I think we should disallow selecting windows in minibuffer-setup-hook. > > This hook is run after the mini-window has been selected in read_minibuf, > > just before the recursive edit. > We cannot disallow it. We can only undo its effect. And that would > constitute an incompatible change - do you really want to go for it? Maybe not. I'm going to write a patch as outlined above, which might well be easier to follow than my text above. I think it might well fix the bug properly. > martin -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri May 28 16:14:50 2021 Received: (at 48674) by debbugs.gnu.org; 28 May 2021 20:14:50 +0000 Received: from localhost ([127.0.0.1]:55417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmisc-0002Wc-Bs for submit@debbugs.gnu.org; Fri, 28 May 2021 16:14:50 -0400 Received: from colin.muc.de ([193.149.48.1]:49331 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmisa-0002WN-7w for 48674@debbugs.gnu.org; Fri, 28 May 2021 16:14:49 -0400 Received: (qmail 39000 invoked by uid 3782); 28 May 2021 20:14:41 -0000 Received: from acm.muc.de (p4fe155b9.dip0.t-ipconnect.de [79.225.85.185]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 28 May 2021 22:14:41 +0200 Received: (qmail 27328 invoked by uid 1000); 28 May 2021 20:14:41 -0000 Date: Fri, 28 May 2021 20:14:41 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin. On Fri, May 28, 2021 at 17:15:37 +0000, Alan Mackenzie wrote: > On Fri, May 28, 2021 at 10:26:32 +0200, martin rudalics wrote: [ .... ] > > But why precisely does Fselect_window fail here? > Sorry, my last night's reply wasn't very clear. That Fselect_window in > do_switch_frame will fail when a later Fselect_window (or more precisely, > Fset_frame_selected_window) in move_minibuffers_onto_frame selects a > different window for that frame. That happens when with-selected-frame > selects a different frame, moving the minibuffers onto that other frame. > I have another idea for solving this problem. Suppose when we switch > from F1 to F2, and F1's selected window is the mini-window, we allow F1 > to remain in the MW. The minibuffer stack gets moved to F2. Some sort > of commands or Lisp runs in F2, then we return to F1. Should any > minibuffer come back to F1, we allow the MW to remain selected. > Otherwise we select a different window in F1. > I think this would work better that what I proposed last night. I'll try > and formulate a patch for this this evening. I think the following patch, along the above lines, solves the bug completely. Could you review it for me, please? diff --git a/src/minibuf.c b/src/minibuf.c index cffb7fe787..c97a672ad6 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -192,10 +192,10 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion) struct frame *f = XFRAME (selected_frame); minibuf_window = f->minibuffer_window; - if (!(minibuf_level - && (for_deletion || minibuf_follows_frame () || FRAME_INITIAL_P (of)))) + if (!(for_deletion || minibuf_follows_frame () || FRAME_INITIAL_P (of))) return; - if (FRAME_LIVE_P (f) + if (minibuf_level + && FRAME_LIVE_P (f) && !EQ (f->minibuffer_window, of->minibuffer_window) && WINDOW_LIVE_P (f->minibuffer_window) /* F not a tootip frame */ && WINDOW_LIVE_P (of->minibuffer_window)) @@ -203,15 +203,12 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion) zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window); if (for_deletion && XFRAME (MB_frame) != of) MB_frame = selected_frame; - if (!for_deletion - && MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of)))) - { - Lisp_Object old_frame; - XSETFRAME (old_frame, of); - Fset_frame_selected_window (old_frame, - Fframe_first_window (old_frame), Qnil); - } } + /* If the new frame's selected window is the mini-window, select + some other window if we don't have an active minibuffer there. */ + if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f))) + && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents)) + Fselect_window (Fframe_first_window (selected_frame), Qnil); } DEFUN ("active-minibuffer-window", Factive_minibuffer_window, -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 29 05:21:17 2021 Received: (at 48674) by debbugs.gnu.org; 29 May 2021 09:21:17 +0000 Received: from localhost ([127.0.0.1]:56004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmv9h-0001yv-11 for submit@debbugs.gnu.org; Sat, 29 May 2021 05:21:17 -0400 Received: from mout.gmx.net ([212.227.15.18]:52779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmv9b-0001ye-QM for 48674@debbugs.gnu.org; Sat, 29 May 2021 05:21:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622280060; bh=s0l/7Qaj01xLaDhk7Yy+SKHQ9A0KZ5mqttuupzqcf+U=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=SVRi8NRux6Mimod8CMomFcdCj4xEFkN7TFgILz7iNEndCqhXtHykYoSltb8cVH9Rd 9FgDf/Rn0/S9TGV/bSzjZGr8I6m4It/z7RVx4DGBzg+h8B9Exm64VnNYjFLENEQ4Rx X1nxwDUzwxCQTNwYbya3mCPEjJHQtBWtHGHoA8mY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([213.142.96.193]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhD2O-1l8vUs2SsU-00eM7R; Sat, 29 May 2021 11:21:00 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> From: martin rudalics Message-ID: <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> Date: Sat, 29 May 2021 11:20:58 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:mRu6T7f57avz8nJWFlZ5gUz+FzcTdtdGWyS8Kolw1sqSeWLmcP+ Ypps4Y9eiooxUr40k4F5ecyboc67dbDHExGfuA0OrxMDXnyr6ElKaPIYPB69ljyWR9fuIrN Qkvhnmd5KTiksSdvWbQ9yhuK1K6dSqjTA6vopYder3bDOYJmYR5QhHO7lv5bVsiIWXn21T/ L0vLDGi1IxJABy02PpxRw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DKyZJFzDtl8=:M45SHa4v02ZUxCwRJCHRa3 BwMFdhZ3mDwYuA/OhtP2PlL0pWQQTH0BTP6rqcvSG8kZXr7AoGU9mK3+DUXM1wR44OPbokSpc ps+TGRDvPosuLQZ0PmhrNv1CP0XIQHoIGTTWJ5hwg2yqBBfz5/3kQ9PXOn6rgIk84iWU/cFOm zetTDXXbCCi0O3pMoGUWIHYRMkjQc1F30RaY7HCF/gBCv+SoNy3qmCSym3TmMiLz8GWJq5DI/ RUa5/5YA1rfigKmaswUGQQ4FFsnf+JFuBE9JB6fff538PLxLC+HxaYLgSSH4MKunB1O6nDy3W 8oPmHzvKMmotMf3byYshfmJgt9vgQzxNJhzuNu9Tmg13diJWTF7g0ts6fqiME9ScKPTOVGLD6 eEvIZqfXlZHPbCVwgDTHdRppwJSGy5FISzPf5sBYI4ihh0OPg11GXQo04vmLwR3+vw+8U+SPB MplccXHEyxZnITt0cRzaRxt02nAtMsCKLpdQzTm5+kI7e3RpmOiX8BJ0cDdIbnnmCgRSP+xhc s5RzzGeeqHrWY6dX1wMefjimgULD0UpVK2bVdkCaAUJ+fasPdpwPMwyBs0s9MZgCFbZf3E/nZ uqqKE/sAbxd2kGd5zdrTInfAL3P9rW773Yt6M+FqzGYmvb/SGG49QPO2G9D7tfc93F0v4D7it 0E1Am40kAs1iu53eiDOB7AAcTxXHR95qs3ypY7lnnBl98HFJcbM1kUEV6r+CqGWDieOd322y0 5XPsQFsmqdLEM2jPQdSnyoQwx0x6+Mfu1ST1DnOg1/ufzyMeRwGWgQVEhEF+onHOGu+/RC6eP yioNfTiM/nJcFZQJr31c6kfy7/802d2KVGqMEapLHNoUeV7NTYlbR3g8/+Jia8yzvobTwPROK VjHKEbDN/PAcKAkWETCLULoK6D+hdTYoRLgvmhgaDeNhIS31EYeVcgZrdK/S7+nrY0N9+Vswb 7JZxeMj+y6ilybd+eLzhESqMNev0UW2bRDKqSNMT+AgsGQyoPzxgkUVSoEyl43kszB5eQ34Y5 Z2xsH6KPX9N8KD71EAu1A6dT3iq0X94iU8LmGtjuJjrbjL5zTBTd8UmeKqq10aTKHY6MHOKiD xVubqLiBLjLuwgoJMvbwi4OK/LCk0j1uuPs X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, =?UTF-8?Q?Iris_Garc=c3=ada?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I think the following patch, along the above lines, solves the bug > completely. Could you review it for me, please? It fixes the bug and the potential use case I mentioned earlier. But for this part /* If the new frame's selected window is the mini-window, select some other window if we don't have an active minibuffer there. */ if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f))) && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents)) Fselect_window (Fframe_first_window (selected_frame), Qnil); I would first have to understand why such a minibuffer window should be OT1H its frame's selected window and OTOH not be active when switching back to that frame. As a user I can always do (select-window (minibuffer-window)) regardless of whether a minibuffer is active. Switching away from that window's frame and back to it is problematic in Emacs 27 - no window has the active cursor. You apparently fixed this by selecting the frame's first window when switching back. Right? One reason why I ask is because with emacs -Q and the present patch (setq default-frame-alist '((minibuffer . nil))) followed by C-x 5 2 and (select-window (minibuffer-window)) in the new frame violates the assertion on line 548 of window.c /* Fselect_frame called us back so we've done all the work already. */ eassert (EQ (window, selected_window)); with the backtrace below. Basically, I would try to avoid that a non-selected frame's selected window is an inactive minibuffer window. But I'm not sure how difficult it is to achieve that. martin #0 0x00000000005ac2a7 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at ../../src/emacs.c:400 #1 0x00000000006593a5 in die (msg=0x792187 "EQ (window, selected_window)", file=0x791f12 "../../src/window.c", line=548) at ../../src/alloc.c:7451 #2 0x00000000004c8185 in select_window (window=XIL(0x11109dd), norecord=XIL(0), inhibit_point_swap=false) at ../../src/window.c:548 #3 0x00000000004c8315 in Fselect_window (window=XIL(0x11109dd), norecord=XIL(0)) at ../../src/window.c:625 #4 0x000000000069110e in eval_sub (form=XIL(0x1102163)) at ../../src/eval.c:2517 #5 0x000000000068af94 in Fprogn (body=XIL(0)) at ../../src/eval.c:471 #6 0x0000000000690cfc in eval_sub (form=XIL(0x1102123)) at ../../src/eval.c:2467 #7 0x0000000000690661 in Feval (form=XIL(0x1102123), lexical=XIL(0x30)) at ../../src/eval.c:2343 #8 0x0000000000692dc5 in funcall_subr (subr=0xc61600 , numargs=2, args=0x7fffffffce80) at ../../src/eval.c:3116 #9 0x000000000069285e in Ffuncall (nargs=3, args=0x7fffffffce78) at ../../src/eval.c:3039 #10 0x00000000006ec8e5 in exec_byte_code (bytestr=XIL(0x7ffff3e1e10c), vector=XIL(0x7ffff3e1ccd5), maxdepth=make_fixnum(18), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd380) at ../../src/bytecode.c:632 #11 0x0000000000693026 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3e1cca5), syms_left=make_fixnum(257), nargs=1, args=0x7fffffffd378) at ../../src/eval.c:3163 #12 0x00000000006934ac in funcall_lambda (fun=XIL(0x7ffff3e1cca5), nargs=1, arg_vector=0x7fffffffd378) at ../../src/eval.c:3244 #13 0x00000000006928b2 in Ffuncall (nargs=2, args=0x7fffffffd370) at ../../src/eval.c:3043 #14 0x00000000006ec8e5 in exec_byte_code (bytestr=XIL(0x7ffff3e1e38c), vector=XIL(0x7ffff3e1cc45), maxdepth=make_fixnum(4), args_template=make_fixnum(257), nargs=1, args=0x7fffffffd978) at ../../src/bytecode.c:632 #15 0x0000000000693026 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3e1cc0d), syms_left=make_fixnum(257), nargs=1, args=0x7fffffffd970) at ../../src/eval.c:3163 #16 0x00000000006934ac in funcall_lambda (fun=XIL(0x7ffff3e1cc0d), nargs=1, arg_vector=0x7fffffffd970) at ../../src/eval.c:3244 #17 0x00000000006928b2 in Ffuncall (nargs=2, args=0x7fffffffd968) at ../../src/eval.c:3043 #18 0x000000000068656e in Ffuncall_interactively (nargs=2, args=0x7fffffffd968) at ../../src/callint.c:260 #19 0x0000000000692c98 in funcall_subr (subr=0xc60e40 , numargs=2, args=0x7fffffffd968) at ../../src/eval.c:3094 #20 0x000000000069285e in Ffuncall (nargs=3, args=0x7fffffffd960) at ../../src/eval.c:3039 #21 0x0000000000688bf4 in Fcall_interactively (function=XIL(0x7ffff3134918), record_flag=XIL(0), keys=XIL(0x7ffff4375585)) at ../../src/callint.c:791 #22 0x0000000000692df1 in funcall_subr (subr=0xc60e80 , numargs=3, args=0x7fffffffdd40) at ../../src/eval.c:3119 #23 0x000000000069285e in Ffuncall (nargs=4, args=0x7fffffffdd38) at ../../src/eval.c:3039 #24 0x00000000006ec8e5 in exec_byte_code (bytestr=XIL(0x7ffff3db0ccc), vector=XIL(0x7ffff3db0935), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7fffffffe2b0) at ../../src/bytecode.c:632 #25 0x0000000000693026 in fetch_and_exec_byte_code (fun=XIL(0x7ffff3db0905), syms_left=make_fixnum(1025), nargs=1, args=0x7fffffffe2a8) at ../../src/eval.c:3163 #26 0x00000000006934ac in funcall_lambda (fun=XIL(0x7ffff3db0905), nargs=1, arg_vector=0x7fffffffe2a8) at ../../src/eval.c:3244 #27 0x00000000006928b2 in Ffuncall (nargs=2, args=0x7fffffffe2a0) at ../../src/eval.c:3043 #28 0x000000000069217b in call1 (fn=XIL(0x43e0), arg1=XIL(0x7ffff3134918)) at ../../src/eval.c:2899 #29 0x00000000005b4838 in command_loop_1 () at ../../src/keyboard.c:1466 #30 0x000000000068e3bd in internal_condition_case (bfun=0x5b3fdf , handlers=XIL(0x90), hfun=0x5b35ee ) at ../../src/eval.c:1478 #31 0x00000000005b3bc4 in command_loop_2 (ignore=XIL(0)) at ../../src/keyboard.c:1094 #32 0x000000000068d59a in internal_catch (tag=XIL(0xe100), func=0x5b3b97 , arg=XIL(0)) at ../../src/eval.c:1198 #33 0x00000000005b3b62 in command_loop () at ../../src/keyboard.c:1073 #34 0x00000000005b30d5 in recursive_edit_1 () at ../../src/keyboard.c:720 #35 0x00000000005b32cd in Frecursive_edit () at ../../src/keyboard.c:789 #36 0x00000000005af1a4 in main (argc=2, argv=0x7fffffffe7c8) at ../../src/emacs.c:2298 Lisp Backtrace: "select-window" (0xffffcaa0) "progn" (0xffffcc50) "eval" (0xffffce80) "elisp--eval-last-sexp" (0xffffd378) "eval-last-sexp" (0xffffd970) "funcall-interactively" (0xffffd968) "call-interactively" (0xffffdd40) "command-execute" (0xffffe2a8) (gdb) From debbugs-submit-bounces@debbugs.gnu.org Sat May 29 09:10:20 2021 Received: (at 48674) by debbugs.gnu.org; 29 May 2021 13:10:20 +0000 Received: from localhost ([127.0.0.1]:56285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmyjM-0003lz-4O for submit@debbugs.gnu.org; Sat, 29 May 2021 09:10:20 -0400 Received: from colin.muc.de ([193.149.48.1]:20438 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lmyjI-0003ld-Au for 48674@debbugs.gnu.org; Sat, 29 May 2021 09:10:18 -0400 Received: (qmail 42628 invoked by uid 3782); 29 May 2021 13:10:09 -0000 Received: from acm.muc.de (p2e5d5176.dip0.t-ipconnect.de [46.93.81.118]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 May 2021 15:10:09 +0200 Received: (qmail 697 invoked by uid 1000); 29 May 2021 13:10:09 -0000 Date: Sat, 29 May 2021 13:10:09 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin. On Sat, May 29, 2021 at 11:20:58 +0200, martin rudalics wrote: > > I think the following patch, along the above lines, solves the bug > > completely. Could you review it for me, please? Thanks for the review. I withdraw my assertion about a complete solution to the bug. :-( > It fixes the bug and the potential use case I mentioned earlier. But > for this part > /* If the new frame's selected window is the mini-window, select > some other window if we don't have an active minibuffer there. */ > if (MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (f))) > && !live_minibuffer_p (XWINDOW (FRAME_SELECTED_WINDOW (f))->contents)) > Fselect_window (Fframe_first_window (selected_frame), Qnil); > I would first have to understand why such a minibuffer window should be > OT1H its frame's selected window and OTOH not be active when switching > back to that frame. When the user switches from F1 to F2 with C-x 5 o, and there was an active minibuffer on F1, that MB gets moved to F2. The user then terminnates the MB....then switches back to F1. There is no longer an active MB. > As a user I can always do > (select-window (minibuffer-window)) > regardless of whether a minibuffer is active. Switching away from that > window's frame and back to it is problematic in Emacs 27 - no window has > the active cursor. You apparently fixed this by selecting the frame's > first window when switching back. Right? Yes. > One reason why I ask is because with emacs -Q and the present patch > (setq default-frame-alist '((minibuffer . nil))) > followed by C-x 5 2 and > (select-window (minibuffer-window)) > in the new frame violates the assertion on line 548 of window.c > /* Fselect_frame called us back so we've done all the work already. */ > eassert (EQ (window, selected_window)); > with the backtrace below. Just as a quick aside, how do I configure Emacs so as to generate these easserts? At the moment I've got CFLAGS='-O0 -g3' and --enable-checking in my ./configure command line. I think I'm missing something. > Basically, I would try to avoid that a non-selected frame's selected > window is an inactive minibuffer window. But I'm not sure how difficult > it is to achieve that. That's the way it currently is (without the patch). It is difficult to make it work properly. Maybe the best workaround would be to create a new flag in struct frame, which when set means "select mini-window if "possible" when selecting this frame". "Possible" meaning there's an active MB. (i) This flag would be set, somehow, by with-selected-frame when moving away from F1. (ii) do_switch_frame would test this flag, act on it, and clear it. f->flag would always be clear when f is the selected frame. With this, F1's selected window would be moved away from the mini-window and the flag set, when F2 gets selected. Or something like that. What do you think? > martin [ Backtrace snipped, but understood. ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 29 11:13:11 2021 Received: (at 48674) by debbugs.gnu.org; 29 May 2021 15:13:11 +0000 Received: from localhost ([127.0.0.1]:57552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0eE-00078N-Qk for submit@debbugs.gnu.org; Sat, 29 May 2021 11:13:11 -0400 Received: from mout.gmx.net ([212.227.17.22]:53741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0eB-00077p-0G for 48674@debbugs.gnu.org; Sat, 29 May 2021 11:13:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622301179; bh=dp/BEeeF3+NEnqvdUP2zDA5ozDjoch5nU6RCXug8Buw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=gMUaVARd780yE21dh4Q//ZqFWzHi089CdjQHdZ30lyr6UW6Z0bvWgiHCfPrxrKxNa lij7G7ABFoqF65anIhYhWykOgadiSSZw3zovzRZ3eq+N+xKGo9oPX9c7774NTdOPuI acSTXZGKdpCQXfDZ0CXvsrD5AJHQm5jcbcUMXtIE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([212.95.7.233]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MrQJ5-1l1b3s0y3D-00oYCx; Sat, 29 May 2021 17:12:59 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> From: martin rudalics Message-ID: <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> Date: Sat, 29 May 2021 17:12:58 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:858OmK/YHc+55eNFXpqx8FklWkDcdIN/jLaK42+s7VFytbBSEha V16n1lb6P5YS0tA62Ad+0u5AZmZlvBnDbFskyE2V01q9Z7VDydo9xHRBpNrAW2mSpmIWgAd O+OI9R0qoiaFNToD6HyqyYvuaUrd4PYlA+/lATMlYk6YYfnRWm+3ssLtBtLjGpcEAHc/L9f e4JtGj21/J0rgDUbXSCJQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QZcr3tkFGrM=:YysFBDwTazhDqdXZ0e8WIv c/Jnh9FKXlcWl2jBKy6aPVXz4+3dFUXugNlTbA+BnJofgVtqrfoMqNWws8EpEY29KRIsz3+pv D/iazAm1AvZHgdh96kWNuEPl6awUTTmsSy4pNCBj+G6sVaMQ6zjCbg7eBNvPBiRMQB1u8YLTn 7TDo9zkwEaWV0NyxWmlLJ+p+Y9pa1CqcWsb9LJUPOri4y4eKcJXlRSUfCFMlx6yFUcCHOooq5 UXQI5iJXPB/qr4RWnM3YPQMD+W3A7t/JFWdveUZKGerXByecEyV2wPFGNqmkQK1hFZ0ujFrvz 2swuivm9Ke80I+EJB/4vg7STO2MKa/9J3oaqLGecerSTXjXsh4WQLueJxSgXz0qzIrtW5hjzt b/aUyHFobDEHD3Fa3ZvDtdTV4p5PW7mc8FQRYFGlKMx76XeOBFoIpzxwMW/oqRPeOby/2A7Q6 XWCbOCVVpQtJqP655+KDCtdlZVb0KQ8xlWBh08oN5MDDmmjAuYUEzYwaU77bDZaJ2JTZOHQcy UcsXweaLJicBqrtS/zhIOO/sm1tFp6RBMTFCVDzVMGVsJGDWZpRqsUorLAgLlGMusC+FmXqBD vGKQK9dG5XAg1XinKwt89pi2usE84y/CCDsCkqtkIzX3I5ZG6ylVce3CBeypPzCD1s3dcVQjj 7QIrsvdswzSe49qmgSWGOUpzayMVdeSOWVH93JLQojJ2q+5u+Bmk+q0kJFMPAOdez2RBVuCG6 fZCLHV6g/PHtVlgJpJEuZW4iFCRCtzJzs0Uw9vpLrWRKftKHyOw8qw8RXqgBOrQ4pxjFSDibS Ylz194zKRNTccYrG2dJdw5etI6X/UGjcB4NcNbKAmGqEpU+TW0AfOO2GczwjA4wbdYd8hkdhG YNthTLusBN8fGIK1Qgb0CBIGUubiRo8xwoLrx+SZBiZdEFABuGhmzsRBpivd3dpas0n4PLfQZ K6QOa3ib/0c7da02pckMAPApEhhTPjSAR+uvE2M6komRwgufK7OiJkE3kSRrZEpJdV4Wd5er/ T2EEVDddE+ZCsaKn+zXHq2MfL0CAEKaOQrQDTFiDaStdcJDx6Z1WprRVWn5gkoEd0OaC2qmL/ OOxBUlOGGzv0oJN6Q28+rO92xKfuv/zGUY8oUImEANaF/5AaR/BNG9gE1Exagu1+cKK7gW0NG 7WAPm+Q8yfysiXbuWdeIk6nSZYX0YzQHzbqRoQXgjLTQgZHRusMTyPwgAQ7Xf3rVle/Qc= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, =?UTF-8?Q?Iris_Garc=c3=ada?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > When the user switches from F1 to F2 with C-x 5 o, and there was an > active minibuffer on F1, that MB gets moved to F2. The user then > terminnates the MB....then switches back to F1. There is no longer an > active MB. > >> As a user I can always do > >> (select-window (minibuffer-window)) > >> regardless of whether a minibuffer is active. Switching away from that >> window's frame and back to it is problematic in Emacs 27 - no window has >> the active cursor. You apparently fixed this by selecting the frame's >> first window when switching back. Right? > > Yes. This is safe but not quite right. The last window on that frame selected before the minibuffer window got selected should be selected instead - that's the window returned by `minibuffer-selected-window' immediately after selecting the minibuffer window. We'd probably have to put that into the frame structure to make it work but this can wait. >> One reason why I ask is because with emacs -Q and the present patch > >> (setq default-frame-alist '((minibuffer . nil))) > >> followed by C-x 5 2 and > >> (select-window (minibuffer-window)) > >> in the new frame violates the assertion on line 548 of window.c > >> /* Fselect_frame called us back so we've done all the work already. */ >> eassert (EQ (window, selected_window)); > >> with the backtrace below. > > Just as a quick aside, how do I configure Emacs so as to generate these > easserts? At the moment I've got CFLAGS='-O0 -g3' and --enable-checking I use --enable-checking='yes,glyphs' --enable-check-lisp-object-type=yes but cannot tell which ones are right, which matter and from where I obtained them. > in my ./configure command line. I think I'm missing something. > >> Basically, I would try to avoid that a non-selected frame's selected >> window is an inactive minibuffer window. But I'm not sure how difficult >> it is to achieve that. > > That's the way it currently is (without the patch). It is difficult to > make it work properly. > > Maybe the best workaround would be to create a new flag in struct frame, > which when set means "select mini-window if "possible" when selecting > this frame". "Possible" meaning there's an active MB. > (i) This flag would be set, somehow, by with-selected-frame when moving > away from F1. I doubt that anyone knows when we move away from a frame. With emacs -Q --eval "(setq default-frame-alist '((minibuffer)))" do in the normal, non-minibuffer frame (select-window (minibuffer-window)) You will see that the previous window remains selected but its mode line changes to inactive. So even the display engine doesn't know which frame is selected here. Maybe on purpose ... > (ii) do_switch_frame would test this flag, act on it, and clear it. > f->flag would always be clear when f is the selected frame. > > With this, F1's selected window would be moved away from the mini-window > and the flag set, when F2 gets selected. Or something like that. do_switch_frame is called by (i) and (ii) - so how would you "set" this flag in (i) and "test this flag and act on it" in (ii)? How would do_switch_frame distinguish between (i) and (ii)? OTOH what would go wrong if we did always auto-select a minibuffer window in do_switch_frame when it is its `frame-selected-window' and `minibuffer-depth' is non-zero regardless of whether the window's minibuffer is on live_minibuffer_p or not? If it is not, then this frame would just become the next participant in moving the minibuffer from one frame to another. martin From debbugs-submit-bounces@debbugs.gnu.org Sat May 29 11:24:50 2021 Received: (at 48674) by debbugs.gnu.org; 29 May 2021 15:24:50 +0000 Received: from localhost ([127.0.0.1]:57566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0pV-0007QQ-Ra for submit@debbugs.gnu.org; Sat, 29 May 2021 11:24:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln0pT-0007QC-Ke for 48674@debbugs.gnu.org; Sat, 29 May 2021 11:24:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45498) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ln0pN-0006s9-Dm; Sat, 29 May 2021 11:24:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4950 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ln0pM-0005Q3-Nt; Sat, 29 May 2021 11:24:41 -0400 Date: Sat, 29 May 2021 18:24:47 +0300 Message-Id: <83eedp5zr4.fsf@gnu.org> From: Eli Zaretskii To: martin rudalics In-Reply-To: <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> (message from martin rudalics on Sat, 29 May 2021 17:12:58 +0200) Subject: Re: bug#48674: Frames and minibuffer bug References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, acm@muc.de, iris.garcia.desebastian@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: martin rudalics > Date: Sat, 29 May 2021 17:12:58 +0200 > Cc: 48674@debbugs.gnu.org, > Iris García > > > Just as a quick aside, how do I configure Emacs so as to generate these > > easserts? At the moment I've got CFLAGS='-O0 -g3' and --enable-checking > > I use > > --enable-checking='yes,glyphs' --enable-check-lisp-object-type=yes > > but cannot tell which ones are right, which matter and from where I > obtained them. Assertions via eassert are activated by --enable-checking. From debbugs-submit-bounces@debbugs.gnu.org Sat May 29 13:00:16 2021 Received: (at 48674) by debbugs.gnu.org; 29 May 2021 17:00:16 +0000 Received: from localhost ([127.0.0.1]:57633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ln2Js-0001JR-B8 for submit@debbugs.gnu.org; Sat, 29 May 2021 13:00:16 -0400 Received: from colin.muc.de ([193.149.48.1]:26451 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ln2Jo-0001I9-Dl for 48674@debbugs.gnu.org; Sat, 29 May 2021 13:00:14 -0400 Received: (qmail 25269 invoked by uid 3782); 29 May 2021 17:00:05 -0000 Received: from acm.muc.de (p2e5d5176.dip0.t-ipconnect.de [46.93.81.118]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 May 2021 19:00:05 +0200 Received: (qmail 10790 invoked by uid 1000); 29 May 2021 17:00:04 -0000 Date: Sat, 29 May 2021 17:00:04 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Martin. On Sat, May 29, 2021 at 17:12:58 +0200, martin rudalics wrote: > > When the user switches from F1 to F2 with C-x 5 o, and there was an > > active minibuffer on F1, that MB gets moved to F2. The user then > > terminnates the MB....then switches back to F1. There is no longer an > > active MB. > >> As a user I can always do > >> (select-window (minibuffer-window)) > >> regardless of whether a minibuffer is active. Switching away from that > >> window's frame and back to it is problematic in Emacs 27 - no window has > >> the active cursor. You apparently fixed this by selecting the frame's > >> first window when switching back. Right? > > Yes. > This is safe but not quite right. The last window on that frame > selected before the minibuffer window got selected should be selected > instead - that's the window returned by `minibuffer-selected-window' > immediately after selecting the minibuffer window. We'd probably have > to put that into the frame structure to make it work but this can wait. I agree, this can wait. ;-) > >> One reason why I ask is because with emacs -Q and the present patch > >> (setq default-frame-alist '((minibuffer . nil))) > >> followed by C-x 5 2 and > >> (select-window (minibuffer-window)) > >> in the new frame violates the assertion on line 548 of window.c > >> /* Fselect_frame called us back so we've done all the work already. */ > >> eassert (EQ (window, selected_window)); > >> with the backtrace below. > > Just as a quick aside, how do I configure Emacs so as to generate these > > easserts? At the moment I've got CFLAGS='-O0 -g3' and --enable-checking > I use > --enable-checking='yes,glyphs' --enable-check-lisp-object-type=yes > but cannot tell which ones are right, which matter and from where I > obtained them. Thanks. It was just me being a bit stupid. I had minibuffer-follows-selected-frame set to nil, so I didn't get to the code which easserts. On setting that variable to t, I did get it. [ .... ] > > Maybe the best workaround would be to create a new flag in struct frame, > > which when set means "select mini-window if "possible" when selecting > > this frame". "Possible" meaning there's an active MB. > > (i) This flag would be set, somehow, by with-selected-frame when moving > > away from F1. > I doubt that anyone knows when we move away from a frame. With > emacs -Q --eval "(setq default-frame-alist '((minibuffer)))" > do in the normal, non-minibuffer frame > (select-window (minibuffer-window)) > You will see that the previous window remains selected but its mode line > changes to inactive. So even the display engine doesn't know which > frame is selected here. Maybe on purpose ... I've been thinking about my proposed mechanism. There is no need for with-selected-frame to set that new flag in struct frame. More simply, do_switch_frame can set it whenever the old frame has the mini-window selected. In the new frame it will check the flag and if appropriate select the MW. Functions such as Fselect_window and Fset_frame_selected_window which want to select a specific window would clear the flag. This mechanism could be implemented entirely in the C code, without affecting any Lisp interfaces. > > (ii) do_switch_frame would test this flag, act on it, and clear it. > > f->flag would always be clear when f is the selected frame. > > With this, F1's selected window would be moved away from the mini-window > > and the flag set, when F2 gets selected. Or something like that. > do_switch_frame is called by (i) and (ii) - so how would you "set" this > flag in (i) and "test this flag and act on it" in (ii)? How would > do_switch_frame distinguish between (i) and (ii)? Sorry, I think I was a bit unclear. The flag would be in struct frame, so (i) and (ii) would be acting on the flags for different frames. > OTOH what would go wrong if we did always auto-select a minibuffer > window in do_switch_frame when it is its `frame-selected-window' and > `minibuffer-depth' is non-zero regardless of whether the window's > minibuffer is on live_minibuffer_p or not? If it is not, then this > frame would just become the next participant in moving the minibuffer > from one frame to another. I don't think that situation can arise. We're talking exclusively about the (eq minibuffer-follows-selected-frame t) case, and in this case there will always be a live minibuffer moved onto the target frame when minibuffer-depth is non-zero. I think I'm going to discard yesterday's attempted patch, and write another patch along the lines sketched above. This will likely take me longer than just this evening. > martin -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 30 09:58:41 2021 Received: (at 48674) by debbugs.gnu.org; 30 May 2021 13:58:41 +0000 Received: from localhost ([127.0.0.1]:60128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lnLxh-0005Fg-As for submit@debbugs.gnu.org; Sun, 30 May 2021 09:58:41 -0400 Received: from colin.muc.de ([193.149.48.1]:58232 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lnLxe-0005FT-QM for 48674@debbugs.gnu.org; Sun, 30 May 2021 09:58:40 -0400 Received: (qmail 41846 invoked by uid 3782); 30 May 2021 13:58:31 -0000 Received: from acm.muc.de (p2e5d5a0f.dip0.t-ipconnect.de [46.93.90.15]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 30 May 2021 15:58:31 +0200 Received: (qmail 16437 invoked by uid 1000); 30 May 2021 13:58:30 -0000 Date: Sun, 30 May 2021 13:58:30 +0000 To: martin rudalics Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, Iris =?iso-8859-1?Q?Garc=EDa?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello again, Martin. On Sat, May 29, 2021 at 17:00:04 +0000, Alan Mackenzie wrote: > On Sat, May 29, 2021 at 17:12:58 +0200, martin rudalics wrote: [ .... ] > > > Maybe the best workaround would be to create a new flag in struct > > > frame, which when set means "select mini-window if "possible" > > > when selecting this frame". "Possible" meaning there's an active > > > MB. (i) This flag would be set, somehow, by with-selected-frame > > > when moving away from F1. [ .... ] > I've been thinking about my proposed mechanism. There is no need for > with-selected-frame to set that new flag in struct frame. More simply, > do_switch_frame can set it whenever the old frame has the mini-window > selected. In the new frame it will check the flag and if appropriate > select the MW. Functions such as Fselect_window and > Fset_frame_selected_window which want to select a specific window would > clear the flag. > This mechanism could be implemented entirely in the C code, without > affecting any Lisp interfaces. [ .... ] > I think I'm going to discard yesterday's attempted patch, and write > another patch along the lines sketched above. This will likely take me > longer than just this evening. Here is that patch. Please tell me what you think of it. Thanks! diff --git a/src/frame.c b/src/frame.c index e3d65dd28f..623e4ba2cd 100644 --- a/src/frame.c +++ b/src/frame.c @@ -982,6 +982,7 @@ make_frame (bool mini_p) f->ns_transparent_titlebar = false; #endif #endif + f->select_mini_window_flag = false; /* This one should never be zero. */ f->change_stamp = 1; root_window = make_window (); @@ -1542,7 +1543,17 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor tty->top_frame = frame; } + sf->select_mini_window_flag = MINI_WINDOW_P (XWINDOW (sf->selected_window)); + selected_frame = frame; + + move_minibuffers_onto_frame (sf, for_deletion); + + if (f->select_mini_window_flag + && !NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt))) + f->selected_window = f->minibuffer_window; + f->select_mini_window_flag = false; + if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame))) last_nonminibuf_frame = XFRAME (selected_frame); @@ -1559,7 +1570,6 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor #endif internal_last_event_frame = Qnil; - move_minibuffers_onto_frame (sf, for_deletion); return frame; } diff --git a/src/frame.h b/src/frame.h index 75a0b184c1..cad3df5ae1 100644 --- a/src/frame.h +++ b/src/frame.h @@ -462,6 +462,11 @@ struct frame in X builds only. */ bool_bf was_invisible : 1; + /* True when the frame isn't selected, and selecting it in the + future should select the mini-window rather than the currently + selected window in the frame, assuming there is still an active + minibuffer in that mini-window. */ + bool_bf select_mini_window_flag : 1; /* Bitfield area ends here. */ /* This frame's change stamp, set the last time window change diff --git a/src/window.c b/src/window.c index 9961c54161..f0451359c1 100644 --- a/src/window.c +++ b/src/window.c @@ -468,6 +468,7 @@ Return WINDOW. */) else { fset_selected_window (XFRAME (frame), window); + /* Don't clear FRAME's select_mini_window_flag here. */ return window; } } @@ -517,6 +518,9 @@ select_window (Lisp_Object window, Lisp_Object norecord, /* Do not select a tooltip window (Bug#47207). */ error ("Cannot select a tooltip window"); + /* We deinitely want to select WINDOW, not the mini-window. */ + f->select_mini_window_flag = false; + /* Make the selected window's buffer current. */ Fset_buffer (w->contents); @@ -3242,6 +3246,9 @@ window-start value is reasonable when this function is called. */) if (EQ (selected_frame, w->frame)) Fselect_window (window, Qnil); else + /* Do not clear f->select_mini_window_flag here. If the + last selected window on F was an active minibuffer, we + want to return to it on a later Fselect_frame. */ fset_selected_window (f, window); } } @@ -5153,7 +5160,10 @@ Signal an error when WINDOW is the only window on its frame. */) if (EQ (FRAME_SELECTED_WINDOW (f), selected_window)) Fselect_window (new_selected_window, Qt); else - fset_selected_window (f, new_selected_window); + /* Do not clear f->select_mini_window_flag here. If the + last selected window on F was an active minibuffer, we + want to return to it on a later Fselect_frame. */ + fset_selected_window (f, new_selected_window); unblock_input (); > > martin -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon May 31 03:55:42 2021 Received: (at 48674) by debbugs.gnu.org; 31 May 2021 07:55:42 +0000 Received: from localhost ([127.0.0.1]:60978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lncly-0003oS-Ni for submit@debbugs.gnu.org; Mon, 31 May 2021 03:55:42 -0400 Received: from mout.gmx.net ([212.227.15.15]:50495) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lnclw-0003oG-Sy for 48674@debbugs.gnu.org; Mon, 31 May 2021 03:55:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1622447731; bh=EaKdjb/ND/Ibl2NaU8fnLC0oQ+D2fWVVW5ZZhEEN6og=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=eB2re9EtfFOL78NVezalsQ+CFredHll2adpqz7P5X/Cq7yveYQu3aPMSIdpNmhjPL GkzQv10myDgJk0cbQZR239x6A89pHGPs5Aw0YfjqxWeU9aJE3jvYjJWvwVer79aCRT 64oZOaW2RukL8GxiJZF9BmighxijdBozT1r5XpZs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.100] ([213.142.96.227]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MeU0k-1lDBYd2Gge-00aVqX; Mon, 31 May 2021 09:55:31 +0200 Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie References: <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> <89cc93a4-15b1-2d1c-095e-7a0b5f1683a1@gmx.at> <3dba4122-30e3-99a7-2326-263f3f7023cf@gmx.at> From: martin rudalics Message-ID: Date: Mon, 31 May 2021 09:55:30 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:NVNEQ3Wg73Kim6sudkP6aP1ZfXA9NpfnuL4zAZHTyC+mZJVMBe1 CF9R1nrZ56oZWuTXF9+V7ICIIRTHu/ZCJNZoP+CkkgoCTdeJPdv2lGDTUuClSgOn+PRzoh2 44vzy1RcWcEYbOu6eG1xMYSPe60wGAXlJkIRieGmTeOSZvHP7xkuFt2p/Y0kCGV3Q5/HYQS 3EjyDnAAoUBuM7N4Z6DMA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:rDHLxryO23I=:DV34LvDW/KKtitjE5uVK7y 7WouU2H8/EBYajuk8/0CqYmQcThjxZgBXcLHhMdYh8SlwbBj8KjSaUlxY0JAarPeNI94QrjA1 FjptX3mqeY/hUZrTwzN3jJMX/xx1aLE/xidh/NiR4jo76qP/gL/LWHmNElzQFK9qpvy60prJZ 20oWNUG669k4K0k5YotRKUkG8Bflhq5dSpeIQNE/xS0SyzjsFvgQLa/M6VtLQ0FDdmPxNLd2k cLUDy/MTN6slid/L+uo81morjC1TrNOP5acpspkrzlzOON1wC0FSqlzyUO9s8Vu423cKVinA2 ArE8fsK36rzJCdqOwP76emM0fIvE+NTwuNi5YcC3xcfwv1rB5LtRKeP3mWbx0Wvoa6b708AeP wWP0hgTd1/RF7yaBk969Nz120NGm+9WR0/wXKB8cSylnb9kW7go1EIZkjfB+pbsp0Sg0CCuMa J7a3ulh4JEEJBzWZdzS2xZLp4Kp/6Rrie2rhRE19EHUkGKfgzz5pL1u/TT+P/9/rvRNxKaxnW w1F2/v7kbUIxUnd8+9Ly3hRO5A55Pk8mZnozpJDKyRQmRS5Q81IvLXlMMpVFunVmlmnFgCY7J 2AoCBYH+fo+scbp4vDR3XlUEt1zzuKQKlEmpHOBhzqjY48MFyPdzKL+xcbdUFqoe2FygrDVNF MoM5JKWaJFoELxcCuXR/vX+18uL1sILdcQl0uA6OGLe5jLXCeFt9eH/mWSxbhMtZs8qx4Y206 IqYBzBS5f/TKent3F0YNqClBPouVvgLDH3UYabTKPmBz+86BwkVohDUEf4TuWpMJQZJhJBlg4 REuxwlXrJgMckeUGbl31mhEfdBEG9nJbFqD7BJyXW1+39avTlOx34sm79KrTECXAkWCPL/e4h gwz99himdQL+2937Fc17RIPxj4K+pskzB+n55i4yxqPV0qcmBKLN3Lt+hBydgKWKSPMNm2q2o 9Lb4DGhTlalaLdRQ4o2yQbU9TqLXideMLEz4vX6us7l/Jpk981UU3stzfIMX37xt03Y7cUm3W 172tsic0iEqM07Vss9dOxe7jY0eiGTuMz4mVjQ+tOI4TACnN+tF1wgDB5dMPuFmicnSclMZhO PCXh9JIiLkAznES839YJPjWMT9M8rJLCSUEz95dkA2kPEdChUtttPDYCln7a+OQGY37XC+7a0 gQvKD3qFDfz70lmkZKoHVOi1riRyfHOTxwL48Lixx7F4QkBbLGQw0ccf07pWzYCYlfsTQ= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 48674 Cc: 48674@debbugs.gnu.org, =?UTF-8?Q?Iris_Garc=c3=ada?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Here is that patch. Please tell me what you think of it. Thanks! It seems to work so please install. Thanks, martin From debbugs-submit-bounces@debbugs.gnu.org Mon May 31 12:36:56 2021 Received: (at 48674-done) by debbugs.gnu.org; 31 May 2021 16:36:56 +0000 Received: from localhost ([127.0.0.1]:34702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lnkuN-0007FY-Ng for submit@debbugs.gnu.org; Mon, 31 May 2021 12:36:55 -0400 Received: from colin.muc.de ([193.149.48.1]:45181 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lnkuI-0007FG-El for 48674-done@debbugs.gnu.org; Mon, 31 May 2021 12:36:54 -0400 Received: (qmail 94844 invoked by uid 3782); 31 May 2021 16:36:43 -0000 Received: from acm.muc.de (p4fe15aad.dip0.t-ipconnect.de [79.225.90.173]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 31 May 2021 18:36:43 +0200 Received: (qmail 21593 invoked by uid 1000); 31 May 2021 16:36:43 -0000 Date: Mon, 31 May 2021 16:36:43 +0000 To: Iris =?iso-8859-1?Q?Garc=EDa?= Subject: Re: bug#48674: Frames and minibuffer bug Message-ID: References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674-done Cc: 48674-done@debbugs.gnu.org, martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Iris. Firstly, forgive me for not answering you sooner. I didn't want want to waste any more of your time with any more unusable patches. This was a tricky bug to solve, and indeed only the third patch attempt was satisfactory. I have now committed this third patch, and would ask you to remove the patch I sent you a few days ago, and update your Emacs to the current master version. I am closing the bug with this post, but if you find any more trouble with it, would you please let us know, so that we can open it again. Thanks! -- Alan Mackenzie (Nuremberg, Germany). On Thu, May 27, 2021 at 19:56:03 +0000, Iris García wrote: > Hi Martin, > I forgot to include you in my last mail where I said: > I think I have found the new issue (it is related to the former one), my > > code this time was the following: > > (defvar box-cursor t) > > > > (defun test/set-cursor() > > "Set cursor in all frames depending on the active state." > > (interactive) > > (dolist (frame (frame-list)) > > (with-selected-frame frame > > (if box-cursor > > (progn > > (modify-frame-parameters > > frame (list (cons 'cursor-type 'box))) > > (modify-frame-parameters > > frame (list (cons 'cursor-color "#00A9FE")))) > > (progn > > (modify-frame-parameters > > frame (list (cons 'cursor-type 'hbar))) > > (modify-frame-parameters > > frame (list (cons 'cursor-color "green"))) > > ))))) > > > > (defun test/enter-minibuffer() > > (setq box-cursor nil) > > (test/set-cursor)) > > > > (defun test/exit-minibuffer() > > (setq box-cursor t) > > (test/set-cursor)) > > > > > > (add-hook 'window-state-change-hook #'test/enter-minibuffer) > > (add-hook 'window-state-change-hook #'test/exit-minibuffer) > > > > (server-start) > > (make-frame > > The only difference is the add-hook, this time using > > window-state-change-hook instead of minibuffer-... > > This leads to the same bug. > > Regards, > > Iris. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 01 07:29:45 2021 Received: (at 48674-done) by debbugs.gnu.org; 1 Jun 2021 11:29:45 +0000 Received: from localhost ([127.0.0.1]:35853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lo2af-0002lU-4B for submit@debbugs.gnu.org; Tue, 01 Jun 2021 07:29:45 -0400 Received: from mail-ej1-f42.google.com ([209.85.218.42]:42970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lo2ac-0002lE-Sb for 48674-done@debbugs.gnu.org; Tue, 01 Jun 2021 07:29:43 -0400 Received: by mail-ej1-f42.google.com with SMTP id qq22so12880476ejb.9 for <48674-done@debbugs.gnu.org>; Tue, 01 Jun 2021 04:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Cz16JuDN8CTXpewADsDWKadRd0qpmxJZftDDA1rIOw=; b=pIV7dwZnP90tEr7oyy4yKqzAH3q2G87bAXw4s+VaddinaWi1PdJ+TE4tzHi0lwvVmM FydaXSSgbjCm6EDkRMpv1PrnnEQHbCI1UQvw2ZOKDPBzLuCQv99kuHXYozTLeIkO8x5u /IxIaxJVp0ei+ze1AhLC9Em3FtG8Bl27FrGBZTWIZ43AtxoxpK7pEuwCfXRmAVQSndhd 9BrAgRlpEbsv8eYLjp42bp6p1dpsLPNmkF6d5TFouXfXF439dGQqXUWCD6WVIFdJaQ8B nXCJcApFJs32Gi6CnFPYB16extzThW6gTb/2IX35m2iseGomh1WIi/IEmf4qYlpVY12m r0Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Cz16JuDN8CTXpewADsDWKadRd0qpmxJZftDDA1rIOw=; b=NHnFHE+W7fQ+vgmCLlfEDtyvUU/ONPVnS+l2I1x1vsEQLxEbKhGk4z7mfxzGhuTJ8X QnL6XAwvTN5FkHquR2ktIYHlZAbwPfRTGxQDw4kmjdjvMHEzl7XR+BCLScZUcKUJL6mt iYlCEEa6lvsb1YR+lDTqz4kZw8WZan5OucnPh8/nwLoISPnSdlYRw0IDv5DR2nAXVkBn 9guA1DxCkIUQCTjkjwz8YbKSstjUg8GTZ9J67L3uYy5soXG7NdcGMNG7UIb1JTyHVYY4 Xz3YfTCLV8ewLCJKZMk+W8y6JlZtjETN/VKl0r4erIbEhVguoqN3K0E3HkOqLOLhwx4X 400w== X-Gm-Message-State: AOAM531YJrqYhrA/VJR9L+CfAkyw3PyPk2E4gQcE5k8hC7ugjD9cks6d MSk/UQmBZLO37gwpwTsauFVwjxADo2gZEAnwix0= X-Google-Smtp-Source: ABdhPJxz80wq0fAzRec8npCr57sFIZd/j885+8k3J9kI/31nNKAMkgzOSfDrTKlUTZ0ldwkyaaxiWBem6N126aMk0jU= X-Received: by 2002:a17:906:eb88:: with SMTP id mh8mr11116193ejb.540.1622546977001; Tue, 01 Jun 2021 04:29:37 -0700 (PDT) MIME-Version: 1.0 References: <1911d1b0-ed9f-7359-b28c-fbaef27df8f3@gmx.at> <1e21b121-91c1-cbe9-d9ae-24915f163ae5@gmx.at> In-Reply-To: From: =?UTF-8?B?SXJpcyBHYXJjw61h?= Date: Tue, 1 Jun 2021 13:29:25 +0200 Message-ID: Subject: Re: bug#48674: Frames and minibuffer bug To: Alan Mackenzie Content-Type: multipart/alternative; boundary="0000000000003215ea05c3b2a82d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48674-done Cc: 48674-done@debbugs.gnu.org, martin rudalics X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003215ea05c3b2a82d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan, No worries! I did follow the thread and tried your 3 patches, the last one is indeed working as expected as far as I can tell. Thank you very much for the quick response and fix. Regards, Iris. On Mon, 31 May 2021 at 18:36, Alan Mackenzie wrote: > Hello, Iris. > > Firstly, forgive me for not answering you sooner. I didn't want want to > waste any more of your time with any more unusable patches. This was a > tricky bug to solve, and indeed only the third patch attempt was > satisfactory. > > I have now committed this third patch, and would ask you to remove the > patch I sent you a few days ago, and update your Emacs to the current > master version. > > I am closing the bug with this post, but if you find any more trouble > with it, would you please let us know, so that we can open it again. > Thanks! > > -- > Alan Mackenzie (Nuremberg, Germany). > > > On Thu, May 27, 2021 at 19:56:03 +0000, Iris Garc=C3=ADa wrote: > > Hi Martin, > > > I forgot to include you in my last mail where I said: > > > I think I have found the new issue (it is related to the former one), m= y > > > code this time was the following: > > > > (defvar box-cursor t) > > > > > > (defun test/set-cursor() > > > "Set cursor in all frames depending on the active state." > > > (interactive) > > > (dolist (frame (frame-list)) > > > (with-selected-frame frame > > > (if box-cursor > > > (progn > > > (modify-frame-parameters > > > frame (list (cons 'cursor-type 'box))) > > > (modify-frame-parameters > > > frame (list (cons 'cursor-color "#00A9FE")))) > > > (progn > > > (modify-frame-parameters > > > frame (list (cons 'cursor-type 'hbar))) > > > (modify-frame-parameters > > > frame (list (cons 'cursor-color "green"))) > > > ))))) > > > > > > (defun test/enter-minibuffer() > > > (setq box-cursor nil) > > > (test/set-cursor)) > > > > > > (defun test/exit-minibuffer() > > > (setq box-cursor t) > > > (test/set-cursor)) > > > > > > > > > (add-hook 'window-state-change-hook #'test/enter-minibuffer) > > > (add-hook 'window-state-change-hook #'test/exit-minibuffer) > > > > > > (server-start) > > > (make-frame > > > > The only difference is the add-hook, this time using > > > window-state-change-hook instead of minibuffer-... > > > This leads to the same bug. > > > > Regards, > > > > Iris. > --0000000000003215ea05c3b2a82d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan,

No worries! I did f= ollow the thread and tried your 3 patches, the last one is indeed working a= s expected as far as I can tell.

Thank you very mu= ch for the quick response and fix.

Regards,
<= div>
Iris.

On Mon, 31 May 2021 at 18:36, Alan Macken= zie <acm@muc.de> wrote:
Hello, Iris.

Firstly, forgive me for not answering you sooner.=C2=A0 I didn't want w= ant to
waste any more of your time with any more unusable patches.=C2=A0 This was = a
tricky bug to solve, and indeed only the third patch attempt was
satisfactory.

I have now committed this third patch, and would ask you to remove the
patch I sent you a few days ago, and update your Emacs to the current
master version.

I am closing the bug with this post, but if you find any more trouble
with it, would you please let us know, so that we can open it again.
Thanks!

--
Alan Mackenzie (Nuremberg, Germany).


On Thu, May 27, 2021 at 19:56:03 +0000, Iris Garc=C3=ADa wrote:
> Hi Martin,

> I forgot to include you in my last mail where I said:

> I think I have found the new issue (it is related to the former one), = my
> > code this time was the following:

> > (defvar box-cursor t)
> >
> > (defun test/set-cursor()
> >=C2=A0 =C2=A0"Set cursor in all frames depending on the activ= e state."
> >=C2=A0 =C2=A0(interactive)
> >=C2=A0 =C2=A0(dolist (frame (frame-list))
> >=C2=A0 =C2=A0 =C2=A0(with-selected-frame frame
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(if box-cursor
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(progn
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(modify-frame-para= meters
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame (list (cons= 'cursor-type 'box)))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(modify-frame-para= meters
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame (list (cons= 'cursor-color "#00A9FE"))))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(progn
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(modify-frame-parameters<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame (list (cons 'c= ursor-type 'hbar)))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(modify-frame-parameters<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame (list (cons 'c= ursor-color "green")))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0)))))
> >
> > (defun test/enter-minibuffer()
> >=C2=A0 =C2=A0(setq box-cursor nil)
> >=C2=A0 =C2=A0(test/set-cursor))
> >
> > (defun test/exit-minibuffer()
> >=C2=A0 =C2=A0(setq box-cursor t)
> >=C2=A0 =C2=A0(test/set-cursor))
> >
> >
> > (add-hook 'window-state-change-hook #'test/enter-minibuff= er)
> > (add-hook 'window-state-change-hook #'test/exit-minibuffe= r)
> >
> > (server-start)
> > (make-frame

> > The only difference is the add-hook, this time using
> > window-state-change-hook instead of minibuffer-...
> > This leads to the same bug.

> > Regards,

> > Iris.
--0000000000003215ea05c3b2a82d-- From unknown Thu Jun 19 14:10:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 30 Jun 2021 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator