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: Stefan Kangas <stefankangas@gmail.com>
Cc: 58777@debbugs.gnu.org, "Michał Dubiel" <majkijin@gmail.com>
Subject: bug#58777: eldoc + eglot does not highlight the function parameter the cursor is at
Date: Sat, 12 Nov 2022 21:12:46 +0000	[thread overview]
Message-ID: <CALDnm50nd_s0zNY9o1H3YSVJ+rT3_sTwvFOkPttNPxR4=v94fA@mail.gmail.com> (raw)
In-Reply-To: <CADwFkmm2+A23zj6_q5RiT=S=7z4Lphqmnv5deofTm8OTTASnUQ@mail.gmail.com>

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

I'd say this looks good. It would be even better with a couple of automated
tests, but then again eglot-tests.el hasn't migrated to Emacs yet.

João

On Sat, Nov 12, 2022, 20:45 Stefan Kangas <stefankangas@gmail.com> wrote:

> Copying in João; please see the below patch.
>
> Michał Dubiel <majkijin@gmail.com> writes:
>
> > Hi,
> >
> > I have noticed an issue with highlighting the function parameters by
> > eldoc when using eglot + pyright python LSP server (version 1.1.276).
> > Assume this very simple python code:
> > ```
> > def function(arg1, arg2, arg3):
> >     pass
> >
> > function(1, 2, 3)
> > ```
> >
> > If the cursor is placed at any of the arguments of the function call
> > statement, eldoc does not highlight the argument the cursor is
> > currently at.
> >
> > This happens because pyright does not include the function name in the
> > returned signature help label when the cursor is inside the
> > parentheses, i.e (cursor denoted as |) :
> > 1. For fun|ction(arg1, arg2, arg3), the returned signature label from
> > pyright is:
> > (function) function: (arg1: Unknown, arg2: Unknown, arg3: Unknown) ->
> None
> >
> > 2. For function(1|, 2, 3) (please notice the cursor is at arg1):
> > (arg1: Unknown, arg2: Unknown, arg3: Unknown) -> None
> >
> > Because in case 2 there is no function name but only the arguments
> > inside the parenthesis, the eglot's `eglot--sig-info' function fails
> > to parse the label correctly and mark the `params-start' and
> > `params-end' variables.
> >
> > I believe a simple fix for this is to change the regexp pattern used
> > for finding the arguments in the function signature label as in the
> > attached patch. It ensures that the parameters are found regardless of
> > whether the function name was included in the signature label or not.
> >
> > Regards,
> > Michal
> >
> > From e9cebcd9aed7d92bd2ea0b692165e5b55adf8084 Mon Sep 17 00:00:00 2001
> > From: Michal Dubiel <majkijin@gmail.com>
> > Date: Sun, 23 Oct 2022 19:54:31 +0200
> > Subject: [PATCH] eglot: Support signature labels without a function name
> >
> > * lisp/progmodes/eglot.el (eglot--sig-info): Support signature labels
> > without a function name.
> > ---
> >  lisp/progmodes/eglot.el | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> > index 71001ba680..f5a00b03c7 100644
> > --- a/lisp/progmodes/eglot.el
> > +++ b/lisp/progmodes/eglot.el
> > @@ -2909,7 +2909,7 @@ for which LSP on-type-formatting should be
> requested."
> >         (let ((active-param (or activeParameter sig-help-active-param))
> >               params-start params-end)
> >           ;; Ad-hoc attempt to parse label as <name>(<params>)
> > -         (when (looking-at "\\([^(]+\\)(\\([^)]+\\))")
> > +         (when (looking-at "\\([^(]*\\)(\\([^)]+\\))")
> >             (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))
>

[-- Attachment #2: Type: text/html, Size: 4094 bytes --]

  reply	other threads:[~2022-11-12 21:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 10:47 bug#58777: eldoc + eglot does not highlight the function parameter the cursor is at Michał Dubiel
2022-11-12 20:45 ` Stefan Kangas
2022-11-12 21:12   ` João Távora [this message]
2022-11-12 21:34     ` Stefan Kangas

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='CALDnm50nd_s0zNY9o1H3YSVJ+rT3_sTwvFOkPttNPxR4=v94fA@mail.gmail.com' \
    --to=joaotavora@gmail.com \
    --cc=58777@debbugs.gnu.org \
    --cc=majkijin@gmail.com \
    --cc=stefankangas@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 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.