bug#61072: How to change the length of the separation lines in eldoc, used by eglot?

[João Távora]

Felician Nemeth <felician.nemeth@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> Rather,  Eglot should add a markdown-capable element to
>> eldoc-display-functions and hint in the documentation item
>> produced by Eglot's eldoc-documentation-functions that that item
>> has a markdown version (it may also have a plaintext version
>> alongside),  taken directly from the LSP source. The new function
>> would then render the item appropriately.
>
> Maybe I overthink this, but I wonder if it would make sense to specify
> an optional content-type argument instead of a markdown-capable element.
> That way, eldoc could potentially handle raw html texts as well.
> Additionally, this would support different markdown variants.  And I'm
> sure gnus/eww already has some helper functions that eldoc could reuse.
>
> References for the text/markdown content-type:
>   https://www.rfc-editor.org/rfc/rfc7763
>   https://www.rfc-editor.org/rfc/rfc7764#section-3

This could be reasonable.  I've pushed some commits to master addressing
Eldoc/Eglot problems.  The protocol between
eldoc-documentation-functions and eldoc-display-functions is enhanced,
and eldoc-display-in-doc-buffer is now more independent, which could
pave the way for this kind of thing.  See docstring of
eldoc-documentation-functions.

I stopped short of adding :content-type there.  There's not much point
in moving rendering from Eglot to ElDoc if the rendering is going to
suck just as bad.  So I think this has to be analyzed carefully.  Here
are some ideas:

1. Use eww to render HTML, as you suggest.  But how to get that HTML?
   Call an external process?

2. You seem to suggest that eww can render markdown directly.  Sure?

3. Lobby for markdown.el to become more render-friendly, (remove hard
   newlines from paragraphs, remove invisible text, etc.)

4. Make a new Markdown mode based on a tree-sitter grammar

João