[feature request] Emit diagnostic hint/info for TODO / HACK / FIXME comments

[Anrock]

Emit a diagnostic hint or info for comments containing TODO:, FIXME:, HACK: with message containing whatever text after opening token.

[Ailrun]

Thank you for the request! It is indeed a very useful feature. PR is welcomed.

[berberman]

Should lsp server be responsible for that? I think it's more like an editor feature though...

[konn]

I strongly agree with @berberman.I think the way of specifying FIXME and/or TODO differs among each individual user, and it should not be handled or hard-coded by a language server. In my opinion, the TODO management functionality is orthogonal to the responsibility Language Server.
Indeed, at least in VSCode, there are plenty of customisable TODO management extensions. To name a few:

• TODO Highlight
• Todo+
• Todo Tree
• ...

I usually use the first two extensions to extract and manage TODO/FIXMEs from the code base, and they are indeed particularly useful.
I don't know the situation in other LSP clients, but it seems at least Emacs has FIXME mode, and vim seems to have native support for highlighting.

As TODO management is a language-agnostic feature and there are several mature enough extensions, I think we should leave users to choose such extensions independent of HLS.

[Ailrun]

@berberman, @konn, I believe it is a LSP feature, not for a single file, but for the entire workspace. Editors don't necessarily know the scope of workspace, and if they don't, they cannot give workspace-based TODO list.

[konn]

FWIW, Todo+ in VSCode DOES picks up TODO/FIXMEs from the entire workspace, not only in TODO file, but also in comments in the codes in the workspace.

[Ailrun]

@konn I think that's because VSCode has a native workspace... and that workspace will not just print TODO of some specific project, but will print all TODOs under the root directory, right?

[Ailrun]

FWIW, eclipse lsp and dart lsp support this feature, AFAIK.

[konn]

I think that's because VSCode has a native workspace...

Ah, yes. So in other clients, we need some configuration for delimiting the search range.

and that workspace will not just print TODO of some specific project, but will print all TODOs under the root directory, right?

Some filtering based on paths can be done. But, yes, it is rather heuristic (and heuristics works in most cases).

To be clear, I agree that TODO management can be provided by an LSP server in a client-agnostic way. And, yes, although there can still be heuristics that works in most cases, the project information available in HLS could be useful to control the reporting precisely.

I'm now convinced that some simple TODO/FIXME comment reporting feature (possibly as an INFO diagnostics?) with a configurable set of TODO-like keywords could make sense.
Still, I think more advanced management features (such as due-date management and tree-view generation) should be implemented independently of HLS, as it brings some language-unrelated complexity to HLS and there are already competing mature implementations.

[Ailrun]

I agree with you, especially in advanced features part. I don't think it is worth (or for some features, even possible) to implement due date / tree view / etc. in LSP server. I think this feature should be limited to simple TODO/FIXME/etc. reporting.

[ndmitchell]

I don't think adding this to HLS would be a good idea. It's completely orthogonal to Haskell. It's something that some people want and some people don't, so needs to have configuration. It's something that itself needs a lot of configuration to do it right. LSP extensions are designed to be composable, so two can be running at once, Why not just pick one of the mature implementations and install it alongside HLS, then you can get exactly the functionality you want.

[Anrock]

@konn RE: existing extensions: of course I tried some extensions before creating this request, but they're all unsatisfiable in some points:

• Only highlighting, no summary all-in-one-place list, which is main point of my request (TODO Highlight)
• Not picking up all TODOs (TODO Tree pickups only todos from multiline comment)
• Require some configuration (Todo+ picking up some garbage from dist-newstyle)
• All require VSCode :)

To clarify my request:

1. I do not expect any advanced features like trees, due dates, separate todo files, formatting, etc. Just emit diagnostic for each TODO item and that's all.
2. I want it to work out-of-the-box with zero configuration:
   2.1 no path management to ignore dist dirs and include all source files
   2.2 no comment token configuration so it must know how to parse haskell comment syntax
3. Editor agnostic

With those points in mind generic editor plugins are not exactly fitting:

• They're all not editor-agnostic by definition
• Probably will require path configuration to ignore dist dirs and include source dirs, since generic todo plugin will not know about your specific project and probably about haskell at all
• Will either require syntax configuration to correctly pick up TODOs (due to Haskell uncommon comment syntax) or they will have false-positive in case they're shotgunning with string.contains("TODO:")

Why it's fitting HLS:

• HLS already knows a lot about your project and about Haskell (comment syntax, files belonging to a project, etc)
• Proposed implementation for 90% will reuse existing facilities of HLS, see previous point.

@ndmitchell RE: configuration. I believe just a single switch to turn it on/off will be enough. I can't speak for all people, obviously, but I believe that majority will find this useful with no further configuration. FIXME/TODO/HACK is semi-standard for this kind of notes.

---

Also, since HLS is "One IDE to rule them all" I don't see a problem in forcing some specific note format. As @Ailrun mentioned Dart does exactly that: it lists all basic todos out of the box and also provides optional diagnostic to force the format of todo to // TODO(username): message, https://URL-to-issue..

[ndmitchell]

Another way of writing my objection. Lets agree N% of people want this feature. If so, we can either turn it off by default (in which case very few people find it, and it's not worth the maintenance time) or we can turn it on by default (if so, 100-N% of people need to reconfigure their editor as the first thing they do). I suspect that for this feature. If N is less than 75 (and I suspect it is, since I definitely don't want it), and at N < 75%, I don't see it being viable either way round. My projects certainly use FIXME/HACK/TODO. I definitely don't want them cluttering valuable screen estate, as they aren't my todo list. Some people use them like that, but my experience is it's the minority.

I think you are saying that you want something which works at the LSP layer and is IDE generic. That sounds great. It seems sad if it also doesn't work for all languages - I certainly have projects with some JavaScript and some Haskell, and if the TODO handling was different between these languages, it would be annoying.