Tags: patch

1. I already reported this issue with Eglot's eglot--sig-info:

    (when (and (stringp documentation)

It does not show the SignatureInformation's documentation if it's 
not a string but rather of type markup.

This issue is addressed by the attached patch.


2. I found another bug while reading the code:

    (concat "\\<" (regexp-quote label) "\\>")

Here, we try to find the ParameterInformation's label within the 
parameters. And that's the regex used for searching. 
Unfortunately, this regex won't match if the label has a non-word 
character at its beginning or end. Take a look at these examples:

    ELISP> (string-match "\\<bar: \"BAR\"" "foo(bar: \"BAR\", 
    baz)")
    4 (#o4, #x4, ?\C-d)

    ELISP> (string-match "\\<bar: \"BAR\"\\>" "foo(bar: \"BAR\", 
    baz)")
    nil

I tried to use "\\(\\`\\|\\W\\|\\=\\)" instead of "\\<" and 
"\\(\\'\\|\\W\\)" instead of "\\>", but that fixes the problem 
only for the first parameter, somehow. Maybe you have an idea 
which regex would fit here?

Until then, the attached patch just removes the "\\<" and "\\>" 
parts.


3. eglot--sig-info does not highlight the active parameter if it 
does not match the <name>(<params>) pattern. Here's the 
responsible code:

    ;; Ad-hoc attempt to parse label as <name>(<params>)
    (when (looking-at "\\([^(]*\\)(\\([^)]+\\))")
      (setq params-start (match-beginning 2) params-end (match-end 
      2))
      ;; ...
      )
    (when params-start
      ;; ...
      (add-face-text-property
        beg end
        'eldoc-highlight-function-argument))

But we are in fact able to highlight the active parameter, if 
ParameterInformation's label is a pair of numbers, denoting the 
active parameter's position. We just need to nest our conditions 
the other way around.

This issue is addressed by the attached patch.


4. The "documentation" field of both SignatureInformation and 
ParameterInformation can be either of type string or of type 
MarkupContent, according to LSP 3.17. I think we should not format 
the documentation as GitHub-Flavored-Markdown (GFM) because it 
might lead to wrong interpretations/displayings of the doc-string.

This is addressed by the attached patch.


5. There is a little overhead on pattern matching on a pair. 
Instead of

    ((`(,beg ,end)
      (if COND
        (list FOO BAR)
        (append CONS-CELL nil))))

we could simply:

    ((`(,beg . ,end)
      (if COND
        (cons FOO BAR)
        CONS-CELL)))

This is also addressed in the attached patch.


6. Using ": " and "\n" to separate information is not enough of 
separation. This is fixed by the attached patch by using "\n\n" 
instead. Should we make it a customizable variable?