From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Sheng Yang" Newsgroups: gmane.emacs.bugs Subject: bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer Date: Mon, 19 Apr 2021 14:18:29 -0500 Message-ID: <887bda9c-906c-4163-a8db-08b45e021bfd@www.fastmail.com> References: <8cbe7629-2091-45d3-9424-46444d7a4633@www.fastmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=6b456ae6cda94b8cb21cb41733063795 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25537"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.5.0-alpha0-380-gda4c716772-fm-20210419.004-gda4c7167 Cc: "47150@debbugs.gnu.org" <47150@debbugs.gnu.org> To: "Stefan Monnier" , "Alan Mackenzie" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 19 21:24:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYZVD-0006Tx-VX for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 21:24:12 +0200 Original-Received: from localhost ([::1]:39416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYZVD-0004YA-0o for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Apr 2021 15:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYZQE-0006nS-3H for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 15:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40578) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lYZQD-0001D8-RC for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 15:19:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lYZQD-0000w9-Ms for bug-gnu-emacs@gnu.org; Mon, 19 Apr 2021 15:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Sheng Yang" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Apr 2021 19:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47150 X-GNU-PR-Package: emacs Original-Received: via spool by 47150-submit@debbugs.gnu.org id=B47150.16188599403594 (code B ref 47150); Mon, 19 Apr 2021 19:19:01 +0000 Original-Received: (at 47150) by debbugs.gnu.org; 19 Apr 2021 19:19:00 +0000 Original-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 Original-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 Original-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) Original-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: Original-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 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:204500 Archived-At: --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--