bug#50989: 28.0.60; nobreak-char-display in Eldoc buffers

[Augusto Stoffel]

On Sun,  3 Oct 2021 at 12:12, João Távora <joaotavora@gmail.com> wrote:

> On Sun, Oct 3, 2021 at 12:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> IMNSHO, this doesn't make much sense.  That face exists for a reason:
>> to signal to the users that some innocently-looking characters aren't
>> what they look like.
>
> Eldoc's display facilities are only for displaying.  Sure, you may want
> to copy text away from there, but I'd say that's rare.  So it wouldn't
> be a problem
> in practice, unless I'm missing something

I agree -- this is for display only, in which case NBSP and space are
supposed to be indistinguishable.  With the attached patch, if you copy
the text from the Eldoc buffer to some other buffer, the NBSPs are still
there so they will be displayed as such.

>> Why does the server return these NBSP characters?  Would it make sense
>> to automatically convert them to spaces on input?

I don't know for sure what the thinking is in any particular server, but
there are sensible reasons why one might do this.  Suppose, for
instance, that the client editor decides to refill the text before
displaying it.  Then it might be relevant to add NBSPs at strategic
places, and removing them would produce strange results.

> That's also sweeping it under the rug.  But I don't object either.  Augusto, 
> if
> you agree, match a patch to Eglot (this is where I presume the "input"
> Eli refers
> to lives).  Of course the real input is the server, but I'd rather not
> go there, since
> there are so many and all are out of our control.

I don't know how to do this on the Eglot side, or at least not in a
simple manner: Eldoc callbacks take a string, not a buffer, as argument,
and Eldoc buffers are reused whenever possible.

So I've attached a patch implementing the simplistic solution.  Feel
free to ignore it if this seems unsuitable.

0001-Disable-nobreak-char-display-in-Eldoc-buffers.patch
Description: Text Data