LSP and Evergreen

[Phil Norman]

Hi.

Back in 2018 we briefly exchanged words on LSP (well, I mentioned 'YCM' - still don't like the name - and Elliott said he didn't like it).

I'm back to thinking about it. Although it's quite a lot of work. Elliott: did you do anything in this direction at all, or was it always just a nice idea? I'm kind of tempted to try to get something working.

Cheers,

Phil

[Elliott Hughes]

Nothing useful. I read the docs and got very distracted by their use of line:column coordinates rather than just byte offset, and I may have written some json code, but that was it. 

(I've actually spent far more time in these past few years dicking about writing tty-based editors. They've all been thrown away so far, but there's a lot of little things that work quite well, better than I've seen in any real tty-based editor, presumably because everyone has a "can I reinvent vi or emacs?" mental model rather than an Evergreen/VSC one.)

Cheers,

Phil

--
You received this message because you are subscribed to the Google Groups "evergreen-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to evergreen-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/evergreen-users/CAOa8eG6bm5878tp-pNm3GJKYEz-LQGfvdeKrNwU_J%2BswCcwL2Q%40mail.gmail.com.

[Phil Norman]

Hi again.

I've also had a few vague looks at LSP. The choice of line+col numbers is actually fairly sensible, IMO, as it makes the handling of unicode simpler. Considering that most languages use UTF8, but Java uses UTF16 internally (UTF8 when saving, at least from Evergreen), line+col helps consistency.

However, LSP seems like a lot of effort. I'd either have to write a load of json-mangling boiler-plate, or figure out how to import an existing Java implementation. There is one, and it's available in github, but it's built using Gradle, and I have not the first clue as to how to integrate that into our Makefile system in any kind of sensible way.

Adding LSP support looks like an annoying task I'll never get around to, so instead I've implemented a hacky solution which allows me to write my own auto-complete thing. There's now another way to run external commands now (using '|!' as the prefix), where the tool concerned is expected to spit out special commands which Evergreen will then execute. There's a command to replace a chunk of text, and one to position the selection (or just caret). It might make sense to add a command to open a list of auto-complete suggestions.

I've also augmented the set of environment variables, so that all sub-commands now get $EVERGREEN_CURRENT_CHAR_OFFSET alongside the previous $EVERGREEN_CURRENT_LINE_NUMBER, and also equivalent variables for the end of the current selection ($EVERGREEN_SELECTION_END_LINE_NUMBER and $EVERGREEN_SELECTION_END_CHAR_OFFSET). These make it possible for a tool to implement auto-complete, without requiring the user to select text.

I've implemented a simple auto-completer tool, and stuck it in the new jessies/evergreen/tools directory (called "substituter.go"). If you bind that to a hotkey (run using the new "|!" method), when you hit the hotkey it'll try to auto-complete what's to the left of the caret. If it finds no matching rule, it'll pop up a dialog (using the "yad" program) to ask you to specify one. It accepts normal regexp matching and replacement rules (using ${1} etc). It stores the completion rules in $HOME/.evergreen-substituter.

I haven't really used it in earnest yet, but it seems to work OK. It'll get some proper real-life testing starting tomorrow.

So we still don't have LSP.

Cheers,

Phil

To view this discussion on the web visit https://groups.google.com/d/msgid/evergreen-users/CANZA4YmUUj_4wOrydoSSv724qa3QdSdgjpt-UHDgnnfvbRMMJg%40mail.gmail.com.

[Phil Norman]

Hi again.

It's been a while. The hacky auto-complete solution I mentioned in my last email is working fairly well for me at work, although it does require some effort to fill it in with autocomplete entries.

I recently had a go at using emacs. While I did appreciate the LSP-based autocomplete and some other fancy features, I just can't get around emacs's bloody awful choice of key bindings. Any time I try to use anything other than Evergreen, I just end up coming back again because nothing else seems to allow me to navigate code anywhere near as easily.

So I had another look at the situation with LSPs. It turns out that Google's been nice and released a JSON lib (called 'gson'), and the Eclipse foundation have also been nice and released a "jsonrpc" lib (which builds on gson), and an LSP lib (which uses their "jsonrpc" lib). The result is a really quite usable API.

I managed to hack enough dodgy code into the PTextAreaDemo to prove the concept of using it to generate auto-completions, and I've just spent today implementing it semi-properly in Evergreen itself. It's not submitted yet, and doesn't work quite correctly, but fundamentally this looks very doable, and I think I'll have something working this weekend or next.

There are a couple of questions I have yet to answer; if anyone has strong feelings please let me know. Err, and also please shout if you're actually using Evergreen - I do wonder if I'm the only person on the planet to be doing so.

1: Do we still want to keep the JavaResearcher that provides the existing autocomplete? Or should we just go the LSP-only route for that? If the latter, any ideas as to a good LSP for Java that will work with the Evergreen codebase? I tried 'jdtls', and it complains that nothing's in a workspace and so it won't provide any useful features (I think it's looking for some build system it supports, like gradle or maven or something).

2: I'm considering refactoring the PTextArea a little. Currently PTextBuffer has the raw bytes, but the PTextArea also has both the PLineList (handling the real line structure of the file) *and* the SplitLine stuff, which handles wrapping and is dependent on the width of the PTextArea component. I would like to add both multiple column, and multiple-views-for-one-file support. This would mean we'd want to have the split lines still associated with the PTextArea component, but the PLineList is probably best shared. I'm wondering whether to move the PLineList down into the PTextBuffer, or add an extra component between PTA and PTB. I've not looked into the practicalities of either yet.

3: I started using Sway some time ago (tiling window manager). The auto-complete results list, which is supposed to appear as an undecorated white window right next to the cursor, is actually being turned into a full-scale window, which causes everything else to be shifted about when it opens and closes. I'm wondering whether to try to fix that as it is, or rather to change the 'ctags' thing into an EColumn (although a separate one per workspace) which can contain the ctags along with other stuff. Other stuff could include "open quickly" and "find in files" results, autocomplete results, and the output of running processes (+Errors window - I think we used to have that). This might be a better use of space on modern-sized monitors, and would work better with tiled window managers. Any thoughts on this would be really helpful.

Cheers,

Phil