I've been a "casual" Emacs user for 20ish years. I've never written a full-blown package, but went thru several cycles of init.el bankruptcy.
In my opinion and from my POV, Elisp is completely fine - no need to amend or replace it. The last thing I'd like is to mix yet another language into my config (already have to call out to shell and AppleScript).
Now I don't know how annoying Elisp is for package authors, or maybe there's a Guile/Scheme library somewhere out there that Emacs could desperately use.
The problems are IMHO elsewhere, and the main one is that Emacs feels antiquated next to literally any text editor conceived in the past 30+ years. The defaults are awful - most of my config is just fixing papercuts, like adding support for light/dark mode, finding a reasonable font and applying text size consistently, locating the correct LSP executable, or following platform conventions for copy/paste (all across Linux, OpenBSD, and macOS).
I would really like it if Magit was a standalone program, rather than an Emacs package, so that I could just switch to a more reasonable editor.
I don't think there is any plan to replace or even supplement ELisp with Guile Scheme. Guile is a language, but it is also a compiler and runtime. The later two have been intentionally designed such that different language front ends can be written to use them. The plan here is to use a new Elisp front end for the Guile compiler and runtime to replace Emacs' custom Elisp interpreter. Extensions and internal implementations will still be written in Elisp.
> maybe there's a Guile/Scheme library somewhere out there that Emacs could desperately use.
It isn't the reason for Guile Emacs, but there is in fact a library Emacs could quite desperately use: fibers (<https://github.com/wingo/fibers>). The Emacs concurrency story is about as bad as you could expect from a 40+ year old application.
> I would really like it if Magit was a standalone program
And what about Org, Org-Roam, Anki-editor, pdf-tools and org-noter, Eshell, gptel and chatgpt-shell, Transient, Vertico, Consult and Embark, Dired, Notmuch and mu4e, elfeed and elfeed-tube, consult-omni, gh-notify and code-review.el and many other nice things?
Sure, Emacs has many deficiencies - nothing is ever perfect. I too, would love to find something better, where those deficiencies are not. But tell me please, which alternative does allow you to do any of these things "reasonably" well?
Tell me, in which editor I can be taking my notes while also sending http requests, and queries to an sql database, while transforming the results in a higher-order language and then spitting out the data into a chart? Where I can also mark things in my notes for spaced repetition, without moving them anywhere, without converting anything. Where my notes can have LaTeX embedded formulas. Where I can type 'RFC 7230' in plain text and my editor would intelligently know what that is and allow me to browse the relevant document in-place. Where I can open any pdf and it would automatically locate my annotated notes. Where I can control the playback of any video - YouTube or whatnot, pausing it for note-taking, grabbing entire paragraphs of its transcript and putting them into my notes.
Tell me, which other editor has the notion of 'indirect buffers', where you can modify the same file working with it as if you're editing multiple files - where I can edit my code comments, treating them as if they are in markdown? Where you can freely edit your directory structure, using all editor features like multi-cursors and other things?
Tell me, which other editor allows me to search things in so many ways. Where else can I type a single query once and it sends out requests to Google, DuckDuckGo, Wikipedia, my browser history, GitHub, etc. and consolidates the results into a single buffer?
Bottom line: there just doesn't exist a reasonable option that is better than Emacs in the sense that it is free from its deficiencies and yet so versatile and powerful.
I agree with this. I've tried replacements. vscode(ium) was closest to giving me what I want, but in the end it really wasn't close. I always keep going back to Emacs, because I can do a lot of the little things that add up to a nice experience; and some of the not so little things. To me, Magit is a great example of what you can do with emacs. I love Helm and Deft too. But it's also those little things, some of which I've coded up for myself in a few lines of elisp.
BTW, those wanting an Emacs, but with Common Lisp rather than elisp can check out the lem-project on Github.
Also, a small point, you'll be thrilled to hear that an excellent "light/dark mode" is included in stock emacs since the modus-themes were beamed up into the mothership, which was several years ago at this stage.
This is not about replacing Emacs Lisp with Guile. It is more about replacing the interpreter and the parts written in C with Guile. Emacs Lisp will still be the language for scripting and the code for the plugins shouldn't change much.
33 years here, and that's *exactly* where I am. Emacs... is fine. I mean, there are new features occasionally that are worth using. There are new paradigms it would be nice for it to support. But major architectural changes just seem silly. It's *done*. How many pieces of software ever get to say that? How many of those are entering their fifth decade of popular use?
Just leave elisp alone. I see nothing but grief and churn in this direction.
When I hear concurrency, I just hear bugs and complexity. Imagine writing some code trying to adjust a package and dealing with concurrent logic. One of the thing that make emacs so easy to modify is the global state. With concurrency you will have to hide database-level code to deal with that, or replace it with a more complicated mechanism (actor models?).
I switched from vim to spacemacs back in 2017, (before recently switching to neovim). Emacs just seemed to have far superior packages compared to vim plugins (circa 2017), and with EViL mode honestly emacs just seemed like a better vim than vim for my use case. The performance though was never very good, but the feature set was amazing. I agree that Magit is hands down the best way to use git that's ever been created.
With my recent switch to neovim, I'd say that neovim is a lot better than emacs for me. I used kickstart.nvim as a launching point to base my config off of, and it's incredible! Neogit is a port of magit to neovim and while it's not quite as feature complete as magit, it's close enough when combined with DiffView.nvim and gitsigns.
Lua is a game changer versus vimscript and I'd say now that the gap in packages has been narrowed greatly and you can turn neovim into a pretty equivalently powerful dev environment to Emacs, while having vastly better performance.
to be honest mostly this is Spacemacs' fault. I left Spacemacs around the time you adopted it and I was shocked at how much more performant Emacs was without all the crap in Spacemacs' layers system
I haven't declared init.el bankruptcy since then, either.
> would really like it if Magit was a standalone program
> Magit (for me) has so much value _because_ it is part of Emacs , where I edit all my code.
Same. I'll never ever understand people saying "I use Emacs but only because of org-mode" or "I use Emacs but only because of Magit".
I use for Emacs for many things, hence org-mode and Magit have a lot of value to me. But they're not that amazing in themselves as to put up with Emacs only for one of these two.
Emacs is quite something: I don't think it's reasonable to use if only for either org-mode or Magit. You risk feeling bitter about it like GP.
I’m one of those “I use Emacs but only because of org-mode” people. I’m an associate professor, so I write a lot: research notes, lecture notes, course exercises, academic papers, task management, etc. Org lets me handle all that in an intuitive, plaintext-backed, keyboard-driven way. I haven’t been able to find something equivalent outside of Emacs, and believe me I’ve tried; the closest was Logseq but it doesn’t have the same editor functionality underneath, and orgmode.nvim + org-roam.nvim but there’s just too much missing still (for example, an equivalent to org-cdlatex-mode and a better table mode) and some features are blocked by issues in Vim and NeoVim themselves (e.g. the long-standing unresolved bug when combining “conceal” with soft-wrapped lines, which makes link hiding unusable). So I use Emacs, because this is a huge part of my workday and its best in Emacs.
But I’m really more a Vim guy. I’ve used it since the mid-2000s, still regularly use it, and all the keybindings and workflows just make sense to me. I even like vim9script as a language (I prefer it over Lua, but I do for sure like Elisp better). If it wasn’t for Org-mode I’d still be using Vim full-time.
> The defaults are awful - most of my config is just fixing papercuts, like adding support for light/dark mode, finding a reasonable font and applying text size consistently, locating the correct LSP executable, or following platform conventions for copy/paste (all across Linux, OpenBSD, and macOS).
This describes virtually every editor on earth. In fact because macos leans so heavily on readline input, emacs comes with far more compatibility with native keybindings than VSCode does. IntelliJ is a downright horror show in this regard.
The runtime environment of emacs is definitely showing its age. Freezes and long pauses of non-interactivity are pretty common, although they do get fixed, new ones are regularly introduced. Separating the language fundamentals from the editor itself seems to show promise in opening up alternatives that allow competing with more modern editors on more even footing.
The ubiquity of readline is a bit of a myth. What happened was that Bash (thus Readline) and NeXT (thus MacOS) independently copied Emacs keybindings, where Emacs predates both. But the Mac GUI doesn’t use the Readline library, and differ in some points (e.g. M-f works in Readline but not MacOS). Moreover, it seems a lot of people think Readline is used everywhere in the CLI, but many popular interpreters use other libraries. For instance, Bash uses Readline but Zsh and Fish uses their own things. Python has used Readline up until now, but is moving away in 3.13. IPython switched from Readline to prompt_toolkit many years ago. Readline was also not the first shell to adopt Emacs keybindings, it was preceded by Ksh IIRC.
I have nothing against Readline, and I understand where you’re coming from since this is often repeated online for some reason. I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)
I called them readline bindings because more people are familiar with readline than emacs. Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.
I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.
I don't really give a damn what they're called or why they exist, so I'll happily call them emacs bindings if that makes more sense to you.
> Furthermore macos certainly doesn't take enough of emacs outside of readline bindings to make me comfortable referring to them as emacs bindings.
That’s fair. But on the other hand they also don’t implement any of the Readline keybindings that are not in Emacs, like for example C-w and C-u to delete the last word and line, respectively.
> I hadn't even noticed that zsh and fish used something other than readline. To me, they effectively are using readline as that's the name for the functionality that's fulfilled.
IMO, that’s like calling Vim and Emacs for “TextEdit” because that’s what they do. I see the argument, but it is confusing.
Readline is one particular library, and it is relevant to many users like me whether it’s used or not. Many alternatives (as used by Fish and IPython for example) have better support for modern features like multi-line editing and syntax highlighting. Conversely, if MacOS actually used libreadline, I should have been able to enable Vi mode in .inputrc and get Vi keybindings in every MacOS text field, which I think many Mac users would want. But alas, MacOS ignores .inputrc, although there is a somewhat equivalent DefaultKeyBinding.dict. If you customize your .inputrc it also quickly becomes apparent that Fish and Zsh for example ignore your Readline settings.
> I just want to point out that it’s actually emacs keybindings and not readline keybindings that is the correct term here :)
Not least, because Readline also supports Vi keybindings (`set editing-mode vi` in `.inputrc`), it just defaults to Emacs keybindings (equivalent to `set editing-mode emacs`).
Sure but nobody's going to refer to the non-default bindings as "readline" bindings. Meanwhile cli prompts are where most users are exposed to emacs bindings.
Not sure what part of Magit you're looking for, but the basic workflow of jumping to changes and interactive staging works just as well to me in `tig` (with Vim) as Magit.
Yeah absolutely, but I'd argue only a tiny subset of that benefits from being integrated with an editor (mainly the parts I listed, jumping to changes and managing the staging area).
I think you can make the case that editor integration with Git is objectively better for the use cases I listed, but a lot of what Magit does is just alternative UI to what Git CLI provides, but I'd have a hard time making the case that either is better than the other, just different.
I always assume when people are asking for Magit in other editors, they just want the parts that are objectively better than Git CLI, but I'm not really sure which is why I asked the question.
If the only antiquated defaults are the ones you listed we're not in a bad shape at all...
Curious about light/dark mode, what does it do more than loading a theme? something like circadian.el? maybe it's because I hide menu-bar/tool-bar/scrollbars by default but `M-x load-theme modus-operandi` is all I need for whenever a room is too bright or a colleague complains about my dark theme.
always thought the problem was not multi-threading per se but the whole rendering code that's single threaded with tons of global state that's difficult to decouple without breaking the ecosystem
Agreed. Having gone through it several times myself, I don't even mind init.el bankruptcy once every 5-10 years. It's kind of rejuvinating to clean house and start anew. And these days the "starter kits" like Doom make it easy to setup sane defaults for 95% of what you want to do.
What really bothers me is the sluggish performance, especially when handling large numbers of buffers or even searching large files. Pretty sure fussing with Elisp is not going to fix that.
For me at least it took a few weeks initially to get a set up I liked but then have barely touched it in ~15 years. I suspect "better defaults" won't happen because it's not a continuing problem users have - like maybe you think about it when you're in the initial setup, but then it becomes less important to any developers.
It's an advanced tool, and typically advanced tools don't come out of the box ready to go.
I feel like this as well sometimes. I have a pretty good setup there's been instances where things like activating the correct Python environment, have the LSP work properly or understand some arcane docs has been an issue. I don't see how Guile fixes any of this and it also suffers anemic docs imo.
lazygit is a TUI app, IMHO that's a step back. I have many reflections on the widespread anachronism that is emulating a 60s piece of hardware - wanna make a blog post about it, but tl;dr imagine you're writing software for a GameBoy Color instead.
You can't even select multi-line text or use ctrl-c to copy text. It's not all that far from being limited to A/B/start/select/d-pad.
I would be in favour of the defaults being "prettified" or "modernised" a bit, but I don't agree that it's that big of an issue.
Actually, I'm not sure if there are any "major" issues... Development has been phenomenally good the last few years, the maintainers have been brilliant. There's a steady stream of contributors, new cool stuff (LSP support, native compilation, etc), improvements are happening regularly.
In summary, Emacs seems to be rock solid, and the quaint little splash screen when you run it for the first time does not seem close to keeping people away! Maybe we need to uglify it :)
But sure, yeah, prettier defaults, why not. I'm not convinced it'd suddenly get more people using Emacs, though, as Doom Emacs already exists, and that's very pretty and well-documented and modern-looking and so on.
In my opinion and from my POV, Elisp is completely fine - no need to amend or replace it. The last thing I'd like is to mix yet another language into my config (already have to call out to shell and AppleScript).
Now I don't know how annoying Elisp is for package authors, or maybe there's a Guile/Scheme library somewhere out there that Emacs could desperately use.
The problems are IMHO elsewhere, and the main one is that Emacs feels antiquated next to literally any text editor conceived in the past 30+ years. The defaults are awful - most of my config is just fixing papercuts, like adding support for light/dark mode, finding a reasonable font and applying text size consistently, locating the correct LSP executable, or following platform conventions for copy/paste (all across Linux, OpenBSD, and macOS).
I would really like it if Magit was a standalone program, rather than an Emacs package, so that I could just switch to a more reasonable editor.