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

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

bug#43543: 28.0.50; Supress truncate notice in eldoc


From: João Távora
Subject: bug#43543: 28.0.50; Supress truncate notice in eldoc
Date: Mon, 05 Oct 2020 00:10:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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






reply via email to

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