unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#43543: 28.0.50; Supress truncate notice in eldoc
@ 2020-09-21  1:15 Yuan Fu
  2020-09-21 12:22 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Yuan Fu @ 2020-09-21  1:15 UTC (permalink / raw)
  To: 43543

I limited the number of lines for eldoc to 2, but now instead of showing 2 lines of information, eldoc only shows 1 lines of information and one line for ""\n(Documentation truncated. Use `%s' to see rest)”” I understand the necessity of this notice, but it is so annoying for eldoc to use half of its precious screen space to display this unnecessary (for me) information.

Could there be an option to turn off this notice?

Yuan






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-09-21  1:15 bug#43543: 28.0.50; Supress truncate notice in eldoc Yuan Fu
@ 2020-09-21 12:22 ` Lars Ingebrigtsen
  2020-09-21 15:54   ` Yuan Fu
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-21 12:22 UTC (permalink / raw)
  To: Yuan Fu; +Cc: 43543

Yuan Fu <casouri@gmail.com> writes:

> I limited the number of lines for eldoc to 2, but now instead of
> showing 2 lines of information, eldoc only shows 1 lines of
> information and one line for ""\n(Documentation truncated. Use `%s' to
> see rest)”” I understand the necessity of this notice, but it is so
> annoying for eldoc to use half of its precious screen space to display
> this unnecessary (for me) information.
>
> Could there be an option to turn off this notice?

Sounds reasonable.  I've now added eldoc-display-truncation-message to
Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-09-21 12:22 ` Lars Ingebrigtsen
@ 2020-09-21 15:54   ` Yuan Fu
  2020-09-21 16:21     ` Yuan Fu
  0 siblings, 1 reply; 11+ messages in thread
From: Yuan Fu @ 2020-09-21 15:54 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 43543, 43543-done

Thanks!

Yuan





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-09-21 15:54   ` Yuan Fu
@ 2020-09-21 16:21     ` Yuan Fu
  2020-09-22 14:20       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: Yuan Fu @ 2020-09-21 16:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 43543

Actually, when I set line number to 2, eldoc only shows one line with an ending “…”, and if I set to 3 lines, eldoc shows two lines with an ending “…”.

Yuan




^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-09-21 16:21     ` Yuan Fu
@ 2020-09-22 14:20       ` Lars Ingebrigtsen
  2020-10-04 11:16         ` João Távora
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-22 14:20 UTC (permalink / raw)
  To: Yuan Fu; +Cc: 43543

Yuan Fu <casouri@gmail.com> writes:

> Actually, when I set line number to 2, eldoc only shows one line with
> an ending “…”, and if I set to 3 lines, eldoc shows two lines with an
> ending “…”.

This should now be fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-09-22 14:20       ` Lars Ingebrigtsen
@ 2020-10-04 11:16         ` João Távora
  2020-10-04 14:04           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: João Távora @ 2020-10-04 11:16 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 43543, Yuan Fu

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>> Actually, when I set line number to 2, eldoc only shows one line with
>> an ending “…”, and if I set to 3 lines, eldoc shows two lines with an
>> ending “…”.
>
> This should now be fixed on the trunk.

Hi Lars and Yuan.  I've been working a bit more on ElDoc recently in the
scratch/eldoc-display-functions branch.  There, a clean separation
between different outlets of doc display is achieved.  The echo area is
just one of them, handled by eldoc-display-in-echo-area.  So I think
this new variable should be better named
eldoc-echo-area-display-truncation-message, so we have some consistency
in the names of variables that affect this display tactic:

- eldoc-echo-area-display-truncation-message
- eldoc-echo-area-use-multiline-p
- eldoc-echo-area-prefer-doc-buffer

Path after my sig.  I don't think we need a backward compatibility
alias, since the user option has been around for a relatively short time
in master only.

João

diff --git a/etc/NEWS b/etc/NEWS
index d1db797eb3..b6f99067dd 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -591,7 +591,7 @@ definition.
 ** ElDoc
 
 +++
-*** New user option 'eldoc-display-truncation-message'.
+*** New user option 'eldoc-echo-area-display-truncation-message'.
 If non-nil (the default), eldoc will display a message saying
 something like "(Documentation truncated. Use `M-x eldoc-doc-buffer'
 to see rest)" when a message has been truncated.  If nil, truncated
diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index 9573dac6d7..f7a624f9ae 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -67,7 +67,7 @@ eldoc-print-after-edit
 Changing the value requires toggling `eldoc-mode'."
   :type 'boolean)
 
-(defcustom eldoc-display-truncation-message t
+(defcustom eldoc-echo-area-display-truncation-message t
   "If non-nil, provide verbose help when a message has been truncated.
 If nil, truncated messages will just have \"...\" appended."
   :type 'boolean
@@ -535,7 +535,7 @@ eldoc-display-in-echo-area
               ((> available 1)
                ;; The message takes one extra line, so if we don't
                ;; display that, we have one extra line to use.
-               (unless eldoc-display-truncation-message
+               (unless eldoc-echo-area-display-truncation-message
                  (setq available (1+ available)))
                ;; Else we format the *eldoc* buffer, then use some of
                ;; its contents top section.  I'm pretty sure smarter
@@ -561,7 +561,7 @@ eldoc-display-in-echo-area
                       (buffer-substring (point-min) (point))
                       (and
                        truncated
-                       (if eldoc-display-truncation-message
+                       (if eldoc-echo-area-display-truncation-message
                            (format
                             "\n(Documentation truncated. Use `%s' to see rest)"
                             (substitute-command-keys "\\[eldoc-doc-buffer]"))






^ permalink raw reply related	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-10-04 11:16         ` João Távora
@ 2020-10-04 14:04           ` Lars Ingebrigtsen
  2020-10-04 23:10             ` João Távora
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-04 14:04 UTC (permalink / raw)
  To: João Távora; +Cc: 43543, Yuan Fu

João Távora <joaotavora@gmail.com> writes:

> So I think
> this new variable should be better named
> eldoc-echo-area-display-truncation-message, so we have some consistency
> in the names of variables that affect this display tactic:
>
> - eldoc-echo-area-display-truncation-message
> - eldoc-echo-area-use-multiline-p
> - eldoc-echo-area-prefer-doc-buffer
>
> Path after my sig.  I don't think we need a backward compatibility
> alias, since the user option has been around for a relatively short time
> in master only.

Yup; sounds good to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-10-04 14:04           ` Lars Ingebrigtsen
@ 2020-10-04 23:10             ` João Távora
  2020-10-05  7:21               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: João Távora @ 2020-10-04 23:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 43543, Yuan Fu, felician.nemeth, andreyk.mad

Lars Ingebrigtsen <larsi@gnus.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> So I think
>> this new variable should be better named
>> eldoc-echo-area-display-truncation-message, so we have some consistency
>> in the names of variables that affect this display tactic:
>>
>> - eldoc-echo-area-display-truncation-message
>> - eldoc-echo-area-use-multiline-p
>> - eldoc-echo-area-prefer-doc-buffer
>>
>> Path after my sig.  I don't think we need a backward compatibility
>> alias, since the user option has been around for a relatively short time
>> in master only.
>
> Yup; sounds good to me.

While on this topic, I found a bug in this variable's implementation.
To reproduce, just evaluate these three forms in some scratch Elisp
buffer.


  (setq-local eldoc-documentation-strategy (lambda () (format "one\ntwo\nthree"))
              eldoc-echo-area-use-multiline-p 2
              eldoc-echo-area-display-truncation-message nil)

For the last one remember to use the old name if you haven't the latest
patch yet.  Anyway, as you'll see, the constant dummy docstring will
always be displayed in a 3-line-high echo area even though the user
specified 2 in eldoc-echo-area-use-multiline-p.

I fixed this in the latest commit to the scratch/eldoc-display-functions
branch.  To do so, I much simplified the semantics of a numeric value
given to eldoc-echo-area-use-multiline-p.  When I first idealized them
around three months ago, I thought it should count screen lines -- not
logical lines.  But now I changed my mind and switched to logical lines,
for a number of reasons:

- estimating screen lines is complicated (which probably led to the
  aforementioned bug);

- using screen lines overlaps in meaning with the existing variable
  max-mini-window-height, which is honoured by the display engine;

- I had at least one request by one user of Eglot (Andrii, in CC) to use
  the "logical lines" behaviour. 

We can always enhance the code later on to bring-back the screen lines
behaviour (maybe controlled by a separate variable), in case anyone was
already very fond of it.  Also keep in mind that setting the variable to
`nil' already mandates a single screen line (a meaning which it has
always had).

Let me know what you think,
João






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-10-04 23:10             ` João Távora
@ 2020-10-05  7:21               ` Lars Ingebrigtsen
  2020-10-05  9:21                 ` João Távora
  0 siblings, 1 reply; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-05  7:21 UTC (permalink / raw)
  To: João Távora; +Cc: 43543, Yuan Fu, felician.nemeth, andreyk.mad

João Távora <joaotavora@gmail.com> writes:

> I fixed this in the latest commit to the scratch/eldoc-display-functions
> branch.  To do so, I much simplified the semantics of a numeric value
> given to eldoc-echo-area-use-multiline-p.  When I first idealized them
> around three months ago, I thought it should count screen lines -- not
> logical lines.  But now I changed my mind and switched to logical lines,
> for a number of reasons:
>
> - estimating screen lines is complicated (which probably led to the
>   aforementioned bug);
>
> - using screen lines overlaps in meaning with the existing variable
>   max-mini-window-height, which is honoured by the display engine;
>
> - I had at least one request by one user of Eglot (Andrii, in CC) to use
>   the "logical lines" behaviour. 
>
> We can always enhance the code later on to bring-back the screen lines
> behaviour (maybe controlled by a separate variable), in case anyone was
> already very fond of it.  Also keep in mind that setting the variable to
> `nil' already mandates a single screen line (a meaning which it has
> always had).
>
> Let me know what you think,
> João

Hm...  Logical lines is fine by me, but I wonder whether visual lines is
slightly more logical here?  This is for display purposes, after all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-10-05  7:21               ` Lars Ingebrigtsen
@ 2020-10-05  9:21                 ` João Távora
  2020-10-06  1:26                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 11+ messages in thread
From: João Távora @ 2020-10-05  9:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 43543, Yuan Fu, felician.nemeth, andreyk.mad

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm...  Logical lines is fine by me, but I wonder whether visual lines is
> slightly more logical here?  This is for display purposes, after all.

This is what I thought initially too, and it is still arguable.  But
logical makes _more_ sense, because frequently you're usually truncating
pieces of documentation that come packages in a line.  So you'd normally
want to use the separation between each piece as a cutting point.

Additionally, the control over this dimension as visual lines is already
offered by max-mini-window-height, so offering an ElDoc-specific option
here seems like overkill (with added complexity and added bugs, as we
saw).

So the alternative to my current approach is that we find some other way
to fix the bug introduced by eldoc-echo-area-display-truncation-message
in the visual-lines implementation (which seems complicated) _and_ add a
logical lines interface for users such as Andrii (whose request also
makes a lot of sense).  I think for now, it's better to skip this
complexity and just make the logical lines interface: if someone is
unsatisfied and can't use max-mini-window-height for some reason, we can
attend to it later.

João








^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#43543: 28.0.50; Supress truncate notice in eldoc
  2020-10-05  9:21                 ` João Távora
@ 2020-10-06  1:26                   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-06  1:26 UTC (permalink / raw)
  To: João Távora; +Cc: 43543, Yuan Fu, felician.nemeth, andreyk.mad

João Távora <joaotavora@gmail.com> writes:

> So the alternative to my current approach is that we find some other way
> to fix the bug introduced by eldoc-echo-area-display-truncation-message
> in the visual-lines implementation (which seems complicated) _and_ add a
> logical lines interface for users such as Andrii (whose request also
> makes a lot of sense).  I think for now, it's better to skip this
> complexity and just make the logical lines interface: if someone is
> unsatisfied and can't use max-mini-window-height for some reason, we can
> attend to it later.

Sure, logical lines makes sense, too, and in practice there's often not
much of a difference (because of how Emacs' documentation is structured).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-10-06  1:26 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21  1:15 bug#43543: 28.0.50; Supress truncate notice in eldoc Yuan Fu
2020-09-21 12:22 ` Lars Ingebrigtsen
2020-09-21 15:54   ` Yuan Fu
2020-09-21 16:21     ` Yuan Fu
2020-09-22 14:20       ` Lars Ingebrigtsen
2020-10-04 11:16         ` João Távora
2020-10-04 14:04           ` Lars Ingebrigtsen
2020-10-04 23:10             ` João Távora
2020-10-05  7:21               ` Lars Ingebrigtsen
2020-10-05  9:21                 ` João Távora
2020-10-06  1:26                   ` Lars Ingebrigtsen

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