Or maybe I am just more attentive to the coverage now?
Most notably, he had a long-time prohibition of any sort of FFI for both GCC and Emacs.
Yes, the reversal of that policy was more than 12 years ago at this point[1], but note how the first Emacs release with an FFI came out in late 2016[2]. Arguably it's only in the last couple of years that we've seen the floodgates open on the potential of that. E.g. TreeSitter & the SQLite interface in this upcoming Emacs 29 release is only there because of FFI.
I really respect what Stallman's done for the free software movement at large, but I think in this and a few other cases he was fighting yesterday's battles for around two decades too long.
1. https://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00...
It's encouraging to see the big quality of life additions in 29, if only because one person's “just a package-install away” is another's “should be bundled by default”.
And it's not just the headline features. There are many little things from the 29 notes[1] that solve minor niggles or replace chunks of my old “retired” config:
- New command to change the font size globally. To increase the font size, type 'C-x C-M-+' or 'C-x C-M-='; to decrease it, type 'C-x C-M--'; to restore the font size, type 'C-x C-M-0'.
- New command 'restart-emacs'. This is like 'save-buffers-kill-emacs', but instead of just killing the current Emacs process at the end, it starts a new Emacs process (using the same command line arguments as the running Emacs process).
- New command 'rename-visited-file'. This command renames the file visited by the current buffer by moving it to a new location, and also makes the buffer visit this new file.
[1]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
FINALLYYYYYYY!
FWIW, it's also another's "has transitive dependencies that try to brick my computer". Claims like "just a package-install away" would be significantly more convincing if they could fix that (ie, fix (remove) the ability of packages to have transitive dependencies).
(This isn't anything specific to EMACS, to be clear; I've never seen a mainstream package system that bothered to enforce a meaningful limit on the depth of dependency graphs.)
Also Emacs 28/29 has been way more welcoming and easy to get started with than when I first tried 8 or so years ago.
Emacs is free and is free for life.
Also Davids channel is most excellent. There's a discord channel where people are very friendly and helpful as well.
I mean it's free, it comes with it's own compilers and toolchains, it's a lot easier to pick up than vim or emacs or even IntelliJ (that's just got a much more dense UI), so it's become the standard IDE for students. Then, once you've gotten your degree or your training or whatever, you'll probably want to stick with the tool you know.
In the meanwhile, both Vim and Emacs will incorporate the functionality that originally made the new editors popular, so the long time Emacs and Vim users lose almost nothing, did not have to go out of their way to use a new editor, and continued to benefit from the existing advantages of these editors.
I really don't get how watching a PM-type struggle with emacs for two hours at a spell is compelling or instructive. I can struggle with emacs all by myself.
Because it's a lot scarier to struggle alone. Plus as his videos progress and his knowledge progresses he frequently teaches you things that come up and practice a lot as a matter of course.
It's kind of like when you start programming you have to build up your endurance for feeling like you're always in a dark room feeling around... and you convince yourself that it won't be like this one day.
A decade or two later you realize you've become accustomed the darkness...
In case you're considering a career in software, no, the feeling of groping around in the dark never disappears.
Nice one.
http://www.threepanelsoul.com/comic/i-think-so
Also:
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?
That said, if Emacs gets its claws in you you may, like me, lose a fair few evenings and weekends just playing around with various packages and customization options because it's just so fun to tweak.
Among the big list of features missing in Emacs as of now is remote development that way its done is vscode.
Cue Distrotube on YouTube creating a series that makes it really easy to get started with Doom Emacs, and cue me wanting to learn Clojure combined with it being to hard to modify VSCode's Calva and Cursive... and I finally had enough arrows pointing toward Emacs.
Best decision I've ever made. Emacs is slowly consuming all of my workflows. I finally feel like I have the editor of my dreams, it's just a little rough around the edges still.
I hope to contribute to it once I get better.
For years emacs is what I used for C/C++ coding. Then CLion came on the scene, and it would be very hard for me to walk away that from and train my fingers back to meta super land. But it does seem like Emacs is getting competitive as an alternative to IDEs.
My new job is all in Julia, and I suspect emacs will provide a better experience for that than a Jetbrains IDE. I'll give it a whirl.
Where is this, if you don't mind my asking?
I recommend the following packages for your setup:
julia-vterm (https://melpa.org/#/julia-vterm) (https://github.com/shg/julia-vterm.el)
ob-julia-vterm (https://melpa.org/#/ob-julia-vterm) (https://github.com/shg/ob-julia-vterm.el)
FYI, julia-vterm depends on:
julia-mode (https://elpa.nongnu.org/nongnu/julia-mode.html) (https://github.com/JuliaEditorSupport/julia-emacs)
vterm (https://melpa.org/#/julia-vterm) (https://github.com/akermu/emacs-libvterm)
But when I needed python or c I used emacs, though it was always a slog to get to get IDE-like features working. LSP was really a game changer that let me get rid of CDET and ctags and elpy, and has let me continue using emacs now at work. If not for LSP, I almost certainly would be using clion or VScode.
I will say though, the one place emacs doesn't cut it is for jupyter notebooks. VScode really is pretty killer there.
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 in upstream development, with emphasis on bug tracker hygiene. See Lars blog posts.
* LSP/Treesitter being developed, though this doesn't explain why Emacs seems to get more HN visibility than other editors.
If I put my Emacs hat on, perhaps the promise of Emacs is being fulfilled: an ever growing set of interopable, extensible, introspective functionality being useful to a wider set of active users.
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 understand that the origin of this is minibuffer completions and that it might be justified to do everything synchronously, but in-buffer completions should not freeze the editor!)
Now we have threads, but seemingly nobody uses them - not surprising, given that last time I tried I got a segfault pretty quickly (fixed since then). Still, threads? With locks and semaphores? Didn't we all agree that these are not the greatest primitives for concurrency? What about channels or async streams? Not to mention, the threads normally should be preemptively scheduled, while currently they are "mostly cooperative" in Emacs. IOW you can still run code in a thread that will not return control to any other thread, as long as it doesn't do IO. Which would be fine with coroutines, but these are supposedly threads! So you pay in memory for threads but get coroutines, but with pretty fuzzy notion of what's atomic. It's a cosmic horror story.
I'm trying to write a "guide to modern Elisp programming" - there were definitely very interesting and good developments in Emacs Lisp over the last 5 years, and generally the language, coupled with convenience libraries like cl, seq, s, f, and so on, became a very productive environment. EIEIO (and cl-structs) and multimethods (true multimethods, which landed at some point in cl-lib without much fanfare, though they really deserve more attention) are incredibly expressive if you don't mind a bit of syntactic overhead (clojure-style . and .. would be appreciated). cl-loop is incredibly versatile tool that lets you declaratively state almost any kind of iteration and reduction. There's object inspector, there's a package supporting many kinds of refactorings, and of course helpful for rendering information about commands, functions, and variables. It's overall great and productive environment... until you try doing async, unfortunately.
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.
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 :)
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.
Native LSP and Treesitter support for Neovim shipped nearly 18 months ago.
Someone asked if the uptick in interest in the venerable (Neo)Vim and Emacs editors was due to the neckbeards awakening from their hibernation… something to that affect.
What’s interesting about the Neovim community is how young most of the core contributors and those new-to-Vim are. Lots of vs code refugees.
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.