Re: [GNU ELPA] New package: flymake-harper

Philip Kaludercic <[email protected]> writes:

>>
>> What's uncomfortable about harper-ls or LSP in general?
>
> More moving parts and the general sense of uneasiness that that brings
> with it.  I start eglot and manually specify harper-ls.  Since it is
> async it takes a while, but then I get an error message with that the
> connection timed out after 30 seconds.  With my package I just call M-x
> flymake-harper-setup and get an error message right away, which I
> prefer.  I am not sure how universal this preference is, but I know it
> is mine.

You've confused me.  With your package you "get an error message right
away"?  You don't _want_ to get errors, right?  So what scenario are you
describing?  One where the harper executable is available but somehow
non-functional?  Must be, because when an executable isn't available
'M-x eglot' immediately bails.  And unless the server hangs without
responding to the initial contact by Eglot, you also don't get the 30
second wait.  You only get that if the server is silent on stdout but
alive for 30 seconds, and only after 3 seconds of sync wait, and not
without telling Eglot you so.  That's Eglot waiting reasonably for
servers whose startup time is very slow.

But 'harper-ls' doesn't seem to be one of them.  I've just run 'M-x
eglot RET harper-ls --stdio RET' on a Markdown file of the Emacs project
easily, it starts up instantly and tells me french spaces are not
recommended.  Sacré bleu!  Check the attached screenshot.

Anyway, if you want a hassle-free startup of 'harper-ls' make sure the
'eglot-server-programs' is configured accordingly.  Convince its authors
to use sane configuration defaults (the default configuration doesn't
seem to want to check anything but Markdown files, and it didn't really
check grammar).  Also, if you want to join it with other servers, make
sure that 'e-s-programs' points to some multiplexer (there is
Rassumfrassum ([1]) and recently another called eglot-x ([2])).

Then there are the settings of eglot-send-changes-idle-time and
flymake-no-changes-timeout which are both 0.5s by default but you may
lower them slightly to get a more responsive experience.

That said, I agree with you there are clunky parts to LSP yes (server
bugs and configuration process upfront).  But, modesty aside,
Eglot/LSP's "code action" abstraction and its integration with ElDoc and
Flymake is very good.  I encourage you to bind eglot-code-actions to
some key and try it at least once.  That said, I have nothing against
other types of faster spell checker interfaces I think they can probably
be made faster and more responsive.  If the two things could be brought
together it would IMO be ideal.

João

[1]: https://github.com/joaotavora/rassumfrassum
[2]: https://github.com/cxa/eglotx