Opportunity for Focus Accessibility Features

[aj-foster]

Hello there 👋🏼

This discussion is to collect ideas, raise awareness, and advocate for others. I decided to open it after a conversation with someone in the community, and realizing there are likely others who could benefit as well.

tl;dr: At its current stage of development, Lexical has an opportunity to introduce features that allow for distraction-free work and better support a wider range of folks than existing tooling. If you're open to this, I'd love to brainstorm what that looks like.

---

In the Elixir community, we have a strong stance against the suppression of warnings. This comes from José:

Honestly, releasing/deploying code with warnings is not an option in my book. The reason we emit warnings instead of errors is because there is no reason to make your compilation fail right out of the box, better to collect the warnings and show them for all files, instead of have the frustrating process of fixing one error just for another one to show up. That's also why we don't plan to provide options for disabling warnings: they should be fixed, even if they don't error out upfront.

I understand this thought process, and indeed have followed it for most of my Elixir career. However, a recent conversation highlighted a situation that some developers face:

1. Some Elixir projects accumulate warnings. This is an unfortunate fact of life: as Elixir versions get upgraded, and as multiple people contribute to a project over time, it is not always the case that everyone involved has time to resolve all of the warnings before shipping. New developers coming in may not have the time, context, or confidence to resolve these warnings while completing their next task. Obviously, on paper, this is a situation that any developer would strive to avoid — but the realities of business don't always allow for the ideal outcome. Working code makes more money than warning-free code.

2. In this (again, unfortunate, but real) scenario, the existing warnings in a project are a distraction from whatever task a developer is attempting to accomplish (unless that task is to resolve the warnings, of course). I would say the same about Dialyzer warnings as well, if it is used.

3. These distractions impact some developers more than others. Based on my experience with various languages and their language servers, the presentation of warnings can range from gentle to annoying: subtly pointing out possible bugs to underlining large swaths of code for minor things. As a neurotypical person, the effect of these annotations on my ability to work is usually small. For others, however, such annotations (and related non-task-oriented information) can be more of an issue.

In my best estimation, this feels like an opportunity that is best addressed by editor extensions, as opposed to the compiler. It's all about the presentation of the available information. And I assume doing so would require additional support by the language server itself. Hence, here we are.

---

I don't want to prescribe a solution in this post. Hopefully folks who are more affected by this topic will feel comfortable enough to jump in and add their thoughts and suggestions. Perhaps the maintainers can propose some ideas as well.

As a final note, although this post was prompted by a conversation around neurodiversity and the differing experiences we all have with development tooling, it's important to remember that everyone can benefit, at one time or another, from greater flexibility when it comes to distraction-free / focus-driven presentation of information related to their work.

Cheers, everyone!

[scohen]

@aj-foster I believe most editors allow customization of if, where and when errors and warnings are displayed. For example, I use emacs, and these things are configurable. I believe VSCode and neovim have similar options.

Is this not sufficient for our purposes?

[scohen]

I'll take your point about the as-you-type completions, but I wonder if a quiescence period is a better option than disabling it entirely. Still, that'd be lexical-specific configuration.

[scottming]

I think this functionality can be configured on the client side. It can be fully configured in Neovim(with Trouble.nvim or something).

I really like the current as-you-type diagnostics, and I don't find them distracting when only the underlining is enabled. When I save, I expect there to be no compilation errors. Saving triggers compilation for the entire project, which can be quite slow in large projects.

[zachallaun]

At the risk of getting too in the weeds on this particular feature, here's how I'd expect it to work:

• on change, diagnostics are still calculated but new ones are not shown
• if a change causes a diagnostic to be removed, it's removed immediately
• on save, all "pending" diagnostics are sent immediately (before waiting for the full project compile)
• after full compile completes, all diagnostics are updated

So yes, this does require some client mechanism for setting configuration options, but I don't think it has any real performance implications compared to what's already happening. Lexical can/should still do the same as-you-type compilation, but would add some mechanism to "buffer" new diagnostics and emit them depending on a configured setting.

@scohen Re: configuration, you obviously know more than I do here, but ultimately configuration settings are just a JSON object sent on initialization and didChangeConfiguration events. While some editors may require clients to specify config options to display in a UI, like VSCode, I think that most editors with built-in LSP support offer a simple way of specifying a config object when you register the language server.

[scohen]

here's how I'd expect it to work:

Why not just disable the file compilers and just let the standard project compiler (and plugins) continue to run on save?

configuration settings are just a JSON object sent on initialization and didChangeConfiguration events

This is somewhat true for vscode (though you still have to write a client to get a nice GUI around it), but different editors handle configuration differently. Emacs, for example requires each client to own its configuration, and as we're piggybacking on elixir-ls's client, we don't have any means to configure lexical there. I think vim is the same.

[scottming]

but different editors handle configuration differently.

yes, that's true, and Vim has multiple modes