all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Mekeor Melire <mekeor@posteo.de>
Cc: 62687@debbugs.gnu.org
Subject: bug#62687: [PATCH] Eglot: eglot--sig-info: Show SigInfo Docs if Markup; fix regex for highlighting; etc
Date: Mon, 10 Apr 2023 08:14:19 +0100	[thread overview]
Message-ID: <87v8i4mcok.fsf@gmail.com> (raw)
In-Reply-To: <87ile4g1ou.fsf@posteo.de> (Mekeor Melire's message of "Sun, 09 Apr 2023 21:46:13 +0000")

Mekeor Melire <mekeor@posteo.de> writes:

> 2023-04-08 23:31 joaotavora@gmail.com:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > Unfortunately, that commit causes Eglot to not show the  >
>> "ParameterInformation"'s "documenation" field. I propose to  > show
>> both the SigInfo- and the ParamInfo-documentation,  > whenever
>> possible. (To be more precise: First, the SigInfo-doc  > should be
>> shown, if non-nil. Then, the ParamInfo-doc should be  > shown, if
>> non-nil.) What do you think?
>>
>> I did more changes to master taking that into account. See
>> e33c0a549153fa3894f3b5e9c5e42ce07a1a68c7 and tell me if there's any
>> more stuff missing.
>
> Thank you. That commit is very useful. Let's move on to the next
> thing: Variable-names.

If you mean the names of the formal parameters of a given function and
the ability to display them in the docstring, I think the latest version
handles that already.  I've tested with jdtls,
typescript-language-server, pylsp, and others.

If you mean the local variables names in the Elisp code, then please
let's not touch them.  They might not be up to your standards or ideal
naming, but they help me remember this code, and I have no intention of
changing them.

> If you don't want me tamper with variable-names, then that's fine,
> just let me know and I will further move to the next thing.

You told me my last commit introduced another problem, so I just want to
understand what that new problem is.

> Otherwise, I'd suggest a coherent naming of the
> variables. Specifically, I think we should derive the variable-names
> from the LSP-types (e.g. "SignatureHelp" and
> "ParameterInformation"). A patch is attached. Feel free to apply it or
> do something similar on your own.

Reading your patch, all I see is changed variable names and aliases,
which doesn't help much in reading what behaviour you actually want to
change.  It seems to do exactly the same.  Can you do one of the
following?

1. Re-do your patch without changing names like "siglabel" to
   "sig-info-label".

2. Explain what the problem is in terms of user-visible behaviour.  Like
   "I see 'fooey: foo factor' and I would like to see 'barey: foo
   factor'"

Thanks,
João





  reply	other threads:[~2023-04-10  7:14 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8i4mcok.fsf@gmail.com \
    --to=joaotavora@gmail.com \
    --cc=62687@debbugs.gnu.org \
    --cc=mekeor@posteo.de \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.