emacs | GNU Emacs | |
---|---|---|
11 | 243 | |
67 | 4,258 | |
- | 0.8% | |
0.0 | 9.9 | |
3 months ago | 4 days ago | |
Emacs Lisp | Emacs Lisp | |
GNU General Public License v3.0 only | GNU General Public License v3.0 only |
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 .
GNU Emacs
-
A Love Letter to Intellectualism
gnu.org - contains everything you need to research his philosophy.
stallman.org - personal website, contains a lot of opinion, but I absolutely respect this man in all what he says.
emacs.org (redirects to https://www.gnu.org/software/emacs/) - his non-philosophical work, one of two mainstream console text editors.
-
The KGB, the Computer and Me – The Cuckoo's Egg Story [video]
Forever, there was a file included in stock Emacs, `spook.el`, which could be hooked up to automatically add random strings of "interesting" keywords to each of your email or Usenet messages (in signatures, or in headers like `X-Spook`).
https://www.gnu.org/software/emacs/manual/html_node/emacs/Ma...
Looks like copyright date of 1988:
https://github.com/emacs-mirror/emacs/blob/master/lisp/play/...
https://github.com/emacs-mirror/emacs/blob/master/etc/spook....
Try `M-x spook RET` in an Emacs buffer.
-
How to combine daily journal with general database of people, places, things, etc.
If you want to spare a couple of detours, you probably could start with Emacs Org-mode according to Greenspun's eleventh rule: "Any sufficiently complicated PIM or note-taking program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Org mode."
-
Microsoft is exploring adding a command line text editor into Windows, and it wants your feedback
Emacs: winget install GNU.Emacs
-
Using Common Lisp in Emacs
The whole cl-lib thing is a total disaster:
https://github.com/emacs-mirror/emacs/blob/master/lisp/emacs...
They added cl- as a prefix to each Common Lisp symbol.
FIRST is now called cl-first, CAAAR is now cl-caaar .
I would really prefer if GNU Emacs removes all Common Lisp functionality, instead of creating this really wacky stuff, with discussions about this topic every year.
-
Running SQL Queries on Org Tables
Never too late to try! Take your time. Emacs will outlive us all. https://www.gnu.org/software/emacs/
- Emacs and Shellcheck
-
Free Tech Tools and Resources - MAC Lookup, SQL Tutorials, JSON Converter & More
GNU Emacs is a versatile, open-source text editor that offers extensibility and customization—a sort of self-documenting real-time display editor. Our thanks for the suggestion go to CartanAnnullator.
-
VScode vs Others: the War on Code Editors
Emacs
-
Proof of Concept clang plugin that automatically binds C/C++ -> Lua
Their DEFUN and DEFVAR macros for example let us define a function or a variable that will be available as a Lisp function, and can be used as an ordinary C function from the C code. Emacs is written in pure C99 language and works with both GCC and Clang I believe. We can just define a C function via macro, and it is auto exported and made available to Lisp. For example my first patch to Emacs was for this function (we added "count" argument to make it possible to skip enumerating files in a directory for the case when user code is just interesting if a directory is empty or not):
What are some alternatives?
lsp-bridge - A blazingly fast LSP client for Emacs
Visual Studio Code - Visual Studio Code
homebrew-emacs-plus - Emacs Plus formulae for the Homebrew package manager
Geany - A fast and lightweight IDE
toggleterm.nvim - A neovim lua plugin to help easily manage multiple terminal windows
Atom - :atom: The hackable text editor
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)
uemacs - Random version of microemacs with my private modificatons
lsp-mode - Emacs client/library for the Language Server Protocol
org-roam-ui - A graphical frontend for exploring your org-roam Zettelkasten