bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48798: 26.3; `define-minor-mode': Message should name the current bu


From: Drew Adams
Subject: bug#48798: 26.3; `define-minor-mode': Message should name the current buffer where enabled/disabled
Date: Tue, 4 Jul 2023 15:25:26 +0000

Guess I have to send this again, after unarchiving this bug (as well as 33076)? 
 Is it the case that if N bugs were merged then it's not enough to unarchive 
one of them - you need to unarchive all of them?

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]