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

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

bug#44629: 28.0.50; Eglot noisy with gfm-view-mode and view-read-only


From: João Távora
Subject: bug#44629: 28.0.50; Eglot noisy with gfm-view-mode and view-read-only
Date: Sat, 14 Nov 2020 13:47:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> X-Debbugs-Cc: "João Távora" <joaotavora@gmail.com>
> Severity: minor

Hi Basil, and thanks for X-Debbugs-CC'ing me in this message.  This is
indeed the way I hope to handle Eglot bugs in the future: via email and
the Emacs bug tracker.

> Perhaps Eglot could/should bind view-inhibit-help-message around
> gfm-view-mode?  Any other ideas?

I'd have no problem with that, but as you've noted, it doesn't work when
other modes also use `read-only-mode`.

I think this is more of an Emacs echo-area congestion problem than an
Eglot one.  view-read-only seems a bit akward, I'd say, but it's been
around such a long time that I won't argue for changing it.

I'd say the fix here is for Eglot, jsonrpc.el and all all other code
that needs to set a buffer read only for implementation purposes just
sets the variable buffer-read-only.  In fact, the docstring of
read-only-mode hints at this:

    ...

    Do not call this from a Lisp program unless you really intend to
    do the same thing as the C-x C-q command, including
    possibly enabling or disabling View mode. 

    ...

I wasn't aware of caveat until just now.

Alternatively, and very cautiously, we could also say that the echo area
message issued by view-mode should only be displayed to the user if it's
running interactively, i.e. if it's a direct synchronous consequence of
an interactive command.  That would exclude elisp code running
asynchronously like jsonrpc.el's updating of the events buffer, and
probably also the use that ElDoc clients make of `read-only-mode`.

In fact, the docstring of called-interactively-p seems to indicate its
main use is to cover these use cases.

    ...

    The only known proper use of `interactive' for KIND is in deciding
    whether to display a helpful message, or how to display it.

    ...

In that spirit, maybe this could fix it?

    diff --git a/lisp/view.el b/lisp/view.el
    index 204e28c2a2..6233f3ba7d 100644
    --- a/lisp/view.el
    +++ b/lisp/view.el
    @@ -559,7 +559,8 @@ view-mode-enter
     
       (unless view-mode
         (view-mode 1)
    -    (unless view-inhibit-help-message
    +    (unless (or view-inhibit-help-message
    +                (not (called-interactively-p 'interactive)))
           (message "%s"
               (substitute-command-keys "\
     View mode: type \\[help-command] for help, \\[describe-mode] for commands, 
\\[View-quit] to quit.")))))

João





reply via email to

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