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

João Távora <[email protected]> writes:

> 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?  

If Harper doesn't work, I would want it to recognize this as quickly as
possible.

>                                                 So what scenario are you
> describing?  One where the harper executable is available but somehow
> non-functional?  

For instance, that appears to be the situation for me.

>                  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.

Ah, I forgot the --stdio in my first test.  Now it connects, but it
hangs until I manually intervene with C-g.  It is probably something
specific to my installation or configuration, so we don't have to debug
this, I am just trying to illustrate the point that more moving parts
(eglot is inherently and necessarily much more complex than my little
flymake backend) can cause issues like this.

> 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.

I do use Eglot and eglot-code-actions for code, and am fine with it.  It
is not that I am unfamiliar with these things, it is just that my
experience nudges me to avoid using LSP as a technology if a simpler
solution is available.

> João
>
> [1]: https://github.com/joaotavora/rassumfrassum
> [2]: https://github.com/cxa/eglotx