unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Mekeor Melire <mekeor@posteo.de>
To: 62687@debbugs.gnu.org
Cc: joaotavora@gmail.com
Subject: bug#62687: 30.0.50; Eglot (eglot--sig-info): SignatureInformation's Documentation is never shown when it's of type MarkupContent
Date: Thu, 06 Apr 2023 20:34:00 +0000	[thread overview]
Message-ID: <87sfdcn3h8.fsf@posteo.de> (raw)
In-Reply-To: <87wn2on4jj.fsf@posteo.de>

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

2023-04-06 19:49 mekeor@posteo.de:

> 2023-04-06 19:21 mekeor@posteo.de:

> >            (string-match "[[:space:]]*\\([^.\r\n]+[.]?\\)"
> >                          documentation))
> >   (setq documentation (match-string 1 documentation))
>
> Here, we trim the beginning of the documentation-string and 
> extract the first sentence; or rather: We extract the text up to 
> the first dot.
>
> (I guess here is another bug because this regex will cut 
> "a().chain().like().this()" (which might occur inside a 
> documentation-string) off right after the first dot.)
>
> I guess, the motivation for these lines is to reduce the size of 
> the echoed documentation message; i.e. prevent flooding of the 
> echo-area. Large echo-areas take up much of the screen and are 
> annoying.
>
> Personally, I don't think that we should extract only one 
> sentence or so. Instead, I think, `max-mini-window-height' (and 
> `eldoc-echo-area-use-multiline-p') suffices to configure the 
> maximum size of the echo-area.
>
> But, if we decide to stick to the idea of only echoing the first 
> sentence, then I wonder: How do we implement this feature for 
> documentation-markups? How to extract the first sentence of a 
> markup? `string-match' would not work, right?

Another idea would be to echo the documentation up to the first 
newline. That would work especially nice if we stick to use ": " 
as separator between label and documentation. See below.

> >   (unless (string-prefix-p (string-trim documentation) label)
>
> This line makes sure that we do not echo the "first sentence" of 
> the documentation-string if it's a prefix of the label. How 
> often does this happen? Has this been reported as a bug before? 
> It seems rather unlikely to me.
>
> Also, if we decide to stick to this feature, then I wonder: How 
> to recreate the logic of `string-prefix-p' for documentations of 
> type markup?
>
> >     (goto-char (point-max))
> >     (insert ": " (eglot--format-markup documentation))))
>
> Here, we finally format the "first sentence" of the 
> documentation-string and insert it into the temporal buffer 
> which will be echoed later.
>
> Also, does it make sense to pass a documentation of type string 
> into `eglot--format-markup' which will format it as 
> GitHub-Flavored-Markdown (GFM) although the documentation is not 
> of type markup?

Additionally, I don't think that ": " is a good separator between 
the previously inserted label and the documentation. I think we 
should use a newline.

Alternatively, we could make that separator customizable.

But if we decide to stick to ": " as separator, here's a minimal 
patch that makes Eglot echo the SignatureInformation's 
Documentation -- even if it's of type MarkupContent:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 62687.patch --]
[-- Type: text/x-patch, Size: 1385 bytes --]

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 10b6c0cc2ca..a4f859745e7 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -3128,14 +3128,12 @@ for which LSP on-type-formatting should be requested."
           (setq params-start (match-beginning 2) params-end (match-end 2))
           (add-face-text-property (match-beginning 1) (match-end 1)
                                   'font-lock-function-name-face))
-        ;; Decide whether to add one-line-summary to signature line
-        (when (and (stringp documentation)
-                   (string-match "[[:space:]]*\\([^.\r\n]+[.]?\\)"
-                                 documentation))
-          (setq documentation (match-string 1 documentation))
-          (unless (string-prefix-p (string-trim documentation) label)
-            (goto-char (point-max))
-            (insert ": " (eglot--format-markup documentation))))
+        ;; Insert documentation
+        (goto-char (point-max))
+        (unless (null documentation)
+          (insert ": " (if (stringp documentation)
+                         documentation
+                         (eglot--format-markup documentation))))
         ;; Decide what to do with the active parameter...
         (when (and active-param (< -1 active-param (length parameters)))
           (eglot--dbind ((ParameterInformation) label documentation)

  reply	other threads:[~2023-04-06 20:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 21:17 bug#62687: 30.0.50; Eglot (eglot--sig-info): SignatureInformation's Documentation is never shown when it's of type MarkupContent Mekeor Melire
2023-04-06 19:21 ` Mekeor Melire
2023-04-06 19:49   ` Mekeor Melire
2023-04-06 20:34     ` Mekeor Melire [this message]
2023-04-07 22:40 ` bug#62687: [PATCH] Eglot: eglot--sig-info: Show SigInfo Docs if Markup; fix regex for highlighting; etc Mekeor Melire
2023-04-07 23:49   ` João Távora
2023-04-07 23:53     ` João Távora
2023-04-08 14:35     ` Mekeor Melire
2023-04-08 19:47       ` João Távora
2023-04-08 20:44         ` Mekeor Melire
2023-04-08 21:12           ` João Távora
2023-04-08 22:31             ` João Távora
2023-04-09 21:46               ` Mekeor Melire
2023-04-10  7:14                 ` João Távora
2023-04-10 20:02                   ` Mekeor Melire
2023-04-11 11:16                     ` João Távora
2023-04-11 11:47                       ` Mekeor Melire
2023-04-11 12:56                         ` João Távora
2023-04-11 13:53                           ` João Távora
2023-04-11 13:59                             ` Eli Zaretskii
2023-04-09 22:14             ` Mekeor Melire

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=87sfdcn3h8.fsf@posteo.de \
    --to=mekeor@posteo.de \
    --cc=62687@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    /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).