bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58777: eldoc + eglot does not highlight the function parameter the c


From: João Távora
Subject: bug#58777: eldoc + eglot does not highlight the function parameter the cursor is at
Date: Sat, 12 Nov 2022 21:12:46 +0000

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))

reply via email to

[Prev in Thread] Current Thread [Next in Thread]