unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 43103@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Date: Mon, 31 Aug 2020 23:50:12 +0100	[thread overview]
Message-ID: <87sgc2ig63.fsf@gmail.com> (raw)
In-Reply-To: <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@yandex.ru> (Dmitry Gutov's message of "Tue, 1 Sep 2020 00:20:59 +0300")

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01.09.2020 00:12, João Távora wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> On 31.08.2020 23:25, João Távora wrote:
>>>
>>>>>>> These is definite wisdom in that.
>>>>>> I see only signs of rudimentary intial design which predates
>>>>>> eldoc-...-multiline-p, composition, Flymake...
>>>>> That doesn't mean the initial design didn't get something right.
>>>>> If it didn't, this aspect would have likely changed by now.
>>>> It couldn't change because there weren't the tools for it to change.
>>>> There are now.
>>> I don't think so. It still uses the echo area.
>> The echo area is not one of the new tools.
> You're making my point here.

If you say so, I really have no clue what your point is.  The echo area
has been there from ElDoc's first design, it is not one of the new tools
that ElDoc offers now.

For your benefit, and to wrap up this exchange, here's a summary of what
I propose: In Elisp mode, I've experimented with the
`eldoc-documentation-compose` strategy and I like the results: it's
useful to have Elisp function signatures, Elisp variable documentation
and Elisp diagnostics displayed somewhere, constantly updated.  I think
other people would like these things, hence my proposal.  I don't mind
the echo area jumping in height one or two lines once in a while, but if
others do, there are tools to control it, which we can leverage to good
effect.  That's it.

>>> One particular way it's unfortunate, is I actually *would* like a
>>> generic "show documentation" feature with an existing key
>>> binding. Shame it doesn't really work for that purpose.
>> Try M-x eldoc and global-set-key and tell us what's missing.
>
> Already told you. I'm not sure how many different ways I can explain
> things, if you keep snipping those explanations out.

You said you wished for a command to "show documentation" and I pointed
you to M-x eldoc, a new command which seems to do what you want, and
that you might not be aware of since it wasn't discussed.  If you don't
wish to pursue this suggestion, fine.  I am in no obligation to waste my
time replying to every new off-topic point you bring up, I do so only
where I think I can add value.  Bickering with you is not one of those
things.

João





  reply	other threads:[~2020-08-31 22:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 15:36 bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy) João Távora
2020-08-29 15:58 ` Eli Zaretskii
2020-08-29 16:07   ` João Távora
2020-08-29 18:17     ` Eli Zaretskii
2020-08-29 20:13       ` João Távora
2020-08-30 14:26         ` Eli Zaretskii
2020-08-30 15:15           ` João Távora
2020-08-31  1:07             ` Dmitry Gutov
2020-08-31  8:38               ` João Távora
2020-08-31 20:03                 ` Dmitry Gutov
2020-08-31 20:25                   ` João Távora
2020-08-31 20:48                     ` Dmitry Gutov
2020-08-31 21:12                       ` João Távora
2020-08-31 21:20                         ` Dmitry Gutov
2020-08-31 22:50                           ` João Távora [this message]
2020-09-01 10:52                             ` Dmitry Gutov
2020-09-01 11:11                               ` João Távora
2020-09-01 11:23                                 ` Dmitry Gutov
2020-08-31  0:47           ` Dmitry Gutov

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=87sgc2ig63.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=43103@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    /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).