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