emacs
homebrew-emacs-plus
emacs | homebrew-emacs-plus | |
---|---|---|
11 | 68 | |
67 | 2,205 | |
- | - | |
0.0 | 8.0 | |
3 months ago | 10 days ago | |
Emacs Lisp | Ruby | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
emacs
-
The Good, The Bad, and The Ugly
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.
- emacs: Mirror of GNU Emacs
-
is it just me, or LSP mode is very slow in emacs?
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).
-
How do I improve Emacs as a Typescript IDE
https://emacs-lsp.github.io/lsp-mode/page/performance/ . If this doesn't do, then https://github.com/emacs-lsp/emacs
-
Emacs 29 is at least several weeks away
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.
-
Is lsp volar extremely slow or is it just me?
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 .
-
My IDE is too heavy so I moved to 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
-
Emacs 29 is nigh What can we expect?
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 :)
-
Async non-blocking JSONRPC (or lsp performance faster/comparable with other clients)
In order for that to work, you have to use the json-rpc branch from here: https://github.com/emacs-lsp/emacs .
homebrew-emacs-plus
-
Flakes aren't real and cannot hurt you: using Nix flakes the non-flake way
I am intrigued by this line in the description:
"Super Fast Emacs: Bleeding edge Emacs that fixes itself, thanks to a community overlay"
Could you possibly tell me (or link to the explanation) what's special about that Emacs instance? (I'll update this comment if I find a link myself)
I use this homebrew cask and have been very happy with it thus far, but I'm always up for some new exploration. https://github.com/d12frosted/homebrew-emacs-plus
- Emacs Plus
-
Emacs 29.1 Released
Oh, I just realized I'm using https://github.com/d12frosted/homebrew-emacs-plus . I recommend using that over the default formula.
- Thinking about buying a macbook, does Emacs work well?
-
Change the emacs theme to light/dark according to the system theme
There is the code to do just that. Works with emacs-mac and emacs-plus.
-
Need Help with Emacs as a Noob
Firstly as others have mentioned, the default Emacs distribution in macOS is very old and Doom doesn’t support it. If you haven’t already you would be better off downloading a newer version. You can download it straight from the GNU website, but I recommend emacs-plus as it has some macOS niceties thrown in.
-
Emacs Web Buttons
Not a badge, but a modern icon https://github.com/SavchenkoValeriy/emacs-icons
ps. Emacs plus aggregates a great collection https://github.com/d12frosted/homebrew-emacs-plus#icons
- Reinstall emacs with native comp using brew on macos
-
Doom Emacs is broke for me and life just isn't the same
homebrew-emacs-plus generally works for me. I'd recommend it.
-
I asked the AI overlords for an over the top Emacs icon 😅
Awesome! You should create a PR to add it to https://github.com/d12frosted/homebrew-emacs-plus/
What are some alternatives?
lsp-bridge - A blazingly fast LSP client for Emacs
homebrew-emacsmacport - Emacs mac port formulae for the Homebrew package manager
toggleterm.nvim - A neovim lua plugin to help easily manage multiple terminal windows
nix - Nix, the purely functional package manager
codelite - A multi purpose IDE specialized in C/C++/Rust/Python/PHP and Node.js. Written in C++
spacemacs - A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
telega.el - GNU Emacs telegram client (unofficial)
HomeBrew - 🍺 The missing package manager for macOS (or Linux)
lsp-mode - Emacs client/library for the Language Server Protocol
doom - Doom Emacs config
SpaceVim - A community-driven modular vim/neovim distribution - The ultimate vimrc
Rectangle - Move and resize windows on macOS with keyboard shortcuts and snap areas