Why isn't --fallback-read-dot-merlin the default?

[kit-ty-kate]

I'm not sure why this option exists since it's just a fallback, i see no reason why it shouldn't be the default.
Not everyone use dune, and it sounds weird to have to know in advance if every projects you going to look at or work on, use it.

The dot-merlin-reader binary could simply be part of the merlin library, this way there wouldn't be any optional runtime dependency either.

[rgrinberg]

There was a time when people had a bunch of stale, hand written .merlin files in their source directories that confused users and created a bunch of false bug reports. In general, mixing source files and generated files always seems to have negative consequences like this. That's why I decided to disable this feature by default.

[kit-ty-kate]

but i'm not sure to understand, since it's just a fallback, it's a choice between broken (because lsp has no idea where everything is, since it's not using dune) and another kind of broken if the .merlin file is stale (which should be fixed upstream anyway)

[rgrinberg]

The .merlin in the source will be broken, but lsp has no way of knowing that.

Without the fallback, lsp knows to tell the user they need to build the project. With the fallback present, this suggestion is not always correct.

[voodoos]

In fact, it is not a "fallback" at all:

• When the flag is false, the server uses some custom logic to find that configuration that only detect dune projects
• When the flag is true, the server uses the logic inherited from merlin-lib. This one stops at the first .merlin file it finds and this as priority over the presence of a dune artifacts: it's not fall-backing on an eventual .merlin file in an absence of a dune project.

What we could do instead, is:

• Always try first to find a dune project.
• If that fails, always try to find a .merlin file

And change the name of the flag to: --favor-dot-merlin-files