bug#73500: eglot: diagnostic location not always shown

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

I'm using `emacs` 29.4 with the `haskell-language-server` 2.8.0.0 on 
NixOS 24.05.

The following code
```haskell
isAscending [x] =True
```
produces the following diagnostic from the lsp
```elisp
(:jsonrpc "2.0" :method "textDocument/publishDiagnostics" :params
           (:diagnostics
            [(:code "-Wunused-matches" :message "Defined but not used: 
‘x’" :range
                    (:end
                     (:character 14 :line 17)
                     :start
                     (:character 13 :line 17))
                    :severity 2 :source "typecheck" :tags
                    [1])
             (:code "-Wmissing-signatures" :message "Top-level binding 
with no type signature:\n  fbeCircle :: 
svg-builder-0.1.1:Graphics.Svg.Core.Element" :range
                    (:end
                     (:character 9 :line 25)
                     :start
                     (:character 0 :line 25))
                    :severity 2 :source "typecheck")]
            :uri 
"file:///home/user/tmp/haskell/test-flake-utils/test/src/Main.hs" 
:version 0))
```
The first diagnostics (corresponding to the above code) is shown in the 
Emacs buffer only with an exclamation mark in the fringe. However, the 
diagnostic message is not shown anywhere unless the cursor is placed on 
the exact location in question (the 'x' in the square brakes). Without 
any visual aid, it's very difficult to pinpoint the exact location of 
the problem to see the message.

The other diagnostic in the same server message, on top of the 
exclamation mark, it's properly highlighted with a blue wiggled 
underline and easy to locate. I'd expect this to happen for all diagnostics.

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

bug#73500: eglot: diagnostic location not always shown

[Eli Zaretskii]

> Date: Thu, 26 Sep 2024 15:49:41 +0200
> From:  Federico Beffa via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I'm using `emacs` 29.4 with the `haskell-language-server` 2.8.0.0 on NixOS 24.05.
> 
> The following code
> ```haskell
> isAscending [x] = True
> ```
> produces the following diagnostic from the lsp
> ```elisp
> (:jsonrpc "2.0" :method "textDocument/publishDiagnostics" :params
>           (:diagnostics
>            [(:code "-Wunused-matches" :message "Defined but not used: ‘x’" :range
>                    (:end
>                     (:character 14 :line 17)
>                     :start
>                     (:character 13 :line 17))
>                    :severity 2 :source "typecheck" :tags
>                    [1])
>             (:code "-Wmissing-signatures" :message "Top-level binding with no type signature:\n  fbeCircle ::
> svg-builder-0.1.1:Graphics.Svg.Core.Element" :range
>                    (:end
>                     (:character 9 :line 25)
>                     :start
>                     (:character 0 :line 25))
>                    :severity 2 :source "typecheck")]
>            :uri "file:///home/user/tmp/haskell/test-flake-utils/test/src/Main.hs" :version 0))
> ```
> The first diagnostics (corresponding to the above code) is shown in the Emacs buffer only with an exclamation
> mark in the fringe. However, the diagnostic message is not shown anywhere unless the cursor is placed on
> the exact location in question (the 'x' in the square brakes). Without any visual aid, it's very difficult to pinpoint
> the exact location of the problem to see the message.
> 
> The other diagnostic in the same server message, on top of the exclamation mark, it's properly highlighted
> with a blue wiggled underline and easy to locate. I'd expect this to happen for all diagnostics.

João, any comments or suggestions?

bug#73500: eglot: diagnostic location not always shown

[João Távora]

I would expect a 1-character long underline for the first one too.

There might be a off-by-one error somewhere, but I doubt it.  I just
tried with clangd a a diagnostic like this:

{"code":"unknown_typename","message":"Unknown type name 'a'",
 "range":{"end":{"character":1,"line":34},"start":{"character":0,"line":34}},
 "severity":1,"source":"clang"}

gets its own small underline.

So, maybe look closer and if you still don't see it, follow the steps in

https://joaotavora.github.io/eglot/#Reporting-bugs

and construct a full error recipe so that we can (not) see it, too.

João

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1080 bytes --]

The attached archive includes everything mentioned at the indicated link.
See the included `README.md` file for instructions on how to reproduce 
the bug (minimally).

It also points to instructions on how to install the Haskell tools, but, 
given that https://github.com/joaotavora/eglot claims support for the 
`haskell-language-server` (and to be up-to-date) I assume you have 
running test benches with everything.

On 28/09/2024 13:47, João Távora wrote:
> I would expect a 1-character long underline for the first one too.
>
> There might be a off-by-one error somewhere, but I doubt it.  I just
> tried with clangd a a diagnostic like this:
>
> {"code":"unknown_typename","message":"Unknown type name 'a'",
>   "range":{"end":{"character":1,"line":34},"start":{"character":0,"line":34}},
>   "severity":1,"source":"clang"}
>
> gets its own small underline.
>
> So, maybe look closer and if you still don't see it, follow the steps in
>
> https://joaotavora.github.io/eglot/#Reporting-bugs
>
> and construct a full error recipe so that we can (not) see it, too.
>
> João

[-- Attachment #1.2: Type: text/html, Size: 1737 bytes --]

[-- Attachment #2: bug73500.tgz --]
[-- Type: application/x-compressed-tar, Size: 290882 bytes --]

bug#73500: eglot: diagnostic location not always shown

[João Távora]

On Sat, Sep 28, 2024 at 4:23 PM Federico Beffa <federico.beffa@fbengineering.ch> wrote:
>
> The attached archive includes everything mentioned at the indicated
> link.  See the included `README.md` file for instructions on how to
> reproduce the bug (minimally).

Thanks.

>  assume you have running test benches with everything.

You assume wrong.  Eglot supports hundreds of servers.  I only have the
servers I work or worked with in the past.  "Supports foo server " means
solely that someone knowledgeable with foo tried it and reported good
results at some point, so they requested to add a server invocation to
eglot-server-programs.

Anyway, I couldn't reproduce your problem simply because the Main.hs
program you provided does not seem to produce any diagnostics, according
the haskell-language-server I installed in my system, which identifies
itself as

haskell-language-server version: 1.9.1.0 (GHC: 9.2.8) (PATH: /usr/bin/haskell-language-server)

I'm not a Haskell programmer, so I don't know if this makes sense to
you.

In the events log, the publishDiagonstics message is the following:

[jsonrpc] e[22:01:33.466] <-- textDocument/publishDiagnostics {
  "jsonrpc": "2.0",
  "method": "textDocument/publishDiagnostics",
  "params": {
    "diagnostics": [],
    "uri": "file:///home/capitaomorte/Downloads/bug73500/src/Main.hs",
    "version": 2
  }
}

Notice the empty JSON array.  However, when I change your Main.hs to
what is likely a nonsensical Haskell program:

    module Main where
     
    isAscending :: [Int] -> Bool
    isAscending [] = True
    isAscending [x] = x
    --                ^ this second 'x' _is_ underlined
    isAscending (x : y : ys) = x < y && isAscending (y : ys)
     
    main :: IO ()
    main = putStrLn "Hello, bug 73500!"

Then I see the second x being underlined with a 1-char-long diagnostic,
the corresponding LSP event being:

[jsonrpc] e[22:05:21.403] <-- textDocument/publishDiagnostics {
  "jsonrpc": "2.0",
  "method": "textDocument/publishDiagnostics",
  "params": {
    "diagnostics": [
      {
        "code": "-Wdeferred-type-errors",
        "message": "• Couldn't match expected type ‘Bool’ with actual type ‘Int’\n• In the expression: x\n  In an equation for ‘isAscending’: isAscending [x] = x",
        "range": {
          "end": {
            "character": 19,
            "line": 4
          },
          "start": {
            "character": 18,
            "line": 4
          }
        },
        "severity": 1,
        "source": "typecheck"
      }
    ],
    "uri": "file:///home/capitaomorte/Downloads/bug73500/src/Main.hs",
    "version": 25
  }
}

I have now removed haskell-language-server from my machine.
João

bug#73500: eglot: diagnostic location not always shown

[João Távora]

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

On Sun, Sep 29, 2024, 18:00 Federico Beffa <federico.beffa@fbengineering.ch>
wrote:

> On 28/09/2024 23:18, João Távora wrote:
>
> On Sat, Sep 28, 2024 at 4:23 PM Federico Beffa
> ... Anyway, I couldn't reproduce your problem simply because the Main.hs
> program you provided does not seem to produce any diagnostics, according
> the haskell-language-server I installed in my system, which identifies
> itself as
>
> haskell-language-server version: 1.9.1.0 (GHC: 9.2.8) (PATH: /usr/bin/haskell-language-server)
>
>
> This is not the version I indicated in the `README.md` file: GHC 9.6.5
> with the supported haskell-language-server 2.8.0.0 (indicated in the
> initial bug report).
>

Well that's the server archlinux has on its repos.

Please use the indicated tool versions.
>

No I won't do that, sorry. Maybe you'll find someone who has time to
install your specific toolkit. But you can try out my recipe and see if you
get the one-char underlines I got.

João

>

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

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1.1: Type: text/plain, Size: 1631 bytes --]

Sure, no problem and nothing changes, the bug is still there.

For that GHC version you need the `bug73500.cabal` in the newly attached 
file (with dropped version constraints). It also includes the new 
`lsp-ghc92.log` transcript of `eglot` events including the diagnostics 
and `screenshot/emacs-ghc92.png` showing the fringe exclamation mark, 
but no underlining.

You must have the package `cabal-instal` providing the executable 
`cabal`. You can test that it works by running `cabal build` in the 
directory containing the cabal file.


On 29/09/2024 19:20, João Távora wrote:
> On Sun, Sep 29, 2024, 18:00 Federico Beffa 
> <federico.beffa@fbengineering.ch> wrote:
>
>     On 28/09/2024 23:18, João Távora wrote:
>>     On Sat, Sep 28, 2024 at 4:23 PM Federico Beffa
>>     ... Anyway, I couldn't reproduce your problem simply because the Main.hs
>>     program you provided does not seem to produce any diagnostics, according
>>     the haskell-language-server I installed in my system, which identifies
>>     itself as
>>
>>     haskell-language-server version: 1.9.1.0 (GHC: 9.2.8) (PATH: /usr/bin/haskell-language-server)
>>
>     This is not the version I indicated in the `README.md` file: GHC
>     9.6.5 with the supported haskell-language-server 2.8.0.0
>     (indicated in the initial bug report).
>
>
> Well that's the server archlinux has on its repos.
>
>     Please use the indicated tool versions.
>
>
> No I won't do that, sorry. Maybe you'll find someone who has time to 
> install your specific toolkit. But you can try out my recipe and see 
> if you get the one-char underlines I got.
>
> João
>

[-- Attachment #1.2: Type: text/html, Size: 3765 bytes --]

[-- Attachment #2: bug73500-ghc92.tgz --]
[-- Type: application/x-compressed-tar, Size: 129310 bytes --]

bug#73500: eglot: diagnostic location not always shown

[João Távora]

On Sun, Sep 29, 2024 at 7:59 PM Federico Beffa
<federico.beffa@fbengineering.ch> wrote:
>
> Sure, no problem and nothing changes, the bug is still there.

So far, there is one sighting of it: yours.  If I were you I would try
out the modified Main.hs program and report if you see the underlined
second x.

If you didn't know, Eglot has virtually 0 haskell-specific code (much
as it has 0 foo-specific code for any language foo).

João

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

A few questions:
* have you checked the provided lsp*.log files which show that the 
diagnostics is sent?
* have you checked the provided screenshots showing an exclamation mark 
in the fringe but no underlining?
* How do you explain the exclamation mark in the fringe which doess not 
appear if eglot is not enabled?
* Do you also see the exclamation mark in the fringe on the line in 
question?
* Does "cabal run" works? Do you see the output? If not please provide 
the complete error message.

If cabal is not working properly then you'll not see any diagnostics 
because the `bug73500.cabal` file includes a compiler directive to 
display all warnings.

Please provide the full `eglot-events-buffer` transcript.

Two `xx` still don't cause underlining.

On 29/09/2024 23:18, João Távora wrote:
> On Sun, Sep 29, 2024 at 7:59 PM Federico Beffa
> <federico.beffa@fbengineering.ch> wrote:
>> Sure, no problem and nothing changes, the bug is still there.
> So far, there is one sighting of it: yours.  If I were you I would try
> out the modified Main.hs program and report if you see the underlined
> second x.
>
> If you didn't know, Eglot has virtually 0 haskell-specific code (much
> as it has 0 foo-specific code for any language foo).
>
> João

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

bug#73500: eglot: diagnostic location not always shown

[João Távora]

On Mon, Sep 30, 2024 at 10:19 AM Federico Beffa
<federico.beffa@fbengineering.ch> wrote:
>
> A few questions:
> * have you checked the provided lsp*.log files which show that the diagnostics is sent?

Yes.  But I don't get that log, as I already showed.

> * have you checked the provided screenshots showing an exclamation mark in the fringe but no underlining?

These are not from emacs -Q so I ignored them. For all I know you may have a
(imaginary-bugs) in your init file. Or have a different setting of the
underlining face
to something that can't be rendered.

A screenshot of a clean Emacs -Q would have been slightly more useful (well
not really useful, but more interesting at least).

> * How do you explain the exclamation mark in the fringe which doess not appear if eglot is not enabled?

That's an odd question.  I don't, of course. Much as I can't "explain"
that grainy
footage that someone says they took of bigfoot.  Maybe bigfoot exists, maybe
it's just a far away hunchback person.  I'll have a better change of
"explaining" something once I can investigate it myself, and so far
I haven't been able to reproduce your sighting.

> * Do you also see the exclamation mark in the fringe on the line in question?

No, when I tried your Emacs -Q recipe I didn't see any diagnostics.  I
thought I
explained that.

> * Does "cabal run" works? Do you see the output? If not please provide the complete error message.

Eglot doesn't interact with cabal, it interacts via LSP with
haskell-language-server.
I can tell you I managed a successful interaction where the server in question
connected perfectly and analized the Main.hs program you provided.  When
Tweaking the program, I got some diagnostics.  As far as I'm concerned
witnessed  first hand in an Emacs -Q session, Eglot correctly underlines all
diagnostics coming from that server, which is not suprising to me, since
they look a lot like any other diagnostic coming from  any other server and
Eglot doesn't care about the provenance of diagnostics.

Also, I uninstalled everything haskell, it bloated up my system and I don't plan
on installing it again..

João

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On 30/09/2024 13:21, João Távora wrote:
> On Mon, Sep 30,
>
>
>     From all your previous replies I expected these answers.
>     Dismissing bug reports without making any serious effort to
>     reproduce them just makes a disservice to your own and to the
>     Emacs projects.
>
>
> I didn't dismiss you bug report, I simply couldn't reproduce. I'm 
> sorry my performance and engagement has not lived up to be your 
> standards. You're welcome to speak to my manager and recommend a pay 
> cut from 0 to 0.
>

Well, let's be honest. You didn't try seriously: did you install all 
required software? No. You did see the logs and screenshots proving the 
problem? Yes, but arbitrarily decided that I was making things up, which 
is false. You're probably angry due to the code lens thread.

And, by the way, I also have and sometimes still do contribute to open 
source projects without any remuneration. That doesn't justify such a 
toxic behavior and answers. Most of the time developers are thankful for 
bug reports, not dismissing them out of pride or whatever.

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

bug#73500: eglot: diagnostic location not always shown

[João Távora]

On Mon, Sep 30, 2024 at 1:08 PM Federico Beffa
<federico.beffa@fbengineering.ch> wrote:
>
> On 30/09/2024 13:21, João Távora wrote:
>
> On Mon, Sep 30,
>>
>>
>> From all your previous replies I expected these answers. Dismissing bug reports without making any serious effort to reproduce them just makes a disservice to your own and to the Emacs projects.
> I didn't dismiss you bug report, I simply couldn't reproduce. I'm sorry my performance and engagement has not lived up to be your standards. You're welcome to speak to my manager and recommend a pay cut from 0 to 0.
> Well, let's be honest.

Yes, let's :-)

> You didn't try seriously: did you install all required software? No.

Should I have installed a Nix Linux distro or ghcup distribution to
get exactly those versions?  I used my Archlinux package manager.
Seemed "serious" enough to me.  I installed a working version of
haskell-language-server which proved to be working correctly and
interfacing with Eglot correctly, sending diagnostics similar to the
ones you reported.

> You did see the logs and screenshots proving the problem?
> Yes, but arbitrarily decided that I was making things up,
> which is false.

I didn't say you made it up.  Why would you? I said the screenshot
you provided was not of Emacs -Q, which is plain to see.

Your Emacs -Q recipe is emacs -Q -l init.el` where init.el is

  (use-package haskell-mode :ensure t)

Did you run this yourself?  I don't think it will produce an Emacs
that has yasnippet, company, whatever WK is, a non-default font size
and possibly a lot more customizations. It won't turn on wombat-theme
as you mentioned (and note that a theme is also a potential culprit,
as it can run arbitrary lisp code).

And what do screenshots help anyway?? I didn't even request
screenshots.  I can't debug a screenshot.  Noone is doubting
your affliction is real, it's just that no one is obliged to stop what
they're doing IRL to help you either.

> You're probably angry due to the code lens thread.

Why on earth would I be angry about that?

> And, by the way, I also have and sometimes still do contribute to open
> source projects without any remuneration.

Good for you.

> That doesn't justify such a toxic behavior and answers.

Get yourself a mirror.  Accusing someone who has spent _any_ amount
of unpaid time analysing your report of not having  making a serious effort
is not a nice thing to do.

> Most of the time developers are thankful for bug reports, not dismissing them out of pride or whatever.

And I am thankful, which is why I thanked you for the recipe, didn't I?
I didn't ask for the bug to be closed, did I?  You'll just have to do the
investigation yourself or wait for someone with enough time or the Nix
system to do a better analysis.  Be patient, sometimes that helps.
(and not harassing maintainers also helps).

You can also follow my recommendation of using Emacs -Q.  I also
suggested you try out my version of Main.hs to see if you get the
underline  I see. You're free to ignore these suggestions but they are
the best I can do with the time I have available.

If that doesn't live up to your standards I'm very sorry, but ultimately
I don't care about what standard of technical support you think
you are entitled to as an Eglot user.

João

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa]

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




-------- Forwarded Message --------
Subject: 	Re: bug#73500: eglot: diagnostic location not always shown
Date: 	Mon, 30 Sep 2024 12:16:53 +0200
From: 	Federico Beffa <federico.beffa@fbengineering.ch>
To: 	João Távora <joaotavora@gmail.com>



On 30/09/2024 11:41, João Távora wrote:
> On Mon, Sep 30, 2024 at 10:19 AM Federico Beffa
> <federico.beffa@fbengineering.ch> wrote:
>> A few questions:
>> * have you checked the provided lsp*.log files which show that the diagnostics is sent?
> Yes.  But I don't get that log, as I already showed.
>> * have you checked the provided screenshots showing an exclamation mark in the fringe but no underlining?
> These are not from emacs -Q so I ignored them. For all I know you may have a
> (imaginary-bugs) in your init file. Or have a different setting of the
> underlining face
> to something that can't be rendered.
>
> A screenshot of a clean Emacs -Q would have been slightly more useful (well
> not really useful, but more interesting at least).

They are, I just enabled manually in the session the wombat theme 
because I prefer dark ones.

>> * How do you explain the exclamation mark in the fringe which doess not appear if eglot is not enabled?
> That's an odd question.  I don't, of course. Much as I can't "explain"
> that grainy
> footage that someone says they took of bigfoot.  Maybe bigfoot exists, maybe
> it's just a far away hunchback person.  I'll have a better change of
> "explaining" something once I can investigate it myself, and so far
> I haven't been able to reproduce your sighting.
>
>> * Do you also see the exclamation mark in the fringe on the line in question?
> No, when I tried your Emacs -Q recipe I didn't see any diagnostics.  I
> thought I
> explained that.
>
>> * Does "cabal run" works? Do you see the output? If not please provide the complete error message.
> Eglot doesn't interact with cabal, it interacts via LSP with
> haskell-language-server.

Nobody said that eglot interacts with cabal. It's the 
`haskell-language-server` that does...  and, as I told several times, 
without cabal you don't get any warning and hence the diagnostics.

> I can tell you I managed a successful interaction where the server in question
> connected perfectly and analized the Main.hs program you provided.  When
> Tweaking the program, I got some diagnostics.  As far as I'm concerned
> witnessed  first hand in an Emacs -Q session, Eglot correctly underlines all
> diagnostics coming from that server, which is not suprising to me, since
> they look a lot like any other diagnostic coming from  any other server and
> Eglot doesn't care about the provenance of diagnostics.
>
> Also, I uninstalled everything haskell, it bloated up my system and I don't plan
> on installing it again..
>
> João

 From all your previous replies I expected these answers. Dismissing bug 
reports without making any serious effort to reproduce them just makes a 
disservice to your own and to the Emacs projects. Never mind, I wanted 
to help the project, but I'll move on to other less buggy and more 
feature reach options.

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

bug#73500: eglot: diagnostic location not always shown

[Dmitry Gutov]

Hi!

I cannot comment on the whole previous discussion, but what I'm seeing 
here's is both diagnostics are rendered, but one of them (the first one) 
gets lost inside the second one visually.

Is that the problem?

On 26/09/2024 16:49, Federico Beffa via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> The first diagnostics (corresponding to the above code) is shown in the 
> Emacs buffer only with an exclamation mark in the fringe. However, the 
> diagnostic message is not shown anywhere unless the cursor is placed on 
> the exact location in question (the 'x' in the square brakes). Without 
> any visual aid, it's very difficult to pinpoint the exact location of 
> the problem to see the message.

That's a fair complaint, but we have a limited number of tools at our 
disposal. For warnings, we use underlines, and the color of the 
underline is set. When there are several diagnostics in the same place, 
they can get difficult to distinguish, true.

> The other diagnostic in the same server message, on top of the 
> exclamation mark, it's properly highlighted with a blue wiggled 
> underline and easy to locate. I'd expect this to happen for all diagnostics.

When you say "this", what exactly would you expect to happen, and when?

Eglot prints diagnostics (through Flymake) at the positions that the 
language server reports them for. The second diagnostic spans the whole 
line; the first one is reported to be just 1 character long.

One existing way to see the warnings separate from each other is invoke 
Flymake's diagnostics buffer: 'M-x flymake-show-buffer-diagnostics'. It 
shows this:

     1   1 warning  e-f-b    typecheck [-Wmissing-signatures]: Top-level 
binding with no type signature:
     1   1 warning  e-f-b    compile [-Wincomplete-patterns]: Pattern 
match(es) are non-exhaustive
     1  14 warning  e-f-b    typecheck [-Wunused-matches]: Defined but 
not used: ‘x’

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Thanks for the constructive answer!

On 01/10/2024 18:08, Dmitry Gutov wrote:
> Hi!
>
> I cannot comment on the whole previous discussion, but what I'm seeing 
> here's is both diagnostics are rendered, but one of them (the first 
> one) gets lost inside the second one visually.
>
> Is that the problem?
>

No, not really. The initial report included a single line code example 
that I extracted from a slightly longer example and produces 3 
diagnostics, one more than the full code that I was using. In the 
following emails I sent the following full example:

```haskell
module Main where

isAscending :: [Int] -> Bool
isAscending [] = True
isAscending [x] = True
--           ^ thix 'x' is not underlined!
isAscending (x : y : ys) = x < y && isAscending (y : ys)

main :: IO ()
main = putStrLn "Hello, bug 73500!"
```

Here I see the fringe exclamation mark on the line above the comment, 
but no underline anywhere. What I'd expect is to see the `x` underlined 
(comment likely off due to non-monospaced fonts in the email).

> One existing way to see the warnings separate from each other is 
> invoke Flymake's diagnostics buffer: 'M-x 
> flymake-show-buffer-diagnostics'. -matches]: Defined but not used: ‘x’
>

Yes, `flymake-show-buffer-diagnostics` shows the diagnostic

     5  13 warning  e-f-b    typecheck [-Wunused-matches]: Defined but 
not used: ‘x’


  It's just the missing underline that's unexpected. Here a screenshot

[-- Attachment #2.1: Type: text/html, Size: 2398 bytes --]

[-- Attachment #2.2: Smr3V0zrFH5D99G7.png --]
[-- Type: image/png, Size: 27676 bytes --]

bug#73500: eglot: diagnostic location not always shown

[Dmitry Gutov]

On 01/10/2024 19:32, Federico Beffa wrote:

>> I cannot comment on the whole previous discussion, but what I'm seeing 
>> here's is both diagnostics are rendered, but one of them (the first 
>> one) gets lost inside the second one visually.
>>
>> Is that the problem?
>>
> 
> No, not really. The initial report included a single line code example 
> that I extracted from a slightly longer example and produces 3 
> diagnostics, one more than the full code that I was using. In the 
> following emails I sent the following full example:

Great! I guess it exhibits something I haven't noticed.

> ```haskell
> module Main where
> 
> isAscending :: [Int] -> Bool
> isAscending [] = True
> isAscending [x] = True
> --           ^ thix 'x' is not underlined!
> isAscending (x : y : ys) = x < y && isAscending (y : ys)
> 
> main :: IO ()
> main = putStrLn "Hello, bug 73500!"
> ```
> 
> Here I see the fringe exclamation mark on the line above the comment, 
> but no underline anywhere. What I'd expect is to see the `x` underlined 
> (comment likely off due to non-monospaced fonts in the email).

That one is using the face eglot-diagnostic-tag-unnecessary-face, which 
you can customize to add an underline or any other decorations.

It was added in commit 0f44d338f17bd4, see the description here 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0f44d338f17bd4

The choice of using 'shadow' is explained with a reference to the 
protocol, which says:

/**
  * Unused or unnecessary code.
  *
  * Clients are allowed to render diagnostics with this tag faded out
  * instead of having an error squiggle.
  */

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticTag

 > Here a screenshot

Same look on my machine.

Should we remove the exclamation point instead, to avoid the semantic 
conflict? I'm not sure, probably not.

bug#73500: eglot: diagnostic location not always shown

[Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

On 01/10/2024 21:48, Dmitry Gutov wrote:
> That one is using the face eglot-diagnostic-tag-unnecessary-face, 
> which you can customize to add an underline or any other decorations.
>
> It was added in commit 0f44d338f17bd4, see the description here 
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0f44d338f17bd4
>
> The choice of using 'shadow' is explained with a reference to the 
> protocol, which says:
>
> /**
>  * Unused or unnecessary code.
>  *
>  * Clients are allowed to render diagnostics with this tag faded out
>  * instead of having an error squiggle.
>  */
>
> https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnosticTag 
>
>

OK, I see, the shadow is so similar the normal font that, before you 
mentioned it, it was unnoticeable to me. But if it's customizable, 
that's great.

> > Here a screenshot
>
> Same look on my machine.
>
> Should we remove the exclamation point instead, to avoid the semantic 
> conflict? I'm not sure, probably not.

Is the exclamation mark used with all warnings? If yes, I'd keep it. 
Even if the warning has a tag equal to 1, it's still a warning.

Thanks for your help!

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

bug#73500: eglot: diagnostic location not always shown

[Dmitry Gutov]

On 01/10/2024 23:18, Federico Beffa wrote:
> On 01/10/2024 21:48, Dmitry Gutov wrote:
>> That one is using the face eglot-diagnostic-tag-unnecessary-face, 
>> which you can customize to add an underline or any other decorations.
>>
>> It was added in commit 0f44d338f17bd4, see the description here 
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0f44d338f17bd4
>>
>> The choice of using 'shadow' is explained with a reference to the 
>> protocol, which says:
>>
>> /**
>>  * Unused or unnecessary code.
>>  *
>>  * Clients are allowed to render diagnostics with this tag faded out
>>  * instead of having an error squiggle.
>>  */
>>
>> https://microsoft.github.io/language-server-protocol/specifications/ 
>> lsp/3.17/specification/#diagnosticTag
>>
> 
> OK, I see, the shadow is so similar the normal font that, before you 
> mentioned it, it was unnoticeable to me. But if it's customizable, 
> that's great.

Yep. I suggest customizing 'shadow' itself then, if it's not noticeable 
enough on your system/theme/etc.

>> > Here a screenshot
>>
>> Same look on my machine.
>>
>> Should we remove the exclamation point instead, to avoid the semantic 
>> conflict? I'm not sure, probably not.
> 
> Is the exclamation mark used with all warnings? If yes, I'd keep it. 
> Even if the warning has a tag equal to 1, it's still a warning.

It is. Sure.

> Thanks for your help!

No problem! Guess we're finished here, so I'm closing the report.