unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 10:21:24 +0100	[thread overview]
Message-ID: <878sclgh9n.fsf@gmail.com> (raw)
In-Reply-To: <87lfglqgru.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 05 Oct 2020 09:21:57 +0200")

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








  reply	other threads:[~2020-10-05  9:21 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
2020-10-05  7:21               ` Lars Ingebrigtsen
2020-10-05  9:21                 ` João Távora [this message]
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=878sclgh9n.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).