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

["Sheng Yang" <styang@fastmail.com>]

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