From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 14 20:57:29 2021 Received: (at submit) by debbugs.gnu.org; 15 Mar 2021 00:57:29 +0000 Received: from localhost ([127.0.0.1]:34534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLbY1-0000Nq-6d for submit@debbugs.gnu.org; Sun, 14 Mar 2021 20:57:29 -0400 Received: from lists.gnu.org ([209.51.188.17]:51438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLbXz-0000Ni-BH for submit@debbugs.gnu.org; Sun, 14 Mar 2021 20:57:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLbXy-0006Cn-UB for bug-gnu-emacs@gnu.org; Sun, 14 Mar 2021 20:57:27 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:36621) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lLbXv-0000xD-V9 for bug-gnu-emacs@gnu.org; Sun, 14 Mar 2021 20:57:26 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 02E322917 for ; Sun, 14 Mar 2021 20:57:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 14 Mar 2021 20:57:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:to:subject:date:message-id:mime-version:content-type; s= fm2; bh=kefw6pvHlOy0vqdZmDZkmWjKDWWASgoZhmpScLOWF38=; b=FDsFqsOL mvDNfGPQDR2b2FFK3ZKCo755johr6gztE9WoL/mTnqbeFpkzoyMeYwlkVWkoxzsh wC07Ka8rGRjN5zFFBpPJ5QuaKrGG+OZB+Brh+paEgG7hxSRN8/5Qwow8uf4nyNhv P9Ynd0ZoG++CKKAqJwLKCHyuk43rbkmW0OmmOH6PWU6bov6hbqX7Qes/uxbWcoqr PvbVHgOC7MWctWKWaYBwMxu6embFJDcqdNYR837oYy5LFOfHPGQyPBiRKGep8Wxf FKiTps1Ap0orCqhT3HcVwT5/VofMHdkvPjdNAA9HYEj6qo9YBbqCG2O9SVlaFsXx DUAIC/FEFGZIpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=kefw6pvHlOy0vqdZmDZkmWjKDWWAS goZhmpScLOWF38=; b=L7t7p6V+oKCQd7dGV+FmoAS7/8KbpRrhg6zg2nJ1lE3is 4Zk4SRRnHJ8txWvmqJpah8mI73ol8RUC/XGJ1dz/90rSpZfn5XNdC6vINI1Yciue qjOW/+2h+PcgC0rE5Qpe3F/ltMvtFj6RqbRMo3r9wKg2RUE9VImt97gfyzvzghQU UNBNXQrUveI3HzfuWs8Of1IrPphReoES0HDWc3aro7rPMdyp9hfaYqF9rlEffFMs 9gjkeCwdqFKQXdhh4k0xFi1dKShYxjajHzF38XzO+3UrkXVRW72QFNWMAUDIZwNc 9OvXASRgyyjnvojNwp181kCVOOWSxeWhhM6hxl+4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvkedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtsehttdertddttd dtnecuhfhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmnecuggftrfgrthht vghrnhepveehvdffvdejteehhfdthfegfeejgfffgeeuvdeivdevvedvfeduhfdvfefhff ehnecukfhppeejfedrvddtkedrudegledrkeefnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepshhthigrnhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from localhost (c-73-208-149-83.hsd1.il.comcast.net [73.208.149.83]) by mail.messagingengine.com (Postfix) with ESMTPA id E47EB240054 for ; Sun, 14 Mar 2021 20:57:19 -0400 (EDT) From: styang@fastmail.com To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Incorrect major-mode in minibuffer Date: Sun, 14 Mar 2021 19:57:09 -0500 Message-ID: <877dm9nsii.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.147.123.20; envelope-from=styang@fastmail.com; helo=wout4-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: submit 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.7 (--) The major-mode in the minibuffer is incorrectly set to fundamental-mode, even when it is the first one. Reproduce with the following steps: 1. emacs -q 2. Eval the following: (defun report-major-mode () (message "mini-buffer major-mode is %s" major-mode)) (add-hook 'minibuffer-setup-hook 'report-major-mode) 3. Press M-; to call eval-expression, which will report that the major-mode is fundamental-mode The offending commit is 636ef445af. In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.26, cairo version 1.17.4) of 2021-03-12 built on Desktop Repository revision: 592fabdc7f8d9c52c931843a153fdac67a302c30 Repository branch: makepkg Windowing system distributor 'System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-gconf --without-gsettings --with-native-compilation --with-pgtk --with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo --with-xwidgets --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -g -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB Important settings: value of $LC_CTYPE: zh_CN.UTF-8 value of $LANG: zh_CN.UTF-8 value of $XMODIFIERS: @im=fcitx locale-coding-system: utf-8-unix Major mode: ELisp/d 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 china-util iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/pgtk-win pgtk-win term/common-win 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 facemenu 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 dynamic-setting font-render-setting cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty make-network-process nativecomp emacs) Memory information: ((conses 16 86740 7633) (symbols 48 7951 1) (strings 32 21797 2724) (string-bytes 1 749467) (vectors 16 16994) (vector-slots 8 376872 18158) (floats 8 31 79) (intervals 56 277 0) (buffers 992 14)) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 14 21:02:38 2021 Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 01:02:38 +0000 Received: from localhost ([127.0.0.1]:34552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLbd0-0000Yq-5P for submit@debbugs.gnu.org; Sun, 14 Mar 2021 21:02:38 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:40245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLbcx-0000Yd-Uk for 47150@debbugs.gnu.org; Sun, 14 Mar 2021 21:02:36 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C383129C2; Sun, 14 Mar 2021 21:02:29 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Sun, 14 Mar 2021 21:02:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:date:from:to:cc:subject:content-type; s= fm2; bh=ao7imPTKrOduSqanXS8WIhgMRwPMHVpEoZuOw8WY7lc=; b=VKszraKT H854oPh/SmGomd+V4MbafN89n4nL0ikmPAxtQSFSDOIFX8pCX9YY7NBLz3RQ17D2 HzNT0ubcqPploVqw13woPsGGrpdvdWD6vZOCnwNrExg+tMda/sPI2gVmmnkwIOk3 5+Qj0zAXDb06Y9dEZVhwHfp74kSj/fXMEqaY1zwwIU8OnnSiO+Wk7EICojjhmwOK ira8f1dDPcdEILjB2oY189MDb6wDcPz7oMjwvZO/FWvL5aBo+kHb+BfEBXGIHi1r JW/ZsctwYejbc/36v1ItHb/KSl5JAd+/ZXQsN59IOgEMVOOBn5mIUE0y2sqtPSz2 dygcSp+CbSVhuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ao7imPTKrOduSqanXS8WIhgMRwPMH VpEoZuOw8WY7lc=; b=tD6QIiKxXxsbcmJERwHIDOqn8wVs2UkdU5IGN8QOt0/bF dH/eBa6JGNPeu+9scI0cPTDut5lSDmIZiXLPVr5B+j85UegLWEetMilVuLIbyJ86 RFINhr1Q7oeZSmYtz32w6DG/dMcHK/RzzLZgikl38PE8x1ABWxOHI+wzv9GApQn+ Q5RL2j/TvT2l0mDIC+5d9RvSZEy26/ssLl+6Tk1byaS4jy3zhHIXNe7I/lFIVmFE c4r3Ynh5FQkzBTwQprV9LNwKENvjb5YTY/pF4VLl9Z5Ovcj768gdG4B512cD+9+1 x0L7+W4Hq2Zj3Nlba9mlIO9vJavM70q+kjZGnjXEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvkedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfufhhvghnghcujggrnhhgfdcuoehsthihrghnghesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeejvedvheekudeggfduhfduieeile dvfedvkeehleduuefhleeugeehtdekueetueenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 057A2A00073; Sun, 14 Mar 2021 21:02:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <6f08da77-9cf3-46f7-9f6c-d351ace99f4c@www.fastmail.com> Date: Sun, 14 Mar 2021 20:02:08 -0500 From: "Sheng Yang" To: 47150@debbugs.gnu.org Subject: Emacs bug#47150 28.0.50; Incorrect major-mode in minibuffer Content-Type: multipart/alternative; boundary=7eda725d5f6849da9ac906c53292a0b0 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 47150 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 (-) --7eda725d5f6849da9ac906c53292a0b0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable CCing the author of the offending commit 636ef445af. Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --7eda725d5f6849da9ac906c53292a0b0 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
CCing the autho= r of the offending commit 636ef445af.

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: sty= ang@fastmail.com
E-mail (old but s= till used): yangsheng6810@gma= il.com


--7eda725d5f6849da9ac906c53292a0b0-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 15 04:00:10 2021 Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 08:00:10 +0000 Received: from localhost ([127.0.0.1]:34807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLi93-0004Wt-W4 for submit@debbugs.gnu.org; Mon, 15 Mar 2021 04:00:10 -0400 Received: from colin.muc.de ([193.149.48.1]:12401 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lLi91-0004Uq-HV for 47150@debbugs.gnu.org; Mon, 15 Mar 2021 04:00:08 -0400 Received: (qmail 54367 invoked by uid 3782); 15 Mar 2021 08:00:00 -0000 Received: from acm.muc.de (p4fe15b5d.dip0.t-ipconnect.de [79.225.91.93]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 15 Mar 2021 09:00:00 +0100 Received: (qmail 5396 invoked by uid 1000); 15 Mar 2021 07:59:59 -0000 Date: Mon, 15 Mar 2021 07:59:59 +0000 To: styang@fastmail.com Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877dm9nsii.fsf@gmail.com> 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: 47150 Cc: 47150@debbugs.gnu.org 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, Sheng. On Sun, Mar 14, 2021 at 19:57:09 -0500, styang@fastmail.com wrote: > The major-mode in the minibuffer is incorrectly set to > fundamental-mode, even when it is the first one. Why is fundamental-mode incorrect for a minibuffer, and what should the major mode be instead? What problems does fundamental-mode give you in a minibuffer? > Reproduce with the following steps: > 1. emacs -q > 2. Eval the following: > (defun report-major-mode () > (message "mini-buffer major-mode is %s" major-mode)) > (add-hook 'minibuffer-setup-hook 'report-major-mode) > 3. Press M-; to call eval-expression, which will report that the major-mode is fundamental-mode > The offending commit is 636ef445af. > In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.26, cairo version 1.17.4) > of 2021-03-12 built on Desktop > Repository revision: 592fabdc7f8d9c52c931843a153fdac67a302c30 > Repository branch: makepkg > Windowing system distributor 'System Description: Arch Linux [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 15 14:15:35 2021 Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 18:15:35 +0000 Received: from localhost ([127.0.0.1]:36976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLrkc-0004zR-E1 for submit@debbugs.gnu.org; Mon, 15 Mar 2021 14:15:35 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:47431) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLrkZ-0004zC-Kc for 47150@debbugs.gnu.org; Mon, 15 Mar 2021 14:15:32 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E876F2754; Mon, 15 Mar 2021 14:15:24 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 15 Mar 2021 14:15:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=Ol6qxcGayOyCw9+GdhIKlcyg7VS1fUv 1K6QwRlWpfgs=; b=mWPXEtDdKeLixDwdtTlc65VePfOt/ko7GhRGizrc5d+O36D tc3hY8DfLvgX3WOsmgNzkumN3FCotFJ2/YxSWnmUJ1FeHUEu8Z+4fLZPgFWSpe6I l7v/Qn31yjaJ5Z3Hzr5OZqf6l81GrIuYY/oCgwFeE2uYjLEUDcntu9xFkgnmSK8r oFy5vHBF/iLp1h8v2vABRCQ3bP3AfE4RaSNkhVu+wXLruNpF2FD9U0cnzWwZRUQ6 yOC8Mb+qbr4nsj2eo3yByh9PYdENTU347rX542g9Oq0CROGJRe1Ir78bi5cj7a7j hwqEbjGEqgawJsxHRFVZYqAYRIel0tO4yVKKKQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ol6qxc GayOyCw9+GdhIKlcyg7VS1fUv1K6QwRlWpfgs=; b=Vy+L64YN2+z7koJfDpYEiO pJ9DdF6H/zIU2vwvIUxdy0pTVlBlCqz4JhyyaDIK+mgy2psZR+wGsdSr4vf+A7Cs 909iHq1Q1JLO+Q2G8uzKt036BKw8vhy/5cyCtYP2xmk1QLNTFHMj1QVdf4LZI4aU J55s37L1IVbleS3AJ4JU+VWT+hl2F3/UjkHNO+jX8WbXAuSGBtgxi5mNmnV7FxQd tNpHd5Ed/ZNMphru0I1wZWMM67bBwo4R6/hn2lCoby9RAbxqo7dRUaY7j79lFOaK tn0b/TzfzKvmfPTzRiwzxWSc0QBUuZIp/FIFlTKjl7F23h1W5veehdL5tVfS00dw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvledgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfuhhgvnhhgucgjrghnghdfuceoshhthigrnhhgsehf rghsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepheeluedtudffffegffeile ettedvudeihefhvefgvdeivddttdeifeeigeegveejnecuvehluhhsthgvrhfuihiivgep udenucfrrghrrghmpehmrghilhhfrhhomhepshhthigrnhhgsehfrghsthhmrghilhdrtg homh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EE17DA00073; Mon, 15 Mar 2021 14:15:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> In-Reply-To: References: <877dm9nsii.fsf@gmail.com> Date: Mon, 15 Mar 2021 13:15:02 -0500 From: "Sheng Yang" To: "Alan Mackenzie" Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Content-Type: multipart/alternative; boundary=9d45e26453b1409292122bd5e766879b X-Spam-Score: 1.8 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Alan, On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wrote: > Why is fundamental-mode incorrect for a minibuffer, and what should the > major mode be instead? > > What problems does fundamental-mode give yo [...] Content analysis details: (1.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [64.147.123.21 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [64.147.123.21 listed in wl.mailspike.net] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (styang[at]fastmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 FROM_FMBLA_NEWDOM From domain was registered in last 7 days 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 47150 Cc: 47150@debbugs.gnu.org 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: -0.2 (/) --9d45e26453b1409292122bd5e766879b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan, On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wrote: > Why is fundamental-mode incorrect for a minibuffer, and what should th= e > major mode be instead? >=20 > What problems does fundamental-mode give you in a minibuffer? The word "correct" here has a two-fold meaning, 1) the design itself is = good (whether it is good can be discussed), 2) the behavior is as intend= ed. For the first point, I think before the offending commit, the major-mode= of a minibuffer is minibuffer-inactive-mode. I am not aware of the reas= ons behind the decision, but it seems a reasonable choice. We do not nee= d a reason to keep the existing decision, but we do need an explanation = for a decision to change it to fundamental-mode. Anyway, I would give a = few points for keeping the major-mode as minibuffer-inactive-mode:=20 1. Packages depend on it, to name a few: lispy, smartparens, and telega.= 2. We do need something to check that we are in the minibuffer, and appl= y something. For my case, I want automatic paren pairing and editing in = eval-expression. Plus we also need a keymap for it, which is minibuffer-= inative-mode-map. We can use (minibufferp), but this will prevent the ex= isting use of *-global-modes in packages to decide whether to enable in = the minibuffer. 3. The choice of minibuffer-inactive-mode is written in elisp manual. I = believe any changes that breaks backward compatibility needs a sound rea= son. If you are aware of a thread on an explanation for the decision to switc= h to fundamantal-mode, please send me a pointer. For the second point, the new behavior seems not intended according to t= he commit message of the offending commit. Here is the whole commit mess= age of 636ef445af: > With minibuffer-follows-selected-frame `hybrid', preserve recursiv= e Mbuffers > =20 > ...when enable-recursive-minibuffers is non-nil, and several minib= uffers are > activated from different frames. Also set the major mode of a reu= sed active > minibuffer to `fundamental-mode' - up till now it's been > minibuffer-inactive-mode. > =20 > * src/minibuf.c (read_minibuf): with the indicated settings of var= iables, > "stack up" all containing minibuffers on the mini-window of the cu= rrent > frame. Delete another, now superfluous such stacking up. > (set_minibuffer_mode): New function. > (get_minibuffer): Call the above new function (twice), in place of= inline > code, ensuring active minibuffers are never left in minibuffer-ina= ctive-mode. At the point of reporting the bug, I thought the change of major mode on= ly applies when you have minibuffer-follows-selected-frame set to `hybir= d'. I am less sure about this understanding now. Currently, from what I = understand, it is only when we reuse an active minibuffer when we have f= undamental-mode set as major mode. However, with a single buffer, and th= e first interactive usage of the minibuffer by pressing M-:, the major-m= ode is reported as fundamental-mode, instead of minibuffer-inactive-mode= , as in Emacs 27.1. What does a "reuse" means here? I am not sure I understand the differences between an active and inactiv= e minibuffer, and the elisp manual does not really help me much. It seem= s to me the minibuffer is alwals inactive? I tried M-x, M-!, M-:, all re= ports minibuffer-inactive-mode in Emacs 27.1. Is this a mistake and the= offending commit was trying to fix this inconsistency? > > 3. Press M-; to call eval-expression, which will report that the maj= or-mode is fundamental-mode Typo fix: to call eval-expression, the key-binding is `M-:' instead of `= M-:' Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --9d45e26453b1409292122bd5e766879b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Alan,

On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wr= ote:
Why is= fundamental-mode incorrect for a minibuffer, and what should the
major mode be instead?

What problem= s does fundamental-mode give you in a minibuffer?
=

The word "correct" here has a two-fold meaning, 1) t= he design itself is good (whether it is good can be discussed), 2) the b= ehavior is as intended.

For the first point= , I think before the offending commit, the major-mode of a minibuffer is= minibuffer-inactive-mode. I am not aware of the reasons behind the deci= sion, but it seems a reasonable choice. We do not need a reason to keep = the existing decision, but we do need an explanation for a decision to c= hange it to fundamental-mode. Anyway, I would give a few points for keep= ing the major-mode as minibuffer-inactive-mode:
1. Packag= es depend on it, to name a few: lispy, smartparens, and telega.
2. We do need something to check that we are in the minibuffer, an= d apply something. For my case, I want automatic paren pairing and editi= ng in eval-expression. Plus we also need a keymap for it, which is minib= uffer-inative-mode-map. We can use (minibufferp), but this will prevent = the existing use of *-global-modes in packages to decide whether to enab= le in the minibuffer.
3. The choice of minibuffer-inactive= -mode is written in elisp manual. I believe any changes that breaks back= ward compatibility needs a sound reason.

If= you are aware of a thread on an explanation for the decision to switch = to fundamantal-mode, please send me a pointer.

<= div>For the second point, the new behavior seems not intended according = to the commit message of the offending commit. Here is the whole commit = message of 636ef445af:
 &nb= sp;  With minibuffer-follows-selected-frame `hybrid', preserve recu= rsive Mbuffers
   
 &nbs= p;  ...when enable-recursive-minibuffers is non-nil, and several mi= nibuffers are
    activated from different = frames.  Also set the major mode of a reused active
&= nbsp;   minibuffer to `fundamental-mode' - up till now it's be= en
    minibuffer-inactive-mode.
<= div>   
    * src/minibuf.c = (read_minibuf): with the indicated settings of variables,
=     "stack up" all containing minibuffers on the mini-win= dow of the current
    frame.  Delete = another, now superfluous such stacking up.
  &nb= sp; (set_minibuffer_mode): New function.
   = ; (get_minibuffer): Call the above new function (twice), in place of inl= ine
    code, ensuring active minibuffers a= re never left in minibuffer-inactive-mode.

At the point of reporting the bug, I thought the= change of major mode only applies when you have minibuffer-follows-sele= cted-frame set to `hybird'. I am less sure about this understanding now.= Currently, from what I understand, it is only when we reuse an active m= inibuffer when we have fundamental-mode set as major mode. However, with= a single buffer, and the first interactive usage of the minibuffer by p= ressing M-:, the major-mode is reported as fundamental-mode, instead of = minibuffer-inactive-mode, as in Emacs 27.1. What does a "reuse" means he= re?

I am not sure I understand the differen= ces between an active and inactive minibuffer, and the elisp manual does= not really help me much. It seems to me the minibuffer is alwals inacti= ve? I tried M-x, M-!, M-:, all reports minibuffer-inactive-mode in Emacs= 27.1.  Is this a mistake and the offending commit was trying to fi= x this inconsistency?

> 3. Press M-; to call eval-expression, whi= ch will report that the major-mode is fundamental-mode

Typo fix: to call eval-expression, the key-binding is `= M-:' instead of `M-:'

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@fastmail.com=
E-mail (old but still used): yangsheng6810@gmail.com


--9d45e26453b1409292122bd5e766879b-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 15 17:30:51 2021 Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 21:30:51 +0000 Received: from localhost ([127.0.0.1]:37401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLunb-0001iD-5y for submit@debbugs.gnu.org; Mon, 15 Mar 2021 17:30:51 -0400 Received: from colin.muc.de ([193.149.48.1]:34408 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lLunY-0001hz-N2 for 47150@debbugs.gnu.org; Mon, 15 Mar 2021 17:30:49 -0400 Received: (qmail 83914 invoked by uid 3782); 15 Mar 2021 21:30:42 -0000 Received: from acm.muc.de (p4fe15b5d.dip0.t-ipconnect.de [79.225.91.93]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 15 Mar 2021 22:30:41 +0100 Received: (qmail 20021 invoked by uid 1000); 15 Mar 2021 21:30:41 -0000 Date: Mon, 15 Mar 2021 21:30:41 +0000 To: Sheng Yang Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> 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: 47150 Cc: 47150@debbugs.gnu.org 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, Sheng. On Mon, Mar 15, 2021 at 13:15:02 -0500, Sheng Yang wrote: > Hi Alan, > On Mon, Mar 15, 2021, at 02:59, Alan Mackenzie wrote: > > Why is fundamental-mode incorrect for a minibuffer, and what should the > > major mode be instead? > > What problems does fundamental-mode give you in a minibuffer? > The word "correct" here has a two-fold meaning, 1) the design itself > is good (whether it is good can be discussed), 2) the behavior is as > intended. > For the first point, I think before the offending commit, the > major-mode of a minibuffer is minibuffer-inactive-mode. I am not aware > of the reasons behind the decision, but it seems a reasonable choice. > We do not need a reason to keep the existing decision, but we do need > an explanation for a decision to change it to fundamental-mode. > Anyway, I would give a few points for keeping the major-mode as > minibuffer-inactive-mode: OK, I'll start with 2). Up to Emacs-27, a minibuffer got created in fundamental-mode, got used, then after the user typed RET or C-g, was put into minibuffer-inactive-mode. When the minibuffer got used a second time, it got left in minibuffer-inactive-mode. This was a bug, though not a serious one. The minibuffer then stayed in that mode until Emacs shutdown. minibuffer-inactive-mode: the critical thing here is "inactive", which means "doing nothing", or "not in use", or even "sleeping". The opposite word is "active". From its name, this major mode was never intended for use in active minibuffers, but somehow nobody noticed that the buffer never got shifted out of minibuffer-inactive-mode when it came to be used again. I've been fixing things in minibuf.c recently, and when I discovered this anomaly, I fixed it, so that an active minibuffer now runs in fundamental-mode, as originally intended. I did wonder why there was no "minibuffer-mode". But it was clear from the code that whoever wrote it intended minibuffers to use fundamental-mode whilst active. > 1. Packages depend on it, to name a few: lispy, smartparens, and > telega. The maintainers of those packages are probably unhappy about minibuffer-inactive-mode. In any case, it doesn't work on the first use of a minibuffer (see above). > 2. We do need something to check that we are in the minibuffer, and > apply something. As you say, there is (minibufferp). What is wrong with that? > For my case, I want automatic paren pairing and editing in > eval-expression. That does indeed suggest we really want a minibuffer-mode, rather than just fundamental-mode. But surely, the parenthesis pairing will be dependant on the sort of text you're typing into the minibuffer, so it can't really be connected with, say, minibuffer-mode. > Plus we also need a keymap for it, which is > minibuffer-inactive-mode-map. No. That keymap is very low functionality, and almost useless, as it's intended to be. The idea is that while a minibuffer is inactive, a user can't do any damage with it. When a (low-level) minibuffer function is called, a keymap is an argument to that function, and that gets used instead. > We can use (minibufferp), but this will prevent the existing use of > *-global-modes in packages to decide whether to enable in the > minibuffer. Sorry, I don't understand what you mean, here. How will the use of (minibufferp) prevent anything else? > 3. The choice of minibuffer-inactive-mode is written in elisp manual. > I believe any changes that breaks backward compatibility needs a sound > reason. minibuffer-inactive-mode is described in the elisp manual as being for INACTIVE minibuffers, i.e. those that aren't currently in use. It was a bug that that major mode was still in force for active minibuffers (apart from their first use in an Emacs session). > If you are aware of a thread on an explanation for the decision to > switch to fundamantal-mode, please send me a pointer. I hope my description in this post is satisfactory. > For the second point, the new behavior seems not intended according to > the commit message of the offending commit. Here is the whole commit > message of 636ef445af: > > With minibuffer-follows-selected-frame `hybrid', preserve recursive Mbuffers > > ...when enable-recursive-minibuffers is non-nil, and several minibuffers are > > activated from different frames. Also set the major mode of a reused active > > minibuffer to `fundamental-mode' - up till now it's been > > minibuffer-inactive-mode. > > * src/minibuf.c (read_minibuf): with the indicated settings of variables, > > "stack up" all containing minibuffers on the mini-window of the current > > frame. Delete another, now superfluous such stacking up. > > (set_minibuffer_mode): New function. > > (get_minibuffer): Call the above new function (twice), in place of inline > > code, ensuring active minibuffers are never left in minibuffer-inactive-mode. It was me that made that commit. The change to the major mode was fully intended. I thought the description of the change was adequate. > At the point of reporting the bug, I thought the change of major mode > only applies when you have minibuffer-follows-selected-frame set to > `hybrid'. Sorry, that wasn't the intended meaning. The change in major mode is regardless of the setting of minibuffer-follows-selected-frame. > I am less sure about this understanding now. Currently, from > what I understand, it is only when we reuse an active minibuffer when > we have fundamental-mode set as major mode. However, with a single > buffer, and the first interactive usage of the minibuffer by pressing > M-:, the major-mode is reported as fundamental-mode, instead of > minibuffer-inactive-mode, as in Emacs 27.1. What does a "reuse" means > here? "Reuse", probably better written as "re-use", just means to use again. > I am not sure I understand the differences between an active and > inactive minibuffer, and the elisp manual does not really help me > much. "Active" means "in use", "inactive" means "not in use", in this context. > It seems to me the minibuffer is always inactive? I tried M-x, > M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1. Is this > a mistake and the offending commit was trying to fix this > inconsistency? Very much so! > > > 3. Press M-; to call eval-expression, which will report that the > > > major-mode is fundamental-mode > Typo fix: to call eval-expression, the key-binding is `M-:' instead of > `M-:' So, a quick summary: (i) the change in the minibuffer's major mode to fundamental-mode was intended; (ii) there may be some problems in some packages because of this; (iii) we aren't yet in agreement on how to proceed with this bug report. > Sheng Yang(杨圣), PhD > Computer Science Department > University of Maryland, College Park > E-mail: styang@fastmail.com > E-mail (old but still used): yangsheng6810@gmail.com -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 15 17:58:34 2021 Received: (at 47150) by debbugs.gnu.org; 15 Mar 2021 21:58:34 +0000 Received: from localhost ([127.0.0.1]:37445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLvEQ-0002Ol-0L for submit@debbugs.gnu.org; Mon, 15 Mar 2021 17:58:34 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]:44259) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lLvEO-0002OX-7y for 47150@debbugs.gnu.org; Mon, 15 Mar 2021 17:58:33 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4330027EE; Mon, 15 Mar 2021 17:58:26 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 15 Mar 2021 17:58:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=3+e0mahPm1Lp9SK8rxnINJgfySysifQ bfFFvuwxdr6w=; b=W2K4u18eJmy244YKkSXZGgYZ730JpxkInXVzQ0/IHW/smrd 3CbHXnr+XX8AApy7pOlwyRMvITaYXP0hOeKQYZRk+X/tLolaPYqj6U18S7C8eiHp 26P/LWZ0uAizN3DTpabJYYuJAwrm2psV7oL0AS7WMPaNb2CfX43ntSfTwbFFC0Di rSJSHOfdrksXxMZeEhxg29uBbV+pS3VeDIqMOcRmt869YMFhMhqZvNvOUtEToLvs 8G+mk3WcqXFgdvqFW9P5lpf81qeehjTG33ojcxoOCr5BgkhQDhk4VkKkfSXanHFI 5M8etm14b4Pkvc1KhZKdKYX5Nf+wYllBdxVH8ow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3+e0ma hPm1Lp9SK8rxnINJgfySysifQbfFFvuwxdr6w=; b=QC4xeuEpxd8NOPm1ZTsUYs RhyAm6wYSZE5zQvE8Bjbs7QTFEtuEmkTeDWEjie/dbLTUwUJUyjC5NPSRcU4VJOg KGmIv5J1D8GiOgcdQfnSdWwlXubUnqibXs4XtVFClqlujfiPew191z1Z08Hkt1nI mYUDlCPHLu3bBYYWDtMkj+mXa6WFZDh0a7OySY5f2t2zUe9eXBhhkAoOpRMNAbjW HykX7EVJzz1aV4Nkcl7zY0U1UIvc/65ic0ThkgXJUinZpk6L6zRgWQh6OzCtuXsI o5OggsjnuaJkasGbGO6oIlujpFfSxxnc4yalmX3PqVmn7mGjUnf9J2V52DIclajA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeftddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfufhhvghnghcujggrnhhgfdcuoehsthihrghnghesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeehleeutdduffffgeffieelte etvdduieehhfevgfdviedvtddtieefieeggeevjeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 32CEDA00073; Mon, 15 Mar 2021 17:58:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> In-Reply-To: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Mon, 15 Mar 2021 16:58:04 -0500 From: "Sheng Yang" To: "Alan Mackenzie" Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Content-Type: multipart/alternative; boundary=7b00dfe34f644f6e8a660dca0fab2ec1 X-Spam-Score: 1.8 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Alan, Thanks for the detailed explanation, everything makes sense now. I still would like to clarify the following > As you say, there is (minibufferp). What is wrong with that? > > That does indeed suggest we really want a minibuffer-mode, rather than > just fundamental-mode. But surely, the parenthesis pairing w [...] Content analysis details: (1.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (styang[at]fastmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [64.147.123.25 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [64.147.123.25 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 FROM_FMBLA_NEWDOM From domain was registered in last 7 days 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 47150 Cc: 47150@debbugs.gnu.org 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: -0.2 (/) --7b00dfe34f644f6e8a660dca0fab2ec1 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks for the detailed explanation, everything makes sense now. I still= would like to clarify the following > As you say, there is (minibufferp). What is wrong with that? >=20 > That does indeed suggest we really want a minibuffer-mode, rather than= > just fundamental-mode. But surely, the parenthesis pairing will be > dependant on the sort of text you're typing into the minibuffer, so it= > can't really be connected with, say, minibuffer-mode. >=20 > Sorry, I don't understand what you mean, here. How will the use of > (minibufferp) prevent anything else? I am not suggesting anything wrong with (minibufferp). What I have in mi= nd is that it would be better if there is a mode for the minibuffer, so = that existing packages can still use *-modes, *-global-modes, *-inhibit-= modes, etc. to decide whether to enable or disable some functionalities.= I checked the several packages I mentioned, they either compare major-m= ode with minibuffer-inactive-mode directly, or use some *-modes variable= that checks the major-mode. Their maintainers' life will be easier comp= aring to the case where only (minibufferp) is available and they are for= ced to make a corner case for the minibuffer. > I hope my description in this post is satisfactory. Yes, crystal clear! > So, a quick summary: (i) the change in the minibuffer's major mode to > fundamental-mode was intended; (ii) there may be some problems in some= > packages because of this; (iii) we aren't yet in agreement on how to > proceed with this bug report. (i)(ii) agreed. (iii), I am mostly in support of removing minibuffer-inactive-mode and m= inibuffer-inactive-mode-map, and give the minibuffer a proper mode. This= way, the maintainers' life will be easier. Another option is still remo= ve minibuffer-inactive-mode and minibuffer-inactive-mode-map, but keep m= inibuffer in fundamental mode. What do you think? Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --7b00dfe34f644f6e8a660dca0fab2ec1 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Alan,

Thanks for the detailed explanation, everything m= akes sense now. I still would like to clarify the following

As you s= ay, there is (minibufferp).  What is wrong with that?

That does indeed suggest we really want a minibuffer-mod= e, rather than
just fundamental-mode.  But surely, th= e parenthesis pairing will be
dependant on the sort of tex= t you're typing into the minibuffer, so it
can't really be= connected with, say, minibuffer-mode.

Sorr= y, I don't understand what you mean, here.  How will the use of
=
(minibufferp) prevent anything else?

I am not suggesting anything wrong with (minibufferp).= What I have in mind is that it would be better if there is a mode for t= he minibuffer, so that existing packages can still use *-modes, *-global= -modes, *-inhibit-modes, etc. to decide whether to enable or disable som= e functionalities. I checked the several packages I mentioned, they eith= er compare major-mode with minibuffer-inactive-mode directly, or use som= e *-modes variable that checks the major-mode. Their maintainers' life w= ill be easier comparing to the case where only (minibufferp) is availabl= e and they are forced to make a corner case for the minibuffer.

I ho= pe my description in this post is satisfactory.
Yes, crystal clear!

So, a quick summary: (i) the change in the mi= nibuffer's major mode to
fundamental-mode was intended; (i= i) there may be some problems in some
packages because of = this; (iii) we aren't yet in agreement on how to
proceed w= ith this bug report.

(i)(ii) a= greed.
(iii), I am mostly in support of removing minibuffe= r-inactive-mode and minibuffer-inactive-mode-map, and give the minibuffe= r a proper mode. This way, the maintainers' life will be easier. Another= option is still remove minibuffer-inactive-mode and minibuffer-inactive= -mode-map, but keep minibuffer in fundamental mode. What do you think?


Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@fastmail.com<= br>
E-mail (old but still used): yangsheng6810@gmail.com


--7b00dfe34f644f6e8a660dca0fab2ec1-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 11:12:28 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 15:12:28 +0000 Received: from localhost ([127.0.0.1]:58272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOMEF-0002w3-Us for submit@debbugs.gnu.org; Mon, 22 Mar 2021 11:12:28 -0400 Received: from colin.muc.de ([193.149.48.1]:20296 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOMED-0002vo-IE for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 11:12:26 -0400 Received: (qmail 90971 invoked by uid 3782); 22 Mar 2021 15:12:18 -0000 Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Mar 2021 16:12:18 +0100 Received: (qmail 6515 invoked by uid 1000); 22 Mar 2021 15:12:18 -0000 Date: Mon, 22 Mar 2021 15:12:18 +0000 To: Sheng Yang Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> 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: 47150 Cc: 47150@debbugs.gnu.org, acm@muc.de 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, Sheng. On Mon, Mar 15, 2021 at 16:58:04 -0500, Sheng Yang wrote: > Hi Alan, > Thanks for the detailed explanation, everything makes sense now. I > still would like to clarify the following > > As you say, there is (minibufferp). What is wrong with that? > > That does indeed suggest we really want a minibuffer-mode, rather than > > just fundamental-mode. But surely, the parenthesis pairing will be > > dependant on the sort of text you're typing into the minibuffer, so it > > can't really be connected with, say, minibuffer-mode. > > Sorry, I don't understand what you mean, here. How will the use of > > (minibufferp) prevent anything else? > I am not suggesting anything wrong with (minibufferp). What I have in > mind is that it would be better if there is a mode for the minibuffer, > so that existing packages can still use *-modes, *-global-modes, > *-inhibit-modes, etc. to decide whether to enable or disable some > functionalities. I checked the several packages I mentioned, they > either compare major-mode with minibuffer-inactive-mode directly, or > use some *-modes variable that checks the major-mode. Their > maintainers' life will be easier comparing to the case where only > (minibufferp) is available and they are forced to make a corner case > for the minibuffer. OK, thanks, I understand now. > > I hope my description in this post is satisfactory. > Yes, crystal clear! > > So, a quick summary: (i) the change in the minibuffer's major mode > > to fundamental-mode was intended; (ii) there may be some problems in > > some packages because of this; (iii) we aren't yet in agreement on > > how to proceed with this bug report. > (i)(ii) agreed. > (iii), I am mostly in support of removing minibuffer-inactive-mode and > minibuffer-inactive-mode-map, and give the minibuffer a proper mode. > This way, the maintainers' life will be easier. Another option is > still remove minibuffer-inactive-mode and > minibuffer-inactive-mode-map, but keep minibuffer in fundamental mode. > What do you think? After some thought, I think the best thing would be to leave minibuffer-inactvie-mode as it is, and create a new mode for an active minibuffer called `minibuffer-mode'. That would enable minor modes to specify minibuffer-mode in lists of modes they handle, or don't handle, as you say. This shouldn't be too much work. What do you say? > Sheng Yang(杨圣), PhD > Computer Science Department > University of Maryland, College Park > E-mail: styang@fastmail.com > E-mail (old but still used): yangsheng6810@gmail.com -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 11:52:27 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 15:52:27 +0000 Received: from localhost ([127.0.0.1]:58292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOMqx-0003uw-Dw for submit@debbugs.gnu.org; Mon, 22 Mar 2021 11:52:27 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:52590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOMqv-0003ui-Gh for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 11:52:26 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MFXtla087500; Mon, 22 Mar 2021 15:52:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=; b=sPwcMxywh7OQ0D9uRgqj8G7LDr8EbrcZCeCSPxLtHfHsuuIrIPrnAjYc5OncOeoyo55+ cOempsjsQHztb230Ok/Qi12pvtE7DTQeJsjrNJOeleXhuj3NHiL2hVATTGa6PA53UO+p FsJYh+4SjyCjs+011lpnylIkaCQuNbJ9MDnu0hLyGssWBSw9yHDvKAIeZW+UQ1ng8al7 glC3HZh9WHkFJqipNYdn0m0IhgF7oPG0iK2YNjyNbe39+FsJMmnMH8YhyibXvtVgJB7r Jbfw4+JsBjh/KivZaoEsq2uNwAw2BuAa7WvKvbr4R8o5N8uOwYBUm6PyvMNkfpSYmE7i lw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 37d9pmuwnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 15:52:15 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MFab6W059276; Mon, 22 Mar 2021 15:52:15 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) by userp3030.oracle.com with ESMTP id 37dtyw8pqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 15:52:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=li0VHrsKyJhN2LTsG7lhOfq5uyi777AMDXZanZ8FhiWWn/e3gqpBWUFj5c3xkGFt9045PHCIBezhnKLts30AL71G5UWkgvLUxFJDiQauyI2VLeDAssOYpEID19Gj14srVITM9Gtpb9HAdbIILEebkowGrc25ymAcNraVsmkav7mHJehsLHgZzfNOnRLQtDE8u5kNWKz9XMi5oAbsr0nKplbT1ogI33ARFmQVvALoIVFzuLmXeKXWyH4tqqodVYtDi05DRg4WpxTBviCOXSZH4oMN2MDDh+dY07y5KLdGBikZbfIX+0eOSVcHMN5pEpDKf6o624kyUZHUa1GK9MaW1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=; b=kglwl+fbLitQq1bV4T+9svTLMhaBTKlE509l78qXlsTjNBw/Y7AKiPb9jjdDtn2gYlukHBVlly4xJ8vW5lfaTHmyYRHpC6ZEmGoeYNgTCup2g2kssHPrzZBvoSXlINwJoa71IpfyL7XWqS/Cd6M0/p4EHoW25UNEPw1hJjQEPFaax8IsMyUaL96c2sNfvxUTur31O0diccz7CwiIzhR3L7zNGGtylReGK53woHSwttLKKj9Lj1DafMy+ISExI0KjMxt5szCFcH6A5TmQb1ecf6+evvjoj2upQDh8pL94eImWCjF4HuKLGeDw9R+zTOSjJ2R7vWM/CUN1M4a/N6TQ7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mZ+PPj3egXB+EMxzYE9n8u/zbcj9FXSYRepYelh8YwY=; b=XZVMVwAuc0EM310LOyqPOwr4prIsFEjhmF9wHE/fcPhrzfg8KvzZbM11E0dQ1MJMppMc8JqTJZcoVja3+My0X11BPUr19JtYw277HQTlXAD0nQoqeOP12KLH9RHemcPU3bIsrQAUn9o3/IiSWo+lGsubeMG9TejkIPN0jjp+CDY= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4588.namprd10.prod.outlook.com (2603:10b6:806:f8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 15:52:13 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 15:52:13 +0000 From: Drew Adams To: Alan Mackenzie Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXHy3loRhmbplnOk6CuxGlsSCTQaqQIaXg Date: Mon, 22 Mar 2021 15:52:13 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muc.de; dkim=none (message not signed) header.d=none;muc.de; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20886578-563d-4175-9c04-08d8ed4a75e5 x-ms-traffictypediagnostic: SA2PR10MB4588: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hoPBK76oUfr8/SbIWhqJ0+gSsmzpyDJwq58rz2hPkQRVTPx5BoMVSU5l/yvMKd1hoz1uqZ2yOWt1txRSQBftxH6cHo/R2NbPcIaoCHgEvQqFAvH3Jpd/L+WghwW1yFhwQc6xQAjmXAslSCQZWxIOkK4sOEfxxQViqdbPK0ipcws7dG2zDTwKIOqQbdvEkpPYRdHVx7vlghRJYBfOeMgAurfUDZ8HxgkEeN06TuiMF1svUequf6gh17uZoidiGHzQ0w/p9OuaIYVk0pVeKk6hfS+Y9h0/J89oxsUFX+0eSuzHJADTNMnySerm5R9XC/hiCk4qrz+ST4tzeV3S3DYLNHfRPN69Az3muY7FR3vOvaq1TNwZnoXAqCJbx0vnNPsjsmMQ3dWlyonJDoqNJfFUD/B20gO2a2RFDdCepM4PrEo++M+BhBKKAYDNtBpSdkSJJ4hR9dxFsv4SE19phKmcrK34rsX9AJVONrwzs+ODNVM2ldAlhse9xiUTxA0R6kNsaHQkB71Q/eSKYAMGkQEesN6X2LtjWRfZocZ3GshZ04460NFGSxpUOPFylHB++VrYFZF1CJXUXILVyo30dYXrm8kbZpjblpnggI6TwR35RJKaf2BSjfILZdEMreLDEd/Rfneud6eNrnJi9VV8UoaelLlid9pLU1iTXPS7zAOG/5k= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(39860400002)(366004)(8676002)(6506007)(26005)(186003)(9686003)(33656002)(44832011)(7696005)(66476007)(66446008)(5660300002)(52536014)(64756008)(76116006)(38100700001)(66946007)(6916009)(316002)(66556008)(4326008)(71200400001)(8936002)(55016002)(478600001)(2906002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?OUpJdW94WUxDcWM5STZLQkx5VmFDSXdpYmhuc29MalZUc3VIWS9nUnpERkhF?= =?utf-8?B?UUY3ek9VSDFraDlYZy9VRGhXQVo1dDdmRGxqdTlSM2JxeU9HNzhtTit5eUZk?= =?utf-8?B?NTRvNTdFMGNqb2xyZkhSMG9yeUFKU1pRbEM3eW5jaE1DeWJlUTZsSFc5aEtl?= =?utf-8?B?eTFzUzczNXF3TVhzV2NUa0JSUVhmclFjUHUwVThxTmQwa0NLeWxJY1FYUEZE?= =?utf-8?B?NTRqKzJadHprV3VxTE8yc3Foa1JkK2M1RlZCbjlEUGJ1YWoveWVLVmE0REhJ?= =?utf-8?B?YjZzNTMvNDI5UVBzUExqdW9XMlNxcGxWS3hDOUhtZTJIR0JIckVYTnl2aEhX?= =?utf-8?B?d3BQNjczYVhEb3pqeERhR2Z2cHltUE1jRTdXcUl1S0JBN1JhSG11YUhvNDRP?= =?utf-8?B?ZlBGMWVRb1UyYVBRb2tGUnAvWUhBSkxaaGc5TkQ4Qk9ranpUOTBjYzNGT3ZD?= =?utf-8?B?Y00wb3lrZjg4S05FM3V4blY3bFVkVVZiMXJNNFZFdTBKbThIaG95Vjc5L0Vs?= =?utf-8?B?RzhQYU5NNEtuNVJmd0xtaGZMT3ZMQXpzRFY3WTFLRkFQSXBheE91aGdNdEl1?= =?utf-8?B?aXBoR216cGtJcG5qdjVwT00ydjRVdGxpOTBxbWJFZ3B5dHg1KzRPQ0MxOGdK?= =?utf-8?B?QkJJbHptaHlMZHhpTGVJNHdDYVBLVWxJcldFSC8xMzZPeE81Wk5rRCs3RkJI?= =?utf-8?B?SXREaGhEaXJWMzRXR3VnYnRndGhic3pGRkdIMG1vTWpqTVJVeWJtL0JmTXZw?= =?utf-8?B?WmFscDJ1ZERjVDJhQ1lPMWE0WENLanoyZGVoWnBUMTViZDd1dHYrSDVkdlhm?= =?utf-8?B?NnVWd2Zhalh0d1ltd1lHeUdIcUV3eCtvT2Q4NkhjVHhYUUQ0Z1lCS0xOenE2?= =?utf-8?B?ZXd5L1E5bWJONXN2bGYreGdPTGZjOFRkRU10Sk1lZFBtZWlTd3dzTC9FYnlC?= =?utf-8?B?c2pnWTAyUklFK2lEenRnR2hZd1hOU1ZBM3YxN1NnN0h4bkVIMVh1TEZUTmxK?= =?utf-8?B?eU5BaVhMdGd1L093M0NmL3pHeDVpV25Kd0RYQ2E0ZjVKTzVvd3dKcVZwQnlo?= =?utf-8?B?ejZ5TWxDblBVUElBSHhvUHpOYmN0azU0T2JVblZlZmJITVRBS3NuMklYRlU1?= =?utf-8?B?N0xOcDBRRGRrUTAvMGc4TGxGWktjcDdJbzNrdWJmb1BnNmRUeUtYVTJ5c0RT?= =?utf-8?B?eGdMQUZDajVTT3dKUWtjc0NvWUdBRitpNzhxRXFtL3NhaVZpM0RkTHk1OGFP?= =?utf-8?B?V0dHSWVBSnRJSWRvUS9LRUFPWU9jSVYxcllUQTRzbGtxaEZHR045QXgrbEcx?= =?utf-8?B?bERXbWFiNCszRHorK2V3Z2VmeFV2WXBjYWJNOVY0bCtkYXdSMm1jK0lTMmp4?= =?utf-8?B?ZWdlS1podW00eU5hZlpoVS9MVUNXaUVXbGtSWGttR1dTZDBCYnltaCswL1Zq?= =?utf-8?B?YkxqOUVvUSsvU2IxMjRiQUxCekd0ckFpOWpPRzNibHJIRUV4SVpoL0QrUTlq?= =?utf-8?B?TmZsY3VxNHp1ZFFkMWxXWGZITTRtTEpXdEk1UDZVSlRwd1J0SWxsMW02SzBB?= =?utf-8?B?TWFJK0dVbmVDb0RTSitFa2MwRDFNV1BKUUNqNGFuTTVpT05lQjg5bHl1YnJS?= =?utf-8?B?aGhhTFZLbjNBTFdLOGtpb3hoTzBldFAvZlFnRURIRUMzRFVidnFPNzNwNjIx?= =?utf-8?B?T2g1eHorOHlTT09HajZiMEdla05oeEowRXFGVVVTdEozZ3FhV21lWkd1aE5H?= =?utf-8?Q?vjNJgIzZVTioFo/ho4=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20886578-563d-4175-9c04-08d8ed4a75e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 15:52:13.3821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kJazsr/b7iSFLgGMGOsIy3xngrW0IzfevhE61Xpmjkjs1nWakzk1SrF9eP3sGjGQrbqLjudQmq/RpeOx3BLsRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4588 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=669 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220111 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 mlxlogscore=970 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 adultscore=0 clxscore=1011 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220111 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (---) SGkgQWxhbi4NCg0KU29ycnksIEkgY2FuJ3Qgc3BlYWsgYXV0aG9yaXRhdGl2ZWx5IG9yIHNwZWNp ZmljYWxseSBhYm91dCB0aGlzLg0KDQpCdXQgSSBmZWFyIHRoaXMgd2lsbCBicmVhayB0aGluZ3Mg LSBqdXN0IHdoYXQsIEkgZG9uJ3Qga25vdy4gIEkgdXNlIG1pbmlidWZmZXJzIGEgbG90LCBpbiB2 YXJpb3VzIHdheXMuDQoNCkkgZmVhciB0aGF0IGJlY2F1c2UgcGVyaGFwcyBubyBvbmUgd2lsbCBi ZSBhYmxlIHRvIG9mZmVyIGEgY29uY3JldGUgcmVhc29uIHdoeSB5b3Ugc2hvdWxkbid0IG1ha2Ug c3VjaCBhIGNoYW5nZSwgeW91J2xsIG1ha2UgaXQsIGFuZCBvbmx5IChtdWNoPykgbGF0ZXIgd2ls bCB3ZSBmaW5kIG91dCB0aGF0IGl0J3MgYnJva2VuIHN0dWZmLiAgQW5kIHRoZW4gd2UnbGwgaGVh ciBvbmNlIGFnYWluIHRoYXQgIlRoYXQgc2hpcCBoYXMgc2FpbGVkLiINCg0KVGhlIG1pbmlidWZm ZXIgc2hvdWxkIGJlIGF2YWlsYWJsZSBieSBkZWZhdWx0IGZvciBnZW5lcmFsIGVkaXRpbmcuICBJ dCBoYXMgaXRzIG93biBrZXltYXBzLCBldGMuICBJdCBtYXkgbm90IG1hdHRlciB3aGF0IG1ham9y IG1vZGUgaXQncyBpbiBieSBkZWZhdWx0IC0gdGhhdCdzIG15IGd1ZXNzLCBpbiBmYWN0IC0gYnV0 IHRoZW4gYWdhaW4sIGl0IG1heS4gIEFuZCBpZiBpdCBkb2Vzbid0IG1hdHRlciwgdGhlbiB3aHkg Y2hhbmdlIHRoaW5ncz8NCg0KV2h5IGRvIHlvdSBmaW5kIGEgbmVlZCBub3cgdG8gZ2l2ZSBpdCBh IHNwZWNpYWwvbmV3IG1ham9yIG1vZGU/ICBXaGF0J3MgdGhlIHJlYWwgcHJvYmxlbSB5b3UncmUg dHJ5aW5nIHRvIHNvbHZlPyAgT3IgaXMgdGhpcyBqdXN0IGFub3RoZXIgY2FzZSBvZiBsb29raW5n IGF0IHRoZSBDIGNvZGUgYW5kIHRoaW5raW5nIHRoYXQgc29tZXRoaW5nIGlzbid0ICJjb25zaXN0 ZW50IiBvciAiY29tcGxldGUiIGVub3VnaD8NCg0KSXMgdGhlcmUgYSByZWFsIGJ1ZyB0aGF0IHlv dSdyZSB0cnlpbmcgdG8gc29sdmUgaGVyZT8gIElmIHNvLCB3aGF0J3MgYSBzaW1wbGUgcmVjaXBl IHRvIHJlcHJvIGl0Pw0KDQpBcG9sb2dpZXMgZm9yIGJlaW5nIHNrZXB0aWNhbC4gIExpa2VseSB0 aGlzIHdpbGwgYmUgb2Ygbm8gY29uc2VxdWVuY2UgKGJ1dCB0aGVuIHdoeSBkbyBpdD8pLiAgQnV0 IG1heWJlIG5vdD8NCg== From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 12:27:39 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 16:27:39 +0000 Received: from localhost ([127.0.0.1]:58343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lONP1-0004q1-Fc for submit@debbugs.gnu.org; Mon, 22 Mar 2021 12:27:39 -0400 Received: from colin.muc.de ([193.149.48.1]:22403 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lONOz-0004pn-LB for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 12:27:38 -0400 Received: (qmail 42567 invoked by uid 3782); 22 Mar 2021 16:27:31 -0000 Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Mar 2021 17:27:30 +0100 Received: (qmail 7830 invoked by uid 1000); 22 Mar 2021 16:27:30 -0000 Date: Mon, 22 Mar 2021 16:27:30 +0000 To: Drew Adams Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de 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, Drew. On Mon, Mar 22, 2021 at 15:52:13 +0000, Drew Adams wrote: > Hi Alan. > Sorry, I can't speak authoritatively or specifically about this. > But I fear this will break things - just what, I don't know. I use > minibuffers a lot, in various ways. Things are already broken, slightly. > I fear that because perhaps no one will be able to offer a concrete > reason why you shouldn't make such a change, you'll make it, and only > (much?) later will we find out that it's broken stuff. And then we'll > hear once again that "That ship has sailed." In my recent enhancements to the minibuffer handling, I noticed that minibuffers (the actual buffers) began life in fundamental-mode, got used, then on termination were put into minibuffer-inactive-mode. However, on being reused, these buffers remained in minibuffer-inactive-mode rather than being restored to fundamental-mode. This is silly, and "obviously" a bug. I fixed this bug by making an active minibuffer always be in fundamental-mode. > The minibuffer should be available by default for general editing. It > has its own keymaps, etc. It may not matter what major mode it's in by > default - that's my guess, in fact - but then again, it may. And if it > doesn't matter, then why change things? An active minibuffer doesn't use its own key map - it uses the key map supplied to it by the calling function. This is how being in minibuffer-inactive-mode (which does have its own key map) "worked" for so long. > Why do you find a need now to give it a special/new major mode? What's > the real problem you're trying to solve? Or is this just another case > of looking at the C code and thinking that something isn't "consistent" > or "complete" enough? The OP of this bug tells me that minor modes which maintain lists of "valid" major modes they work in, included minibuffers by including minibuffer-inactive-mode in their lists. This sort of worked (except for the first time a minibuffer was used), but is undesirable. So the idea is to allow these minor modes to specify minibuffer-mode. > Is there a real bug that you're trying to solve here? If so, what's a > simple recipe to repro it? I think there's a bug here, yes. I don't know of any particular minor mode, off hand, that is affected by this, but the OP assure me they exist. This isn't really the sort of bug that has recipes. > Apologies for being skeptical. Likely this will be of no consequence > (but then why do it?). But maybe not? No apology needed! Thanks for raising the points. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 13:09:48 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 17:09:48 +0000 Received: from localhost ([127.0.0.1]:58422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOO3n-0005vu-PS for submit@debbugs.gnu.org; Mon, 22 Mar 2021 13:09:48 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:37926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOO3l-0005vf-TW for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 13:09:46 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MH73NT052968; Mon, 22 Mar 2021 17:09:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=; b=P2i88JZL1NlhKS8mBUBKiuUkOGx8QZj1DhJV0ohyuLicF01XzPbMs1ScUBMsGzDPTT/x mgKL5RSg7B+BtvVKi48USa2assiBjgZo152nvSRfPJec24+lh5wzamchevsV2AeWBdJc E5+3RwkVlilu/lk9pClD4qR4KBY8e+v6rRncUIrERYTXijOqc05mWflIX4tafYRAoNI7 cgTpxKU0jFl7W6whIxCIqD2FA6P36NWXyucUF61wY/9Hx+4NWdz8z1OmsERyGAFOLXLz fyQh+Z7SiObB0qKFWhLp1+7vTi9y/7H8BfubIDcrGiKxMTZYDOdwiCr+bT7GKtZwPotM 2w== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 37d90mc6w1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 17:09:35 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MH6J1t192064; Mon, 22 Mar 2021 17:09:34 GMT Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2170.outbound.protection.outlook.com [104.47.56.170]) by aserp3020.oracle.com with ESMTP id 37dtxx73da-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 17:09:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LxBI+Gn47e+T/rhow/b6ySWOdNpwVh2GkfH1T33v+E5GgWrTs9GBRaQpfvUWAkWpiGIG3OB/Q0+lN0lUFTY6pjnswNktReJISEjC6Tw9dgFc1iaUDBtCOrg2reTTBlTumvJNk3PaqUkfzaw2OZe5nFqPRRBxulKQ3orZKRbbLtKg2JBYyOMC0MCTv81gEtkLo/5mmD17ivq7ys7kch0WqugfTISPFTmi486Duws5o5PKjIt7dpcwxUu124MSmeIzLqaaYlEdKrrq1LAtIiFelqBicy/jSI/8NvVOKE+cbTP1pP4Ft1tReLhhtZVbzBtyyzgZ9BcZSogSZG+kTwyjBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=; b=lt2H5uC08qvgiJWwxB+uOWIXDjJi7mie+ZjfAJglfokwdlx25RmEORRJhYIB4P46QeQ53iF+c29gnP5oOeOSBb1Rh1e2AypYxs84hmQjUjG6XxT2wor9z5LiynyW8SfOYaMTlh9sNkhkNjYla/oWu8shOtt5b19k54jvbmLu2llzMQc+pA9CHOBfLXK7Pj6LSwKPMAKXuR8yVhidleN8ZoUHTiGz/5skdqu8fwkrzkOxL3P+GiQ+ZovK0Xfl0fQ6RR1OSXjudBfRzBr0zg3k+2JNrvjbpuY7VD6cmpBnTdkU5vn2OV0oxe0ktwDImLRbqm8gAaAoY7E2xVSTPCYfFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e9nWlKbjzStFceDQJduu/bc42uMl54hsw/5YKIcxq8g=; b=HtSGslxOmn/7C/NH8ajHaONxjKAh4oWStdQCzW5vLcapVcgmdEjJpSJD+nRfOlOnKETMRpZrs41pKJgsyQJoJ9Jkd5nuc0o35SP3xWyToljsODAN8NxFPFBT6+g2z57rlALIo0d3v7Ir+gWDDOfGgOI28KRGu/NUSd/oiD2YUNY= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4411.namprd10.prod.outlook.com (2603:10b6:806:116::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 17:09:32 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 17:09:32 +0000 From: Drew Adams To: Alan Mackenzie Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXHzhGkdcXS6vwFUSNlV7whKGfDaqQNpzQ Date: Mon, 22 Mar 2021 17:09:32 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muc.de; dkim=none (message not signed) header.d=none;muc.de; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3eb942e1-3587-468f-9dfe-08d8ed554333 x-ms-traffictypediagnostic: SA2PR10MB4411: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ts/fyT83m39teSiZKq19b+9JbCAWg20vaz6Oy2rE+ik7kkPS0os+XHxtctBwjF5HM/qqKEwJ3jzFvSnmzNHTJNONqq+2/hFw9tr/coojZkZOBmDpatklpUQ62vguSeRldDpdfVvE4NvRIzkZ/sQ3lpHvz3kBtJGm++mfYCKVWN/9VDEaHettdImaj9j++okIIsdFYXIs3lZ+VIiI4WVMU8kvAfTdsbCeBKho5BJ9w08CntZIaFbOJI+zT8ju8gwPRI7XYZM9SKn6WOMO/EVVjLpnH+BTVgK5EM64OEH3NHgu1cuky/QFuSZ5qKbe3F9+6Jfl3bGi2bTG6epOSr+9MCM8IMUOrrJkIRp0ya9zrTzEIQ9MO1hXqtabTrkO+vgoi19uo/h/I3VUezwb/HL8WIhh+s3A8RhbLnzbUWOfjUUPjVdCfAP1t8vOH7PHt/qsXHLzhB7mFPF897NyqJkIqyTh3ueZiC0kN0KQ9DVqdSNtM4bdf0JU08hycBTHw+yY/6CbJ67IOVwi6C125nA6jNz9NHUREq60fNnPqTImTX36u/HlVxrJOnybJGPt988farL+Fp5isApXdVw9BPKNGwJE1T1sBri8JCX9Va4nul6O302+nADIkMFcRS4pITFUKjzc6WqcY0UXzpkVC8908SQY5HP8Ps0J7uU+Vx7WGQ8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(376002)(366004)(136003)(346002)(8936002)(66446008)(33656002)(66946007)(52536014)(2906002)(64756008)(66556008)(66476007)(44832011)(4326008)(7696005)(38100700001)(86362001)(83380400001)(71200400001)(6506007)(478600001)(76116006)(6916009)(186003)(316002)(9686003)(26005)(5660300002)(55016002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?E9vU5Led86c5KblEMWz+BANYPT4sWsEWvign3Se4rrusCTSesmiFIubneO88?= =?us-ascii?Q?PHs7XvSQt/8BFm2EVNa9Zjt1XrXDr9hKD0CZXLwUy9hZo3n05lIUZ1f1KAH8?= =?us-ascii?Q?j8q3muGeKYUq3yyZd27evtoGCozxwFBC42SmAbZVYgkD1BFPs6QZb0KoncMp?= =?us-ascii?Q?0dR5heoVpyfOs4hHjlnH8PBO9/fE7t3yD3j09kxoWNfo7lzDnhwV0pm0F+sg?= =?us-ascii?Q?yO3FGrlFrGRfyKMuOROWQTE7iX/RuNTIxafvZpe3uLvu8uo3jQ8ukOW1xqp0?= =?us-ascii?Q?QUkYoSF4MNOP83MgBPhvSjCErhhIxapqFCEvJyLnNNLIDdk+fguAJB+sHFFD?= =?us-ascii?Q?ZZ0Dc6Iroo6pcWdhm8Aa6PemwjmMbcrAgn/YY7kWHDhUqPDP6K8auR833ABJ?= =?us-ascii?Q?Ja771/X1jIVUfFLvzSBeIaJjPjVsYRP4ckcn4UEX5aA7ONPSzLJeQ7jP0TLr?= =?us-ascii?Q?Ow8FdoSfNy7c6QZ8jTBg3fvS8qeESh4rk1RNBRXaUP1jZGKTTTOQjsqeFIip?= =?us-ascii?Q?kfNC9FcW/f9xmW1mJ4SenW2651VPJY1lK5VQtJBO7+J79fhMDKBvj+hOH9Op?= =?us-ascii?Q?8/jyIw2KnHeS3IGNB4rdPB+eecHxwi/8GdlhWgl4WdAEapT5/TOMhCZ6Fy9b?= =?us-ascii?Q?kHj+SvX1h8xnRBo+YTxOVYB6OsBsdObs5Yj0EJrc/54vTrr0/PpyhsIF6nW0?= =?us-ascii?Q?/T6jgoi7hohrE1SN50JNn4HtUyt69RDNmkU5tYoqT/8LwFSPD3tEVJxBEDUO?= =?us-ascii?Q?4uvCjM8xMMndegUsCmoXTgLL1yXpV3wIDlmBUR8oU2HxT/RUxCdz+X3F5aVt?= =?us-ascii?Q?/NFkoxO9obFpszeaAMYJut/S2lIUYrc55VlCh3qCraAhvKblfAE6FbtP3GwH?= =?us-ascii?Q?BO1h3qgnzE/xZ+cDjxRZnXmc2876MaJOQqkSS0ZGTP3emb7XXtrfL4QmUd58?= =?us-ascii?Q?xNVy8ie6udAsIhh6KdefyJOknOoSbFKXH6B7zfiSvuZXdrI+vUC5/uQZqLCs?= =?us-ascii?Q?9G3usdthmMdG0aTACc/J0OUoO7vtKU0O+7Ssp5Wcrg8uAGWia1aTa4qyWF6g?= =?us-ascii?Q?x6RN2ulGwGQCvL514fYwk6VLkG56wXIqLikhkH942BjyCw9ioFsZOpB/VuIO?= =?us-ascii?Q?pzgldPju/0gZdRHyc1jydIm9QDursj6GMleIOgeZ89cjuRvpxhmam+AOfAAt?= =?us-ascii?Q?tBn2FdKTRCGqEoJ7+pH+c7W7AvSBEzVezAlOKCxGt9X1b6ivki/9Re+sJjSO?= =?us-ascii?Q?kaFYv6DVHg0qBniuUciSkgn0tf+F1SA3o5gq6K0+w5/zFjkbQuZuX37PElzK?= =?us-ascii?Q?XsNiJMXHuO5L1z4RmZPBklAf?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3eb942e1-3587-468f-9dfe-08d8ed554333 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 17:09:32.7906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Bu6grOkt2nQgVqQKKynqgsRAxQkggwCFMiKu8APPm1xzCClRQBZF9vzVHYTKFAykjI/rKjyxowp3vFVJm40fpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4411 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=901 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220123 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220123 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (---) > Things are already broken, slightly. I don't see that you say how things are (even slightly) broken. > In my recent enhancements to the minibuffer handling, I noticed that > minibuffers (the actual buffers) began life in fundamental-mode, got > used, then on termination were put into minibuffer-inactive-mode. >=20 > However, on being reused, these buffers remained in > minibuffer-inactive-mode rather than being restored to fundamental-mode. > This is silly, and "obviously" a bug. I fixed this bug by making an > active minibuffer always be in fundamental-mode. I don't see why it's "silly" or "'obviously' a bug", sorry. Yeah, I see that the doc string for `minibuffer-inactive-mode' suggests that it's not used when the minibuffer is active. And that's effectively the case, though the mode name might not reflect it. There's _nothing to that mode_, apart from its keymap, and its keymap is not used when the minibuffer is active. So the mode is there in name only. That's why I expect that your change will have no real effect. But I'm wary of it - let sleeping dogs lie. And if it does, in fact, have no real effect, then why make your change? This seems like a solution in search of a problem. What if the name of that mode was just `minibuffer' or `foobar'? Would you think/feel the same way about needing to add another mode? Seriously - please think about this. `minibuffer-inactive-mode' is, yes, a misnomer ... except that its (only?) purpose was to provide a keymap for use when the minibuffer is inactive. And the keymap name (with "inactive") comes free with the mode creation. If you really feel a need to clean something up here, consider changing that mode name (but aliasing the old one, for compatibility). To me, that would be the OCD end of story. > An active minibuffer doesn't use its own key map - > it uses the key map supplied to it by the calling function. Exactly. Exactly. Exactly. An active minibuffer doesn't have a separate mode from `minibuffer-inactive-mode' (a misnomer, when active). And functions dynamically provide different keymaps for different active-minibuffer contexts/uses. > This is how being in minibuffer-inactive-mode (which > does have its own key map) "worked" for so long. Yes. It just means that `minibuffer-inactive-mode' is a do-nothing when the minibuffer is active. But what's the point of providing a new mode for when it's active? What could/would/will anyone _do_ with such a mode? Keymaps are all that really matter here, and giving the new mode its own keymap would be useless. (At least it _should_ be useless. And it will be ... until someone decides that for "consistency" or "completeness" its keymap should really take effect.) I don't really see that anything is missing or broken. > The OP of this bug tells me that minor modes which maintain lists of > "valid" major modes they work in, included minibuffers by including > minibuffer-inactive-mode in their lists. This sort of worked (except for > the first time a minibuffer was used), but is undesirable. Sounds like pilot error (misunderstanding) to me. Did OP demonstrate a real need to include a minibuffer mode in such minor-mode lists? IOW, where's the beef (bug)? > So the idea is to allow these minor modes to specify minibuffer-mode. Why? What's the need? Sorry, but I don't get it. It all sounds quite vague, as if someone thought that s?he really needed to specify a minibuffer mode in those minor-mode lists, and that need wasn't (isn't) real. Can we see a recipe that demonstrates a real problem? > I think there's a bug here, yes. I don't know of any particular minor > mode, off hand, that is affected by this, but the OP assure me they > exist. This isn't really the sort of bug that has recipes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That, right there, hints of a non-bug, I think. It sounds like a misunderstanding, to me. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 14:08:57 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:08:57 +0000 Received: from localhost ([127.0.0.1]:58546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOOz2-0003Ga-MT for submit@debbugs.gnu.org; Mon, 22 Mar 2021 14:08:56 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOOz1-0003GN-IQ for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 14:08:56 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5009E44031E; Mon, 22 Mar 2021 14:08:50 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B34C84402DE; Mon, 22 Mar 2021 14:08:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616436528; bh=l2GM/zeVTPTkq2k+8xyGj4nBy1Q9RfijHgNIstnfd8Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lTGw0yNZbGtutA1T7ZgbfQBVSZUYumeDTzQCQEoC+GlvzlUjqJ0W9rTyGbdz47468 zPRmtErIlSSZaYlqEbbpbh3q7P7WdYrsU9+UXNJz106YBMLgaWCFnOCoYAb1CDkReG h+hPUXfgGgFSLKLS985D+ikiIHo+Onw4YW/P9Vr84oeZGmNeddmSCpP+faGrWGsYgL A8HmbHBNrtskxkag6R/8EFq55po7hxDij8d1PeApQym1WS+HtSAHhpUcyzuQjUw3pa HJHHaor7L84EVt3BPT9RSuzjM4QJCETMpuXL7ZXa6e6sUnvObOCDf310IDukZuqOlW 0jopDT+ctfVxg== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D7D2D1204AD; Mon, 22 Mar 2021 14:08:47 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Mon, 22 Mar 2021 14:08:46 -0400 In-Reply-To: (Alan Mackenzie's message of "Mon, 15 Mar 2021 21:30:41 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.103 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: 47150@debbugs.gnu.org, Sheng Yang 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 (---) [ Hi, perpetrator of `minibuffer-inactive-mode` speaking. ] > minibuffer-inactive-mode: the critical thing here is "inactive", which > means "doing nothing", or "not in use", or even "sleeping". The > opposite word is "active". From its name, this major mode was never > intended for use in active minibuffers, That's right. > but somehow nobody noticed that the buffer never got shifted out of > minibuffer-inactive-mode when it came to be used again. I did notice, but it didn't seem to cause any harm and I didn't want to get into the discussion in which we are now, so I left things as they stood. > I've been fixing things in minibuf.c recently, and when I discovered > this anomaly, I fixed it, so that an active minibuffer now runs in > fundamental-mode, as originally intended. I did wonder why there was no > "minibuffer-mode". But it was clear from the code that whoever wrote it > intended minibuffers to use fundamental-mode whilst active. I'm in favor of introducing a `minibuffer-mode`. Part of the question is also when and how that mode is activated (since activating such a mode has the effect of deleting the local variables). I think we should call `minibuffer-mode` every time we (re)activate a minibuffer. >> For my case, I want automatic paren pairing and editing in >> eval-expression. > That does indeed suggest we really want a minibuffer-mode, rather than > just fundamental-mode. But surely, the parenthesis pairing will be > dependant on the sort of text you're typing into the minibuffer, so it > can't really be connected with, say, minibuffer-mode. The way I see it, `eval-expression` would want to use a new major mode that derives from `minibuffer-mode`. And more generally `read-from-minibuffer` should accept an argument that says which major mode to use (I think it'd make sense to re-use the `keymap` argument for that: if that argument is `functionp`, then treat it as a major mode, if it's `keymapp` then use it as the keymap). It would also provide a cleaner way to do what we currently do via the `minibuffer-with-setup-hook` hack. >> Plus we also need a keymap for it, which is >> minibuffer-inactive-mode-map. > No. That keymap is very low functionality, and almost useless, as it's > intended to be. Indeed, the purpose of that keymap is that you can press `f` (for example) into a minibuffer-only frame to open a file, but only when there's no active minibuffer in that minibuffer-only frame. >> It seems to me the minibuffer is always inactive? I tried M-x, >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1. Is this >> a mistake and the offending commit was trying to fix this >> inconsistency? > Very much so! BTW: thank you for that. > So, a quick summary: (i) the change in the minibuffer's major mode to > fundamental-mode was intended; (ii) there may be some problems in some > packages because of this; The minibuffer used to be "always" in fundamental mode in Emacs<24 (since there was no `minibuffer-inactive-mode` back then), so I'm not too worried. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 14:12:59 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:12:59 +0000 Received: from localhost ([127.0.0.1]:58551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOP2x-0003MO-BG for submit@debbugs.gnu.org; Mon, 22 Mar 2021 14:12:59 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1524) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOP2w-0003MB-1Y for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 14:12:58 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AA01980A59; Mon, 22 Mar 2021 14:12:52 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0131D806F1; Mon, 22 Mar 2021 14:12:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616436771; bh=s9LR/sV4iMEVLzDSfIM26mc+dVsiOc7bpOzqUE8Qsqk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=g5AhqFhTwTp7r/zDNO68cMcVHJVGeySd97U9pkdZ6PJ/tF0X88wtDt6yu8uqpCqYq TOgVfY/p7eXZmMTLKhbQBKO1YK+WEU4HvLXjJDeR84PlY8Fzimw/13h2/NK0ahPPw4 jFIYhLoPaA/c2QeFjVhbNXR2xtjz+2/t1cdqLmccEXOR2P7I668sH3QPjKd5+Rz3nt BZaguyEUfpsp7lBrCBcs7pGxqFb0SOaaXQVXgUy/bTvNMg7QMHIoBFWzNW6ImXNwDg GOiyH73+raIV4mEvl8im8jLzuNk6idOGZNlJRJZKGfrWEvBVs0zaR/FvLGtxSSmraR BN9CNpBmsFf6Q== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B436C12034D; Mon, 22 Mar 2021 14:12:50 -0400 (EDT) From: Stefan Monnier To: "Sheng Yang" Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> Date: Mon, 22 Mar 2021 14:12:49 -0400 In-Reply-To: <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> (Sheng Yang's message of "Mon, 15 Mar 2021 16:58:04 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.096 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: 47150@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: -3.3 (---) > I am not suggesting anything wrong with (minibufferp). What I have in mind > is that it would be better if there is a mode for the minibuffer, so that > existing packages can still use *-modes, *-global-modes, *-inhibit-modes, > etc. to decide whether to enable or disable some functionalities. FWIW, these techniques sound pretty brittle, so I'd put the blame on the use of those techniques rather than on Alan's change ;-) Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 14:24:04 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:24:04 +0000 Received: from localhost ([127.0.0.1]:58596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPDf-0003fI-U2 for submit@debbugs.gnu.org; Mon, 22 Mar 2021 14:24:04 -0400 Received: from chiru.no ([142.4.209.132]:57680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPDe-0003ew-1j for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 14:24:02 -0400 Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id 2278E1280050; Mon, 22 Mar 2021 18:24:01 +0000 (UTC) From: jakanakaevangeli@chiru.no To: Drew Adams Subject: Re: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 22 Mar 2021 19:24:02 +0100 In-Reply-To: Drew Adams's message of "Mon, 22 Mar 2021 17:09:32 +0000 (1 hour, 10 minutes, 49 seconds ago)" Message-ID: <8735wnt5bx.fsf@miha-pc> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@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 (-) Drew Adams writes: >> Things are already broken, slightly. > > I don't see that you say how things are (even slightly) broken. > > [...] > > That's why I expect that your change will have no real > effect. But I'm wary of it - let sleeping dogs lie. And > if it does, in fact, have no real effect, then why make > your change? Actually there is one positive effect: `C-h m' from a minibuffer used to confusingly claim that we are in minibuffer-incative-mode-map and listed its keybindings. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 14:39:08 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:39:08 +0000 Received: from localhost ([127.0.0.1]:58608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPSG-00041H-55 for submit@debbugs.gnu.org; Mon, 22 Mar 2021 14:39:08 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:45598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPSD-00040l-II for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 14:39:06 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MION1b028077; Mon, 22 Mar 2021 18:38:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=; b=vjNpX/PlwXl0CabIAXHE7VbF7k8Pz2gI8A+Pt3brkDiiSe4WmiNNNoVQi5yz7vyek640 oy1cySf/ixT4uPLrMoiayCBB351DqE8UsvRmFxp6/nxVJ3nIMhVnc17UAno0Q/LAYySS TgGsGN7v0JeQzR+NjgCgzjsbSXCBby8deNAcZgM6paJwbfnJ3SgnEl2AHq+rYomv2gER MIgdHCWqlU9huAXVmTE1HqQQRqNWpepmOkZ32CMaqN5d+L7AzRmz8MQrcJtyRaDbAXhp VeyhhR+xyuXoxf91QsHLMb7jfGsf1uCohl9eTnzoMgshrYKxuJjtx61VEyLYCIBsTmbH dg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2130.oracle.com with ESMTP id 37d6jbckq3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 18:38:57 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIPLju067285; Mon, 22 Mar 2021 18:38:56 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by aserp3030.oracle.com with ESMTP id 37dtmnj47x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 18:38:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O1mSp3eBWsCM++sEjrmDyPKKbD6rn/ea0qgCtKSl9i5Q//uXnRIbucBJjtrmab5W+M+IJKwQ95/7etWzrddXZiJtJYA/nrBKqpbmnCdIMkgpmuAoUCKtkelfte3BXgDZEF8tt5/ykR2uDPP+5sZGbSlZGVFbTSTzT+ZJMNx1Pzm0GwJt+ro7Jcigx1mWZQaWuGXmSVDSpGQpT0cCxDeuGFwLL7fc4l+MdIIGlZ9zVhM64mXBPe6O+u4vtYh0ElOj5imgTqQ7lQjWWdU3sFuXyHGG1NxCtbyc/i4O7ayM5J/Y00u06GLHFLPIho0utrKRSV7FV+U/do1xIOfkjpDztA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=; b=jlqqMbKVd9J5YFnh192LpAwBRs+PTJaSr54EfhtBSeqVWAxvNtetZz+feVwZn10YwazkQhfKBikK69GtCwIHNwpL4WiU6G4VxuxTpi8hH+mt8H0UVxyIimS3J70yP04Gwqk96FDXlqJF8mjcO3AzWAcgKpweP2pXY3/tp8BKgv1I3nE3BHdyH0ZNzjip4T1y3vo/biyAVzU5utESB1x90sy2tRII5Tuqb18JLVW0Dff0zf2jAuLnul+Z9InZxBngB2dnqtrkVrmZlYGBgkilk9KAOL8wm3gfhKdq7NZCkvQDnGXixCtPE1Hk1f25MbMvo3NH0/YFEJ1U2tAyRpW3qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ty+IJoOB05qLftmlZMP9FKIgg1mO8kbIiy739iRys88=; b=aqdLEqMlpbKg5UmBm1URKq0m+90dZSM829XdppTR/Q/3bBf8swExbcoo01M6XZPqRO6Do8Qvo3LT6JI0QvpCYLAIitc20xF74cn56ER/VE7HDxqJ5sdDMuC6AAYPe2IMoes8wC82My2E0iDDezr9wJ00Ajk+EjcgPYjDoXQHhTk= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB2479.namprd10.prod.outlook.com (2603:10b6:805:41::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.24; Mon, 22 Mar 2021 18:38:54 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 18:38:54 +0000 From: Drew Adams To: "jakanakaevangeli@chiru.no" Subject: RE: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH0aawQknHPNxc0CVnEaK38+EEqqQT7EQ Date: Mon, 22 Mar 2021 18:38:54 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> <878s6ft5ze.fsf_-_@miha-pc> In-Reply-To: <878s6ft5ze.fsf_-_@miha-pc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chiru.no; dkim=none (message not signed) header.d=none;chiru.no; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03753ac0-c2f3-4d29-71cd-08d8ed61bf38 x-ms-traffictypediagnostic: SN6PR10MB2479: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jVvVJT7YQOnARv7gcAKgDCkqYAiO8ThpX8ypooe4VaBB1tccgY1CXnq+fL0bsgpSo4xSxva659RulNtGhDblCnOaT+kpppEDrsA1B/LbaBJbf1eVUUnOpZBnX1PL7TTGOqhVmJAQ2gyYQRr9NMooTlTnVuWZkOn65+2MMpDN+BB3eD+N83Uyqi85VtQrLg1hca0I/za+TQBdoaebNTdN16jgVC8bwrwzKZ7WjSNQbQwcBlrkMeQfRcXA7BlmzCZdTg9GdyguNwxoXdD9GK+hVTqC+CBPWSTV41RBbWYNdA27odslZVtlmM/3ir2x44vxHBSctQdtK+Ay2fCovN/zbm7OtCej6NjLJfq8uwuMAT5u8RpyK8iteaKl+IBrlBf6J4l+C59XR42+jelhvW36GQREGMct5aP48S7FLy3MWbV7FaVFeWCa1FKoT5TpxxZlVnSld6lutZehZYpq2W4cFf9YtOMslceUG0wrfdWzY2f6e1mmPstXfr/dk6mmk4iI8UUYwOqfV5NAwX9oPVvP+we6v5d9j5F39p7E4W25ptFD0/KFxr+ypee0iQ70dZ6JBblRR6WGVjxzSqA5+2KMXG/gPIb5hjkn82Bws8yg7aYJVeG/Ifq5XCBOdtwSc7c+lIOAFRhxrykPTRqNXlxLS4d/NvHCyJ4EiyI/FLHTRxY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(396003)(366004)(346002)(136003)(6506007)(186003)(7696005)(66556008)(66446008)(4326008)(76116006)(52536014)(66476007)(64756008)(66946007)(9686003)(55016002)(26005)(5660300002)(2906002)(478600001)(8676002)(44832011)(71200400001)(86362001)(6916009)(316002)(8936002)(38100700001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?OmmcyruWp0SQi0pKAaQLPy5QYeUh1awvH6XpqFsG+U0jDvswY8q0D6wmT7SV?= =?us-ascii?Q?DiE/1JYz0ZhohyKfkx3nC8UeedgcfHCIJ3Ic+cxxXQMOJbjkA6l5QKPGY546?= =?us-ascii?Q?1Xd5QMPBH3sdUsjTLcSOwNtlb03n5Rbh98q6KM6YW5A046Mz15bh+kVBh9D3?= =?us-ascii?Q?NxA+8/zzFS3bONUkIlpbpu8PPzCn9IQQqo7h0bSBdrZXsFO5l/eQVCeRDHX4?= =?us-ascii?Q?XhNIheTQEWap1HRsEWB/BQBErEW7GPmZiM5U9+ywlA8GzWq5Li5O9qjC262U?= =?us-ascii?Q?BC6UzVy3jSPNabTaLS3i08s5Ynu3clk6cwcHrAik6FRcdahQeC5eNF9ixYl4?= =?us-ascii?Q?ys3bybW2oFvtvm+sXMBSYrnbiFigh3Bb20SdBGm9mnLmajR1Wv4xt6olfoG0?= =?us-ascii?Q?KBT36e8Cc5sspJxZhcTAjsxvv40XScBhBdNdnbQlPEr9krHM6FikrzfSAmvc?= =?us-ascii?Q?DP38r0oJRe9+2dFcBYsOghGYC9f0IyvKYqEZ5WrdywwRMaMgElUjS3v+bsTq?= =?us-ascii?Q?3gPd72AH3/+v9swsp3CKrU3NAWviAoy9WK8Va5LCMfyTcsBeg3NWpX392Kjb?= =?us-ascii?Q?PF7oOR+bAwnXYaN43k65cnAgjtD8foyoBa8p0/r835u9gkeCLjB+8XtzHxSn?= =?us-ascii?Q?8pWCsEBTTEwrjsTgxlB5Uq1Y5Zb5ct72E3eRzDU1l6yRRjaUum5bOBmLH/Be?= =?us-ascii?Q?IyWXccLT/iielFuaxN2HqrTpubvffhMTQkY0A/L3zibxVwIefialkhncyxlw?= =?us-ascii?Q?t1hjLbWEarXs25BR3Ja9DMGfXhgNCjswgqWCvuVeZ/wnaqvIByilobbT8snL?= =?us-ascii?Q?BZ3q0Jv1uqgYdZlEoDUsdmpaO1gX+sqqm6dXpGG2Gq5EUqWC21FVdYqVnRX6?= =?us-ascii?Q?oZV3A6mKLFSPuN7ZopeQk2ge1dY6pZgj2W7QOl+sRk3doQyxlfv809PHuY76?= =?us-ascii?Q?sw36rT1n4DZJLMJ9AYoLY3deGAUKugVJNL3D4qPmDwZiG2FgQZEV6z6Jv5nv?= =?us-ascii?Q?3wV3qB2zmhNG5CXHK9EM8yeMttax6QU4XNYCOF8+Z9b8bhKLsCLPWKBPjFtu?= =?us-ascii?Q?/4wn308O3iZnLj6nox9FR/V8U9iYtbHOQybORek//IWMUo6ia1y2VDVokf+1?= =?us-ascii?Q?ddVDYrevljd2xZPtlyR6NRsNq9SSk+jg2Tbktl6vCgRU/QBuPq9BDpE16HEx?= =?us-ascii?Q?Bd98lNlV3ZFmnXVcZjXK6F9kZ6EJ5X0RSrxlAb4sK2SrWKOQLBSlgQV4Epih?= =?us-ascii?Q?6w8saUxuxLf++cVZrrLT1lx0wBgRvF2Ltf9EKb+tAxN66DBe4/wMeSz+qEmU?= =?us-ascii?Q?AduA/quOnRJeFb+fCEwQT68/?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03753ac0-c2f3-4d29-71cd-08d8ed61bf38 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 18:38:54.7428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MWQBUPo9YtuH+kXt7yK2Tt+0Srm8G8tTOjajvRLOBRMkY6JJ9nlN3cNxr0Hafa8+7YptkHPZ70H0M3HDaFDIog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2479 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=916 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220134 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 priorityscore=1501 spamscore=0 adultscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220134 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (---) > > I see that the doc string for `minibuffer-inactive-mode' > > suggests that it's not used when the minibuffer is active. > > > > And that's effectively the case, though the mode name might > > not reflect it. There's _nothing to that mode_, apart from > > its keymap, and its keymap is not used when the minibuffer > > is active. So the mode is there in name only. > > > > That's why I expect that your change will have no real > > effect. But I'm wary of it - let sleeping dogs lie. And > > if it does, in fact, have no real effect, then why make > > your change? >=20 > There actually is at least one immediate positive effect: > `C-h m' from an active minibuffer used to claim that the current major > mode is inactive-minibuffer-mode and confusingly listed its bindings. Yes, but putting something else there is bound to be just as misleading, or nearly so. If what you describe is a real worry then a more appropriate fix would be: 1. Rename `minibuffer-inactive-mode' (e.g. `minibuffer-mode') 2. Provide a mode description that says clearly: a. Minibuffer-reading functions provide the active keymaps. And list them, so users can follow their linked names to their descriptions. b. Explain that when the minibuffer is inactive the keymap that's active there is the following... IOW, why have two modes? One suffices, I think; it just needs a better name and description. And the description for the _active_ case - the keymaps - is more important - that's what the minibuffer's about. I doubt that anyone ever even uses the inactive keymap (but maybe there's some rare use of it somehow). [Oops, Stefan just posted his use of it. Still - very corner/rare, I think.] The mode description of the active case can/should say that, in general (by default), you can carry out _general editing_ on minibuffer contents. That's not so obvious, IMO. (And Emacs should make it more true, by making `?' and `SPC' self-insert generally.) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 14:40:16 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 18:40:16 +0000 Received: from localhost ([127.0.0.1]:58617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPTL-00043o-Ri for submit@debbugs.gnu.org; Mon, 22 Mar 2021 14:40:16 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:37304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOPTJ-00043X-LA for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 14:40:14 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIO9b2158395; Mon, 22 Mar 2021 18:40:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=; b=bCI5uiGtkQ6gfU86SsWlHaO5mAjVWA6w4iR5Mg7AfSpcW0nUduVg+ljCYJE+nlk4b8S5 S+oppXhaaMecaRAhMafAjPTEi9kGA9ktBTA6hhSPqzVZgJv5W4YQ0TAkLVcYNJ4loGow R4qHqDpWzGLuqyHqJadbs0UtvEya37EKYa1rbh2CnMOhByPJSbdRo2QfmnG2DkuWQ7i6 KS/fxs0SONzRBFG+SYJkOgHu48SUPmJNFd9A/4H/R2f6fclTVMOqXaITJgAXkVsI5uby gSnCSCJ+dH4ZgGA9hv/3oCUCtZzCBvy98VWlgOX1uqEOu7fXvc5ZFjOsVyuvDpo2E8wa pg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 37d9pmveg9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 18:40:07 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MIQZJh088865; Mon, 22 Mar 2021 18:40:06 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106]) by aserp3020.oracle.com with ESMTP id 37dtxx9wgy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 18:40:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MH+HcChyuim/8CW1jBr7PILz9XDTRZXEXxCjagzyXyYUd7RVo5B1prmZMJ/Nz0UdemxThj7RVAveYQPLpt0CZjD5sn8arsnZCaFdooF4khJ1nTRPv9TxugwVPlpeTULHxIIEAi2X7cDThZqKYT1kaHY6/JrxL6whjZcPfRv4ViqfOrS98tI1cRPD2Yzb9BtGlOCxuOTIyKifi9ZOk5+vRSLMRJl80ydw6BkMNd0wRw8ngFT514o4j+LvD4ZPbxAdNkxa3DwgBdLDt8RikAObfXOdF8+Ityt+bCtJ18TskG1SWtMh+DkW6KfEM74MNuiGsz71HOkFF27QVHFtqYbFyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=; b=fYFxur9vUl5nW2hy0QNz7542fEL3fJLDfO/sJTwWLwSZoWAJF1E2n7Ljer3i4/mLFT1Ybw7Ek0nzvu/IY1s8Ipyrs0A+iwsyB1xmvdLGWyWmjzO2IX0yjDyYTJjnW/c8IrrJ5uLiDxnoAADK8R1RpKGIdcCqNooB78G88oRlo2+wTvOA29IIwpXU2r1XFrF59BzbzvEycll8Y+Rwj3n0hkI6pAPYIm/4GUALfD3lznaPdOHIZ5Mj8X9hx/qYP7/C83oah3bAJlLMoAaDvxX9Lxi9Jwm/s8+DfffvCQwQz4bdjPMcWhnrm9bLRcnXJVNtEAsmbs3MM71Ln6bBBiu1ww== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vPHy1b6kfxIGbQVR3y8tbI7K9Ng4NuQngFBzs7Cwg7w=; b=fGtEPAaY4LJjQrXASgN10WSHQ8tl1BxSKguOhHgu4dwEmGu49DJSEwv5KwUGMRSYkAUz1qDgt6lAquy63bGcgib5qPYysNVX0H7I+zN5QSL2mMVjox1AqYREsumEnaCYIkeCPBnm0pTsuK1DyhJ7WJ/EfRAlJI9ZLhkLD/bTHLs= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4411.namprd10.prod.outlook.com (2603:10b6:806:116::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 18:40:05 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 18:40:05 +0000 From: Drew Adams To: Stefan Monnier , Alan Mackenzie Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH0bjCkTZGRWC/E2X/mGKfPiRn6qQU15Q Date: Mon, 22 Mar 2021 18:40:05 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iro.umontreal.ca; dkim=none (message not signed) header.d=none;iro.umontreal.ca; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c223c38a-95b8-42b1-4acc-08d8ed61e919 x-ms-traffictypediagnostic: SA2PR10MB4411: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bhMhSDgVHiBKP9GUPjybwQyDyiCWhSn/3T0RNatI5eZiiYwjmNuRr1oNrMhiLwDM5pV9r7HouxZzp9QZavfL0jefGfbnvulLVpB2VOWJGKMji/O53V4GzKPk6uJZL5D/4q83rUbgcAfeMyGDGk2ZWzJSXCFbNvZClDqET59RYhTue2hEUl0LSEETZJvf0I9fhfaXeLUwhEh0VUoOCpPlPzJtGURbyvw1SojsELrhog+xIvj4esB9oIzXBz1ots5pG5wf1tJf7/zCCKTcqw++QANgpLQ+N9z24TlOh2b5ptE5BQcuNYyaQajNgdoQSzw03tm/xvVHxI1VR5n85H3ui9y6UiLZssw3Gd1XXxH5y6Akr4760W5n3WS6Kc4x/WAihqEMHziDbbDJzJCHM5Q9lbyQxdUXvyq1iHfW8qkDtCCO3wBvc0vkNjz8o7ksLyhVVFZgMOhHkdPSJ/YtE5wbHMW2Oe8JvOep4vX6zVVfHPUr5JPyfdgFqzcTUW0+E0YE+R28zw4sz1I7uM17PFT+j2AeFsEq95Ag+0N7TIChPb4R77Vwo6/0/Dodkht47C9ojnOKFiWh9jvSWEwpMDmP+QORIbT8H0AbVb8Q40nrImUzW4tKdb4VB5dtD4/AmbL8eQHFMlZ2hal2o4XQdnHx1FaWhPULr8n1HvdwP+4buE4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(136003)(376002)(39860400002)(8936002)(66446008)(33656002)(66946007)(52536014)(2906002)(66556008)(66476007)(64756008)(4326008)(7696005)(38100700001)(86362001)(83380400001)(44832011)(71200400001)(6506007)(478600001)(76116006)(186003)(316002)(55016002)(9686003)(26005)(5660300002)(296002)(54906003)(110136005)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WQbVlXAyDItOrNMOP1E2jTD9hR4TDg5M25UXfez4GZlKrIe7esjUH/CvLRZP?= =?us-ascii?Q?q2F6Ixf3iFVutBYVd9+xSC5ZyIZtTnB+PrlC+KcRBfcXCA1KictxAkHkKSD5?= =?us-ascii?Q?/i2rWWSQ199eRRKUrJu9HQ7M8y5JfgcSQs1tcdcvBZRnTSfrErMi/q2bUGCC?= =?us-ascii?Q?cp/L253yuu2cwedRx9WQHy9q7+ocBxEg4Kg6YFWLT74KKiae4i8P5Ej+Pw3R?= =?us-ascii?Q?BUUmwcdHhT19XB/IDO7QQ2o4cjHLvmPYpQmtigbXTWVCaYYG0uLwvF3iGeHi?= =?us-ascii?Q?2ZwiOK9uvFpV6AhXsY0BGQ0YifJcSLpBKiTpcsu6Mh1AkGwtm0NdRR2xGuee?= =?us-ascii?Q?modfUzJU1iLcHzOFmIzwTIUSYAlPqEbeprlv8a8s2XemyOYT0W1FVN1YNWtp?= =?us-ascii?Q?j1tjV9tCQKwFKshMEsTWFDWhROtDuY6fTOmKH8bdFolzDVTPuoo99kTugZEw?= =?us-ascii?Q?wLYsfb3MgucH/YiqkJeN/ErEI4Q5pZ9HUCNYdgqBxo0KFXEzY3MuJcFp4v3h?= =?us-ascii?Q?X+j43bdt7CsLnUXiU12T7mdTtF92en4s7CUUIbk2aLylKkKXX8a/wUIBmPpI?= =?us-ascii?Q?xBMky74jGWKJ7F8+l8wnJzTTY1iQUHJm/QLomKaIoZni14nTgNm3hcGzLseb?= =?us-ascii?Q?OwmRW3P5zGM0cv3yd7cqvQJHOMLu9hqD/RCD/b5x/UX37QnnA2Clv5hXl71K?= =?us-ascii?Q?ZaAWrDnacYV5cfAW4UthwbltQspUT2QZWtqU+JcIcbVGGKdg8SPDorWDLTEw?= =?us-ascii?Q?TMPzHrfYdDOwfvxCC+rYCPx0EWkJ2LcARstPBuuPtxBH6C4cG8Sz7tCzlqj1?= =?us-ascii?Q?73hXibfUof1RsjZ8Lj1pSKpbivvPpLjxlOqk+MJPb+6WIFiUNN/1rcwY9qd1?= =?us-ascii?Q?ArNJN8z63jd57g7ArPF8gB8oFEms6xvuRUDVankiIHCfhtjgPC7Z0y+yx/4p?= =?us-ascii?Q?AyVTiClhI520qbrw5PWSl45URuJc95iIlwP9iBfWCgeeavsXWDJ9bRp0pZ9D?= =?us-ascii?Q?xTUbBzZ5bW8yVqf2HH/Ja+AMYTl5S1Sev0CQBBUHkPov/45Ns5KO7v1qCz/V?= =?us-ascii?Q?TTOg2uByjBb7NOCauwJzmhX1hLltEa5T9m4RvYRzNMk8cXaMwLBdpUxPsELa?= =?us-ascii?Q?rPbANW3Ef1c6XhrNFFSSBYrgbwuVy0KzxsRT4xhcjLTINAq/TPU410niRiGP?= =?us-ascii?Q?BaMBLvj4seOMzVR56ztU1MdULsjeK0LqQJTpkkYS9ngUIz/jFKkSMFnvNso2?= =?us-ascii?Q?cRjItvSke10yq+V3iPuDRQ8PY6htCF52kbVJcKpL8KLqimiQqir6i0SOPT4E?= =?us-ascii?Q?gJmgBE++OfDDLQTSCbQzu2+I?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c223c38a-95b8-42b1-4acc-08d8ed61e919 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 18:40:05.0727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hTm78XV7GlGc/+A5Pk88C+rmlppxvHiMAzDaB5ssjSWgwo9J4xlwZZNfB0ZFFhgcUBGNKu1UTmD32B0dKQ/H1g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4411 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220134 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 adultscore=0 clxscore=1011 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220134 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang 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 (---) > I'm in favor of introducing a `minibuffer-mode`. Why? > Part of the question is also when and how that mode is activated (since > activating such a mode has the effect of deleting the local variables). > I think we should call `minibuffer-mode` every time we (re)activate > a minibuffer. Why? > The way I see it, `eval-expression` would want to use a new major mode > that derives from `minibuffer-mode`. Why change the major mode? What's involved, besides keymaps? Does parenthesis pairing and such require a major-mode change? > And more generally > `read-from-minibuffer` should accept an argument that says which major > mode to use (I think it'd make sense to re-use the `keymap` argument > for that: if that argument is `functionp`, then treat it as a major > mode, if it's `keymapp` then use it as the keymap). Why? What's the use case for changing major modes? > It would also provide a cleaner way to do what we currently do via the > `minibuffer-with-setup-hook` hack. Really? Everything that someone might do on that hook you would have passed as a function arg? Why would you find that cleaner? > >> It seems to me the minibuffer is always inactive? I tried M-x, > >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1. Is this > >> a mistake and the offending commit was trying to fix this > >> inconsistency? > > Very much so! >=20 > BTW: thank you for that. AFAICT, the only "offense" was committed by the misleading mode name. I don't see why two (or more...) major modes are needed. > > So, a quick summary: (i) the change in the minibuffer's major mode to > > fundamental-mode was intended; (ii) there may be some problems in some > > packages because of this; >=20 > The minibuffer used to be "always" in fundamental mode in Emacs<24 > (since there was no `minibuffer-inactive-mode` back then), so I'm not > too worried. Right. There was nothing missing before `minibuffer-inactive-mode' was added, except possibly the corner case you mentioned for a standalone minibuffer frame. (And I use such a frame, and I've never felt the need to use it in an "inactive" active way.) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 15:30:58 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:30:58 +0000 Received: from localhost ([127.0.0.1]:58711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQGQ-0007T3-3y for submit@debbugs.gnu.org; Mon, 22 Mar 2021 15:30:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQGO-0007Sq-4x for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 15:30:56 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7B36144031A; Mon, 22 Mar 2021 15:30:50 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 06E3844031E; Mon, 22 Mar 2021 15:30:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616441449; bh=N8pAlPxTZpmus+ta6icGOIE1KxXwl8dV6fX8W0lWTw0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=PR47cJE2RYqBuNCzkum8gcxEFrz8BRr1pWTzgCRq4rHDsvimd+kchN7uNmPoyCLF9 T0FMgnIIK6FvwEzlstvsj4bXaJlbo1VoaVE/qyw5nUbRQ0Ey6vCE77/ziE4kX5mI+6 EiwzevHHW2ytZto2QczKpPwAeURX7/kkh5cLQgA2tANko0pkYvD8mKHRTDcXQHopZu ABYk3bw2xbmk8b79KpSiKZqcN4wJK3n10Kdh9FZMNC4YFpUXsO7Pee6ggHaOsV1qyZ cUmeC4WrdG8fwIDA8I49FxPoTLXH0HojM/V7WCLBcMItZOmpYj4EH6uJq+uJ9S9hhm A+cghhP8FRvsQ== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5865C1202A4; Mon, 22 Mar 2021 15:30:48 -0400 (EDT) From: Stefan Monnier To: Drew Adams Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Mon, 22 Mar 2021 15:30:47 -0400 In-Reply-To: (Drew Adams's message of "Mon, 22 Mar 2021 18:40:05 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.103 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Sheng Yang 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 (---) >> I'm in favor of introducing a `minibuffer-mode`. > Why? Because that's already what "fundamental-mode + minibuffer-local-map" is, tho without the benefit of all the associated conventions of a major mode (e.g. C-h m to name just one). >> Part of the question is also when and how that mode is activated (since >> activating such a mode has the effect of deleting the local variables). >> I think we should call `minibuffer-mode` every time we (re)activate >> a minibuffer. > Why? So a minibuffer isn't affected by what happened in its previous invocation. >> The way I see it, `eval-expression` would want to use a new major mode >> that derives from `minibuffer-mode`. > Why change the major mode? Why not. That's already what `eval-expression` does, except it does it piecemeal instead of via the well known major-mode concept. > What's involved, besides keymaps? In the case of `eval-expression, potentially anything that applies to a normal buffer seems to be applicable, e.g. indentation, show-paren-mode, eldoc, font-lock, flymake, company-mode, you name it... >> It would also provide a cleaner way to do what we currently do via the >> `minibuffer-with-setup-hook` hack. > Really? Everything that someone might do on that > hook you would have passed as a function arg? I don't think we could replace all uses of `minibuffer-with-setup-hook` with that, no, at least not without additional changes (since my suggestion only covers code which currently directly uses `read-from-minibuffer`, so we'd at least have to change `completing-read` so it too can take a major-mode as argument). > Why would you find that cleaner? If you don't know, it's because you haven't looked at the implementation of `minibuffer-with-setup-hook`, which is fundamentally inherently brittle (tho it's sufficiently tuned that it's normally never a problem in practice, of course). > Right. There was nothing missing before `minibuffer-inactive-mode' > was added, except possibly the corner case you mentioned for > a standalone minibuffer frame. (And I use such a frame, and I've > never felt the need to use it in an "inactive" active way.) Nobody forces you to use it. It should be harmless. Have you suffered from the addition of `minibuffer-inactive-mode`? I can't remember seeing many bug reports about it (although I was worried when I added it). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 15:42:19 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:42:19 +0000 Received: from localhost ([127.0.0.1]:58723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQRO-0007jV-VB for submit@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:19 -0400 Received: from colin.muc.de ([193.149.48.1]:28519 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOQRN-0007jC-OO for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:18 -0400 Received: (qmail 74161 invoked by uid 3782); 22 Mar 2021 19:42:10 -0000 Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Mar 2021 20:42:10 +0100 Received: (qmail 8616 invoked by uid 1000); 22 Mar 2021 19:42:10 -0000 Date: Mon, 22 Mar 2021 19:42:10 +0000 To: Stefan Monnier Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> 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: 47150 Cc: 47150@debbugs.gnu.org, Sheng Yang 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, Stefan. On Mon, Mar 22, 2021 at 14:08:46 -0400, Stefan Monnier wrote: > [ Hi, perpetrator of `minibuffer-inactive-mode` speaking. ] :-) > > minibuffer-inactive-mode: the critical thing here is "inactive", which > > means "doing nothing", or "not in use", or even "sleeping". The > > opposite word is "active". From its name, this major mode was never > > intended for use in active minibuffers, > That's right. > > but somehow nobody noticed that the buffer never got shifted out of > > minibuffer-inactive-mode when it came to be used again. > I did notice, but it didn't seem to cause any harm and I didn't want to > get into the discussion in which we are now, so I left things as > they stood. Umm. Maybe I should apologise, then. ;-) > > I've been fixing things in minibuf.c recently, and when I discovered > > this anomaly, I fixed it, so that an active minibuffer now runs in > > fundamental-mode, as originally intended. I did wonder why there was no > > "minibuffer-mode". But it was clear from the code that whoever wrote it > > intended minibuffers to use fundamental-mode whilst active. > I'm in favor of introducing a `minibuffer-mode`. Thanks. > Part of the question is also when and how that mode is activated (since > activating such a mode has the effect of deleting the local variables). > I think we should call `minibuffer-mode` every time we (re)activate > a minibuffer. At the moment, fundamental-mode is activated from read_minibuf after " *Minibuf-n*" has been selected, but before minibuffer-setup-hook is called (which is as it should be). It would be easy to call minibuffer-mode instead. So we are in agreement, here. > >> For my case, I want automatic paren pairing and editing in > >> eval-expression. > > That does indeed suggest we really want a minibuffer-mode, rather than > > just fundamental-mode. But surely, the parenthesis pairing will be > > dependant on the sort of text you're typing into the minibuffer, so it > > can't really be connected with, say, minibuffer-mode. > The way I see it, `eval-expression` would want to use a new major mode > that derives from `minibuffer-mode`. And more generally > `read-from-minibuffer` should accept an argument that says which major > mode to use (I think it'd make sense to re-use the `keymap` argument > for that: if that argument is `functionp`, then treat it as a major > mode, if it's `keymapp` then use it as the keymap). > It would also provide a cleaner way to do what we currently do via the > `minibuffer-with-setup-hook` hack. Umm, why? Do we really need all this extra complexity? Having just spent an extended period of time struggling with minibuf.c, I'd be happier not to make it even more complicated. > >> Plus we also need a keymap for it, which is > >> minibuffer-inactive-mode-map. > > No. That keymap is very low functionality, and almost useless, as it's > > intended to be. > Indeed, the purpose of that keymap is that you can press `f` (for > example) into a minibuffer-only frame to open a file, but only when > there's no active minibuffer in that minibuffer-only frame. > >> It seems to me the minibuffer is always inactive? I tried M-x, > >> M-!, M-:, all reports minibuffer-inactive-mode in Emacs 27.1. Is this > >> a mistake and the offending commit was trying to fix this > >> inconsistency? > > Very much so! > BTW: thank you for that. A pleasure! > > So, a quick summary: (i) the change in the minibuffer's major mode to > > fundamental-mode was intended; (ii) there may be some problems in some > > packages because of this; > The minibuffer used to be "always" in fundamental mode in Emacs<24 > (since there was no `minibuffer-inactive-mode` back then), so I'm not > too worried. As you agreed earlier, I think we should put minibuffer-mode in place for those minor modes which maintain lists of valid (for them) major modes, and suchlike. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 15:42:32 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 19:42:32 +0000 Received: from localhost ([127.0.0.1]:58727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQRc-0007jw-9d for submit@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:32 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:42398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQRa-0007jh-8w for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 15:42:30 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MJe15l079232; Mon, 22 Mar 2021 19:42:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=; b=dSlPaUAhDtHJWMeDqp18JnIrRgBJSAediGn21ggd70QqO7T/OxVWR10HlahXtMGmQwd5 8/4tRI7S5lcfCkG7TTZVhsoo+d/RSM7ChQR0SV1nVGplRO1uBuX/c5ceBewRar9A5gSi puY/bh1phz9QKWlGsLRPKXgnLRU/sDXqK/e5WjL1/bYnMEy2MLm56lJU5z7Czhbsj8IE 16WiaEw1INRo+FcdhUN8YWpS24NQGiDAjMABeZXrZiKN7eVHLqEqDS6eKVJjgNQWZ8uv 6Mz7L+hQo0LSxcNGtI61KRgHMMYKuXxDC2v4IGfeWh+Ro6UMB/egxpL+CSqmP7pKc1UJ xg== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 37d9pmvm4q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 19:42:24 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MJeboe193415; Mon, 22 Mar 2021 19:42:23 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by userp3030.oracle.com with ESMTP id 37dtywgpb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 19:42:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqCTV1sDiNr+SlSN2d726JfjBOal2bqjLIqdauuC4GgTkwWATnoAC+0n0tsSvAhaV6u0RMtF2vwfOGsSI0nFUDe8bvowdQJIf8ylX3Eq1jn0s/0E+Rswzx3LBObtzyf2zumnc/Bo050mm9rqjhGu9YvqSQ+Hlgbtt03ypT3cv7WyBsbHUTSMgF1246bF9Cc8VxFXiscp6TcbhtmPYvHiSz17//49n1dOM4277MZIFyXViHfx30+R3DKKrv0IshyyrPs7Bl4h7swi267C3AjxBGtFP6UsSi2+tkgnNXy+cxDfTeWCc3hJhz6KxfVdya9hdzeLCkqjKw6VcDj/OIDLRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=; b=d3+0IzB7y5/PNl7ANw3IN7+fHgTKJR3j2htzWhD/7FR5dWiPpU8KBsgb+ayP+oP5DXNfTE5hC+1eHFaiMH5I1wuBIB0qLvYOiB7wzIx1zTC6JehTWxaEBVtoR9eQ5LK/etz7MGVij9KY25lZ7quOGeuXV11j3XlQeF9DG4pbSt/qIlaQthx3yGnw3SQNDxYs1gaArShByk20+0y8ZW2ohtUKX1swJ/65NkhPaS7Q+gFsY9GgQ7tq3NUuuh+ojOcaWwBCywtBQlvGK3s/IbBstlV/FVwFYo0dW5cIGUPG4FvkZu4gTMYGIAIxyrgCHwXUk+nwWin6i7DuOSfMqZxVhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ICL9shq9Q7wS86XuUHeb3KiaCytyuQQUWxu8naKY2uc=; b=obPQ57k8C4clat2V1DoxBufVTXqZXIPjhWIETOx9fi3nnzg48gw3Q7jMRJIM5pQDxUrWhyl8IjKCEFOMkP6Tu++S8mLwKWamXsLBOvJAQjgRjPC1XxoB5USlIklI8QDD2L7CDEkpTHrSFg1Ac0tW4vYZIzmqfUClkTJpjbMIAUU= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4634.namprd10.prod.outlook.com (2603:10b6:806:114::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 19:42:22 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 19:42:22 +0000 From: Drew Adams To: Stefan Monnier Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH1HkSy92TZ2uh02eoEgOCtiSq6qQZhQQ Date: Mon, 22 Mar 2021 19:42:21 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iro.umontreal.ca; dkim=none (message not signed) header.d=none;iro.umontreal.ca; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3fd825fd-c94c-40eb-99ab-08d8ed6a9c79 x-ms-traffictypediagnostic: SA2PR10MB4634: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LJpcGpoMXuufd4sg8M3+F8smNpHa6BSKq6c2r8DXSj32nw5qswD1ihpZl4XBHNMTd9tu20goAB9BqiXA0kx5tK9FQBdvIfcZmbl6OWu7d6bqobIbjYPDEb2vGY/JjjnXErIGK+2uqor/WWgTyANJUFogKcRCSamw1DLV3RZUaQjo4oBBZwZPoq9c2/w1n5I/0LHr1izsiLpARJLaqpIcOR8z63+b/pdCg9uYfUHuAz7nnnemFuicewxCU/dAdyM3i716C+DLN9+ZIqHfMHeSORb9QOfdxn4bOJbrtMcdt7jQBQtU6PcW0Haa/QZiTn/QZrf+vMzzFsNFCWl8cocP9m14N+/b+vgCwp6yFyViPoLJZ5CiMn29FOI7n1G/xkjkzCgaxRogVHySxtMBkWPG1fstcmSM5pQR7KqTDPePXDw5gIEYfAGwgOq7y+nw/M4qcJ2Oxd5gMb0Dm02WW3l43RZV84wrUJcqlc1yOPBIQew93glZxjepvFHp7RTv+kRzsN15+ktXylW7XKhVWXuolnF38071C87RRX8bSzc6j677NoF91UcFwybFrkto/0UlZ3XPjCgXV4TTV6r79nO5dNnekk2h+sj4MjV75nOqAfNH628Yi+/Ud3JuBdgwgpksMoCdEjWMjiI/oFV1vP1qqeFGcamh1IJvaoquVg9y+YY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(346002)(376002)(136003)(396003)(6916009)(54906003)(66946007)(5660300002)(8936002)(66556008)(6506007)(66476007)(26005)(186003)(7696005)(66446008)(83380400001)(76116006)(478600001)(296002)(44832011)(52536014)(316002)(64756008)(33656002)(4326008)(9686003)(38100700001)(71200400001)(55016002)(2906002)(86362001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9DIzWyOjiojOIO4eliklcMAnk/oax6Nc5W6evxGU2NlxrLk+34uXUeBl5Uzm?= =?us-ascii?Q?a5/zbfvWRif/wZ2a+27UwJ8hqJpfdnV2GSgKOCaGCd1MST0ymD9mLlikJrM5?= =?us-ascii?Q?p/2/w4hRAx1s2Q7Fk/OTE2fJ2Q2lRhy234kyniMaRzcl3rzJEz+YzS7LYM97?= =?us-ascii?Q?ikMY6talufOQea6opJHzqlEK/nhLBwxejzPx6EvEGE43Jq3BNO9Lgld6a6ZN?= =?us-ascii?Q?wZu8jNSRWU7Djk2w/gAs1LHHy4kuo7SzHbzm6L2MTm1n49UwEuKKZP+0OTaL?= =?us-ascii?Q?hxEEgkJGfa2Zci1adv70XoMnTxEQZCeFC8wfCPtxBo9TZf/AEWqAes4DoVeu?= =?us-ascii?Q?cw3VmXiRUs+2u/oOTFqiN5PR+zvQ1avBpzg7HLAt5W58sbJ19Jikhcv+8rcS?= =?us-ascii?Q?wzZ1GOlPcZhjfAu55uYuW9RXwhaIcSi3c0SPF/D/PGluj5I7TxoJURdShi8A?= =?us-ascii?Q?uQ9e7+QuhykjtOTeoY1OST/5Dd6MSWJT1BqqMRt17ef+k8uzmyotghNgflM+?= =?us-ascii?Q?dAuD/eri/drMCYyZVdVeg2rFx+KqzFrYYRSj5MndyHqIB7ZKscFJGY/FPcXk?= =?us-ascii?Q?HW9TrzTxxhxdGvKt/Zl3rIZqUwW/muHugmPe45elhAUrRZ4TdU4JqIQnP5f8?= =?us-ascii?Q?zh0SEsM5JjROKazE/A8ORSpDK4wvpXiChAkwRfxiDQ31Zxu5NhIS+qjcmTVS?= =?us-ascii?Q?0ORedSYNN3bDqlONAzoMh+VlYlbw3RZ+AE0XWIZaY3NJrOXcm83wmqyq9grc?= =?us-ascii?Q?Ft1SBYLTs8X8dRbncTEkWO707fm+JblAhw3Vv07MiJ0RiNCgcd3MOgmWygzI?= =?us-ascii?Q?PhpvH+7O4KI5ByPkrj1AI7/NPUVPQfwU5k/w2NKKbSOUw9ZIm8XVdSNKqoe2?= =?us-ascii?Q?6f3bbyktHIFt/hNuSsgIzg5itxAILllUWuHzvzIcaLV+z+A8BfOst3M5ItPk?= =?us-ascii?Q?AXfhn1U2Tse0F533/kiOrorsCNLc7qqDiE/fRwSb5RiaBx9qPaMmgDZgg//+?= =?us-ascii?Q?SqR87+2yWPnUQpSnRR5arDSBjmFOXlelDg2ldVK4MWrECX1dOa8JocpVlQwq?= =?us-ascii?Q?FjQwXP7d48VY6nWX3+CGZMx/mki4mwF/Vm++oax1U1DKDzt0YXnY8wfgpNxx?= =?us-ascii?Q?KvStGO2iy+VuMkQXqYA4GopSq2eQrwX5DRtGYdcqL3GJEY6I7dr9DjI9dBTH?= =?us-ascii?Q?MgV7eHRemOymMSWTnsfJoR01lEq0UYlR9TSdKH1AUjkZwku207e22dF8PrHX?= =?us-ascii?Q?38mpqmdZP/7GchDFWXK4oA9wr+DciHmWTTPvxCEZ+y2g4E3oBbqxnRAdtY2G?= =?us-ascii?Q?sjYiVRmr/K4jNrIwntlSC4Xh?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fd825fd-c94c-40eb-99ab-08d8ed6a9c79 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 19:42:21.9829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zWyQLsIAfgw1+YjvGHLmmLCWyuoaRwDH3Xj7kbC6ZAWgb7LzdJpCHjKAsBSAtOkOBr32crSy3QdcYJDlCcDUSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4634 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220144 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220144 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Sheng Yang 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 (---) > >> I'm in favor of introducing a `minibuffer-mode`. > > Why? >=20 > Because that's already what "fundamental-mode + minibuffer-local-map" > is, tho without the benefit of all the associated conventions of a major > mode (e.g. C-h m to name just one). >=20 > >> Part of the question is also when and how that mode is activated (sinc= e > >> activating such a mode has the effect of deleting the local variables)= . > >> I think we should call `minibuffer-mode` every time we (re)activate > >> a minibuffer. > > Why? >=20 > So a minibuffer isn't affected by what happened in its previous invocatio= n. Can you give a quick example? I don't think I've ever noticed a minibuffer affected by what happened in a previous invocation. > >> The way I see it, `eval-expression` would want to use a new major mode > >> that derives from `minibuffer-mode`. > > Why change the major mode? >=20 > Why not. That's already what `eval-expression` does, except it does it > piecemeal instead of via the well known major-mode concept. >=20 > > What's involved, besides keymaps? >=20 > In the case of `eval-expression, potentially anything that applies to > a normal buffer seems to be applicable, e.g. indentation, > show-paren-mode, eldoc, font-lock, flymake, company-mode, you name it... Hm. Be careful what you wish for. > >> It would also provide a cleaner way to do what we currently do via the > >> `minibuffer-with-setup-hook` hack. > > Really? Everything that someone might do on that > > hook you would have passed as a function arg? >=20 > I don't think we could replace all uses of `minibuffer-with-setup-hook` > with that, no, at least not without additional changes (since my > suggestion only covers code which currently directly uses > `read-from-minibuffer`, so we'd at least have to change > `completing-read` so it too can take a major-mode as argument). Ugh. > > Why would you find that cleaner? >=20 > If you don't know, it's because you haven't looked at the implementation > of `minibuffer-with-setup-hook`, which is fundamentally inherently > brittle (tho it's sufficiently tuned that it's normally never a problem > in practice, of course). I thought you were saying it would be cleaner for _users_. My question was/is how it would be cleaner for users. > > Right. There was nothing missing before `minibuffer-inactive-mode' > > was added, except possibly the corner case you mentioned for > > a standalone minibuffer frame. (And I use such a frame, and I've > > never felt the need to use it in an "inactive" active way.) >=20 > Nobody forces you to use it. It should be harmless. > Have you suffered from the addition of `minibuffer-inactive-mode`? > I can't remember seeing many bug reports about it (although I was > worried when I added it). Right. That was my expectation too - harmless. (Though your comment above, about "anything that applies to a normal buffer makes me just a tiny bit nervous now.) And no, I've never suffered from `*-inactive-mode'. I've never found a use for it either. Can I ask what's wrong with what I suggested: One mode, not two; just change the name and provide a helpful doc-string that covers both active and inactive? From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 16:03:56 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 20:03:56 +0000 Received: from localhost ([127.0.0.1]:58795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQmK-0008JV-0H for submit@debbugs.gnu.org; Mon, 22 Mar 2021 16:03:56 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQmI-0008JH-LJ for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 16:03:55 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0BED310022E; Mon, 22 Mar 2021 16:03:49 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB583100091; Mon, 22 Mar 2021 16:03:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616443427; bh=JRZjUQjhfy6RE2JJQ5B6BnjbWzMOH0cZVtEtI5RsySE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GzP5cZ+1A7FCd51qh8cotjwjNU5reLUnHZI3RicunddW+24JH3qOlIJ1Nl07YMWFx XBfjEXfHrGVCJ/Ms9XAYzudM6+LkAIlSj1X7Wr8b3AJOHhscjlXRBUGZmyEbpe2bWs IM5tO+u14f4zlv0xuOM3i4R+uE9W8AwjH/AAORRgaZHwlZBR+RGiOiJnrH+gruZYdR ZTzbuhiYx5+KI/T/l47s5+5PPSeCGZw3mdCylomUTcfLb4dZcTRFfB5O+Of5TZNh8E cVi2uZwtjlweO2rgDSy27EknaaTg4TEhhogz6BogRvqXDTy8jIV14yKwKZzW8xiFQH 6WsZ4Crapn5Ig== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8AA8412040D; Mon, 22 Mar 2021 16:03:47 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Mon, 22 Mar 2021 16:03:46 -0400 In-Reply-To: (Alan Mackenzie's message of "Mon, 22 Mar 2021 19:42:10 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.099 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: 47150@debbugs.gnu.org, Sheng Yang 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 (---) >> The minibuffer used to be "always" in fundamental mode in Emacs<24 >> (since there was no `minibuffer-inactive-mode` back then), so I'm not >> too worried. > As you agreed earlier, I think we should put minibuffer-mode in place > for those minor modes which maintain lists of valid (for them) major > modes, and suchlike. Yes, I indeed agree. In the above I was just pointing out that changing the name of the major-mode used in the minibuffer shouldn't be a significant source of problems, since it has already changed in Emacs-24 (and that didn't elicit much reaction, if any). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 16:11:29 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 20:11:29 +0000 Received: from localhost ([127.0.0.1]:58911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQtd-00009l-1b for submit@debbugs.gnu.org; Mon, 22 Mar 2021 16:11:29 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42559) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOQtb-00009P-Ns for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 16:11:28 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 568F3100236; Mon, 22 Mar 2021 16:11:22 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 88DEF100225; Mon, 22 Mar 2021 16:11:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1616443880; bh=wRgtCkFQYVIrG5DnU272X4rNRVtkAMr4TA5SJZJ2hTI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=TuQlTzR0WFB1cabZd8uBcs62j/0OcSkI34lLc/vIjR00taoHQaR6mlVQfvFtyy0eM McabnFgYh+Ky2ppdvz2OiOl5YkEauYNcMb5ZgodkL0dqlD5QAXDj7Kt8fTqSfjCIuT a1QdTgqWYcSedTJ1XEuYET3SvhXaANcIPgMcd54DROTbhB0YeL9VNU9mHgn7WVk75o gaLSD82fBNESGUHiT0A3QUfxNU5CtN5Gk/9mqE8ilxcOlyF6I1L33lRRHGfE6Ma+c8 /gpByrbZEFdo/1dt5G0GTXsH9PIIwKII+CqEe56N+6usD8ebXqpphDb2Pe+hzL4bt/ CPUmO5+Fru6Lg== Received: from alfajor (unknown [216.154.43.249]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3D2A912021E; Mon, 22 Mar 2021 16:11:20 -0400 (EDT) From: Stefan Monnier To: Drew Adams Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Mon, 22 Mar 2021 16:11:19 -0400 In-Reply-To: (Drew Adams's message of "Mon, 22 Mar 2021 19:42:21 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.099 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Sheng Yang 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 (---) >> So a minibuffer isn't affected by what happened in its previous invocation. > Can you give a quick example? I don't think I've > ever noticed a minibuffer affected by what happened > in a previous invocation. Those problems have mostly been fixed indirectly by the introduction of `minibuffer-inactive-mode`, which happened to kill the local variables at the end of an activation. Before that (i.e. in Emacs<24) there were cases where `indent-line-function` was "inherited" from one minibuffer to the next. The remaining problems (that is, until Alan fixed it by re-instating fundamental-mode upon activation of a minibuffer) were those of an active minibuffer inheriting the settings from `minibuffer-inactive-mode`. > I thought you were saying it would be cleaner for _users_. > My question was/is how it would be cleaner for users. I don't think this should affect users either way (except indirectly by the likelihood of lingering corner case bugs). > Can I ask what's wrong with what I suggested: One mode, not two; just > change the name and provide a helpful doc-string that covers both > active and inactive? What's the benefit? Have you tried to implement it? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 17:37:03 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 21:37:03 +0000 Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOSER-0004KE-EK for submit@debbugs.gnu.org; Mon, 22 Mar 2021 17:37:03 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:38088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOSEQ-0004Jk-1c for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 17:37:02 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MLPjFR109454; Mon, 22 Mar 2021 21:36:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=; b=Fgt24YrX2dJx5Ojbd9NsF7Wo6ktJZNeyIVaTNYR7dTIMnvLhKG72ppec2XCiT5jD0nV7 Etfgf6To4nO0T5doubVdxEBjSh89+8gKq0isekaE1ISFdb0M/xdNKCeXOpwnImXex04l ekOsLT1EOtJgQ370Ocqu5Rx0V8mGCPYSNN/0/64YloSDodnH3CVPoTo9QjZH1UKtMZEN jCPBpMa3njXr6i74n8Nstnr1jcMvvzke90vE9ZlUagNtT/JVZdvkmy/qYpNDR622aP3X Zt3RpEVZ6axhpT4f+jqrwLAeqJhrk/o0LpeBkIeRZKpNqUZdcxmWy33cqV7H62938zAW hw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 37d8fr4xnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 21:36:55 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MLKrsW127589; Mon, 22 Mar 2021 21:36:55 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177]) by userp3030.oracle.com with ESMTP id 37dtywkyqg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 21:36:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=buiuc5ichw9iqcOiVHe1Sz08W+xAQ/r8jI8Kdmzceq56tR8zcmZ8gSgilXhLIzh2xsYBUR96aZutoddvZmmdxcdCv+afSj+bVY0QWvEG+JaOIyE+ybiu52jHSVLyOffVILEC9/mRGhaqAsC1Uyk+JJ4zngEZ7tNJ3dzrwsJl1IR1gwZFRdpX7v1dFSPQWfZJyf3updN9HR7cKlaX47QM8HXGJdjuceO/QJtv2tRx3KQfONhiRdPmImIjU62jnxk8cqgzO3J6oIbI+jRL7uFEG8NDYr5aaS8PujqWdOZ3GgNQr0kqhH69ruxCj7EnFLdGrFC8G8ulLGYBjlN3JP9jIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=; b=gv9elsmbMvhwLSIMYz7RL0hdc5D5C0DudHCB5Ngoi7ioHNTRLaEN/4K7b5GoDXVK24nr8+6LIJhyDnEy79mXGr6iG4sSkmS1yz1G0RFySOKfDhXD0Y0Xa5YQRBBfd2n+kmjH+T34EZikFjAG55HDx5AHwJDjIbNaFtlZuqlMsmHRBJ6/9dQNZ4ibRquQJCzT59XAmQFBrkyoLX4chja4sCx1NR5a8ZPyKusxI8ElcinTAGtscygjWbfGd58PCg4OvF7/gbkpBcsNFSAizVspGjxwJ22zGIOYU0Jrpsf5Dlyry2eivDzqkZi4Zkt7tY60A01SV4xFdEUgJsYGZ34OVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n40kbV84LltyLEd7l16+4NBeBkM1AooPY/CXiQSiMJE=; b=Z+XQA8lFCzVi/iH23hkj+DcLsMLQOHVO7xcgKWQdmvNTgAQHrj4qRNQOJXvihiXY6WqxZ1GfrsHgNDHAXIzqMDVnPON7BvkqisqUQo0kkhIUNAroloE2OdxOA36SCgT0cogxDy/I9lHV8U9OLjvTdd6qpNdIoLPhZVgEJJxfmxg= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4780.namprd10.prod.outlook.com (2603:10b6:806:118::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 21:36:53 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 21:36:53 +0000 From: Drew Adams To: Stefan Monnier Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH1eL2/hwyGfNj0aZBjqNTMDLa6qQhpbA Date: Mon, 22 Mar 2021 21:36:53 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iro.umontreal.ca; dkim=none (message not signed) header.d=none;iro.umontreal.ca; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e38bd72-4405-411a-3c0e-08d8ed7a9c55 x-ms-traffictypediagnostic: SA2PR10MB4780: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 58GqkddjWWxCzotU5FxadOp2455anC7CtlxTNV5ZukDRBxX9mGFepFtIpvd1nGzhfn1rrS/X76aqlJcMKPqzYpM3LntAlfGh0tBe6X3bAgPtTLCw2x8fU2kd7l2NoKpszmgzrkd/yrutFr0erUU/TJf3eYC6+GFTv5tE6X+433ZgutVxaj19A6TrVWpi3puosM/EzRkgOZjWA5gEEOd2PSMrYuAyAUfBC3/ZVVQUrkccQljBmb+ovmbOQKsgzowD05ZPcp16KSVDDzq4ke9eGolBAHMpsBboouciXcS10guxhQ7QGyFH/Z2mRGjZS8BYq1Vr00gkcXDMS7Gl7J2zJL1K0RpS3dE4BQPUsSR0UWs9wgfVEAkmu4+2MnGxedbm9YgeYh289mzrVFUqyVCjcEuxjI6RCwAJdtaISS2t5GNry/9wuyLBDaQyKktLBsF0HftNBsQnYao4M8UYfGzBhL93X5MElKrJkByQgD4NTPgxbg5pi4iGa3h7vSnHxleESnBXfxxfiCrteYq4U+bgwIKaKaywvc9+NRfMi+YsyCqlOvYKbm4vFpAW2iv4jv16Bn1wrvlcMvJvTzxXCAlJoUXEcuflZAemcR8A1ohosbFFDHTTpCIQfq1mlMFp1O9mrqrLIrPpnT3wb7keOaV/s7iITShBOWRPLLuQ1/etTVA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(346002)(396003)(366004)(9686003)(71200400001)(55016002)(4326008)(86362001)(8676002)(2906002)(33656002)(38100700001)(76116006)(186003)(54906003)(296002)(6916009)(316002)(26005)(66446008)(8936002)(64756008)(44832011)(478600001)(66556008)(6506007)(66476007)(66946007)(7696005)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?sqHnBn81krT9M1+4A41tB5B+u8dfVhn63UiC2cH+tSMmzLuclv/+uDhVyJMo?= =?us-ascii?Q?KTQaa8KjQgAi+ZcFKCxTa9CeJOTicCJocbrswZewsHGAF8bTFtdfRMwRWYwf?= =?us-ascii?Q?FetFWHLBbVeaNf5MM3w8sU8092osL4uMapCW3pgYo6JbGuaznB/8Gee/bUYR?= =?us-ascii?Q?o9s+rdKQFma/2WlpEUzRZgcZlNyw6/dXtjUuHqwq2Q1Q1rQS90iTHI5pbdzb?= =?us-ascii?Q?Hl3AOlwV0kHGaOuScMEVS9qGL06Ytz4CN10jRUURvfjaSaJXK7UBI/ag5RI/?= =?us-ascii?Q?7QfzRQSDVv4rTbLl2xg13IKMtTEU334i9/UC0CrainwmFHtaMFdPXTW8A9V/?= =?us-ascii?Q?FtgcZ3gB8ExRcSKb44MlvR+eFk4f//fNhpyTZ5QQDpXSUrqJIgZtgqzo/cdt?= =?us-ascii?Q?Dti/UA3uXXLKsyV95JoBcmLbszsHJw1dwjhaZUOoG9KGaRrCmnkRq0+SR2W4?= =?us-ascii?Q?It2TFQQp8/iJ5BmlPZhPeZ6E+3EIT+10yEL6C1wI7J/vgAhycyVjH8BMiA7h?= =?us-ascii?Q?g4cOyNU5T1+dlScPnWpXyuOFRddPDWhYHb1b96j+a/SKm9bZKOMiyQgZxJK9?= =?us-ascii?Q?GlT9CYuqAMh9UADZ3X2TfxBOPXAHxwEsA07DzBFEwfg4PYbXj7S41PdZnASh?= =?us-ascii?Q?aw1LHmdHn4UhfxlmH6+rOF/kJC7ZMfHnIwdsdayR7z14tS+8ZO/rZB1Tg/IX?= =?us-ascii?Q?x3+mVEAlkI+JwQ2OJMy3FJgwvcQggoZFP88Z9r2iPudkLrRCVEWrZnLfkox9?= =?us-ascii?Q?ZSLoY2tiuGybcj24nO7qJkU8k93mgW3VhVpENQc6Gm7XK6xHsFdPIR6HBfg7?= =?us-ascii?Q?w+D1UrQcXkYosWVid33RVxSjiXwSYdaked6u6+8H6zW6WBghmwDgA785JAsy?= =?us-ascii?Q?9P8yPKkGLITdyoCa/KHk0x+I7RAaHSjw2msyTnAjdCQrDVEMW1zSbFgAmBOU?= =?us-ascii?Q?/wWbWly6+TkBiv2VAdFDBAr4RI3C/dBWmlhK81ctF5VVP2pi03vcmjurNIfW?= =?us-ascii?Q?sRryuy5/LixvwHOMJyxuacfFLRoVFdIV6g3nLuSfy2FVk+pOqsZ96cg9NUnm?= =?us-ascii?Q?t7cPA4H4rLQZsUziO7UAL2LTpWPUyEtIX4CZi1jxwWxXED69bkra1qEUOFiT?= =?us-ascii?Q?v0a6MGecl3ndG78zJCEMoQBeOXH3azQ145tOwpVy6s6Y9ygVmWf76VHjvnT6?= =?us-ascii?Q?Rji+9w2hniud+NbABdZWccWwNGBAdFXOW0M4zfP8w4sPez3TyGzpCASMSVXt?= =?us-ascii?Q?cWA0bA3gWgsz7J+dAEiIGcWCpOktwdbYuxX4v8XGgqiuWzJtzlsrfGF/vYtj?= =?us-ascii?Q?6ASM4indWivHICKZitNLzTL4?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9e38bd72-4405-411a-3c0e-08d8ed7a9c55 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 21:36:53.6295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CDxRSCG9kVPzFflfHXRakgxlY4pKk7IzheCdV0YIA0xMXx5Gsr/s4nmbxjixDjYcLpTPaExZy0uG6Y6mFhbK9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4780 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 phishscore=0 mlxlogscore=803 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220157 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 spamscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 adultscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220157 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Sheng Yang 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 (---) > > Can I ask what's wrong with what I suggested: One mode, not two; just > > change the name and provide a helpful doc-string that covers both > > active and inactive? >=20 > What's the benefit? Have you tried to implement it? Is there really something to "implement"? Rename `minibuffer-inactive-mode' to something without "inactive". Give it a doc string that says when inactive... and when active.... We already have the former part. The latter can just point out the keymaps (which become links to their doc). Benefit: Like what we have now - or after Alan's change to fundamental-mode - but with better doc and without a misleading mode name. The behavior is already there, no? When inactive we get the inactive key bindings. Otherwise, we get the usual minibuffer keymaps. IIUC, that's the case whether or not the "active" state nominally uses `fundamental-mode', since the minibuffer keymaps are still used. The difference is (1) doc and (2) only one mode. Feel free to let me know what I'm missing. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 17:57:47 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 21:57:47 +0000 Received: from localhost ([127.0.0.1]:59046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOSYV-0004ny-E6 for submit@debbugs.gnu.org; Mon, 22 Mar 2021 17:57:47 -0400 Received: from colin.muc.de ([193.149.48.1]:32027 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOSYT-0004nk-AV for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 17:57:46 -0400 Received: (qmail 62438 invoked by uid 3782); 22 Mar 2021 21:57:38 -0000 Received: from acm.muc.de (p4fe15b2f.dip0.t-ipconnect.de [79.225.91.47]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 22 Mar 2021 22:57:38 +0100 Received: (qmail 9173 invoked by uid 1000); 22 Mar 2021 21:57:37 -0000 Date: Mon, 22 Mar 2021 21:57:37 +0000 To: Drew Adams Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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, Drew. On Mon, Mar 22, 2021 at 17:09:32 +0000, Drew Adams wrote: > > Things are already broken, slightly. > I don't see that you say how things are (even slightly) broken. I think I meant that with regard to the philosophy "if it isn't broken, don't fix it", in that I had already fixed it, so a further fix in the vicinity wouldn't do any further damage. > > In my recent enhancements to the minibuffer handling, I noticed that > > minibuffers (the actual buffers) began life in fundamental-mode, got > > used, then on termination were put into minibuffer-inactive-mode. > > However, on being reused, these buffers remained in > > minibuffer-inactive-mode rather than being restored to fundamental-mode. > > This is silly, and "obviously" a bug. I fixed this bug by making an > > active minibuffer always be in fundamental-mode. > I don't see why it's "silly" or "'obviously' a bug", sorry. It's silly, because the mode is called "...-inactive-..." and the minibuffers were, at the time, active. It was obviously a bug, because the major mode was different the first time the MB was used, from the subsequent times. > Yeah, I see that the doc string for `minibuffer-inactive-mode' > suggests that it's not used when the minibuffer is active. > And that's effectively the case, though the mode name might > not reflect it. There's _nothing to that mode_, apart from > its keymap, and its keymap is not used when the minibuffer > is active. So the mode is there in name only. I haven't checked whether its mode hook gets run, but I think it would (if anybody put any functions on it). > That's why I expect that your change will have no real > effect. But I'm wary of it - let sleeping dogs lie. And > if it does, in fact, have no real effect, then why make > your change? Because of the negative effect reported by Sheng Yang, the OP. > This seems like a solution in search of a problem. > What if the name of that mode was just `minibuffer' > or `foobar'? Would you think/feel the same way about > needing to add another mode? Seriously - please think > about this. Well the behaviour of a minibuffer is so utterly different when it is active, from when it is inactive (e.g., in a minibuffer-only frame) that having them share a major mode doesn't seem right. But I take the point. > `minibuffer-inactive-mode' is, yes, a misnomer ... > except that its (only?) purpose was to provide a keymap > for use when the minibuffer is inactive. And the keymap > name (with "inactive") comes free with the mode creation. > If you really feel a need to clean something up here, > consider changing that mode name (but aliasing the old > one, for compatibility). To me, that would be the OCD > end of story. > > An active minibuffer doesn't use its own key map - > > it uses the key map supplied to it by the calling function. > Exactly. Exactly. Exactly. > An active minibuffer doesn't have a separate mode from > `minibuffer-inactive-mode' (a misnomer, when active). > And functions dynamically provide different keymaps > for different active-minibuffer contexts/uses. > > This is how being in minibuffer-inactive-mode (which > > does have its own key map) "worked" for so long. > Yes. It just means that `minibuffer-inactive-mode' > is a do-nothing when the minibuffer is active. > But what's the point of providing a new mode for when > it's active? What could/would/will anyone _do_ with > such a mode? Keymaps are all that really matter here, > and giving the new mode its own keymap would be useless. > (At least it _should_ be useless. And it will be ... > until someone decides that for "consistency" or > "completeness" its keymap should really take effect.) That's about the only thing I worry about (along with the possibility of using a mode hook - but we have that danger with minibuffer-inactive-mode-hook anyway, and it doesn't appear to have caused trouble, as yet.) > I don't really see that anything is missing or broken. > > The OP of this bug tells me that minor modes which maintain lists of > > "valid" major modes they work in, included minibuffers by including > > minibuffer-inactive-mode in their lists. This sort of worked (except for > > the first time a minibuffer was used), but is undesirable. > Sounds like pilot error (misunderstanding) to me. Did > OP demonstrate a real need to include a minibuffer mode > in such minor-mode lists? IOW, where's the beef (bug)? To quote the OP: >>>> Packages depend on it [the major mode], to name a few: lispy, >>>> smartparens, and telega. > > So the idea is to allow these minor modes to specify minibuffer-mode. > Why? What's the need? Sorry, but I don't get it. It > all sounds quite vague, as if someone thought that s?he > really needed to specify a minibuffer mode in those > minor-mode lists, and that need wasn't (isn't) real. It's entirely credible that these packages use lists of major modes, and that their use in an active minibuffer is appropriate. I'm not familiar with any of the three packages cited by the OP, but in previous discussions, we'd already been through talking about using `minibufferp'. > Can we see a recipe that demonstrates a real problem? > > I think there's a bug here, yes. I don't know of any particular minor > > mode, off hand, that is affected by this, but the OP assure me they > > exist. This isn't really the sort of bug that has recipes. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That, right there, hints of a non-bug, I think. That somebody is unable to configure a minor mode like she used to do doesn't feel like a non-bug to me. But maybe your idea of just renaming minibuffer-inactive-mode (with an alias) and using it for active MBs might be the best way to fix it. > It sounds like a misunderstanding, to me. On whose part? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 22 19:06:38 2021 Received: (at 47150) by debbugs.gnu.org; 22 Mar 2021 23:06:38 +0000 Received: from localhost ([127.0.0.1]:59102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOTd8-0000Fv-2P for submit@debbugs.gnu.org; Mon, 22 Mar 2021 19:06:38 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:56454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOTd5-0000Fh-Lf for 47150@debbugs.gnu.org; Mon, 22 Mar 2021 19:06:36 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MN5j1c014692; Mon, 22 Mar 2021 23:06:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=pVGICRBhRr6LALefniSbHxP488uJcYeFv4ignKNtGdQvUoK4qHZkfSiZ4sfjlF4IyybE CgDAHb4LjF1hZJQ3n+uf0tBMNtWLLP0ZxCZb7IkaCS8k9y/O0rsBDbUuJCHK9CpKzIWF zIxM44+oh8PJMtHuIVJ08MoYqQNQKZopFEwF552YSLrl9dq5Vwx2cq/xqyS3bwbwF+0j XP8lsuwAekQgArS3YOrkHaiM5qs/WtaQzqiCd1InivFk+Sf4qcVGTBRhQMb2AAtfL/kS LBC17f0jlkduzlXqWtqDeydmfVpccsXaHQqOMiglmUJYOlJjISnFpO785NilIFbjc7w5 cQ== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 37d90md37k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 23:06:25 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12MN54Z7196254; Mon, 22 Mar 2021 23:06:25 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by aserp3030.oracle.com with ESMTP id 37dtmnseuq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 23:06:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=amFjXF2P2ZLDcWi3EZ3svz1+NVnSatZk81Z7CNQMNlxl0cabepctCMmqiB4y1xg1TMj3rdO/XoeS8d1o91+MYlb0gdx+ZlzhBOCHiU77SUu2cFj5WUFhzJRSPwo3+QEkje7KsnHItrIRAU9w18GOOFa6G0t1A1GzMao1h5F4E15AOAbeJgyq05RWazx7NKMeYhe/yJgFiIEnY0ecfZxNSygbW5F/7FLmtBhvXVxCuIYrTY2iQCiTJj5HK6GjaQRtBnXRHen18yCUgrneTpVvWEksEfgFvZ8MMO4YH4UVxy0SymB+fh3Wuriay9DBQyPh7ZbENWliR3DDhq5bT27J+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=FahqCc0KbdfkNkeyBsKvwt6QqNIBQyzI9G1fv26KdhIa4QOy1jMs6b6DhmwYWIV6vXUQHhnG8yWKpdgy3P8H3fD15m/pggSOYNHeNJGhs2oCsApUDERjuaOYTNIb0ogFx2nVVk6m90j/rKMaML9lwlKaOYDej+of9nDVfX2gjIUMFDPA/pHttShwslK1QrrE4P9gtY1gnIBS61K11KQ98Q0QndD0TsdfCEep/kzyvl0jYNZumd+U+qVY/rXeWIKumo7hGFeJnMMuaRq19vWebXtcbHNG0YnpdFIWh2YnMVL0XnUmG2Afpfu2x+tyI1VHrMPXRCX5ttZGySKIQFHCNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/qQuZkpbCAmFDdROdIFuB5dBRRVs8cdonSqWF4thbDQ=; b=Yd5+y1clGY4XHzRH9OvbxwWB78rdkf6H+smzeA5wDVQiQ9zV1JSc7JrCfVFk3loR4OSLMEqJ9Bz4Hz8D0IiJKcZgfAtSiMYtDc2bYeL+Z3haQ82VWn9ct1H+hqsJCtlkgKUDrQDLW46+E9fC0Q9C9FIFWjUWOe6+TenqU7su9js= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SA2PR10MB4649.namprd10.prod.outlook.com (2603:10b6:806:119::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Mon, 22 Mar 2021 23:06:23 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3955.027; Mon, 22 Mar 2021 23:06:23 +0000 From: Drew Adams To: Alan Mackenzie Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH2ZkGbJ696fBvEOoaQW9Kej3KKqQmMdg Date: Mon, 22 Mar 2021 23:06:23 +0000 Message-ID: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muc.de; dkim=none (message not signed) header.d=none;muc.de; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7758aef-9275-4d64-bec6-08d8ed871cd0 x-ms-traffictypediagnostic: SA2PR10MB4649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u1/pqbjoUibxpkiMxlZfmsN24S1h73OO0ht71PLW+nIZd4gpUP7f3lLpKB+FXpbbCrsPKHj7pbFEVlLENlbouZVGI6t0ugGHF0qjCqjRD3fSFL5vzCHbUpUJU/hb6LYq/nvElWVwkjZXtQEwhbOL9zwl++2wFjUAB8OxzwbIvJm7sITUQpSy0WYFde6gw4HkSYwBUjq9aFqKPkt+LKNcOUvtlKMBTz/meOZmyPQ0hdqvngtPVhdruvQtNJNMxrqz83LtXthrerGTrN96DkY3vas7ZhhASJIWLZFrEhjnswa/fcQFkS8TPRTDTiO0aZS0gMBR/I5U3kN2lifLix8V2Gy0uV8MFmboEEVK97PX6CopXJhgIcud0KNi6MW96RtpqvRVa8vKrzdtHzOTJH0icAvmuHsv0V5hUaz/cKL0d/eO8jiTU2h/ACdp0eHlyB6lBKuJbXZr5xKmfCSvtu05K5n+amRPzAh8rZsAxYWeq2oeAPPesMLGSXjmCOhBa94NvkMNlTHdi6jLKSyB+4H+SMtGaCQg2sXYVgjECoElSPXq0lDcjuOUDvpa1VxQLzyW1mfC+moU4lp2kKqqMqhJy/Gpswb40oywXXG3faZEOuPu/ZyfOEGRWPiPRpbGzEedTikB+rHNbRyjYWEp6ZLmHPJRqjmZsi0MS+6HoISjA7c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(39860400002)(136003)(366004)(71200400001)(76116006)(6506007)(6916009)(5660300002)(66476007)(86362001)(478600001)(66946007)(316002)(26005)(66446008)(66556008)(2906002)(186003)(64756008)(9686003)(7696005)(55016002)(33656002)(4326008)(38100700001)(8676002)(44832011)(83380400001)(8936002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9M4kU8wocriba3Ee4bfQrfN7uloBIzpckWCoHm6HU5GmQrJmOhKbdH2FUGfG?= =?us-ascii?Q?3RUMPSiHHTtepKxyyNSDtIptNUJifBMbVYCXMSRpzzuVBECN+jVZrq7+E4vv?= =?us-ascii?Q?Mi9V8RXQT87gf1APYi7yIVxtZhe/IkssiboDBWAlunGDd4IQAG6PZXfJVGeI?= =?us-ascii?Q?HMyPMIlonJRsg3g+F7FdBXfBwtHsYTFlWD+SWwixE04ICq8hsRyoDMCQpWQ9?= =?us-ascii?Q?ZZRLtPxvVcjR6W4EExW8xD56GsW/mSJnrJqnvKSqfX/eB148e6KM3ILKpLkc?= =?us-ascii?Q?Z9IBBGj4maaUyXJCQ+1YtW7NTnjeBkKUg6xmtdMwNUn3vZE5SkoLrYtCNN3r?= =?us-ascii?Q?94TWIqmc2Zca0IcmpTy/i54WpTsssvYQ6CK9gXNZhJYqgM7Bc1qtqDrg7dTJ?= =?us-ascii?Q?6G+JkCGng4Cy5VrCnpZ0XPjfw8ibkhtPhbZOw9E1Pw1Rdck+BMxImAhVeG9P?= =?us-ascii?Q?xDfvWHUh8Dg6J84pjgmbVNYdlGbjHHh/YXWQqaI3037YzPqvzs4SKOEtsp8h?= =?us-ascii?Q?7r7udGEmfuhxB5VVTwoSq73bFVqfVOF9JEijcuytsc7NYOT4Yrl0NitaOpxR?= =?us-ascii?Q?pn+LhtyiknvCXQqx69pLANM1AFFRSobkg+e6v4ASIQcFPUYrxdODnmjEA8zy?= =?us-ascii?Q?T7pKL5+2eZbMQMhjq1roU99q3bqvpg3sZr9fPlOWwWKL8LVC/87uoCkswJ+t?= =?us-ascii?Q?L/FQF+XCOCH2CX1MsEqOzdL/KwTLk0xB4NGlV17wDSD2rS3ZTk7D66aS4Gt8?= =?us-ascii?Q?WMiAhjjZ+CPPoGQIhkTXDcbQq5MCj46KNat/UhLbPnGDPqBD6wA4L8VlxV4F?= =?us-ascii?Q?JC30JQJk+72u6Mk4GmlbC7D5TL03Uc1Ws++lVQ+vTYlNvwzJGgTX2jO47zq3?= =?us-ascii?Q?Y0sz+bxleC1veCo5WQb+ghloB0d6yfGVRJL0vyK4TzgyQDuV5rnnFZT+23ns?= =?us-ascii?Q?wX06ZVxTD6oi0yCdWCZJQmgqF50DhuQnAxNGtbEBuColukIXmahLCPlRAIPQ?= =?us-ascii?Q?fcV+dAwFmSkSh22lelNhfCfuL4Wbqxe4WvGi4HBS1OdKGD+3ZG0qtFf/Pu3m?= =?us-ascii?Q?FiFrxiFABTPnU97feo67dsoEdYf2+UkX6YwCxanIA2QPJ3DwhifFERu0aEuq?= =?us-ascii?Q?qC8yNnall1shrfQXZBNhvQcIYseeFe3Akd2PVTj14RFoojv9+B2RxvN4xXLZ?= =?us-ascii?Q?YXnfKoHUg7qvIfJCTP1BaJplcVryIh4y+PR56Mn2rZaBQ7L30w+3IhEcvzZb?= =?us-ascii?Q?+A7OK9GpqKOfEIarhV/KezXBLLSBqSfHBdmjVsQmPOkjNNtSeRiXMKg0IPYq?= =?us-ascii?Q?nq7bIFPf1s/ugsQN2TZuouPX?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7758aef-9275-4d64-bec6-08d8ed871cd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 23:06:23.1988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k70f6E2RcWycb0sZI8XOZHJCdazpfs38U7pcMLezmvcCdrs+lXJYa7shZ/MiwdrXvUe/q2wy5Z9wbvmbosRtIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4649 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220171 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220171 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (---) > > > However, on being reused, these buffers remained in > > > minibuffer-inactive-mode rather than being restored to fundamental-mo= de. > > > This is silly, and "obviously" a bug. I fixed this bug by making an > > > active minibuffer always be in fundamental-mode. >=20 > > I don't see why it's "silly" or "'obviously' a bug", sorry. >=20 > It's silly, because the mode is called "...-inactive-..." and the > minibuffers were, at the time, active. It was obviously a bug, because > the major mode was different the first time the MB was used, from the > subsequent times. OK, silly mode name; agreed. But how was the major mode different? It remained `...inactive...', no? Yes, it became actually active, but the mode stayed `minibuffer-inactive-mode', right? Is there something more going on than a poorly named mode? > > Yeah, I see that the doc string for `minibuffer-inactive-mode' > > suggests that it's not used when the minibuffer is active. >=20 > > And that's effectively the case, though the mode name might > > not reflect it. There's _nothing to that mode_, apart from > > its keymap, and its keymap is not used when the minibuffer > > is active. So the mode is there in name only. >=20 > I haven't checked whether its mode hook gets run, but I think it would > (if anybody put any functions on it). OK. But does the mode ever get turned off, once it's turned on (at minibuffer creation presumably)? I didn't think so. My impression has been that the mode remains `minibuffer-inactive-mode'. I said that the behavior is "effectively" as if that mode isn't in effect - its doc description doesn't apply when the minibuffer is active. But the mode is still `minibuffer-inactive-mode' - or so I've thought. > > What if the name of that mode was just `minibuffer' > > or `foobar'? Would you think/feel the same way about > > needing to add another mode? Seriously - please think > > about this. >=20 > Well the behaviour of a minibuffer is so utterly different when it is > active, from when it is inactive (e.g., in a minibuffer-only frame) that > having them share a major mode doesn't seem right. But I take the point. It's a mode for the minibuffer; that's all. Yes, the behavior's different when it's inactive vs active - it's the key bindings. But the behavior's different when you use `completing-read' from when you use `read-string' or whatever - again, it's the key bindings (keymaps). Should we have a different major mode for each kind of active behavior - completing-read, read-file-name, read-buffer, read-number, read-expression,... All of those behaviors are different - different key binding. By your reasoning we should have different major modes for them, no? > > `minibuffer-inactive-mode' is, yes, a misnomer ... > > except that its (only?) purpose was to provide a keymap > > for use when the minibuffer is inactive. And the keymap > > name (with "inactive") comes free with the mode creation. >=20 > > If you really feel a need to clean something up here, > > consider changing that mode name (but aliasing the old > > one, for compatibility). To me, that would be the OCD > > end of story. >=20 > > > An active minibuffer doesn't use its own key map - > > > it uses the key map supplied to it by the calling function. >=20 > > Exactly. Exactly. Exactly. >=20 > > An active minibuffer doesn't have a separate mode from > > `minibuffer-inactive-mode' (a misnomer, when active). >=20 > > And functions dynamically provide different keymaps > > for different active-minibuffer contexts/uses. >=20 > > > This is how being in minibuffer-inactive-mode (which > > > does have its own key map) "worked" for so long. >=20 > > Yes. It just means that `minibuffer-inactive-mode' > > is a do-nothing when the minibuffer is active. >=20 > > But what's the point of providing a new mode for when > > it's active? What could/would/will anyone _do_ with > > such a mode? Keymaps are all that really matter here, > > and giving the new mode its own keymap would be useless. >=20 > > (At least it _should_ be useless. And it will be ... > > until someone decides that for "consistency" or > > "completeness" its keymap should really take effect.) >=20 > That's about the only thing I worry about (along with > the possibility of using a mode hook - but we have that > danger with minibuffer-inactive-mode-hook anyway, and > it doesn't appear to have caused trouble, as yet.) I really don't see the mode hook (on any such mode) being a problem in practice. Currently, the minibuffer is (I think) _always_ in `minibuffer-inactive-mode'. Its mode hook only ever kicks in when a minibuffer buffer is created. OK, that does happen occasionally, for recursive minibuffers. But I think worrying about its mode hook is fruitless and needless. > > Sounds like pilot error (misunderstanding) to me. Did > > OP demonstrate a real need to include a minibuffer mode > > in such minor-mode lists? IOW, where's the beef (bug)? >=20 > To quote the OP: >=20 > >>>> Packages depend on it [the major mode], to name a few: lispy, > >>>> smartparens, and telega. That doesn't answer the question about _need_. What's the real need for them to do so? That would make the bug understandable as a bug. > > Why? What's the need? Sorry, but I don't get it. It > > all sounds quite vague, as if someone thought that s?he > > really needed to specify a minibuffer mode in those > > minor-mode lists, and that need wasn't (isn't) real. >=20 > It's entirely credible that these packages use lists of major modes, and > that their use in an active minibuffer is appropriate. Sure, I get that (although it's abstract). But can't they just either special-case the minibuffer mode or explicitly include it in their lists: `minibuffer-inactive-mode'? Do we even know whether adding that major mode to their lists would solve their problem? > I'm not familiar with any of the three packages cited > by the OP, Nor am I. > but in previous discussions, we'd already been through > talking about using `minibufferp'. Dunno what that was about. See previous: the minibuffer has a major mode, `minibuffer-inactive-mode', doesn't it? Why is that harder to handle than some other major mode? > > > This isn't really the sort of bug that has recipes. > > That, right there, hints of a non-bug, I think. >=20 > That somebody is unable to configure a minor mode like > she used to do... Sorry, hold on. Like she used to do? So something was changed? Do you mean used to before Stefan gave the minibuffer the major mode `minibuffer-inactive-mode'? That was a while back. Did that cause a regression for the OP? > But maybe your idea of just renaming > minibuffer-inactive-mode (with an alias) and using it > for active MBs might be the best way to fix it. Seems straightforward to me, but I may well be missing something. As for "using it for active MBs" - there's nothing to change (IIUC): that misnamed mode is already used for active (and inactive) MBs (IIUC). It's just that the behavior of the minibuffer changes, depending on whether it's active and, if so, keymap is used for the reading. > > It sounds like a misunderstanding, to me. > On whose part? I was thinking OP. I was thinking that it should be sufficient to just include `minibuffer-inactive-mode' in their major-mode lists. But I admit to a poor understanding of the problem. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 23 03:18:48 2021 Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 07:18:48 +0000 Received: from localhost ([127.0.0.1]:59416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lObJQ-00087N-8O for submit@debbugs.gnu.org; Tue, 23 Mar 2021 03:18:48 -0400 Received: from chiru.no ([142.4.209.132]:33796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lObJO-00087D-05 for 47150@debbugs.gnu.org; Tue, 23 Mar 2021 03:18:46 -0400 Received: from localhost (unknown [178.172.46.206]) by chiru.no (Postfix) with ESMTPSA id C249612801AE; Tue, 23 Mar 2021 07:18:44 +0000 (UTC) From: jakanakaevangeli@chiru.no To: Drew Adams Subject: Re: bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Tue, 23 Mar 2021 08:18:45 +0100 In-Reply-To: Drew Adams's message of "Mon, 22 Mar 2021 18:38:54 +0000 (11 hours, 50 minutes, 9 seconds ago)" Message-ID: <87lfaes5gq.fsf@miha-pc> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (-) >>> Yeah, I see that the doc string for `minibuffer-inactive-mode' >>> suggests that it's not used when the minibuffer is active. >>> And that's effectively the case, though the mode name might >>> not reflect it. There's _nothing to that mode_, apart from >>> its keymap, and its keymap is not used when the minibuffer >>> is active. So the mode is there in name only. >> >> I haven't checked whether its mode hook gets run, but I think it would >> (if anybody put any functions on it). > OK. But does the mode ever get turned off, > once it's turned on (at minibuffer creation > presumably)? > > I didn't think so. My impression has been that > the mode remains `minibuffer-inactive-mode'. >> [...] >> That's about the only thing I worry about (along with >> the possibility of using a mode hook - but we have that >> danger with minibuffer-inactive-mode-hook anyway, and >> it doesn't appear to have caused trouble, as yet.) > > I really don't see the mode hook (on any such mode) > being a problem in practice. > > Currently, the minibuffer is (I think) _always_ in > `minibuffer-inactive-mode'. Its mode hook only ever > kicks in when a minibuffer buffer is created. True, the mode doesn't normally switch to a different mode in 27.1, but on the other hand, the function `minibuffer-inactive-mode' does indeed get called on every minibuffer entry and exit (except for the first one, I think) and its hook gets run every time. The only thing Alan changed recently (for 28.1) was to instead call `fundamental-mode' on minibuffer entry and now wants to change this to call `minibuffer-mode'. As I see it, this is as small of a change as it can get. >>> What if the name of that mode was just `minibuffer' >>> or `foobar'? Would you think/feel the same way about >>> needing to add another mode? Seriously - please think >>> about this. >> >> Well the behaviour of a minibuffer is so utterly different when it is >> active, from when it is inactive (e.g., in a minibuffer-only frame) that >> having them share a major mode doesn't seem right. But I take the point. > > It's a mode for the minibuffer; that's all. > > Yes, the behavior's different when it's inactive vs > active - it's the key bindings. But the behavior's > different when you use `completing-read' from when > you use `read-string' or whatever - again, it's the > key bindings (keymaps). > > Should we have a different major mode for each kind > of active behavior - completing-read, read-file-name, > read-buffer, read-number, read-expression,... > > All of those behaviors are different - different > key binding. By your reasoning we should have > different major modes for them, no? I believe Stefan actually proposed something like that in a previous message from this thread when he said read-from-minibuffer could accept a major-mode/functionp argument. This would allow for straight-forward documentation of each different minibuffer usage in `C-h m', including mentioning the ability to use general editing commands. Besides, wouldn't it be cool to have syntax highlighting in `M-:'? I believe function eshell-command already does something like this, it puts the minibuffer into eshell-mode. Not to say that this comes without its own problems. For example, if a user binds current-local-map's RET key from a major mode's hook, he will not be able able to use RET to exit from a minibuffer in such a major mode. `eshell-command' works around this with a minor mode that binds C-g and RET to appropriate minibuffer commands but this solution isn't ideal in my opinion because the user's modifications to minibuffer-local-map aren't taken into account. Perhaps a better way to make a major mode for use in minibuffers is to derive it from an ordinary major mode and use an :after-hook to install a local keymap that is composed of minibuffer-local[-completion|-ns]-map and the current local map. > [...] > > Do we even know whether adding that major mode to their > lists would solve their problem? > >> I'm not familiar with any of the three packages cited >> by the OP, > > Nor am I. > >> but in previous discussions, we'd already been through >> talking about using `minibufferp'. > > Dunno what that was about. See previous: the minibuffer > has a major mode, `minibuffer-inactive-mode', doesn't it? > Why is that harder to handle than some other major mode? See above. Alan recently changed active minibuffers' major mode from `minibuffer-inactive-mode' to `fundamental-mode'. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 23 09:05:40 2021 Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 13:05:40 +0000 Received: from localhost ([127.0.0.1]:59834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOgj5-0004It-Qg for submit@debbugs.gnu.org; Tue, 23 Mar 2021 09:05:40 -0400 Received: from colin.muc.de ([193.149.48.1]:54829 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lOgj3-0004Id-CN for 47150@debbugs.gnu.org; Tue, 23 Mar 2021 09:05:38 -0400 Received: (qmail 86922 invoked by uid 3782); 23 Mar 2021 13:05:30 -0000 Received: from acm.muc.de (p4fe159d5.dip0.t-ipconnect.de [79.225.89.213]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 23 Mar 2021 14:05:30 +0100 Received: (qmail 6715 invoked by uid 1000); 23 Mar 2021 13:05:29 -0000 Date: Tue, 23 Mar 2021 13:05:29 +0000 To: Drew Adams Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de 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, Drew. Some confusion has arisen, which I'd like to try and clear up right at the top of this post. I have recently (in the last few months) changed the modes used by minibuffers. The OP for this bug has drawn attention to the difficulties these changes have caused. Before my changes: (i) An active minibuffer, the first time it was used, was in fundamental mode. In subsequent uses it was in minibuffer-inactive-mode. (ii) An inactive minibuffer was always in minibuffer-inactive-mode. After my changes: (iii) An active minibuffer is always in fundamental mode. (iv) An inactive minibuffer is always in minibuffer-inactive-mode. On Mon, Mar 22, 2021 at 23:06:23 +0000, Drew Adams wrote: [ .... ] > OK, silly mode name; agreed. > But how was the major mode different? > It remained `...inactive...', no? See (i) above. [ .... ] > Is there something more going on than a poorly > named mode? See (i): the fact that the first use of a minibuffer was in a different mode from subsequent uses. [ .... ] > > I haven't checked whether its mode hook gets run, but I think it would > > (if anybody put any functions on it). > OK. But does the mode ever get turned off, > once it's turned on (at minibuffer creation > presumably)? See (iii) and (iv) above. > I didn't think so. My impression has been that > the mode remains `minibuffer-inactive-mode'. This used to be the case, but is no longer so. [ .... ] > > > What if the name of that mode was just `minibuffer' > > > or `foobar'? Would you think/feel the same way about > > > needing to add another mode? Seriously - please think > > > about this. > > Well the behaviour of a minibuffer is so utterly different when it is > > active, from when it is inactive (e.g., in a minibuffer-only frame) that > > having them share a major mode doesn't seem right. But I take the point. > It's a mode for the minibuffer; that's all. > Yes, the behavior's different when it's inactive vs > active - it's the key bindings. But the behavior's > different when you use `completing-read' from when > you use `read-string' or whatever - again, it's the > key bindings (keymaps). I think there's a difference here between "utterly different" and "slightly different". The question is whether the utterly-slightly distinction is sufficient to justify having two modes. You clearly think not. I'm, as yet, undecided. [ .... ] > > > But what's the point of providing a new mode for when > > > it's active? What could/would/will anyone _do_ with > > > such a mode? Keymaps are all that really matter here, > > > and giving the new mode its own keymap would be useless. > > > (At least it _should_ be useless. And it will be ... > > > until someone decides that for "consistency" or > > > "completeness" its keymap should really take effect.) > > That's about the only thing I worry about (along with > > the possibility of using a mode hook - but we have that > > danger with minibuffer-inactive-mode-hook anyway, and > > it doesn't appear to have caused trouble, as yet.) > I really don't see the mode hook (on any such mode) > being a problem in practice. Probably not [ .... ] > > > Sounds like pilot error (misunderstanding) to me. Did > > > OP demonstrate a real need to include a minibuffer mode > > > in such minor-mode lists? IOW, where's the beef (bug)? > > To quote the OP: > > >>>> Packages depend on it [the major mode], to name a few: lispy, > > >>>> smartparens, and telega. > That doesn't answer the question about _need_. > What's the real need for them to do so? That > would make the bug understandable as a bug. I honestly don't see the problem in accepting this bug as a real bug. After several exchanges (earlier on in the thread), the OP's current difficulties are clear, and they were caused by my recent changes in the minibuffer mode handling. [ .... ] > Do we even know whether adding that major mode to their > lists would solve their problem? I think so, yes. [ .... ] > > But maybe your idea of just renaming minibuffer-inactive-mode (with > > an alias) and using it for active MBs might be the best way to fix > > it. > Seems straightforward to me, but I may well be missing > something. There would be minor details to sort out, like does the renamed minibuffer-mode get rerun each time the minibuffer is used, and things like that. [ .... ] > > > It sounds like a misunderstanding, to me. > > On whose part? > I was thinking OP. I was thinking that it should be > sufficient to just include `minibuffer-inactive-mode' > in their major-mode lists. This was what was previously done, and because it no longer works is the cause of the bug report. > But I admit to a poor understanding of the problem. I'm not sure about that. ;-). Thanks indeed for the idea of just having a single minibuffer-mode, rather than two modes. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 23 11:45:12 2021 Received: (at 47150) by debbugs.gnu.org; 23 Mar 2021 15:45:12 +0000 Received: from localhost ([127.0.0.1]:32787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOjDQ-0002GO-0n for submit@debbugs.gnu.org; Tue, 23 Mar 2021 11:45:12 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:44008) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lOjDJ-0002FY-JI for 47150@debbugs.gnu.org; Tue, 23 Mar 2021 11:45:06 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12NFi7Ku094811; Tue, 23 Mar 2021 15:44:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=; b=gASop0lA7kPDTTmh9UPV5E8IKJHq5MNXiUlLtcjWCEozk2jcptApDDnGqV10ifjpScSK RmhSUfd1x/WqyDPt03dD7uvAyCXQUZFy69I0Hno4r+dCGqANA9NJOh+/4xEQUVArLtm/ u+eIeYzsAy1c0C45AbTTX4bhWAPn74GIUb31ymyU87AgFA1k7+HrPrIUcQdL6k711cpD jbOisjsXEYVS50p6O/Ek0SO8G/Vk++0XcC9n6m9AdhiOp5mKhhvXahaqFKdrVbUcbyuw vPrW8w0BxQcqd0weZYYLvIFNSQK6px06Mltl6hzS+/ah7PcZSu6LrdahYDP0juX0QMdw Tg== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 37d9pmyh8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Mar 2021 15:44:52 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 12NFeArv099961; Tue, 23 Mar 2021 15:44:51 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2047.outbound.protection.outlook.com [104.47.73.47]) by userp3020.oracle.com with ESMTP id 37dtts3u9b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Mar 2021 15:44:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fsnLFT5M2MSePutyd1VHcOPO+0zPw6tvbyY/GYqv5SHQxzg5NhYypW9cN6w/lVbsYHVgRMjydu1rsl6wynrUbkZmq3OZZNz5nCJbmN1k9X54e3C7LGNDy18cRuO1pClWk923J6uhuOjzoAhnzWyqIjgkzjKQCO+I6TDJxVq9GtvkzXAj/sbUhS3BpDNh/GJdwnu85zUa2mckLDoZ+jm61idV92B6sgHKRc0IqzjRYCRzpoXsZ/RCA/L43rkb0eN7t9j56MlctqtmCeXNnNBR6uP7aIImahUQcoAPu1t8ZrtOFPloE+Zl8wL6z20cBih9YEq6PGFRO+pUOUnOhOzTHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=; b=VbsWqZNa81rGtdLpt4s+fijJyhqb2mGxlvY4mV2TpZAPrMcYcULcE2jWWp/xyfea1jjjONZ9eTcYEThil5r5Vz1GT6MqSssdLn7LWE3ZnFLSGVieUMa+WtjBy9HysQ50Qt02U8HrEqmWDHN9iWdZ+s4fr6lLZFWJEjRXRpFPLhfkiYBe7HEebRpDmFEnyqi0NIiG1551URYRlo9hvjUq2vsjQgxikQUqaWJEiEAJjKmeccZIr86tfbvGKKpqNv9o74Hif/EfyjnPNnUrCxRDAgWQQ9REqPDrwMm+WbQ5Eee5QtIJM+idw3tb4LqfhnCcTqXkHNl2SG96bCZbDeYndg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p4wEvmEBk/0N8Pjs8T//KauHjeYn63vnwEgMkd8pdPo=; b=XA3OSmjmRuQFTdqJJ6LgUdCIq83IWrO2KBVR1gqE5dTeVyyc9/+0BlBulvke7SgF5evusW+piBIxuNjxnrzAi382Bm8UtShBHgsg6JMRXkclIVPHwyCJgfBLdBspvBFuzGQ4ynCd/sEZ0ic67dRq9FWzv0+haDR0zN9UcIdO7+4= Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB2797.namprd10.prod.outlook.com (2603:10b6:805:cb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.23; Tue, 23 Mar 2021 15:44:47 +0000 Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::b8d2:db6d:3e4b:d315%5]) with mapi id 15.20.3977.024; Tue, 23 Mar 2021 15:44:47 +0000 From: Drew Adams To: Alan Mackenzie Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Topic: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Thread-Index: AQHXH+U3Mfqrx+LstUi6bwxoL5CE4aqRtJLg Date: Tue, 23 Mar 2021 15:44:47 +0000 Message-ID: References: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <05c43a83-6e3c-4f10-a36f-0567bcceb3f6@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muc.de; dkim=none (message not signed) header.d=none;muc.de; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2cb073f-c049-4b61-f41c-08d8ee129646 x-ms-traffictypediagnostic: SN6PR10MB2797: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sGZxfiXqniucKrfP9udwfO6YlvxandOivX0viDiVWonEHx1yoGpDz197zvF+NTK4jGkZP20hbqYCXo20EtDMjjrG86eP9S5Cxn1T/D0gOCKpYIQI6iMVEsxpRAyCDEUPVYMhvv5mU+Sp34NLbnZ59Ik/NfuMgnsmeKQF/SwPBHjJ189xtdeCF9KMIqzjcOPKUjhqNwSF2gdfy17U45+I0o71VBhYY2sF4X5gyRNzBKYxMoq9HxpjjOVcg+G9tPulw8W1PE3/jTPjMMZTnWgneGjosokQ0hEhr3mrIzNFWkZG5rx7OT0nFRG3tKgI7Si4IbVVBPB/u0WtpQ8HsJffDt9sRMVq4cSmplX2ZTDWS7I/UY5m5bP/ZvzWiwNxoW7NvxHUcy17ksOlRep7taYrIL+4RonRT1M+vOD6TEha9REZZdMcRuNKZEW8fxlcKaP0HmjdaJmGDwwrzKdhl/2+l5Wu1o+zwzOjRoEXYhgGidAvqgJV6qYsAmCcl3Z4702Th1u2TXjCJXXoQZlbt9ULUDwXn/QziCGC5zdJM0FwaziSfm9qu3WNW7P2DWWwTWIFoZdgJfqLue7crLTxGw3RpcuhPsuqgSp/RitPWOZK227BhqA9maX3chKpjpgyyaxov+M+c/uwikPidXaRz0GGDg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(136003)(366004)(39850400004)(66556008)(5660300002)(33656002)(6506007)(86362001)(66446008)(26005)(38100700001)(66476007)(9686003)(44832011)(8676002)(6916009)(64756008)(66946007)(478600001)(316002)(4744005)(2906002)(55016002)(76116006)(71200400001)(4326008)(186003)(7696005)(8936002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?AbQSFcAzt0rT1zVAS0bVXQt8F7FKvbUKShdtHcM/2Ql8BkNhZHdUklTWe5Rv?= =?us-ascii?Q?glYOr/nV4tP0EK6pRLtZxblNMomGDHgvYpdfThysFpdTZeEoIq4vkfheFpRF?= =?us-ascii?Q?pmFeQrGEMSiiOSVFkyqWaZIOc22fB+nRQhn1cfgVA1PFLcIq0hI7Ac8bNqeF?= =?us-ascii?Q?ClMr9ARJXHhMVoX1Oh41Hj9ULlJsqXTd1jsRk20RC/I5b0v9NGEC9OUq2cCc?= =?us-ascii?Q?8WweUjowNyRlAvI5W3vdR97UmqI2HuhnjyDzNtpdZKDjRuZNM2CLLrq2hz4P?= =?us-ascii?Q?762opgvA/6ENU1NKZJXrbXIQrxjHyyF+6bdS9hZBGjElKaqOtGHlHkhYk+hr?= =?us-ascii?Q?YAXaz2iV0pelRjpTdwGnUk9qZyfQVj4xg9SB0c4nFdfkOfR+S0g0tmZNFXxM?= =?us-ascii?Q?l7UFyknfZ7NAxP2c2T36XLG+JW2t6ISKM41R+0VjnxjVL9LNMCe5xxQ+CMDV?= =?us-ascii?Q?bzLyo4Go7C5hJm2MLk+VCPnrQx494zQ51ebmnfjnNx/8Iy41i+BWSme0xCAi?= =?us-ascii?Q?q99UT9IP10bSCjjN/1UO22Q8kZjG44JeRzYNy7HDKGHD4jlmrojhaObm5e+Q?= =?us-ascii?Q?E/yxKVTb89Q6t4ZXm52bOjLeB2eeD5s/Z0URxsgGlbHCmE0yj29zhDAZSpfP?= =?us-ascii?Q?R9crRCf4GxfnSSvbah5CiQTy+zzrUzQNze9P6LbkevVIV8nK1joDsyph2rzX?= =?us-ascii?Q?5JN9U/YWFKOs512/0Pc76S/jVPZEEdciv3kIJfcACsBFT6QSz+24yGYtR42s?= =?us-ascii?Q?tbEYkiB2tLjDM34B22OyOepq+An86VbpAIx9wUsev0Xt/687LJlfwc8lxB4a?= =?us-ascii?Q?+uyXAspAiN81zZYodpijh2Co4fgB+bFVQUHS5TCmb/4InE4iBxpDE2BPr8oo?= =?us-ascii?Q?wSN5ZpxCzRDZkNcebuqMkWhvbr9zwc/GCmIcNwtMhkRYt/82DqM4o+lxODxZ?= =?us-ascii?Q?hE3ccWVNucoRckMpHUstTReEYnv5LxqxlaAlJKhx1Dp1agSTlc4eP1DDxF6n?= =?us-ascii?Q?ngtG84PmuyBqhp9Y3CrUdcmKbN2YazjbXfpL8ErjEDcq6tcJVurTUyUyIcIf?= =?us-ascii?Q?qv4CQBqutwIuva5wmK8x+ccr5jnaV2jO8vqhKa+sYOXvI64csN882KVR+0lX?= =?us-ascii?Q?YyKdyIBcLe5lC3bzpBL+amQDmMEBSNMIWbxpDTNHUncmfwe/gws5v6z33QnD?= =?us-ascii?Q?VkqODHw1n0XUiU0dL4GTzAitKkc2SH3w57E5MIX6xaPF1sQIhegqwnAd7VQM?= =?us-ascii?Q?CmLXHCQI3TxgMB9W/X+mNN90h0XXMF0KWslAhtMRBLWundd717FdQY39KYm7?= =?us-ascii?Q?CcyXEZcI60/zo2mnmuPOZynp?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2cb073f-c049-4b61-f41c-08d8ee129646 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 15:44:47.0332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N3xPKQ1l8ZKnz2weenXlHL4ofJ6hWwiC7IpmymRnlifSKraJqX/cnCiw3j+ms7A6zuUTLjrrsDjMeP1hvegTAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2797 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9932 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=816 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103230115 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9932 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103230115 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> 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 (---) Thanks to all for clarifying things for me. And thanks for considering my suggestion to have a single mode, whether or not it makes sense overall. I trust you will work out a good way to handle things. I hope whatever changes are made won't negatively affect my use of Emacs (and I expect they won't). ___ [Other changes that were made after Emacs 26.3 mean that Emacs 27.1 is completely unusable for me with my setup. I haven't been able to track down just what the culprits are. That's a big problem for me, and it probably adds to my wariness of changes to minibuffer behavior.] From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 09 04:57:30 2021 Received: (at 47150) by debbugs.gnu.org; 9 Apr 2021 08:57:30 +0000 Received: from localhost ([127.0.0.1]:49060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lUmxF-0003Xk-Nq for submit@debbugs.gnu.org; Fri, 09 Apr 2021 04:57:30 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lUmxD-0003XV-NM for 47150@debbugs.gnu.org; Fri, 09 Apr 2021 04:57:28 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5B08A5C0103; Fri, 9 Apr 2021 04:57:22 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Fri, 09 Apr 2021 04:57:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=MObfWssnmqdoxFT+3UhQ/0TlJvBziHo LIBtY/6Tuon4=; b=HKpgG1pHVshOWNTFMHGYWSqrFMFdx8xBDN21+VSjdZLS7eV qAAcG1MOngt0XadUzzOv8lqE47CPaNvMXq6VOtS3pwJhy1pJ/4Z3kNWjKC+8wDIo LPWzTziHaidnPQZYg3wLUMvUEVqHYYlPMs4bqjx6ZW3Tj1nmw8Dm372Sd2pxIkoz SAQDLaGrxsWsXtHeejH2lZu1jJJbB5N0WYtRmpAcwD0LcjqxSBIW336g3C2kkUGf E+UIy5vutj/kkHdvOBAH7uDmMF/RJ6r12xqIs6XEV8X5plNGAZzokkG6Jf62jYsO NPiCr4Yw8vOW/Dg/ZFDHdNi32VlAjVIFPd4QAlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MObfWs snmqdoxFT+3UhQ/0TlJvBziHoLIBtY/6Tuon4=; b=k3Yqy/Gp9/cje+THeT8gau lT6DcVJ6D2AIRnxD0ua/tqF9P1f3HmbEcotdclFk7RgbyUtiV6SeoBg3LJtMbg/U Pxr9avSaakQi3IQg/AP86tm0n2UnEFuOQwQPwMFfZi5C78PB3WF+1xhN2OCsUTB5 36s1yAyegH4nOlrsr8vwJCqpLgnFr2O9DovHQy9u2+jaunsq7vc8anbBSJYcrHr/ Q+48s+udFzmYy+hJ6SjhfDXHb1kQlzfKKZr00LUyidajd4PGHiXmFLBsJn5sAWu4 OhoeSerHOKFLAFt+izElhPu9yq1hGKneKpCCKET7ZZomejNjWgszN7a4+jh2NfnQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekuddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgv nhhgucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepheeluedtudffffegffeileettedvudeihefhvefgvdeivddttdeifeei geegveejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshhthigrnhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B787DA00079; Fri, 9 Apr 2021 04:57:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> In-Reply-To: References: <877dm9nsii.fsf@gmail.com> <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> Date: Fri, 09 Apr 2021 03:57:01 -0500 From: "Sheng Yang" To: "Drew Adams" , "Stefan Monnier" Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50; _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?= Content-Type: multipart/alternative; boundary=fe3f80cbb0984c43b668191968bd1984 X-Spam-Score: 1.1 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Any update/decision on this? The discussions have been inactive for more than 2 weeks. On Mon, Mar 22, 2021, at 16:36, Drew Adams wrote: > > > Can I ask what's wrong with what I suggested: One mode, not two; just > > > change the name and provide a helpful doc-string that covers both > [...] Content analysis details: (1.1 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [66.111.4.25 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (styang[at]fastmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [66.111.4.25 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 FROM_FMBLA_NEWDOM28 From domain was registered in last 14-28 days 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@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: -0.9 (/) --fe3f80cbb0984c43b668191968bd1984 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Any update/decision on this? The discussions have been inactive for more= than 2 weeks. On Mon, Mar 22, 2021, at 16:36, Drew Adams wrote: > > > Can I ask what's wrong with what I suggested: One mode, not two; j= ust > > > change the name and provide a helpful doc-string that covers both > > > active and inactive? > >=20 > > What's the benefit? Have you tried to implement it? >=20 > Is there really something to "implement"? >=20 > Rename `minibuffer-inactive-mode' to something > without "inactive". >=20 > Give it a doc string that says when inactive... > and when active.... We already have the former > part. The latter can just point out the keymaps > (which become links to their doc). >=20 > Benefit: Like what we have now - or after Alan's > change to fundamental-mode - but with better doc > and without a misleading mode name. >=20 > The behavior is already there, no? When inactive > we get the inactive key bindings. Otherwise, we > get the usual minibuffer keymaps. >=20 > IIUC, that's the case whether or not the "active" > state nominally uses `fundamental-mode', since the > minibuffer keymaps are still used. The difference > is (1) doc and (2) only one mode. >=20 > Feel free to let me know what I'm missing. >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --fe3f80cbb0984c43b668191968bd1984 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Any update/deci= sion on this? The discussions have been inactive for more than 2 weeks.<= br>

On Mon, Mar 22, 2021, at 16:36, Drew Adams = wrote:
>= > Can I ask what's wrong with what I suggested: One mode, not two; j= ust
> > change the name and provide a helpful doc-st= ring that covers both
> > active and inactive?
> 
> What's the benefit?  Have yo= u tried to implement it?

Is there really so= mething to "implement"?

Rename `minibuffer-= inactive-mode' to something
without "inactive".
<= div>
Give it a doc string that says when inactive...
and when active....  We already have the former
<= div>part.  The latter can just point out the keymaps
= (which become links to their doc).

Benefit:= Like what we have now - or after Alan's
change to fundame= ntal-mode - but with better doc
and without a misleading m= ode name.

The behavior is already there, no= ?  When inactive
we get the inactive key bindings.&nb= sp; Otherwise, we
get the usual minibuffer keymaps.

IIUC, that's the case whether or not the "active"=
state nominally uses `fundamental-mode', since the
minibuffer keymaps are still used.  The difference
is (1) doc and (2) only one mode.

Fee= l free to let me know what I'm missing.


She= ng Yang(=E6=9D=A8=E5=9C=A3), PhD
Compu= ter Science Department
University of M= aryland, College Park
E-mail: styang@fastmail.com
E-mail (old but still used): yangsheng6810@gmail.com


--fe3f80cbb0984c43b668191968bd1984-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 06:18:26 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 10:18:26 +0000 Received: from localhost ([127.0.0.1]:56576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVteE-00009n-0L for submit@debbugs.gnu.org; Mon, 12 Apr 2021 06:18:26 -0400 Received: from colin.muc.de ([193.149.48.1]:16033 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lVteB-00009Y-72 for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 06:18:23 -0400 Received: (qmail 75255 invoked by uid 3782); 12 Apr 2021 10:18:16 -0000 Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 12 Apr 2021 12:18:16 +0200 Received: (qmail 6728 invoked by uid 1000); 12 Apr 2021 10:18:15 -0000 Date: Mon, 12 Apr 2021 10:18:15 +0000 To: Sheng Yang Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Stefan Monnier , Drew Adams 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, Sheng. On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrote: > Any update/decision on this? The discussions have been inactive for more than 2 weeks. Sorry, I got distracted by another project which turned out to be bigger than expected. I will decide this, basically to follow Drew's suggestion, since he is the only one with strong views on the subject. What's more, I am now convinced he is right. ;-) To sum up, the minibuffer will always be in `minibuffer-mode', regardless of whether it is active or inactive. The minibuffer-mode key map will be in force for INactive MBs, the map supplied by the commands will be in force for active MBs. There will be compatibility aliases to `minibuffer-inactive-mode', etc. I think this will enable you to solve the problems you have. It will likely take me a few more days actually to implement this. [ .... ] > Sheng Yang(杨圣), PhD > Computer Science Department > University of Maryland, College Park > E-mail: styang@fastmail.com > E-mail (old but still used): yangsheng6810@gmail.com -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 08:02:46 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 12:02:46 +0000 Received: from localhost ([127.0.0.1]:56686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVvHB-000506-PY for submit@debbugs.gnu.org; Mon, 12 Apr 2021 08:02:46 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:52923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVvH9-0004zt-L3 for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 08:02:44 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2577A5C0049; Mon, 12 Apr 2021 08:02:38 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 12 Apr 2021 08:02:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=1pT7tRGBxKgbcP3gUQU4nFI41qpR8Lc R2D2Jrkwof2g=; b=f15BPg4iq8yBGQeYILzj4MepTceP9I9pE5+KUwLDnvhJe1A x+uBluWJvYTAcVCFpiPOS6+WcKe6oRfvfPmKtGC/bhdXCzyfXxjpdGnGqChdmOqH n0oMeBnJYuf3++v+HnM4b//SjBm5SUOPINNMCxNjsfJLSLnlfFXYlXvlTdGwAszk voKremAklL8pPKIAVcJoIi4/icwRnMLHc52E0AjiFbGIgzzEMBaKAUg7mhVzJsYZ 29zw/QaSsjLCe2aXVJFEMq6JWXJDHfM7jWHk1D/5T1ZurdnVq6NzBHK9/awaMHJY lhJS6OZ60QEzyAKqB721x2VBDhhyXfFb4PWUj2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1pT7tR GBxKgbcP3gUQU4nFI41qpR8LcR2D2Jrkwof2g=; b=InOffulwbNC58F/3oeAsst EyRGLgHn3E/EiTwZp9ee7TbdeBV4VrWyjqM0GoWA2kLwuChWdooPcZabOJiNj+RY VbiOhMH64yKwUMzqfj5JXNWlcYhjs22wjHMo8CU/4Nkr60uHuLmQWbYtgtRP2PfB VW6ZzccSIuX4Umz0Xkpn0ciBBh8Nluy+I4eJPJvfzpCKcsyX2hIqIy0ajC7PSp+E E+RgD4EACubqEHGcjOAFYTJYtw7C/zFibJXnfVQoTioTieznF48Lio+PHYMSeEmx 9inyPOROKySiESIcFaS/fg7EdWI1dPFzsTryHrApR/r3wZRUc4qI2jlp62qeX3GA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekjedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgv nhhgucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepheeluedtudffffegffeileettedvudeihefhvefgvdeivddttdeifeei geegveejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshhthigrnhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A5B85A00360; Mon, 12 Apr 2021 08:02:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> In-Reply-To: References: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> Date: Mon, 12 Apr 2021 07:02:16 -0500 From: "Sheng Yang" To: "Alan Mackenzie" Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50; _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?= Content-Type: multipart/alternative; boundary=05f223638e384f30bb46cbec1eacd7de X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Stefan Monnier , Drew Adams 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 (-) --05f223638e384f30bb46cbec1eacd7de Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick response! The changes sound good to me. On Mon, Apr 12, 2021, at 05:18, Alan Mackenzie wrote: > Hello, Sheng. >=20 > On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrote: > > Any update/decision on this? The discussions have been inactive for = more than 2 weeks. >=20 > Sorry, I got distracted by another project which turned out to be bigg= er > than expected. >=20 > I will decide this, basically to follow Drew's suggestion, since he is= > the only one with strong views on the subject. What's more, I am now > convinced he is right. ;-) >=20 > To sum up, the minibuffer will always be in `minibuffer-mode', regardl= ess > of whether it is active or inactive. The minibuffer-mode key map will= be > in force for INactive MBs, the map supplied by the commands will be in= > force for active MBs. There will be compatibility aliases to > `minibuffer-inactive-mode', etc. >=20 > I think this will enable you to solve the problems you have. >=20 > It will likely take me a few more days actually to implement this. >=20 > [ .... ] >=20 > > Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD > > Computer Science Department > > University of Maryland, College Park > > E-mail: styang@fastmail.com > > E-mail (old but still used): yangsheng6810@gmail.com >=20 > --=20 > Alan Mackenzie (Nuremberg, Germany). >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --05f223638e384f30bb46cbec1eacd7de Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for the = quick response! The changes sound good to me.

On Mon, Apr 12, 2021, at 05:18, Alan Mackenzie wrote:
Hello, Sheng.

On Fri, Apr 09, 2021 at 03:57:01 -0500, Sheng Yang wrot= e:
> Any update/decision on this? The discussions have = been inactive for more than 2 weeks.

Sorry,= I got distracted by another project which turned out to be bigger
than expected.

I will decide this,= basically to follow Drew's suggestion, since he is
the on= ly one with strong views on the subject.  What's more, I am now
=
convinced he is right.  ;-)

To sum up, the minibuffer will always be in `minibuffer-mode', regardle= ss
of whether it is active or inactive.  The minibuff= er-mode key map will be
in force for INactive MBs, the map= supplied by the commands will be in
force for active MBs.=   There will be compatibility aliases to
`minibuffer-= inactive-mode', etc.

I think this will enab= le you to solve the problems you have.

It w= ill likely take me a few more days actually to implement this.
=

[ .... ]

> Sheng Yan= g(=E6=9D=A8=E5=9C=A3), PhD
> Computer Science Departmen= t
> University of Maryland, College Park
> E-mail (old but still used): yangsheng6810@gmail.com
=

-- 
Alan Mackenzie (Nuremberg, Ge= rmany).


Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD=
Computer Science Department
=
University of Maryland, College Park
<= div class=3D"signature">E-mail: s= tyang@fastmail.com
E-mail (old but= still used): yangsheng6810@g= mail.com


=
--05f223638e384f30bb46cbec1eacd7de-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 10:01:43 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 14:01:43 +0000 Received: from localhost ([127.0.0.1]:57625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVx8J-0008Iw-Az for submit@debbugs.gnu.org; Mon, 12 Apr 2021 10:01:43 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVx8G-0008Ii-LY for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 10:01:41 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 53D5580531; Mon, 12 Apr 2021 10:01:35 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CE113801AB; Mon, 12 Apr 2021 10:01:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618236089; bh=48SMd8/6+TLB2hlqwSpcqEKg4Nl0bRNTXKUGzM92EuQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=O/aJaTe01m4Ooq6YrWT/ElxkK0+T1nTYOYq+wHtMW64D7qCKDMtryzSzoYIjFXyuR yvxe6RWVNwy7bCD/UCI+cMeJ1yoNmPw9Vf3l+eLu4YvTp00SQAzDMuPYDXyOHk0a4O KbiW1YKWfp5Gbr+IkpAyT6QhRcKaQXWTPxgf8ilqxWfmsZUkhpGqV7siWLJfzdWbw7 iAbVnH3cH4yNSabcIe73ucyKLSba6Py5VBtDDpHH5QNm/UhqTyZba4WHu1A/JpKMIR J2Yz29rVgu6oROfqIltYEw0V1OrjaFEWr9HhtKnySAcg5bR6x/i4s20JKwUR83gTIX P0z4aMUXa6GsA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92D20120867; Mon, 12 Apr 2021 10:01:29 -0400 (EDT) From: Stefan Monnier To: "Sheng Yang" Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <40f3c845-ba30-4112-bb3c-9c06c1f106d3@www.fastmail.com> <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Mon, 12 Apr 2021 10:01:28 -0400 In-Reply-To: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> (Sheng Yang's message of "Mon, 12 Apr 2021 07:02:16 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.050 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Drew Adams 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 (---) >> To sum up, the minibuffer will always be in `minibuffer-mode', regardless >> of whether it is active or inactive. > Please don't do that. Make `minibuffer-mode` be the *parent* mode, yes. But keep `minibuffer-inactive-mode` as a separate major mode. >> I think this will enable you to solve the problems you have. But it would be a regression since it would get rid of `minibuffer-inactive-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 12:15:31 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 16:15:31 +0000 Received: from localhost ([127.0.0.1]:57824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lVzDn-0003R1-1Q for submit@debbugs.gnu.org; Mon, 12 Apr 2021 12:15:31 -0400 Received: from colin.muc.de ([193.149.48.1]:25439 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lVzDl-0003Qo-JL for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 12:15:30 -0400 Received: (qmail 25399 invoked by uid 3782); 12 Apr 2021 16:15:22 -0000 Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 12 Apr 2021 18:15:22 +0200 Received: (qmail 8223 invoked by uid 1000); 12 Apr 2021 16:15:22 -0000 Date: Mon, 12 Apr 2021 16:15:22 +0000 To: Stefan Monnier Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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, Stefan. On Mon, Apr 12, 2021 at 10:01:28 -0400, Stefan Monnier wrote: > >> To sum up, the minibuffer will always be in `minibuffer-mode', > >> regardless of whether it is active or inactive. > Please don't do that. Make `minibuffer-mode` be the *parent* mode, yes. > But keep `minibuffer-inactive-mode` as a separate major mode. Why? Until very recently (? 2 months ago), minibuffer-inactive-mode served for both active and inactive MBs. The idea is simply to rename that mode to minibuffer-mode (with aliases for the old names). The idea here is to avoid the proliferation of unneeded major modes. We don't seem to need two distinct modes here for the minibuffer. > >> I think this will enable you to solve the problems you have. > But it would be a regression since it would get rid of > `minibuffer-inactive-mode`. No, it would rename it; the only difference between -active- and -inactive- would be the local key map in force. This would revert to minibuffer-mode-map (formerly known as ...-inactive-...) at the termination of the minibuffer operation. This is pretty much, but not quite, the same as how things were up until recently. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 13:11:13 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 17:11:13 +0000 Received: from localhost ([127.0.0.1]:57943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lW05h-0004sH-Dg for submit@debbugs.gnu.org; Mon, 12 Apr 2021 13:11:13 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lW05g-0004s5-7T for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 13:11:12 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 87F168081F; Mon, 12 Apr 2021 13:11:06 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7809780531; Mon, 12 Apr 2021 13:11:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618247464; bh=gPGZhxUILV+4RpmllZZJf2fahGZ/yn7yNYwAC39OBS4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GzQY3KHoCozJKDQFW5CC3rxAZNq1ACmK0CLzTJ9D/G8tyoqp5JwUpGJPgN/0chC5Y K9zT4Pgx2r91xaNB4oCT3sZo3at0D45v8oOh0907Or+vOyqu+Yk6TX2rN8aja4SX6F 7OE8eUhht0aDHMX8Wdk+850mHIe2ViNWkg1GkCITC371RcNTgDGX0g7skXGq9l1tt/ vhSIp5MQNsbXaCh/RBgVVftpHRje2MGLUoraf0cJEtkGmSE63RqoXzZkh09iBNosZd iXrMr8Vex4FS1Ola520PVop55bOCGLgIuPw0+FAMlWd0QCZ7V8uXz/dB0xHpkFpm/q YAdYTz94T7Jfw== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18698120315; Mon, 12 Apr 2021 13:11:04 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Mon, 12 Apr 2021 13:10:57 -0400 In-Reply-To: (Alan Mackenzie's message of "Mon, 12 Apr 2021 16:15:22 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.049 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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 (---) > Why? Until very recently (? 2 months ago), minibuffer-inactive-mode > served for both active and inactive MBs. No: it was *activated* every time the minibuffer became inactive (and not when the minibuffer was becoming active), and its keymap was only active when the minibuffer was inactive. The keymap and the hook are the main two features of `minibuffer-inactive-mode`. > The idea here is to avoid the proliferation of unneeded major modes. Major modes are cheap. There is no problem with proliferation. > We don't seem to need two distinct modes here for the minibuffer. The two situations are very different, where the users expect very different behavior. > This is pretty much, but not quite, the same as how things were up until > recently. No, it's completely different: the difference may seem minor, but this minor reason is the raison d'=EAtre of `minibuffer-inactive-mode`, so what you're suggesting is, in practice, the removal of `minibuffer-inactive-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 14:34:44 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 18:34:44 +0000 Received: from localhost ([127.0.0.1]:58061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lW1OW-0000Z6-Dq for submit@debbugs.gnu.org; Mon, 12 Apr 2021 14:34:44 -0400 Received: from colin.muc.de ([193.149.48.1]:28863 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lW1OU-0000Yr-6r for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 14:34:42 -0400 Received: (qmail 19682 invoked by uid 3782); 12 Apr 2021 18:34:35 -0000 Received: from acm.muc.de (p4fe15ca4.dip0.t-ipconnect.de [79.225.92.164]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 12 Apr 2021 20:34:35 +0200 Received: (qmail 8819 invoked by uid 1000); 12 Apr 2021 18:34:34 -0000 Date: Mon, 12 Apr 2021 18:34:34 +0000 To: Stefan Monnier Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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, Stefan. On Mon, Apr 12, 2021 at 13:10:57 -0400, Stefan Monnier wrote: > > Why? Until very recently (? 2 months ago), minibuffer-inactive-mode > > served for both active and inactive MBs. > No: it was *activated* every time the minibuffer became inactive (and > not when the minibuffer was becoming active), and its keymap was only > active when the minibuffer was inactive. OK, what you say is true, what I said above is also true - active minibuffers ran in minibuffer-inactive-mode (apart from the first invocation of a MB), getting their key maps from the calling Lisp commands. At the end of the MB action m-inactive-m was called. > The keymap and the hook are the main two features of > `minibuffer-inactive-mode`. Yes. Possibly they're the only features. Am I right in thinking that your main worry is the hook not getting called at the end of every MB action? > > The idea here is to avoid the proliferation of unneeded major modes. > Major modes are cheap. There is no problem with proliferation. That's not true - the OP has found a problem, in that some minor modes switch themselves on when (memq major-mode foo-mode-list). The current situation, fundamental-mode (active), minibuffer-inactive-mode (inactive) is causing problems with that scheme, hence this bug. > > We don't seem to need two distinct modes here for the minibuffer. > The two situations are very different, where the users expect very > different behavior. They are indeed very different, but that difference is entirely accounted for by the key map (and optionally, the mode hook). > > This is pretty much, but not quite, the same as how things were up until > > recently. > No, it's completely different: the difference may seem minor, but > this minor reason is the raison d'tre of `minibuffer-inactive-mode`, so > what you're suggesting is, in practice, the removal of > `minibuffer-inactive-mode`. I don't think that's right. What I'm proposing is renaming it (with temporary alias), and regularising what used to be an ugly situation. How about having just minibuffer-mode, and calling it at the end of every MB action (as was previously done with minibuffer-inactive-mode), but not at the start of a MB action? This will call the mode hook at the same times as the m-inactive-m-hook used to be called, and reset the MB's keymap to the inactive map at the same time. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 12 16:46:50 2021 Received: (at 47150) by debbugs.gnu.org; 12 Apr 2021 20:46:50 +0000 Received: from localhost ([127.0.0.1]:58220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lW3SL-0007ZD-HS for submit@debbugs.gnu.org; Mon, 12 Apr 2021 16:46:50 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lW3SJ-0007U3-Sh for 47150@debbugs.gnu.org; Mon, 12 Apr 2021 16:46:48 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 550671001D2; Mon, 12 Apr 2021 16:46:42 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 170AD100040; Mon, 12 Apr 2021 16:46:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618260396; bh=nK4/7wcElqujNXZfLAwpuU8FyUh5DlBokFvF2tOvnVY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=DaRXj00Pl/yvCMqTazAaog1uKIlLZgjxmv0ZwaE0DRRj+CivHFb02+qJ9Q5Jj6qrp lQkgeeC/c/y3tNFsJqXFhVv2sgQasp5+B9/LhLtj3ZTzghNaYUhVhwDaUp7u2tBEOs +PbR2GHHaDNHmfEdhWTgruJ1W80Q5smLacE+E6yMP8V8pi50XT8eA53HeK2OZGfP+s +GNk7R1uLk9GKyavoCZOsvRPTuQ9AobOIufTX0/P/5ahkbL3CU7JCqEguFhLiFmgC2 OpCOyUsa/wSikeVEz8Cx7L161KExsFdzSb0HyoXFx8TcKjxoJPVt4VmQgdRT/LNpjB nwGib/UsJZCFA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8FAAD1204F6; Mon, 12 Apr 2021 16:46:35 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Mon, 12 Apr 2021 16:46:34 -0400 In-Reply-To: (Alan Mackenzie's message of "Mon, 12 Apr 2021 18:34:34 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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 (---) > OK, what you say is true, what I said above is also true - active > minibuffers ran in minibuffer-inactive-mode That was true "in name only" (i.e. only the value of the variable `major-mode` reflected that). >> The keymap and the hook are the main two features of >> `minibuffer-inactive-mode`. > Yes. Possibly they're the only features. Pretty much, yes. > Am I right in thinking that your main worry is the hook not getting > called at the end of every MB action? No. My worries are: - not having the minibuffer-inactive-mode-map active when the minibuffer is inactive. - running minibuffer-inactive-mode-hook at other times than when the minibuffer becomes inactive. >> > The idea here is to avoid the proliferation of unneeded major modes. >> Major modes are cheap. There is no problem with proliferation. > That's not true - the OP has found a problem, in that some minor modes > switch themselves on when (memq major-mode foo-mode-list). > The current situation, fundamental-mode (active), > minibuffer-inactive-mode (inactive) is causing problems with that > scheme, hence this bug. Their code was buggy/naive, will be broken no matter what we choose to do (except for sticking to what we had in Emacs<28), and is easy to fix in a backward compatible way using `minibufferp`. So I don't think this matters very much. Most cases of (eq major-mode ) are bugs waiting to bite you. > How about having just minibuffer-mode, and calling it at the end of > every MB action (as was previously done with minibuffer-inactive-mode), > but not at the start of a MB action? This will call the mode hook at > the same times as the m-inactive-m-hook used to be called, and reset the > MB's keymap to the inactive map at the same time. IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode` and calling it one extra time at the very beginning? Technically, it won't break any of my uses, of course, but then it leads to rather counter-intuitive situations where "the keymap of `minibuffer-mode`" is almost never used (it's only active when the minibuffer is inactive), "the hook of `minibuffer-mode`" is run not when entering a minibuffer but when leaving it, ... Also, there's a natural desire to occasionally use other major modes in the minibuffer (e.g. for `M-:`), so it would be very natural to make them derived modes of `minibuffer-mode` except that it would then inherit from a keymap which makes no sense in an active minibuffer. It just doesn't seem right at all. What's wrong with just making a new mode (define-derived-mode minibuffer-mode nil "Minibuffer" "Mode used inside minibuffers.") and using that instead of `fundamental-mode`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 18 07:14:31 2021 Received: (at 47150) by debbugs.gnu.org; 18 Apr 2021 11:14:31 +0000 Received: from localhost ([127.0.0.1]:45569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY5Nn-0003J1-CN for submit@debbugs.gnu.org; Sun, 18 Apr 2021 07:14:31 -0400 Received: from colin.muc.de ([193.149.48.1]:61075 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lY5Nl-0003Ih-Hp for 47150@debbugs.gnu.org; Sun, 18 Apr 2021 07:14:30 -0400 Received: (qmail 85197 invoked by uid 3782); 18 Apr 2021 11:14:21 -0000 Received: from acm.muc.de (p2e5d56e2.dip0.t-ipconnect.de [46.93.86.226]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 18 Apr 2021 13:14:21 +0200 Received: (qmail 6152 invoked by uid 1000); 18 Apr 2021 11:14:20 -0000 Date: Sun, 18 Apr 2021 11:14:20 +0000 To: Stefan Monnier Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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, Stefan. On Mon, Apr 12, 2021 at 16:46:34 -0400, Stefan Monnier wrote: [ .... ] > > Am I right in thinking that your main worry is the hook not getting > > called at the end of every MB action? > No. My worries are: > - not having the minibuffer-inactive-mode-map active when the minibuffer > is inactive. > - running minibuffer-inactive-mode-hook at other times than when the > minibuffer becomes inactive. > >> > The idea here is to avoid the proliferation of unneeded major modes. > >> Major modes are cheap. There is no problem with proliferation. > > That's not true - the OP has found a problem, in that some minor modes > > switch themselves on when (memq major-mode foo-mode-list). > > The current situation, fundamental-mode (active), > > minibuffer-inactive-mode (inactive) is causing problems with that > > scheme, hence this bug. > Their code was buggy/naive, will be broken no matter what we choose > to do (except for sticking to what we had in Emacs<28), and is easy to > fix in a backward compatible way using `minibufferp`. This would make a special case of minibuffer_mode, which would require minibufferp, when other modes would be matched with (memq major-mode foo-list). > So I don't think this matters very much. This was the meat of the OP's bug report. ;-) > Most cases of (eq major-mode ) are bugs waiting to bite you. I don't see this at the moment, but I won't ask you to elaborate here and now. > > How about having just minibuffer-mode, and calling it at the end of > > every MB action (as was previously done with > > minibuffer-inactive-mode), but not at the start of a MB action? > > This will call the mode hook at the same times as the > > m-inactive-m-hook used to be called, and reset the MB's keymap to > > the inactive map at the same time. > IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode` and > calling it one extra time at the very beginning? Yes. It's that "one extra time at the very beginning" which makes it nasty. :-( > Technically, it won't break any of my uses, of course, but then it leads > to rather counter-intuitive situations where "the keymap of > `minibuffer-mode`" is almost never used (it's only active when the > minibuffer is inactive), "the hook of `minibuffer-mode`" is run not when > entering a minibuffer but when leaving it, ... > Also, there's a natural desire to occasionally use other major modes in > the minibuffer (e.g. for `M-:`), so it would be very natural to make > them derived modes of `minibuffer-mode` except that it would then > inherit from a keymap which makes no sense in an active minibuffer. > It just doesn't seem right at all. Yes, it has disadvantages. You're right. > What's wrong with just making a new mode > (define-derived-mode minibuffer-mode nil "Minibuffer" > "Mode used inside minibuffers.") > and using that instead of `fundamental-mode`. The scheme you propose, having two modes minibuffer-\(inactive-\)?mode also has disadvantages, pointed out by Drew in his post in this thread from Date: Mon, 22 Mar 2021 17:09:32 +0000 - minibuffer-mode would be a useless mode, just a placeholder; it has a key map, a syntax table, an abbreviation table which will never be used (OK, some of these can be specified nil in define-derived-mode), a redundant mode hook (there exist minibuffer-setup-hook and minibuffer-exit-hook). These can surely only cause trouble down the line. So Drew is right, too. The problem is, we're in an anomalous situation. Major modes aren't really the right tool for the minibuffer, but not using major modes isn't any better. Anything we do here is bad. :-( Over the past few days, I've come to the conclusion that having two modes for the minibuffer is the lesser evil than having just one mode whose mode function would be called at the end of a minibuffer use. The deciding criterion, which might seem minor, is that with the one mode, we'd have to call it "one extra time at the very beginning" as discussed above. So I intend to leave minibuffer-inactive-mode more or less alone, and to implement minibuffer-mode, which will get called at the start of each minibuffer use, flushing out old stuff from any previous minibuffer (non-)use. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 18 11:22:28 2021 Received: (at 47150) by debbugs.gnu.org; 18 Apr 2021 15:22:28 +0000 Received: from localhost ([127.0.0.1]:47440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY9Fk-0003RD-EL for submit@debbugs.gnu.org; Sun, 18 Apr 2021 11:22:28 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY9Fi-0003Qo-OL for 47150@debbugs.gnu.org; Sun, 18 Apr 2021 11:22:27 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4541210022F; Sun, 18 Apr 2021 11:22:21 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9EE7F10021B; Sun, 18 Apr 2021 11:22:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618759339; bh=hFVOC11IPSz0KYesdMqkpDYODOL+Raen3ALPU9gIyDw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=jSshPMg99743FWDIgAXAPlCC71OPzhjEFMUIVwgYpDMwC7hBhJJf1PoWRZv5JXjfr +HtgrzsQM5JZlxSs1UcBY5OY/SxHme1ymc91veepVPx9zFNrb55v/ldov3zorpeoIq UGicMixDbSeD72F9eA6v6ERpOrh1nl0donVKy5MaoQd4dxwVEbU8WPwssIHIb22qrM i9wbVG/oVNiPYssHGJH7Oom+8asuKl5t1pbEI7Ry6w3Pkxbl9ciXevo48FsfUqeVuP frKQpq81DnYAbK80HTleOwU677s4+c4Rf2fLp9ADcuuX7AzyuxNV/imOXK1zjy7jV4 scYI4dnZZVY7Q== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5EFDD1201FF; Sun, 18 Apr 2021 11:22:19 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Sun, 18 Apr 2021 11:22:18 -0400 In-Reply-To: (Alan Mackenzie's message of "Sun, 18 Apr 2021 11:14:20 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.023 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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 (---) >> Their code was buggy/naive, will be broken no matter what we choose >> to do (except for sticking to what we had in Emacs<28), and is easy to >> fix in a backward compatible way using `minibufferp`. > This would make a special case of minibuffer_mode, which would require > minibufferp, when other modes would be matched with (memq major-mode > foo-list). No, you could also use (derived-mode-p ) instead of (minibufferp). >> > How about having just minibuffer-mode, and calling it at the end of >> > every MB action (as was previously done with >> > minibuffer-inactive-mode), but not at the start of a MB action? >> > This will call the mode hook at the same times as the >> > m-inactive-m-hook used to be called, and reset the MB's keymap to >> > the inactive map at the same time. >> IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode` and >> calling it one extra time at the very beginning? > Yes. It's that "one extra time at the very beginning" which makes it > nasty. :-( Could you explain the problem you see with calling it one extra time? > The scheme you propose, having two modes minibuffer-\(inactive-\)?mode > also has disadvantages, pointed out by Drew in his post in this thread > from Date: Mon, 22 Mar 2021 17:09:32 +0000 - minibuffer-mode would be a > useless mode, just a placeholder; it has a key map, a syntax table, an > abbreviation table which will never be used (OK, some of these can be > specified nil in define-derived-mode), a redundant mode hook (there > exist minibuffer-setup-hook and minibuffer-exit-hook). These can surely > only cause trouble down the line. So Drew is right, too. These "extras" haven't caused any trouble in all the other major modes where they're not used (including minibuffer-inactive-mode), so it seems to me like you're worried about something perfectly harmless. > The problem is, we're in an anomalous situation. Major modes aren't > really the right tool for the minibuffer, but not using major modes > isn't any better. Anything we do here is bad. :-( I disagree. The minibuffers are normal buffers, and the more normal we can make them, the better. Clearly, the major modes that make sense in a minibuffer will almost invariably be different from the major modes that make sense in other buffers, but that doesn't mean that the concept of "major mode" is wrong for minibuffers. Not at all. On the contrary, from where I stand, it is The Right Thing. I'd argue that we're de-facto already using major modes, just without the advantages that come from having conventions. E.g. `minibuffer-setup-hook` is the hook for the "parent major mode" of all the minibuffer "major modes". The `minibuffer-*-map` are the keymaps of the various different "major modes". The advantages we can gain by bringing the conventions of "real" major modes would be for example that `C-h m` would give useful information when used in the minibuffer. > Over the past few days, I've come to the conclusion that having two > modes for the minibuffer is the lesser evil than having just one mode > whose mode function would be called at the end of a minibuffer use. The > deciding criterion, which might seem minor, is that with the one mode, > we'd have to call it "one extra time at the very beginning" as discussed > above. > > So I intend to leave minibuffer-inactive-mode more or less alone, and to > implement minibuffer-mode, which will get called at the start of each > minibuffer use, flushing out old stuff from any previous minibuffer > (non-)use. Sounds good to me ;-) Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 05:33:14 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 09:33:14 +0000 Received: from localhost ([127.0.0.1]:48448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYQHK-0005Mb-AX for submit@debbugs.gnu.org; Mon, 19 Apr 2021 05:33:14 -0400 Received: from colin.muc.de ([193.149.48.1]:18704 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lYQHI-0005MN-FR for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 05:33:13 -0400 Received: (qmail 3532 invoked by uid 3782); 19 Apr 2021 09:33:05 -0000 Received: from acm.muc.de (p4fe15b44.dip0.t-ipconnect.de [79.225.91.68]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 19 Apr 2021 11:33:05 +0200 Received: (qmail 4989 invoked by uid 1000); 19 Apr 2021 09:33:04 -0000 Date: Mon, 19 Apr 2021 09:33:04 +0000 To: Stefan Monnier Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <0f564ae1-ab0a-4e0f-a436-68f29b71d8a9@www.fastmail.com> <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, acm@muc.de, Sheng Yang , Drew Adams 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, Stefan. On Sun, Apr 18, 2021 at 11:22:18 -0400, Stefan Monnier wrote: > >> Their code was buggy/naive, will be broken no matter what we choose > >> to do (except for sticking to what we had in Emacs<28), and is easy > >> to fix in a backward compatible way using `minibufferp`. > > This would make a special case of minibuffer_mode, which would > > require minibufferp, when other modes would be matched with (memq > > major-mode foo-list). > No, you could also use (derived-mode-p ) instead of > (minibufferp). I can't see how that's different in principle from (memq major-mode foo-list). But that's probably not important any more. > >> > How about having just minibuffer-mode, and calling it at the end > >> > of every MB action (as was previously done with > >> > minibuffer-inactive-mode), but not at the start of a MB action? > >> > This will call the mode hook at the same times as the > >> > m-inactive-m-hook used to be called, and reset the MB's keymap to > >> > the inactive map at the same time. > >> IOW just renaming `minibuffer-inactive-mode` to `minibuffer-mode` > >> and calling it one extra time at the very beginning? > > Yes. It's that "one extra time at the very beginning" which makes > > it nasty. :-( > Could you explain the problem you see with calling it one extra time? That extra time would be calling it just before the MB gets used. Every other call to minibuffer-mode would be just after MB use. This is ugly, and one way or another, would be bound to cause problems. > > The scheme you propose, having two modes > > minibuffer-\(inactive-\)?mode also has disadvantages, pointed out by > > Drew in his post in this thread from Date: Mon, 22 Mar 2021 17:09:32 > > +0000 - minibuffer-mode would be a useless mode, just a placeholder; > > it has a key map, a syntax table, an abbreviation table which will > > never be used (OK, some of these can be specified nil in > > define-derived-mode), a redundant mode hook (there exist > > minibuffer-setup-hook and minibuffer-exit-hook). These can surely > > only cause trouble down the line. So Drew is right, too. > These "extras" haven't caused any trouble in all the other major modes > where they're not used (including minibuffer-inactive-mode), so it seems > to me like you're worried about something perfectly harmless. Maybe they won't cause trouble, but they can't do anything positive. That was what I meant by "only". :-) > > The problem is, we're in an anomalous situation. Major modes aren't > > really the right tool for the minibuffer, but not using major modes > > isn't any better. Anything we do here is bad. :-( > I disagree. The minibuffers are normal buffers, and the more normal we > can make them, the better. Clearly, the major modes that make sense in > a minibuffer will almost invariably be different from the major modes > that make sense in other buffers, but that doesn't mean that the concept > of "major mode" is wrong for minibuffers. Not at all. > On the contrary, from where I stand, it is The Right Thing. OK, please add an IMHO to my last paragraph. While hacking minibuf.c, the major mode stuff didn't feel natural to me. It felt like something forced into something which didn't need it. That's just my view on it. > I'd argue that we're de-facto already using major modes, just without > the advantages that come from having conventions. > E.g. `minibuffer-setup-hook` is the hook for the "parent major mode" > of all the minibuffer "major modes". The `minibuffer-*-map` are the > keymaps of the various different "major modes". > The advantages we can gain by bringing the conventions of "real" major > modes would be for example that `C-h m` would give useful information > when used in the minibuffer. I posted a patch for this yesterday. In the documentation bit, I strongly advised against using minibuffer-mode-hook, instead directing users to minibuffer-setup-hook and minibuffer-exit-hook. Was this the right thing to write? > > Over the past few days, I've come to the conclusion that having two > > modes for the minibuffer is the lesser evil than having just one > > mode whose mode function would be called at the end of a minibuffer > > use. The deciding criterion, which might seem minor, is that with > > the one mode, we'd have to call it "one extra time at the very > > beginning" as discussed above. > > So I intend to leave minibuffer-inactive-mode more or less alone, > > and to implement minibuffer-mode, which will get called at the start > > of each minibuffer use, flushing out old stuff from any previous > > minibuffer (non-)use. > Sounds good to me ;-) Excellent! We've disagreed about a few things, but in the end they've made no difference to the changes to be made. :-) As I said, I posted a patch yesterday. We'll see how much reaction there is to it, and after dealing with that reaction I'll commit the patch and close the bug. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 13:30:44 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 17:30:44 +0000 Received: from localhost ([127.0.0.1]:51932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYXjP-0006c7-K6 for submit@debbugs.gnu.org; Mon, 19 Apr 2021 13:30:44 -0400 Received: from colin.muc.de ([193.149.48.1]:34097 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lYXjJ-0006bn-Kh for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 13:30:42 -0400 Received: (qmail 41226 invoked by uid 3782); 19 Apr 2021 17:30:30 -0000 Received: from acm.muc.de (p4fe15b44.dip0.t-ipconnect.de [79.225.91.68]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 19 Apr 2021 19:30:30 +0200 Received: (qmail 1862 invoked by uid 1000); 19 Apr 2021 17:30:30 -0000 Date: Mon, 19 Apr 2021 17:30:30 +0000 To: Stefan Monnier Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> 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: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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, everybody. On Mon, Apr 19, 2021 at 09:33:04 +0000, Alan Mackenzie wrote: [ .... ] > I posted a patch for this yesterday. In the documentation bit, I > strongly advised against using minibuffer-mode-hook, instead directing > users to minibuffer-setup-hook and minibuffer-exit-hook. Was this the > right thing to write? Apologies. That post didn't make it out, after all. Here is the patch I meant to send. I invite Sheng, in particular, to report how well it fixes the bug. Thanks! diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi index 1eba7074f7..6f2935f1f6 100644 --- a/doc/emacs/mini.texi +++ b/doc/emacs/mini.texi @@ -247,6 +247,9 @@ Minibuffer Edit to show the current recursion depth in the minibuffer prompt on recursive use of the minibuffer. + When active, the minibuffer is in @code{minibuffer-mode}. This is +an internal Emacs mode without any features for the user. + @findex minibuffer-inactive-mode When not active, the minibuffer is in @code{minibuffer-inactive-mode}, and clicking @kbd{mouse-1} there shows the @file{*Messages*} buffer. diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi index d16409d6c8..edb46bbefe 100644 --- a/doc/lispref/minibuf.texi +++ b/doc/lispref/minibuf.texi @@ -97,6 +97,13 @@ Intro to Minibuffers minibuffer local maps. @xref{Completion Commands}, for the minibuffer local maps for completion. +@cindex active minibuffer + An active minibuffer has major mode @code{minibuffer-mode}. This is +an Emacs internal mode, and there is never any point in calling it or +otherwise trying to manipulate it. Rather than using +@code{minibuffer-mode-hook}, you should use +@code{minibuffer-setup-hook} (@pxref{Minibuffer Misc}). + @cindex inactive minibuffer When a minibuffer is inactive, its major mode is @code{minibuffer-inactive-mode}, with keymap diff --git a/etc/NEWS b/etc/NEWS index b641e8d95f..3e5767c953 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -2392,6 +2392,10 @@ This affects the suffix specified by completion 'annotation-function'. ** 'set-process-buffer' now updates the process mark. The mark will be set to point to the end of the new buffer. ++++ +** An active minibuffer now has major mode 'minibuffer-mode', not the +erroneous 'minibuffer-inactive-mode' it formerly had. + +++ ** Some properties from completion tables are now preserved. If 'minibuffer-allow-text-properties' is non-nil, doing completion diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index c900b0d7ce..1a719a12cc 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2474,6 +2474,16 @@ minibuffer-inactive-mode "Major mode to use in the minibuffer when it is not active. This is only used when the minibuffer area has no active minibuffer.") +(define-derived-mode minibuffer-mode nil "Minibuffer" + "Major mode used only in active minibuffers. +This mode is used internally, and should not be set by user code +in any way, although it may be tested by such code. Use +`minibuffer-setup-hook' and `minibuffer-exit-hook' rather than +the mode hook of this mode." + :syntax-table nil + :abbrev-table nil + :interactive nil) + ;;; Completion tables. (defun minibuffer--double-dollars (str) diff --git a/src/minibuf.c b/src/minibuf.c index a3c1b99bf3..439addc9a9 100644 --- a/src/minibuf.c +++ b/src/minibuf.c @@ -567,7 +567,7 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, in previous recursive minibuffer, but was not set explicitly to t for this invocation, so set it to nil in this minibuffer. Save the old value now, before we change it. */ - specbind (intern ("minibuffer-completing-file-name"), + specbind (Qminibuffer_completing_file_name, Vminibuffer_completing_file_name); if (EQ (Vminibuffer_completing_file_name, Qlambda)) Vminibuffer_completing_file_name = Qnil; @@ -920,13 +920,13 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt, && !EQ (XWINDOW (XFRAME (calling_frame)->minibuffer_window) ->frame, calling_frame)))) - call2 (intern ("select-frame-set-input-focus"), calling_frame, Qnil); + call2 (Qselect_frame_set_input_focus, calling_frame, Qnil); /* Add the value to the appropriate history list, if any. This is done after the previous buffer has been made current again, in case the history variable is buffer-local. */ if (! (NILP (Vhistory_add_new_input) || NILP (histstring))) - call2 (intern ("add-to-history"), histvar, histstring); + call2 (Qadd_to_history, histvar, histstring); /* If Lisp form desired instead of string, parse it. */ if (expflag) @@ -965,13 +965,13 @@ set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth) Fset_buffer (buf); if (depth > 0) { - if (!NILP (Ffboundp (intern ("fundamental-mode")))) - call0 (intern ("fundamental-mode")); + if (!NILP (Ffboundp (Qminibuffer_mode))) + call0 (Qminibuffer_mode); } else { - if (!NILP (Ffboundp (intern ("minibuffer-inactive-mode")))) - call0 (intern ("minibuffer-inactive-mode")); + if (!NILP (Ffboundp (Qminibuffer_inactive_mode))) + call0 (Qminibuffer_inactive_mode); else Fkill_all_local_variables (); } @@ -1163,7 +1163,7 @@ read_minibuf_unwind (void) dead, we may keep displaying this buffer (tho it's inactive), so reset it, to make sure we don't leave around bindings and stuff which only made sense during the read_minibuf invocation. */ - call0 (intern ("minibuffer-inactive-mode")); + call0 (Qminibuffer_inactive_mode); /* We've exited the recursive edit, so switch the current windows away from the expired minibuffer window, both in the current @@ -2332,6 +2332,12 @@ syms_of_minibuf (void) /* A frame parameter. */ DEFSYM (Qminibuffer_exit, "minibuffer-exit"); + DEFSYM (Qminibuffer_mode, "minibuffer-mode"); + DEFSYM (Qminibuffer_inactive_mode, "minibuffer-inactive-mode"); + DEFSYM (Qminibuffer_completing_file_name, "minibuffer-completing-file-name"); + DEFSYM (Qselect_frame_set_input_focus, "select-frame-set-input-focus"); + DEFSYM (Qadd_to_history, "add-to-history"); + DEFVAR_LISP ("read-expression-history", Vread_expression_history, doc: /* A history list for arguments that are Lisp expressions to evaluate. For example, `eval-expression' uses this. */); [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 14:22:37 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 18:22:37 +0000 Received: from localhost ([127.0.0.1]:52040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYXd-0007xe-7L for submit@debbugs.gnu.org; Mon, 19 Apr 2021 14:22:37 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYYXY-0007wx-A8 for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 14:22:32 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A725A807A1; Mon, 19 Apr 2021 14:22:26 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 144E480810; Mon, 19 Apr 2021 14:22:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618856545; bh=3imCqgIFIAWtpk/qlhYVIbyNmwE8hsYvjcHnJJ5lb/0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KSEbaj62eXGNhDLgkpnEBXIjzbwIjVXjKrh73MqZ/I+2t0uDAZu7pN+EE1OGwDXHO kFF90WWs4jJtyJJPhFR4rkM93givcQwq7JfZ65s2gvvNAOkhOTByur+e5ikELtQjiR 5OaYaysmg6v/yGWfpE5BpKwCCVEzVscjPOJW6chFpCvxyyu5LeUIthWnsZ9Bm8QCV1 wyE6SWVXJisCMD5hZMspGwA3bR4gFQUlRk45zO32LOy4XEl5D/c97IesNSfyxhT0xQ XiM9KGQ5sYGo+4BZOaXP6LovaYz/goNDg+76EqlWBzJeNSimDhWV49fogxcT8NGM7O L/XVyS2tptyvQ== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3CF512020E; Mon, 19 Apr 2021 14:22:24 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Mon, 19 Apr 2021 14:22:23 -0400 In-Reply-To: (Alan Mackenzie's message of "Mon, 19 Apr 2021 17:30:30 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.053 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Sheng Yang , Drew Adams 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 (---) > diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi > index 1eba7074f7..6f2935f1f6 100644 > --- a/doc/emacs/mini.texi > +++ b/doc/emacs/mini.texi > @@ -247,6 +247,9 @@ Minibuffer Edit > to show the current recursion depth in the minibuffer prompt > on recursive use of the minibuffer. > > + When active, the minibuffer is in @code{minibuffer-mode}. This is > +an internal Emacs mode without any features for the user. I don't think we should be so definitive about it (I don't think we should consider it a bug if some package decides to change the major mode to something else from `minibuffer-setup-hook`, for instance). So, I'd either not document it at all, or add something like "usually" in there to tone things down. > +@cindex active minibuffer > + An active minibuffer has major mode @code{minibuffer-mode}. This is > +an Emacs internal mode, and there is never any point in calling it or > +otherwise trying to manipulate it. I don't see the point in trying to discourage people from using it: I don't see any reason to expect uses to be harmful, nor do I see any sign that hordes are just waiting to jump on the opportunity to (ab)use this mode in unexpected ways. > Rather than using > +@code{minibuffer-mode-hook}, you should use > +@code{minibuffer-setup-hook} (@pxref{Minibuffer Misc}). Sounds fine. We may even motivate it by explaining that at the time `minibuffer-mode-hook` is run the (mini)buffer is not yet fully prepared (e.g. the keymap is not yet set). > +(define-derived-mode minibuffer-mode nil "Minibuffer" > + "Major mode used only in active minibuffers. > +This mode is used internally, and should not be set by user code > +in any way, although it may be tested by such code. Use > +`minibuffer-setup-hook' and `minibuffer-exit-hook' rather than > +the mode hook of this mode." Same here, I don't see the need to waste time discouraging people to set it themselves. Other than those nitpicks: LGTM, thank you, Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 15:19:00 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 19:19:00 +0000 Received: from localhost ([127.0.0.1]:52124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZQB-0000vt-Kp for submit@debbugs.gnu.org; Mon, 19 Apr 2021 15:19:00 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:56487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZQ9-0000vd-6U for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 15:18:58 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E253A5C00B1; Mon, 19 Apr 2021 15:18:51 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 19 Apr 2021 15:18:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=cYI7QiLBDxDqkeCpBVHTiXP9bAiBM/w hxp+C+vaUS5k=; b=lRIQsKoOfLao4GP3+J6Ja0i4E68dNdDvf0VdKXKUHpP/onU 3LmcCtg8fO3gSoGQtMvcOKFgpcPQQl/9SeIRFFEc9TOC2b8SETERajoD5ENGTgSv HySTbQ+AccUZKe1SAiupX/HXiBREvaKy9bGrTCn6DnrdyThnNsLil4iaaLRoNO0F Ikb7CQyMFIqvLDq7urccZTY8EJSFNEZtiH2WpmORZLuJP9J62QEuiUmGl11qYtpM WlmYevE7R9uYqiU+foC+MKRCEhP+F0L4DSje7CZ/OIkqd7qwZQSQDmLQVCdZ/Ox/ 074O+IJpyiRtmZ7YCvdAX3iSG1J5i4PTmO2RM2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=cYI7Qi LBDxDqkeCpBVHTiXP9bAiBM/whxp+C+vaUS5k=; b=k70H4JTrLpMXx9dKvyJE/M C97s6cu5F3VRtkl0uX1cBpNeg2OoQKhezvnCTaK/u0aUkFEQltsXf5AevPIZ7vDv jwrrc2SAkwm/oxMerX/3aMn1kfvEsQqRiYN/nujdjyNRna2PTEziKRtdPgDJ5ox9 V1C5rrf5ULndU9gtdsyA8V/8KQYtT684ghXSpBA5Y21wYEdn790C+iwci+68tyMW yq9cnWrEz4QZyvTAGO9ZGhOHrApN5cxAjEBKQVW9hHLtby07xBuDVDSsFrcqk8GS iREssY5GaNUES8SQ2bmYiTIQLdrAC4C0skTFI9u66v2JOK3YKes9rAD4iVPEmCwQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhh vghnghcujggrnhhgfdcuoehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmqeenucggtf frrghtthgvrhhnpeehleeutdduffffgeffieelteetvdduieehhfevgfdviedvtddtieef ieeggeevjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 095ADA00079; Mon, 19 Apr 2021 15:18:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-380-gda4c716772-fm-20210419.004-gda4c7167 Mime-Version: 1.0 Message-Id: <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> In-Reply-To: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Date: Mon, 19 Apr 2021 14:18:29 -0500 From: "Sheng Yang" To: "Stefan Monnier" , "Alan Mackenzie" Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50; _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?= Content-Type: multipart/alternative; boundary=6b456ae6cda94b8cb21cb41733063795 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Drew Adams 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 (-) --6b456ae6cda94b8cb21cb41733063795 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, Thanks you all for the discussion and especially @Stefan for the patch. = The patch looks good to me (I am on emacs 28 pgtk branch). It does cause= lispy and telega to malfunction due to their use of minibuffer-inactive= -mode, but I managed to fix those by replacing (eq major-mode 'minibuffe= r-inactive-mode) with (derived-mode-p 'minibuffer-mode). When this patch= gets merged to master, I will send PRs to all the packages I am aware o= f using minibuffer-inactive-mode, i.e. lispy/telega/smartparens/lunaryma= cs (and possibly package-lint). Best regards, Sheng On Mon, Apr 19, 2021, at 13:22, Stefan Monnier wrote: > > diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi > > index 1eba7074f7..6f2935f1f6 100644 > > --- a/doc/emacs/mini.texi > > +++ b/doc/emacs/mini.texi > > @@ -247,6 +247,9 @@ Minibuffer Edit > > to show the current recursion depth in the minibuffer prompt > > on recursive use of the minibuffer. > > =20 > > + When active, the minibuffer is in @code{minibuffer-mode}. This i= s > > +an internal Emacs mode without any features for the user. >=20 > I don't think we should be so definitive about it (I don't think we > should consider it a bug if some package decides to change the major > mode to something else from `minibuffer-setup-hook`, for instance). >=20 > So, I'd either not document it at all, or add something like "usually"= > in there to tone things down. >=20 > > +@cindex active minibuffer > > + An active minibuffer has major mode @code{minibuffer-mode}. This= is > > +an Emacs internal mode, and there is never any point in calling it = or > > +otherwise trying to manipulate it. >=20 > I don't see the point in trying to discourage people from using it: > I don't see any reason to expect uses to be harmful, nor do I see any > sign that hordes are just waiting to jump on the opportunity to (ab)us= e > this mode in unexpected ways. >=20 > > Rather than using > > +@code{minibuffer-mode-hook}, you should use > > +@code{minibuffer-setup-hook} (@pxref{Minibuffer Misc}). >=20 > Sounds fine. We may even motivate it by explaining that at the time > `minibuffer-mode-hook` is run the (mini)buffer is not yet fully prepar= ed > (e.g. the keymap is not yet set). >=20 > > +(define-derived-mode minibuffer-mode nil "Minibuffer" > > + "Major mode used only in active minibuffers. > > +This mode is used internally, and should not be set by user code > > +in any way, although it may be tested by such code. Use > > +`minibuffer-setup-hook' and `minibuffer-exit-hook' rather than > > +the mode hook of this mode." >=20 > Same here, I don't see the need to waste time discouraging people to s= et > it themselves. >=20 > Other than those nitpicks: LGTM, thank you, >=20 >=20 > Stefan >=20 >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --6b456ae6cda94b8cb21cb41733063795 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

Thanks you all for the discussion and especia= lly @Stefan for the patch. The patch looks good to me (I am on emacs 28 = pgtk branch). It does cause lispy and telega to malfunction due to their= use of minibuffer-inactive-mode, but I managed to fix those by replacin= g (eq major-mode 'minibuffer-inactive-mode) with (derived-mode-p 'minibu= ffer-mode). When this patch gets merged to master, I will send PRs to al= l the packages I am aware of using minibuffer-inactive-mode, i.e. lispy/= telega/smartparens/lunarymacs (and possibly package-lint).

Best regards,
Sheng

On Mon, Apr 19, 2021, at 13:22, Stefan Monnier wrote:
> diff --git a/doc/= emacs/mini.texi b/doc/emacs/mini.texi
> index 1eba7074f= 7..6f2935f1f6 100644
> --- a/doc/emacs/mini.texi
> +++ b/doc/emacs/mini.texi
> @@ -247,6 +247= ,9 @@ Minibuffer Edit
>  to show the current recur= sion depth in the minibuffer prompt
>  on recursiv= e use of the minibuffer.
>  
&g= t; +  When active, the minibuffer is in @code{minibuffer-mode}.&nbs= p; This is
> +an internal Emacs mode without any featur= es for the user.

I don't think we should be= so definitive about it (I don't think we
should consider = it a bug if some package decides to change the major
mode = to something else from `minibuffer-setup-hook`, for instance).
=

So, I'd either not document it at all, or add someth= ing like "usually"
in there to tone things down.
=

> +@cindex active minibuffer
> +=   An active minibuffer has major mode @code{minibuffer-mode}. = This is
> +an Emacs internal mode, and there is never = any point in calling it or
> +otherwise trying to manip= ulate it.

I don't see the point in trying t= o discourage people from using it:
I don't see any reason = to expect uses to be harmful, nor do I see any
sign that h= ordes are just waiting to jump on the opportunity to (ab)use
this mode in unexpected ways.

> Rathe= r than using
> +@code{minibuffer-mode-hook}, you should= use
> +@code{minibuffer-setup-hook} (@pxref{Minibuffer= Misc}).

Sounds fine.  We may even mot= ivate it by explaining that at the time
`minibuffer-mode-h= ook` is run the (mini)buffer is not yet fully prepared
(e.= g. the keymap is not yet set).

> +(defin= e-derived-mode minibuffer-mode nil "Minibuffer"
> +&nbs= p; "Major mode used only in active minibuffers.
> +This= mode is used internally, and should not be set by user code
> +in any way, although it may be tested by such code.  Use
> +`minibuffer-setup-hook' and `minibuffer-exit-hook' ra= ther than
> +the mode hook of this mode."

Same here, I don't see the need to waste time discouragi= ng people to set
it themselves.

Other than those nitpicks: LGTM, thank you,

<= div>
        Stefan
=



Sheng Yang(=E6=9D=A8=E5=9C=A3), P= hD
Computer Science Department
University of Maryland, College Park
E-mail: styang@fastmail.com
E-mail (old b= ut still used): yangsheng6810= @gmail.com

--6b456ae6cda94b8cb21cb41733063795-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 15:35:44 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 19:35:44 +0000 Received: from localhost ([127.0.0.1]:52155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZgO-0001N4-H1 for submit@debbugs.gnu.org; Mon, 19 Apr 2021 15:35:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZgL-0001Mp-H4 for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 15:35:42 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D427A1002F2; Mon, 19 Apr 2021 15:35:35 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 76C0C10021B; Mon, 19 Apr 2021 15:35:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618860934; bh=DdX0YzAFNzP0VKkk7GePRaPD3N7DCe/d/zaxjnulQ00=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=WKrMNf4e+1dxyxrZdCud904RS531VoW8Bhq4DeUNCrvmvbGycUN+plsgcD44wl/Ey eapYDnOOS+aK+vg6B0sWxNbWhYVOO89NPrZRv8waoyZiZSIWtf2wY6bLmPKcLK836a gnrCIyfAlAbvSW+ldvW/AD4Xt4luk2TFD6cfIzmqzx3nTRNpKrwbUFenqxWAfwgRaZ RwABIyH4cpRNa8PvxUGp1qI5tdhUXU2q/juuGThqIiHMYZc59G17UEntF7x/r1lVQD SJPuf8JYpwokoqsegED/e0GXPeZ/ZfWAsr5gOFxB6pOhUz1SerQcrDxqICJz0yU+9o wq0/w3k/452QA== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3DB43120283; Mon, 19 Apr 2021 15:35:34 -0400 (EDT) From: Stefan Monnier To: "Sheng Yang" Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> Date: Mon, 19 Apr 2021 15:35:33 -0400 In-Reply-To: <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> (Sheng Yang's message of "Mon, 19 Apr 2021 14:18:29 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Drew Adams 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 (---) > I managed to fix those by replacing (eq major-mode > 'minibuffer-inactive-mode) with (derived-mode-p 'minibuffer-mode). When this Any reason why you won't use `minibufferp` instead, which seems more reliable (and backward compatible to boot)? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 15:47:52 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 19:47:53 +0000 Received: from localhost ([127.0.0.1]:52165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZs8-0001ey-MS for submit@debbugs.gnu.org; Mon, 19 Apr 2021 15:47:52 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYZs4-0001ei-61 for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 15:47:52 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C53615C0186; Mon, 19 Apr 2021 15:47:42 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 19 Apr 2021 15:47:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=TP3GVsvd5/DVEDBHbfDsyuLQL4aY9J9 o9+ovl6TiMEY=; b=cBjVP51ww0wjlLXVohL2Si2d5zJW8bO5Z4UJjRlt7aC3Csm 8bk2aEbq1ACjciy38J7ZXjlahMCL70caKlHTZ8Q4uaPQqKw1BR8k9xJExrIA1+OL /zNhZRBiivgzJMy4HaE3ifnZNQ+D594IcTALr270a9ghNJ/P4fvdco7/MEN0Ee6c twKYOuU7Guv7pd9Aa3CfmxGyu1W+Zy9RMDbWjxtxCNk75KZ7uHzteo0znLVBS7Bv cC4e8FQLz8cVB0jev4v6qlmpZMoJGLk9SlZx9TP2etG/k7pS5n+xjjyEAyKqOQmK +hrr4U29pPZyYUPZ1ZbAmKXmCFcDYJCqs9GPkaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=TP3GVs vd5/DVEDBHbfDsyuLQL4aY9J9o9+ovl6TiMEY=; b=Sic64RyOVmNm2evnUqvZ+n NH11sLR8hpogDBmFm7HV1/0ANqY2vuTgvhtWpmHjx3hl3DmlT+MzgOg4zMF+UaaQ DxznyeWy01gUmqpjIgC3iI3f7kLZ2tuo6usNgf3GGg4zoXCgyUlZeokHYhTmCAnj 04UapGX1D+el6O/FFi1yYUDsoVJCmb4cjAQ7UZN32Yvrqud06SDkVE94Egaw09Xy CJs8Ows1UZWzIvNhH61E0gLuhIf6UPaPNdkrlfgo6JYlf64XQgp1diS1Cc/OY5Wr TDUp9hf4VstIKoJ1ICFMEjElsE9nzxPnUuKrEqUv8kG71DNpLUN+3yJUOURM7QRA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhh vghnghcujggrnhhgfdcuoehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmqeenucggtf frrghtthgvrhhnpeehleeutdduffffgeffieelteetvdduieehhfevgfdviedvtddtieef ieeggeevjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4E43A00079; Mon, 19 Apr 2021 15:47:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-380-gda4c716772-fm-20210419.004-gda4c7167 Mime-Version: 1.0 Message-Id: <4e10120a-58e8-4813-bc3d-975ecd19ad75@www.fastmail.com> In-Reply-To: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> Date: Mon, 19 Apr 2021 14:47:20 -0500 From: "Sheng Yang" To: "Stefan Monnier" Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50; _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?= Content-Type: multipart/alternative; boundary=a87d4db7c67d41cfa8e5fe4e05651b90 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Drew Adams 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 (-) --a87d4db7c67d41cfa8e5fe4e05651b90 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable For telega, the check for minibuffer is a simple cl-assert, and I think = your suggestion of using `minibufferp` would be a better choice. For others, their test of minibuffer-inactive-mode is actually buried in= some variable `xxx-ignore-mode-list`, which is later checked by `(membe= r major-mode xxx-ignore-modes-list)`. My current modification is to add = `minibuffer-mode` to those variables. I assume this is the simplest solu= tion? Sheng On Mon, Apr 19, 2021, at 14:35, Stefan Monnier wrote: > > I managed to fix those by replacing (eq major-mode > > 'minibuffer-inactive-mode) with (derived-mode-p 'minibuffer-mode). W= hen this >=20 > Any reason why you won't use `minibufferp` instead, which seems more > reliable (and backward compatible to boot)? >=20 >=20 > Stefan >=20 >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --a87d4db7c67d41cfa8e5fe4e05651b90 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
For telega, the= check for minibuffer is a simple cl-assert, and I think your suggestion= of using `minibufferp` would be a better choice.

For others, their test of minibuffer-inactive-mode is actually bu= ried in some variable `xxx-ignore-mode-list`, which is later checked by = `(member major-mode xxx-ignore-modes-list)`. My current modification is = to add `minibuffer-mode` to those variables. I assume this is the simple= st solution?

Sheng

=
On Mon, Apr 19, 2021, at 14:35, Stefan Monnier wrote:
> I managed to fix th= ose by replacing (eq major-mode
> 'minibuffer-inactive-= mode) with (derived-mode-p 'minibuffer-mode). When this
Any reason why you won't use `minibufferp` instead, which s= eems more
reliable (and backward compatible to boot)?
<= /div>


     &n= bsp;  Stefan



Sheng Yang= (=E6=9D=A8=E5=9C=A3), PhD
Computer Sci= ence Department
University of Maryland= , College Park
E-mail: styang@fastmail.com
E-mail (old but still used): yangsheng6810@gmail.com
=

--a87d4db7c67d41cfa8e5fe4e05651b90-- From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 16:36:45 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 20:36:45 +0000 Received: from localhost ([127.0.0.1]:52214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYadQ-0004zc-Vc for submit@debbugs.gnu.org; Mon, 19 Apr 2021 16:36:45 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYadP-0004zR-Qv for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 16:36:44 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1635280A77; Mon, 19 Apr 2021 16:36:38 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8C6138078F; Mon, 19 Apr 2021 16:36:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1618864596; bh=v7HomFPyPZfjBwmfq92V+c4w0Kn+UNFoG1C/cFum07o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=IjoP1NNG7GWxWqnl/eTCOgUAIkgHBHJkQ8hCe1UQvuCEk37bu5chwUC87gWc4oZA0 xldWCUSjcRtH2dpH7DzzwmcqD+4YJlF/oU3zOxvOmf7DOM9zoywMGqWJhIh32y/dVD gNBwOK1mK+B/6y2Gv6j+QPWnfNAdzEt/Qp/8QuoiBpxtJwetujgiaBpJYI6EbuUz8g FWrWgOqxzIlyHGERC+2E9QNkSzsBv8qeAaWbjWSvBm7TnC8Sv0S0gP38SLcpZ2bsfY MOYajpuyMj1ItA+9fJMB4/3+E0Uy2FTvF+/yNxHfdjOAc0JKisN0KYLM8KPQXYMTr0 prlfIHRvP3K6A== Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 51CEB1202C5; Mon, 19 Apr 2021 16:36:36 -0400 (EDT) From: Stefan Monnier To: "Sheng Yang" Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> <4e10120a-58e8-4813-bc3d-975ecd19ad75@www.fastmail.com> Date: Mon, 19 Apr 2021 16:36:35 -0400 In-Reply-To: <4e10120a-58e8-4813-bc3d-975ecd19ad75@www.fastmail.com> (Sheng Yang's message of "Mon, 19 Apr 2021 14:47:20 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.057 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Drew Adams 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 (---) > For telega, the check for minibuffer is a simple cl-assert, and I think your > suggestion of using `minibufferp` would be a better choice. Indeed. > For others, their test of minibuffer-inactive-mode is actually buried in > some variable `xxx-ignore-mode-list`, which is later checked by `(member > major-mode xxx-ignore-modes-list)`. My current modification is to add > `minibuffer-mode` to those variables. I assume this is the > simplest solution? Probably, tho it depends why they make this test. (e.g. in `smartparens`, I think it'd make a lot of sense to enable the minor mode during `M-:`, so it shouldn't be disabled for all minibuffers). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 19 16:43:18 2021 Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 20:43:18 +0000 Received: from localhost ([127.0.0.1]:52220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYaji-00058v-Nz for submit@debbugs.gnu.org; Mon, 19 Apr 2021 16:43:18 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:35871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYajd-00058e-H9 for 47150@debbugs.gnu.org; Mon, 19 Apr 2021 16:43:13 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 553FB5C0297; Mon, 19 Apr 2021 16:43:04 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Mon, 19 Apr 2021 16:43:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=OUhpOswm+0nYuZ50J6hgffY1PVuJTHo nFu7M0/YdMCQ=; b=e2PadYjzmDP6htELzJrS5Mamhuy2svMUKFsJJ+2bmBnNE34 9fpk3R8umtARWnb3NfhIRkU4digGISb2/LIsFe7xNeS1hvbRUJgOPNUrWFVAEPhT GEUZlkMCFk/6DRntiEsWkPRahvLxMuZXD8TB79qcUur1dHZd2jlVRWl4AHIlM7TP 7C5I9W8yi5BJDzt1KXwMM6KHUK3pympSClfRUhqr4rGkPuYBOwDu8Es8j0jQzv92 wOX6WG7KQnhBiOdyNzd5oUPwmkeAMV+2xne6vkhQdGFQNK9ef7vARfH2CluQPCQY Cs8rOhRg/xefO65ZS71N2xoesC7a5hM87u6Z+LQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OUhpOs wm+0nYuZ50J6hgffY1PVuJTHonFu7M0/YdMCQ=; b=cSnodw4J1BCdgFnfAGOmWz GsYvwy3Ef8xbeLhP4oCSDN8zr2SSXlwyn/CtlgxEwy9aIx7m+Puin+hBfWG26C3m nHKs3ilKNOye8E0Gm2OYNGs1+fArQJRCPome9Ua8ELao3RbaHGWbQtsZE6l1x6v0 csOJ86Cojby7w0mVe1p0/ySGNvcEspqy5N0g4IxiZG8E/9IC+3jxLl8FJrvOlg4y y+/4tyd0bP+kf8/i+jF0IKSTnbyokbn7qE/AzxsgtCS84HSwY6hvWdD0Y6EeymbZ /RtcHl5L6FG7D1wI7GN5iMQ+1FcqEu2DB8V+Ys+xAHXfeEeu1YNLnHAUvpqGYi1Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgedgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhh vghnghcujggrnhhgfdcuoehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmqeenucggtf frrghtthgvrhhnpeehleeutdduffffgeffieelteetvdduieehhfevgfdviedvtddtieef ieeggeevjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehsthihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8D86DA00079; Mon, 19 Apr 2021 16:43:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-380-gda4c716772-fm-20210419.004-gda4c7167 Mime-Version: 1.0 Message-Id: <8140d52d-9b82-45d2-ba38-685b90684ed8@www.fastmail.com> In-Reply-To: References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> <4e10120a-58e8-4813-bc3d-975ecd19ad75@www.fastmail.com> Date: Mon, 19 Apr 2021 15:42:43 -0500 From: "Sheng Yang" To: "Stefan Monnier" Subject: =?UTF-8?Q?Re:_[External]_:_bug#47150:_28.0.50; _Incorrect_major-mode_in_m?= =?UTF-8?Q?inibuffer?= Content-Type: multipart/alternative; boundary=9b7dd94105f845b1873321942ea15033 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 47150 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org>, Alan Mackenzie , Drew Adams 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 (-) --9b7dd94105f845b1873321942ea15033 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable > Probably, tho it depends why they make this test. > (e.g. in `smartparens`, I think it'd make a lot of sense to enable the= > minor mode during `M-:`, so it shouldn't be disabled for all > minibuffers). For smartparens, I traced the history of commits, and the exclusion appe= ars in the initial commit. I am not sure why it is there in the first pl= ace, and plan to submit an issue instead of a PR, which will suggest a s= pecial treatment of `M-:` to enable it. Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --9b7dd94105f845b1873321942ea15033 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Probably, tho it depends why they make this test.
(e.g. in `smartparens`, I think it'd make a lot of sense to enable th= e
minor mode during `M-:`, so it shouldn't be disabled for= all
minibuffers).

For s= martparens, I traced the history of commits, and the exclusion appears i= n the initial commit. I am not sure why it is there in the first place, = and plan to submit an issue instead of a PR, which will suggest a specia= l treatment of `M-:` to enable it.
Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
<= /div>
Computer Science Department
University of Maryland, College Park
E-mail (old but stil= l used): yangsheng6810@gmail.= com


--9b7dd94105f845b1873321942ea15033-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 20 06:25:36 2021 Received: (at 47150-done) by debbugs.gnu.org; 20 Apr 2021 10:25:36 +0000 Received: from localhost ([127.0.0.1]:53039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lYnZX-0006uQ-O0 for submit@debbugs.gnu.org; Tue, 20 Apr 2021 06:25:36 -0400 Received: from colin.muc.de ([193.149.48.1]:19675 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lYnZV-0006uA-E1 for 47150-done@debbugs.gnu.org; Tue, 20 Apr 2021 06:25:34 -0400 Received: (qmail 38779 invoked by uid 3782); 20 Apr 2021 10:25:26 -0000 Received: from acm.muc.de (p4fe15986.dip0.t-ipconnect.de [79.225.89.134]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 20 Apr 2021 12:25:26 +0200 Received: (qmail 14815 invoked by uid 1000); 20 Apr 2021 10:25:25 -0000 Date: Tue, 20 Apr 2021 10:25:25 +0000 To: Sheng Yang Subject: Re: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Message-ID: References: <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> 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: 47150-done Cc: 47150-done@debbugs.gnu.org, acm@muc.de, Stefan Monnier , Drew Adams 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, Sheng. On Mon, Apr 19, 2021 at 14:18:29 -0500, Sheng Yang wrote: > Hi everyone, > Thanks you all for the discussion and especially @Stefan for the patch. > The patch looks good to me (I am on emacs 28 pgtk branch). Many thanks for the testing! > It does cause lispy and telega to malfunction due to their use of > minibuffer-inactive-mode, but I managed to fix those by replacing (eq > major-mode 'minibuffer-inactive-mode) with (derived-mode-p > 'minibuffer-mode). Yes. It seems this is unavoidable. > When this patch gets merged to master, I will send PRs to all the > packages I am aware of using minibuffer-inactive-mode, i.e. > lispy/telega/smartparens/lunarymacs (and possibly package-lint). Thanks for doing that. I've now committed the patch (modified in line with Stefan's suggestions) to the master branch at savannah, and I'm closing the bug with this post. > Best regards, > Sheng [ .... ] > Sheng Yang(杨圣), PhD > Computer Science Department > University of Maryland, College Park > E-mail: styang@fastmail.com > E-mail (old but still used): yangsheng6810@gmail.com -- Alan Mackenzie (Nuremberg, Germany). From unknown Sat Jun 21 05:04:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 18 May 2021 11:24:06 +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