unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).