From: Drew Adams <drew.adams@oracle.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: "33076@debbugs.gnu.org" <33076@debbugs.gnu.org>,
"48798@debbugs.gnu.org" <48798@debbugs.gnu.org>
Subject: bug#33076: bug#48798: 26.3; `define-minor-mode': Message should name the current buffer where enabled/disabled
Date: Tue, 4 Jul 2023 15:08:49 +0000 [thread overview]
Message-ID: <SJ0PR10MB548883BE6C7F71CE0FE0162AF32EA@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <SJ0PR10MB5488B2D028C5416FD6A0217FF3CD9@SJ0PR10MB5488.namprd10.prod.outlook.com>
> > The same problem persists - bugs #33076 and #48798.
> >
> > It's quite possible to not notice - or even not be
> > able to easily see - which buffer is current when
> > it's changed to/from read-only. It just makes
> > sense to tell users which buffer is involved.
> >
> > Really hard to believe this isn't obvious and the
> > trivial fix wasn't applied. This just makes life
> > that much harder for users, with no benefit to Emacs.
>
> Perhaps the problem is more noticeable if buffers
> are in separate frames. Especially since Emacs
> has messed with frame focus so much (since Emacs
> 26, at least). If the buffer you thought was
> current with its window selected is not, for some
> reason (e.g. gratuitous Emacs frame-focus switch),
> then the message doesn't help at all if you have
> multiple buffers in separate frames etc.
>
> I'm guessing that this might be why Lars didn't
> think this was a real problem. It might be less
> noticeable if you're not a victim of Emacs's
> gratuitous frame focus-switching.
>
> But even if that's not the case, I see no reason
> why this shouldn't be fixed. _Whatever_ the
> reason might be why someone doesn't know or isn't
> sure which buffer had the focus, why not have a
> message that tells you what Emacs actually did?
>
> Please reopen this bug and apply the trivial fix.
> Thx. I'd really not like to have to redefine
> `define-minor-mode' for my own use, just to fix
> this annoyance. To me, this message improvement
> for users should be a no-brainer.
I'm asking again that this be fixed. I'm not
asking that such a message be changed for all
modes, i.e., a change in `define-minor-mode'.
Whether that would be appropriate is TBD - a
different question. It could be asked, but
I'm not asking it here.
For this enhancement request I'm asking only
that this be fixed for `read-only-mode'. In
various situations it can be nonobvious which
buffer's read-only state was changed.
And there's really no good reason why the
buffer name shouldn't be included in the msg.
And no objective reason was given - the only
reason given was that Lars subjectively found
the fix to be "more annoying than informative".
Whether or not the code below is the right
fix is for you to decide. It gets the job
done and shows what the behavior should be.
I don't care how the fix gets implemented.
(defun ro-echo-buffer ()
"Echo `buffer-read-only' value, showing buffer name."
(message "Read-only mode is %s in buffer `%s'"
(if buffer-read-only 'ON 'OFF)
(current-buffer)))
(add-hook 'read-only-mode-hook 'ro-echo-buffer)
Please reconsider Emacs not letting users see
this little bit of important info in the msg.
___
As for whether ON/OFF is kosher, vs the more
verbose and less noticeable enabled/disabled:
I think it should be. In fact, I think it's
preferable, at least in a message. And Emacs
itself sometimes says that a mode is "active"
instead of "enabled". (e.g. allout.el,
autorevert.el) I think uppercase ON and OFF
stand out clearly in such a message, and that
helps.
next prev parent reply other threads:[~2023-07-04 15:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 19:36 bug#48798: 26.3; `define-minor-mode': Message should name the current buffer where enabled/disabled Drew Adams
2021-06-02 20:59 ` Drew Adams
2021-06-03 8:06 ` Lars Ingebrigtsen
2021-07-01 11:45 ` Lars Ingebrigtsen
2021-07-01 14:16 ` bug#48798: [External] : " Drew Adams
2021-10-16 21:57 ` Drew Adams
2023-01-28 21:55 ` Drew Adams
2023-07-04 15:08 ` Drew Adams [this message]
2023-07-04 15:25 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR10MB548883BE6C7F71CE0FE0162AF32EA@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=33076@debbugs.gnu.org \
--cc=48798@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.