241–250 of 267 posts
I’ve seen various opinions about eglot vs lsp-mode… anybody care to explain if eglot is better and in general why it was chosen for inclusion in emacs?
Eglot does not have as many dependencies as lsp-mode and was designed to work closer with Emacs built-ins. Lsp-mode comes with many non-standard gui extensions — with some of them being quite cool, honestly — but they make the setup more complicated. Eglot supposedly just works out of the box.
Earlier quoted context omitted.
For me its been the questionable stewardship of vscode ( https://github.com/omnisharp/omnisharp-vscode/issues/5276 ) driving me away from vscode and the Emacs from Scratch videos from the System Crafters youtube channel driving me towards Emacs. When I was looking for alternatives I stumbled on those videos and they blew me away. Also Emacs 28/29 has been way more welcoming and easy to get started with than when I fi…
As a vscode user considering the move, how difficult would it be to get to the point of making emacs a daily driver? Can it be a pick it up as you go thing? Or would I have to spend a few evenings figuring out the basics and configuration? Is lisp knowledge required?
I am loving all this emacs love lately (I am an emacsophile), but I do find all this attention it is getting suddenly a bit surprising. Is it just that "long lines, LSP, fast syntax hightlighting" is making new people interested, or is it just us neckbeards coming out of the woods? I mean, many of these things are just a package-install away right now. I seldom see vim put in the same lime-light, for instance. Or may…
I think editors like VS Code and I guess Atom etc. to a lesser extend have made a lot more people aware of this and it's caused people to take a new look at emacs since it was doing the same thing decades before and arguably does it better.
Earlier quoted context omitted.
The Emacs ecosystem has a larger contributor pool, and contributing is easier. A bunch of factors off the top of my head: * MELPA making contributing and reaching users easier. * The growth of Emacs packages on GitHub. * The ease of concurrent programming, e.g. emacs-aio. * The learning curve being reduced with spacemacs and Doom. * The continued development of Emacs upstream by its great contributors. * The increase…
> * The ease of concurrent programming, e.g. emacs-aio. There's no such thing. emacs-aio is an extension bolted on top of generators and promises, which is how it was bolted on in Python too - so not bad by itself - but the problem is that nothing in Emacs core supports it. Async in Emacs is still, in 2022, a callback hell, and it's not even supported in newer APIs, like completion-at-point (which is awful - I unders…
However, if I recall there are only a few calls which can switch the context; the usual culprits, such as `thread-yield`, `sleep-for`, `accept-process-output` 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.
Personally, I think this model works much better with the current code in Emacs. It would be good if we could spin up domains like in Racket for true parallelization (which uses channels for communication) as well, but threads are pretty useful already if hard to code with.
I don't believe there are any locks or semaphores at all, but I'm happy to be educated.
EDIT: caveat ofc, that non-Elisp code can be parallel but the filters and sentinels will only run if they can grab the context.
Earlier quoted context omitted.
You can try using emacsserver remotely. I would recommend using SSH proxying instead of messing with emacs over tcp. Personally I use emacs on a large dev machine running in a container in a terminal emulator. I can work from my iPad Pro, iPhone, MacBook Pro, Windows Desktop, Linux Desktop, or any guest machine by just adding one public key. Terminal Emulators are still just GUI apps and fit into the GUI ecosystem. M…
The only time I've seen anyone use "emacs server" or "emacsserver" is to refer to the Emacs Lisp needed to make the command emacsclient (the analog to VS Code's "code" command or TextMate's "mate" command) work. Correct me if I am wrong, but I believe you are using it to refer to running Emacs remotely without a GUI (i.e., with only a terminal emulator as the UI) even though the person you are replying to specificall…
And yes you can run the client using the gui emacs not only terminal emacs.
I assume that's what he is talking about.
Earlier quoted context omitted.
What I tell my programming friends is that if you can see yourself molding your computer user-interface as sort of a hobby, then emacs is most definately for you. If you don't see that as a fun past-time activity, then I would not recommend emacs. For instance, (in my emacs email client) I just made a change where if I want to search the subject I am looking at, and it has a #XXX in it, then the subject search is jus…
which email client do you use?
Earlier quoted context omitted.
> * The ease of concurrent programming, e.g. emacs-aio. There's no such thing. emacs-aio is an extension bolted on top of generators and promises, which is how it was bolted on in Python too - so not bad by itself - but the problem is that nothing in Emacs core supports it. Async in Emacs is still, in 2022, a callback hell, and it's not even supported in newer APIs, like completion-at-point (which is awful - I unders…
Regarding threads, they are definitely more co-operative co-routines than threads. However, if I recall there are only a few calls which can switch the context; the usual culprits, such as `thread-yield`, `sleep-for`, `accept-process-output` 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. Personally, I think this model works…
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 :)
Earlier quoted context omitted.
Regarding threads, they are definitely more co-operative co-routines than threads. However, if I recall there are only a few calls which can switch the context; the usual culprits, such as `thread-yield`, `sleep-for`, `accept-process-output` 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. Personally, I think this model works…
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…
I completely forgot about native modules completely...
I don't think I disagree with anything you've said; though I would add that the fact that not many things use threads means that it's self-fulfilling (for example I have a package in the works and it was _super_ unclear to me about what the semantics of how threads interacted with the existing processes and when you could guarantee certain things ran before others).
Yes, Racket's model is broadly as you've described (and soon ocaml will have a similar model I think?), and imo it works really well.
Earlier quoted context omitted.
Emacs was a great editor just like Nirvana was a great band. It’s influenced every other editor after it. People are always going to love it. But I think all the best ideas from that era have been taken. I like Vim but EMacs won the editor wars
The key with Emacs is that it's an editor that grows : the close mapping between the editor and its code makes it more fluid and natural to extend than any other popular tool I've tried. It's a fuzzy distinction—not something you can put on a feature checklist—but it's made working with Emacs qualitatively different from working with other tools. While Emacs has certainly influenced other editors, none of the ones I'…
I don’t think EMacs or Vim will come back. They have revivals, I came in during one of those. This is definitely one of them.