GNU bug report logs - #64101
29.0.91; Eglot inlay hints rendered out of order

Previous Next

Package: emacs;

Reported by: Krzysztof Klimonda <kklimonda <at> syntaxhighlighted.com>

Date: Fri, 16 Jun 2023 05:57:04 UTC

Severity: normal

Found in version 29.0.91

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Krzysztof Klimonda <kklimonda <at> syntaxhighlighted.com>, João Távora <joaotavora <at> gmail.com>
Cc: 64101 <at> debbugs.gnu.org
Subject: bug#64101: 29.0.91; Eglot inlay hints rendered out of order
Date: Sat, 17 Jun 2023 10:56:30 +0300
> From: Krzysztof Klimonda <kklimonda <at> syntaxhighlighted.com>
> Date: Thu, 15 Jun 2023 23:23:45 +0200
> 
> 
> When using eglot with rust-analyzer some inlay hints are not rendered
> correctly. For example, in the following code snippet, inlay hint for
> the `let vec =` is rendered as such:
> 
> > >>>Vec<Arc<Mutex<Item: 
> 
> and not
> 
> > : <Vec<Arc<Mutex<Item>>>
> 
> It works fine for simple hints (like `let x` in my example).
> 
> Looking at what's happening, it seems eglot is creating separate
> overlays for each element of the returned `InlayHintLabelPart` with
> the same beginning in the buffer. From poking around I've noticed
> that overlays have been rewritten recently, and the order of overlays
> for the given position no longer seems to be fixed.
> 
> Code example below:
> ---8<---8<---8<---
> use std::sync::{Arc, Mutex};
> 
> mod static_uninit;
> 
> struct Item;
> 
> fn test() {
>     let vec = vec![Arc::new(Mutex::new(Item))];
>     let x = 1;
> }
> ---8<---8<---8<---

João, are you looking into this?  Should the overlays created for the
inlay hints be forced to be sorted in some particular order?




This bug report was last modified 2 years and 61 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.