From: "João Távora" <joaotavora@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 43543@debbugs.gnu.org, Yuan Fu <casouri@gmail.com>,
felician.nemeth@gmail.com, andreyk.mad@gmail.com
Subject: bug#43543: 28.0.50; Supress truncate notice in eldoc
Date: Mon, 05 Oct 2020 00:10:57 +0100 [thread overview]
Message-ID: <87lfglh9j2.fsf@gmail.com> (raw)
In-Reply-To: <87r1qerstf.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 04 Oct 2020 16:04:12 +0200")
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
next prev parent reply other threads:[~2020-10-04 23:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-10-05 7:21 ` Lars Ingebrigtsen
2020-10-05 9:21 ` João Távora
2020-10-06 1:26 ` Lars Ingebrigtsen
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=87lfglh9j2.fsf@gmail.com \
--to=joaotavora@gmail.com \
--cc=43543@debbugs.gnu.org \
--cc=andreyk.mad@gmail.com \
--cc=casouri@gmail.com \
--cc=felician.nemeth@gmail.com \
--cc=larsi@gnus.org \
/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).