Project infrastructure

[doublep]

I might be interested in working on this project, as it looks like the lightest LSP client for Emacs that works out-of-the box with little configuration. And, unlike Eglot, doesn't make my Emacs freeze to unusable state every ten minutes.

However, not everything works for me. I'm interested in Java, as that's what I use at work. I'm willing to investigate and fix the issues I discover, when I'm able to.

But first I'd like to improve the infrastructure of this project, so that it is easier to install (even if that step is done here, I'd like to improve it for others too), and, most importantly, from my perspective, test. I'm the author of a tool called Eldev, which I'd like to use here.

With minimal changes I have locally achieved that you can e.g. run a standalone Emacs with only LSPCE (and dependencies, of course) inside on given .java (or any other) file. This would make it much easier to work on LSPCE, at least for me.

Another thing I'd want to add would be some Elisp-level test (either ERT or Buttercup, you choose). And after that it would be possible to set up continuous integration on GitHub.

However, before continuing, I'd like to ask if that's generally fine for you. I don't want to spend time on something that will not be merged, so I'm not creating a PR yet.

[zbelial]

Hi @doublep , thanks.

However, not everything works for me. I'm interested in Java, as that's what I use at work. I'm willing to investigate and fix the issues I discover, when I'm able to.

Any issue report or PR is welcome.

But first I'd like to improve the infrastructure of this project, so that it is easier to install (even if that step is done here, I'd like to improve it for others too), and, most importantly, from my perspective, test. I'm the author of a tool called Eldev, which I'd like to use here.

With minimal changes I have locally achieved that you can e.g. run a standalone Emacs with only LSPCE (and dependencies, of course) inside on given .java (or any other) file. This would make it much easier to work on LSPCE, at least for me.

Honestly I've never heard about Eldev before, so I'm not sure what you will do to improve the infrastructure, could you give more details (e.g. where do you think is not easy about installation? what's the obstacle to run a standalone Emacs with only LSPCE?)

Another thing I'd want to add would be some Elisp-level test (either ERT or Buttercup, you choose). And after that it would be possible to set up continuous integration on GitHub.

This is what I always want to do, but have not dirtied my hands already. Contribution is very welcome here.

All in all, I want to keep LSPCE simple ASAP and stable. But I'm not an elisp expert and a rust newbie, so there are a lot to improve in LSPCE. I welcome any kind of help.

[doublep]

My local changes are (weird extension for GitHub to accept it): eldev-preliminary.patch.txt. It's only a preparation, I will create a proper PR with more features if we agree on it.

where do you think is not easy about installation?

You need to manually install all dependency packages. Currently there are three, but what if we add another in future? Every user wishing to upgrade would need to make sure that the new dependency is installed, but I'd envision this to be done automatically. Also, files are not byte-compiled, though this is not terribly important.

My idea is that installation would be as simple as

$ git clone ...  [also, from any directory, not hardcoded]
$ eldev install  [this currently won't work, but will be possible with some more coding]

Of course, users would have to install Eldev first (once, just like Cargo). However, if they don't want to, nothing precludes them from using current installation instruction and just do it as now: Eldev would be an addition and won't be required. In particular, it is only about project infrastructure, at runtime (when installed in any way) LSPCE won't be dependent on Eldev.

what's the obstacle to run a standalone Emacs with only LSPCE?

You need e.g. to install all the dependency packages manually. You need to do that in a separate directory (not ~/.emacs.d) if you want to separate from your normal Emacs. You need to (require 'lspce) every time (though you could do that from command line too), autoloads won't work etc. etc. Eldev does all of this and whatever else for you transparently.

E.g. already now (with the patch above and JDTLS installed) I can just do:

$ eldev emacs ~/path/to/some/File.java

and it will just do the right thing with the following small caveat: I also created file Eldev-local with these two lines:

(setq lspce-server-programs `(("java" "jdtls")))  ; so that it knows about JDTLS
(add-hook 'java-mode-hook 'lspce-mode)  ; so the mode is activated automatically in Java files

I don't want to add it to file Eldev, because that's my local preferences. E.g. other developers (you, for example) probably don't work with JDTLS, but with something else instead.

Another thing I'd want to add would be some Elisp-level test (either ERT or Buttercup, you choose). And after that it would be possible to set up continuous integration on GitHub.

This is what I always want to do, but have not dirtied my hands already.

This was one of my main goal when creating Eldev: simplify testing and, later, continuous integration. If we add test files, running all the test will be as easy as

$ eldev test

This will take care of installing dependencies (in a standalone Emacs, it won't affect your normal Emacs) and even rebuild Rust code as needed (will require more work first, since naturally Eldev is about Elisp; but I use it e.g. in a project that uses Java helpers as well, with some customization).

All in all, I want to keep LSPCE simple ASAP and stable.

As the patch suggests, adding Eldev to infrastructure means only one additional file. And no-one will be forced to use it: current way of installing LSPCE will work just as now.

[maikol-solis]

Hi, I like a lot this package. It's a nice compromise between eglot/lsp mode and lsp-bridge.

Maybe you can grab some ideas from https://github.com/emacs-tree-sitter/tree-sitter-langs. The repo uses extensively the GitHub workflows to compile and test the tree-sitter parsers.

They have a release workflow (https://github.com/emacs-tree-sitter/tree-sitter-langs/blob/master/.github/workflows/release.yml) which compiles all the binaries, and they are installed when people download it from melpa.

If lspce could do something like this, I will be super easy to use in a daily basis.

Best.

[zbelial]

Hi @doublep , thanks for your explaination, and sorry for the late reply, I was a little too busy in the past few days.

As the patch suggests, adding Eldev to infrastructure means only one additional file. And no-one will be forced to use it: current way of installing LSPCE will work just as now.

IIUC, adding eldev is okay for me. But I'd like to create a new branch (e.g. eldev) to merge your commits at first, since I want to test/use it before I really understand how it works, WDYT?

[zbelial]

Hi, I like a lot this package. It's a nice compromise between eglot/lsp mode and lsp-bridge. Hi @maikol-solis , thanks. Very glad you like this package.

Maybe you can grab some ideas from https://github.com/emacs-tree-sitter/tree-sitter-langs. The repo uses extensively the GitHub workflows to compile and test the tree-sitter parsers.

Thanks for providing these information.

I think in the past there was only a very few users, maybe I was the only one :) So I didn't spend too much time on automatic test/build/and so on. When I had a problem, I just modified/tested it locally, although I also wanted to have an CI.

But it seems that more people think lspce is useful and are using it, I'd like to set up Github workflows to help maintain lspce in a good shape. But I'm busy recently, so I think it (I mean integrating with Github workflows) won't happen in the near future. Fortunately @doublep is willing to help in this aspect. After finishing, I think we will have some kind of CI. A big step forward IMO.

Any contribution in this aspect is very welcome :)