GNU bug report logs - #47150
28.0.50; Incorrect major-mode in minibuffer

Previous Next

Package: emacs;

Reported by: styang <at> fastmail.com

Date: Mon, 15 Mar 2021 00:58:01 UTC

Severity: normal

Found in version 28.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 47150 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: "47150 <at> debbugs.gnu.org" <47150 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#47150: 28.0.50; Incorrect major-mode in
 minibuffer
Date: Mon, 22 Mar 2021 15:52:13 +0000
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?

This bug report was last modified 4 years and 33 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.