jedi-language-server is the only one that works ok. The choice of the language server is really important, so be careful from next time.
Eglot and etc is merely a json-rpc client.

Eglot is really awful when it comes to dynamic configs like workspace config and initialization option. I really went so far as using environment variable and a shell script for using clangd to support switching cmake binary dir. It’s so much easier with vim.

In case of python, I stick with jedi-language-server for now. When I figure out how to use pyright, I might come back here and comment again.

First two weeks might be difficult. But you’ll stop caring about vi bindings quickly once you have your bindings. It’s like learning how to drive instead of riding a bicycle.

(advice-add 'jsonrpc--log-event :override #'ignore)

I guess for the consistency.
Say you want to copy or paste thing from the command you are typing, can you do the with the same shortcut in the insert mode?

If you are wealthy, happy hacking keyboard. It would be nice if they release thinner alternatives like this, but they are all thick but relatively light except for the new model with a track point. I carry it around.

jedi-language-server + eglot only.
maybe i’ll extend it to support running unit tests.

Worktrees is a tool. .

It’s a git command option actually.

excuse my pedantics.

No i won’t. It’s a fancy git clone by not fully cloning the repo from the existing clone. It’s just space efficient with some extra command options.

I stopped using worktree completely. It’s basically fancy git clone and it’ll leave unnecessary path histories and I have to index the project from scratch as well.

I think git checkout is enough unless you work in a repo where git checkout causes huge recompilation. It’s also a good moment to make a commit to the working branch for reflog when I checkout some PR.
I never use stash either unless i intend to pop the stash within a minute.

It should error out in a such case and you should rebase your local changes from remote whenever you can, manually fixing the conflicts if they exist.

The only use case for no rebase is when you have a gitconfig not to rebase on pull and you manually want to just pull, which is a quite rare use case.

No rebase is the default for both magit and git

Compared to gud, it’s a lot of config, it’s also nasty that it looks like you have to code the program path to your config.

but, it’s a great effort in any case, both from you and the plugin author. Configuration snippets like this help a lot of people.

Does that mean whatever revelation OP might’ve had was misunderstanding?

If you find an available open port(it’s something you don’t have control unless you have an access to network devices between), it’s the matter of starting ssh servers like openssh, dropbear on the system.

It’s all probably against the policy but if there is a free port open, you can start ssh. If not, I agree there is no way to use local emacs. I would just try to compile emacs on the remote machine which is difficult restrict if the direct or indirect internet access is allowed.

I have a similar requirement.
If folder1 and folder2 have different project root marker, it’s possible to start multiple language servers via project-vc-extra-root-markers.

But the tricky part is when it’s started from folder2, it needs to cd to folder1 before executing the language server.

I achieve this by creating a wrapper script for language server and create a function that sets an environment variable before executing the script and does do complex things in the script.

It’d be nice if there was a better solution without depending on .dir-locals.el and etc, like passing a function for the server program so that I don’t have to use a script + environment variable.

The default one. It’s beautiful with white-space mode on.

GNU Emacs is configurable for a reason. Don’t use those complete garbages.
The configuration should be made by you. It’s really not that hard, just start from the tutorial.

GNU Emacs is configurable for a reason. Don’t use those complete garbages.
The configuration should be made by you. It’s really not that hard, just start from the tutorial.

The tramp maintainer wasn’t really keen on innovating anymore so somebody needs to volunteer.

I feel like network filesystem + some remote commands/plugins handler would stabilise things more. Even with sshfs mode, remote command doesn’t work.

It really doesn’t make sense that it supports so many network filesystems and none of them support remote command/process. If I could mount network filesystem locally, I wouldn’t use tramp to begin with.