GNU bug report logs -
#43103
28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Previous Next
Full log
Message #59 received at 43103 <at> debbugs.gnu.org (full text, mbox):
On 01.09.2020 14:11, João Távora wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>>> 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,
>>
>> I mind. Unfortunately.
>>
>>> but if
>>> others do, there are tools to control it, which we can leverage to good
>>> effect. That's it.
>>
>> What tools?
>
> eldoc-echo-area-use-multiline-p, as I mentiond at least 3 times in this
> thread.
In my very first message, I asked what's the point of changing the
strategy if we set this variable to nil.
Please pay attention.
>>> 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.
>
>> And I told you its semantics are broken.
>
> I think you are still confusing M-x eldoc and M-x eldoc-doc-buffer,
> which are two different commands.
Ah, that very well may be.
But if so, your advice wasn't great. M-x eldoc (if it only uses the echo
area) is for showing small hints, not for showing documentation.
> For the record, both commands and
> surrounding functionality can and probably will be improved.
Indeed.
>> Showing the text intended to be displayed in the echo area (one line,
>> usually; maybe a few) in a full-size window is ridiculous.
>
> This is not true in the generality of ElDoc usage, of course: LSP users
> are confronted with very verbose at-point documentation.
And very verbose eldoc messages, then?
> And a window
> and buffer in Emacs are not the same thing, something I assumed you
> knew.
Your point being?
The said buffer is subsequently displayed in a normal window. Not in a
"mini" window akin to minibuffer.
>>> 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.
>>
>> If you try actually reading what I wrote, you might find some
>> actionable suggestions there.
>
> I told you at least once that it's rude to accuse other people of not
> reading your emails. It's a lie and a disrespect for the precious time
> they invest in reading them and replying to them as they see fit.
And it's not rude to snip off a third of the message your are replying
to without any good reason?
> Not
> to mention wholly unproductive. Because I don't have time for this, I'm
> putting you in my ignore list, joined by very few, if anyone. So now
> you'll _know_ that I won't be reading what you write, and the reason why
> I won't.
It must be fun to see (or not see) one's commits surprisingly reverted
because of a message you chose not to read.
This bug report was last modified 4 years and 347 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.