bug#47150: 28.0.50; Incorrect major-mode in minibuffer

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[styang]

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))

bug#47150: Emacs bug#47150 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

CCing the author of the offending commit 636ef445af.

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


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

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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: 
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 apply 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 existing 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 reason.

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

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.

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 `hybird'. 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?

I am not sure I understand the differences between an active and inactive minibuffer, and the elisp manual does not really help me much. It seems to me the minibuffer is alwals 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?

> > 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-:'

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


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

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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.

> 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?


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


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

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

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.

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."

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?

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?

Is there a real bug that you're trying to solve here?  If so, what's a simple recipe to repro it?

Apologies for being skeptical.  Likely this will be of no consequence (but then why do it?).  But maybe not?

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> 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.
> 
> 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.

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

[ 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

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[jakanakaevangeli]

Drew Adams <drew.adams@oracle.com> 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.

bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> > 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?
> 
> 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.)

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> 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!
> 
> 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;
> 
> 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.)

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

>> 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

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> >> 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.

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?
> 
> 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...

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?
> 
> 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?
> 
> 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.)
> 
> 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?

bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

>> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

>> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> > 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?

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.

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

> > > 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.

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.
> 
> > 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'.

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.
> 
> 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.
> 
> > 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 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)?
> 
> 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.

> > 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.

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.
> 
> 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.

bug#47150: [External] : Re: bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[jakanakaevangeli]

>>> 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'.

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Drew Adams]

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.]

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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
> > > active and inactive?
> > 
> > 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.
> 

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


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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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 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 <mailto:styang%40fastmail.com>
> > E-mail (old but still used): yangsheng6810@gmail.com <mailto:yangsheng6810%40gmail.com>
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 

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


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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

>> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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'être of `minibuffer-inactive-mode`, so
what you're suggesting is, in practice, the removal of
`minibuffer-inactive-mode`.


        Stefan

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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 <foo>) 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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 <foo>) 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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

>> 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 <foo-list>) 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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 <foo-list>) 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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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 'minibuffer-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 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 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
> 
> 

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


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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

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 `(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?

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). When this
> 
> Any reason why you won't use `minibufferp` instead, which seems more
> reliable (and backward compatible to boot)?
> 
> 
>         Stefan
> 
> 

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


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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Stefan Monnier]

> 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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Sheng Yang]

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

> 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 appears in 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 special treatment of `M-:` to enable it.

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


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

bug#47150: [External] : bug#47150: 28.0.50; Incorrect major-mode in minibuffer

[Alan Mackenzie]

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).