GNU bug report logs - #79426
diagnostic with empty range => preceding char is highlighted

Previous Next

To reply to this bug, email your comments to 79426 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Donovan <adonovan <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Subject: diagnostic with empty range => preceding char is highlighted
Date: Wed, 10 Sep 2025 18:07:56 -0400

(from https://github.com/joaotavora/eglot/issues/27#issuecomment-3275571619)

The fix for issue #27 (zero-width ranges) included this code:

                       ;; Fallback to `flymake-diag-region' if server
                       ;; botched the range
                       (when (= beg end)
(if-let* ((st (plist-get range :start))
  (diag-region
   (flymake-diag-region
    (current-buffer) (1+ (plist-get st :line))
    (plist-get st :character))))
    (setq beg (car diag-region) end (cdr diag-region))
  (eglot--widening
   (goto-char (point-min))
   (setq beg
 (eglot--bol
  (1+ (plist-get (plist-get range :start) :line))))
   (setq end
 (line-end-position
  (1+ (plist-get (plist-get range :end) :line)))))))

This causes Emacs to highlight the character before the indicated
range, which is often an irrelevant blank space, instead of the
character after, which is the token of interest. (Gopls' nilness
analyzers publishes zero-width diagnostics.)

Why is that the appropriate fix, as opposed to something as simple as this?

                       (when (= beg end)
                         (setq end (1+ end)))

(Aside: "botched" seems like an unnecessarily pejorative: an empty
range is what it is, and sometimes all the information the server has
is the start point of a token.)

There have been two minor changes to that logic since #27 was fixed,
but neither seems relevant to this question:
- 3d9a6f1 Handle case when diagnostic :character is out of range
- 5b62d00 Enable lsp project-wide diagnostics via flymake

I couldn't check for related issues because
https://lists.gnu.org/archive/html/bug-gnu-emacs/ appears to be down.

thanks
alan

Message #8 received at 79426 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Donovan <adonovan <at> google.com>, João Távora
 <joaotavora <at> gmail.com>
Cc: 79426 <at> debbugs.gnu.org
Subject: Re: bug#79426: diagnostic with empty range => preceding char is
 highlighted
Date: Thu, 11 Sep 2025 07:49:52 +0300

> Date: Wed, 10 Sep 2025 18:07:56 -0400
> From:  Alan Donovan via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> (from https://github.com/joaotavora/eglot/issues/27#issuecomment-3275571619)
> 
> The fix for issue #27 (zero-width ranges) included this code:
> 
>                        ;; Fallback to `flymake-diag-region' if server
>                        ;; botched the range
>                        (when (= beg end)
> (if-let* ((st (plist-get range :start))
>   (diag-region
>    (flymake-diag-region
>     (current-buffer) (1+ (plist-get st :line))
>     (plist-get st :character))))
>     (setq beg (car diag-region) end (cdr diag-region))
>   (eglot--widening
>    (goto-char (point-min))
>    (setq beg
>  (eglot--bol
>   (1+ (plist-get (plist-get range :start) :line))))
>    (setq end
>  (line-end-position
>   (1+ (plist-get (plist-get range :end) :line)))))))
> 
> This causes Emacs to highlight the character before the indicated
> range, which is often an irrelevant blank space, instead of the
> character after, which is the token of interest. (Gopls' nilness
> analyzers publishes zero-width diagnostics.)
> 
> Why is that the appropriate fix, as opposed to something as simple as this?
> 
>                        (when (= beg end)
>                          (setq end (1+ end)))
> 
> (Aside: "botched" seems like an unnecessarily pejorative: an empty
> range is what it is, and sometimes all the information the server has
> is the start point of a token.)
> 
> There have been two minor changes to that logic since #27 was fixed,
> but neither seems relevant to this question:
> - 3d9a6f1 Handle case when diagnostic :character is out of range
> - 5b62d00 Enable lsp project-wide diagnostics via flymake
> 
> I couldn't check for related issues because
> https://lists.gnu.org/archive/html/bug-gnu-emacs/ appears to be down.

Thanks, I added João to the discussion.

Previous Next

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