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

[Sheng Yang]

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