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