emacs VS toggleterm.nvim

The ugly: Handling JSONRPC synchronously. Now that eldoc is in core emacs, LSP is officially supported by core emacs but from this branch https://github.com/emacs-lsp/emacs/tree/json-rpc-29 it looks like core emacs still handles JSONRPC synchronously and blocking.

Without perf profile, it is hard to say. For starters, you may remove lsp-ui. After this: https://emacs-lsp.github.io/lsp-mode/page/performance/ it should be good enough for most use usecases. If you want blazingly fast lsp-mode, you need the LSP Emacs fork https://github.com/emacs-lsp/emacs which is another beast(see https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ as well).

https://emacs-lsp.github.io/lsp-mode/page/performance/ . If this doesn't do, then https://github.com/emacs-lsp/emacs

The other major performance boost is if you're using lsp-mode and this fork. And an lsp-server that sends waaay too much info, I guess.

lsp-mode is async, but sending the messages. If the server is busy and not reading the input messages then lsp-mode will block. The only way ATM to avoid the issue is to use https://github.com/emacs-lsp/emacs .

I disagree. When I am running a compilation (with output being dumped into a visible buffer) + query magit for large commit. Over tramp. Things noticeably freeze. Technically it all is async. Practically, it is implemented as polling things on main thread with some witing happening in non-async fashion.

> For example, querying your compiler for a list of methods that apply to the current object, or a list of functions that start with “Foo” are mostly moving to external processes using LSP as the communication protocol.

That's why we have lsp-bridge and lsp-mode emacs fork :) Both of which build some infrastructure to avoid doing communication work with lsp-mode work in main emacs thread. So, heavy emacs users are building some async machinery which wraps another already async and relatively lightweight protocol, because core emacs facilities can't keep up with it. Architecturally it is kind of insane.

I think, lsp-mode fork is doing the right thing (from practical POV; it goes against "emacs is just an elisp interpreter" ideology though) and hope it gets into core at some point. A better solution would have being having first class async and background threads support at the elisp level. Which would never happen due to elisp messiness.

https://github.com/emacs-lsp/emacs

Locks: https://www.gnu.org/software/emacs/manual/html_node/elisp/Mu...

Semaphores are not there, my mistake; I was thinking about: https://www.gnu.org/software/emacs/manual/html_node/elisp/Co...

That's basically what every other threading library provides in most languages... and it's also what was shown time and again to be very hard to work with directly. Higher-order abstractions are necessary to make parallelism safe and concurrency convenient.

> and atomicity is guaranteed apart from when you use these calls. So you'd never be in a problem state of `setq` failing halfway, for example.

That's true - it looks like Emacs uses a global lock to ensure the atomicity, similarly to what Python does. Also like in Python, you can release that lock from native code (module or core). You cannot touch any interpreter state from other threads, so you need a bit of plumbing to get the results back, but it's possible. I found this: https://github.com/emacs-lsp/emacs/blob/json-rpc/src/json.c very interesting: it's a fork that moves JSONRPC from Lisp to C and out of the main thread. See for example line 1109 and related.

> but threads are pretty useful already if hard to code with.

That's the point: the capabilities are there (mostly), but abstractions are not. Coding with threads, even in the presence of the global lock, is hard, and ensuring correctness is nontrivial. At the very least we should get channels for communication (share by communicating, don't communicate by sharing) between threads and thread pools for executing tasks (like futures in Java or Python, or Task in Elixir). Threads and locks are way too low-level for normal coding. I suspect that's the reason why they're not used more widely, even though they're there for the third(?) release now.

Aside: Racket is actually a nice example of concurrency and parallelism being treated as completely separate concerns. IIRC threads in Racket are call/cc-based green threads, while places are separate instances of the VM that execute in OS-level thread or separate process. Threads provide concurrency and places provide parallelism. It's actually a good thing, I think. Mixing the two is often a major source of errors. Racket also has futures, which are parallel-if-possible primitives that can benefit from parallelism if they don't touch external state - a sort of a middle ground.

In any case: yes, Elisp threads are a good addition to the language, but they alone are not enough to bring concurrency to the masses, so to speak. As a concurrency primitives, and compared to callbacks, they have few advantages and some serious downsides. Emacs still needs a lot of work on the concurrency front. And don't even mention parallelism, that's another can of worms that we don't really need to open :)

In order for that to work, you have to use the json-rpc branch from here: https://github.com/emacs-lsp/emacs .

As a data point, I'd like to chime in here. I have been a 15 year user of tmux (and screen before that) and never thought I'd change my development habits. Over the holidays I decided I would do one of those once-every-five-years upgrades to my vim setup as I had accrued dozens of vendored plugins in normal vim and wanted to see what the big deal with neovim was.

I bit the bullet and evaluated some of the "distributions" (AstroNvim and kickstarter) and played around with all the new lua plugins that I had never thought I needed (why use telescope when FZF-vim worked so well?).

Anyways, after a month of tweaking and absorbing, I found myself running Neovide only, and doing something I never thought I'd see, running tmux from within neovim/neovide. I think this only works (for me) because of session management (there are half a dozen plugins for handling quickly changing 'workspaces') and because the built-in terminal (with a very useful plugin called toggleterm: https://github.com/akinsho/toggleterm.nvim) works so well.

I have not stopped using tmux and layouts, and it sits in another fullscreen iterm2 workspace, but I find that I now spend 90% of my time using a fullscreen neovide and summoning/toggling tmux momentarily for running commands.

Of course, the caveat here is that my preferred mode of operation is being fullscreen as often as possible. I think if your preferred mode of operation is to always see splits then running neovim from the terminal within tmux is still the way to go.

As for why I like neovide? I find the animations, when tweaked to be less 'cool' are extremely useful to see where the cursor jumps to. I am also a huge fan of the fact that I can finally use 'linespace' to put some space between my lines of code -- it is an aesthetic I didn't realize I wanted.

For splitting the terminal you could try either toggleterm or tmux. If you want to send things from one tmux pane to another, then you can use slime. For a toggle-able filetree, you can use nvim tree.

I just found toggleterm which feels awesome. Pretty much exactly what I was looking for to use with Alacritty but even better since its integrated into the rest of my Neovim workflow.

I saw this plugin that tells me how to do it, however I got confused after I added "require("toggleterm").setup({})" in the lazy.lua file and installed the package as well using the Lazy command

I tried toggleterm but I wasn't successful.

And I never really got into Gitsigns or vim-fugitive. Lots of people love them, so I'm sure they're great, but I'm happy opening a floating terminal with Toggleterm and using Lazygit.

I agree with u/Bamseg, but you can get what you want using toggleterm.nvim BUT NOT IN FLOAT.

I use gitsigns for linewise operations (blame, reset, etc), and a floating terminal (toggleterm) for everything else. flatten.nvim also helps with nested nvim instances.

but I ended up finding a good enough workaround by using Lazygit through Toggleterm.

Perhaps you want something like https://github.com/akinsho/toggleterm.nvim and make a custom profile? Remapping a key for each extension seems fine as well, just remap it per-buffer inside of on_attach