From: Bob Proulx <bob@proulx.com>
To: npostavs@gmail.com
Cc: 35887@debbugs.gnu.org
Subject: bug#35887: 26.1; global-eldoc-mode minibuffer noise is very annoying
Date: Fri, 24 May 2019 15:35:25 -0600 [thread overview]
Message-ID: <20190524151617874644844@bob.proulx.com> (raw)
In-Reply-To: <85tvdjd1gy.fsf@gmail.com>
npostavs@gmail.com wrote:
> Bob Proulx writes:
> > In recent Emacs global-eldoc-mode has been enabled by default. This is
> > a very annoying mode that causes minibuffer hints of elisp doc strings
> > to be flashing by in the minibuffer as the point moves around in the
> > buffer.
>
> Your description of "flashing" suggests that maybe you some graphical
> glitching? When I see the eldoc text show up in the minibuffer there is
> nothing that I would call "flashing". The text just appears normally.
You misunderstand my words. I said "as the point moves around in the
buffer". Which means that this is due to the point moving around the
buffer. This is not a graphics artifact. To test this use text mode
emacs in a text terminal to ensure that you will have no graphics
artifacts from emacs.
Let's assume an elisp construct. Put the cursor on the (defun line
then move down to the doc string line. The second line in the below.
(defun unfill-paragraph (&optional region) ; Thanks to Stefan Monnier
"Takes a multi-line paragraph and makes it into a single line of text."
(interactive (progn (barf-if-buffer-read-only) '(t)))
(let ((fill-column (point-max))
;; This would override `fill-column' if it's an integer.
(emacs-lisp-docstring-fill-column t))
(fill-paragraph nil region)))
The following string appears in the minibuffer. The DOCSTRING word is
highlighted.
defun: (NAME ARGLIST &optional *DOCSTRING* DECL &rest BODY)
C-n or Down-Arrow to move to the next line. This then appears in the
minibuffer.
defun: (NAME ARGLIST &optional DOCSTRING *DECL* &rest BODY)
The DECL word is hightlighted. C-n again.
defun: (NAME ARGLIST &optional DOCSTRING DECL &rest *BODY*)
The BODY word is highlighted. C-n again. On the comment line. The
minibuffer is cleared. No message there.
C-n again. No message. C-n again. The flil-paragraph line. The
following appears. The BODY word is highlighted.
let: (VARLIST *BODY*...)
C-n again. Blank line. The minibuffer is cleared.
The above is a small snippet I selected for this example. But now do
this through a large elisp file. With every C-n next-line movement
the minibuffer is displaying or clearing a doc string hint. With
every next-line movement the highlighted word in the minibuffer is
moving from one word to another word.
This is driving me crazy! This continous activity, changing, and
flashing is extremely annoying.
The minibuffer is where I expect to find useful editor feedback. When
things happen there I look to see what it is telling me. Sometimes it
is an error message. Sometimes it is direct dialog interaction such
as for find-file. Sometimes it is simply information such as "Mark
set". But with global-eldoc-mode enabled it is continously posting
distractions in the minibuffer that I must look at, read and
comprehend, and then ignore. This increases the editing workload.
This increases use fatigue.
Please revert the default enabling of global-eldoc-mode.
Bob
next prev parent reply other threads:[~2019-05-24 21:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-24 19:51 bug#35887: 26.1; global-eldoc-mode minibuffer noise is very annoying Bob Proulx
2019-05-24 20:47 ` npostavs
2019-05-24 21:35 ` Bob Proulx [this message]
2019-05-24 22:38 ` Dmitry Gutov
2019-05-24 23:24 ` Bob Proulx
2019-05-25 2:21 ` Noam Postavsky
2019-05-25 6:19 ` Eli Zaretskii
2019-05-26 11:51 ` Basil L. Contovounesios
2019-05-25 8:00 ` martin rudalics
2019-05-27 20:30 ` Juri Linkov
2019-05-27 22:31 ` Drew Adams
2019-05-28 15:54 ` Basil L. Contovounesios
2019-06-04 8:21 ` martin rudalics
2019-06-04 13:30 ` Dmitry Gutov
2019-06-05 21:06 ` Juri Linkov
2019-05-27 3:23 ` Drew Adams
2020-08-16 10:16 ` Stefan Kangas
2020-08-16 14:32 ` Drew Adams
2020-08-16 16:12 ` Kévin Le Gouguec
2020-08-16 14:39 ` Eli Zaretskii
2020-10-01 12:27 ` Stefan Kangas
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=20190524151617874644844@bob.proulx.com \
--to=bob@proulx.com \
--cc=35887@debbugs.gnu.org \
--cc=npostavs@gmail.com \
/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.