You mean like Common Lisp Slime? When Cider started, it was based on slime, later they created a fork and even later created the nrepl protocol.
internet_points3 days ago
I want this but for Haskell :-) Maybe some of the amazing work on dataframe[0] and related libraries could be used for a better Haskell REPL in Emacs. I never much liked the notebook way of working, I prefer having a file of functions alongside a REPL, but time-to-graph is bad, and I don't know if there's a good solution to how the REPL forgets previously defined variables on reloading a file.
Does Haskell have the built in machinery needed for a proper REPL?
throwaway274483 days ago
[flagged]
tadfisher3 days ago
What's not usable about it?
HexDecOctBin3 days ago
You can't scroll without moving the cursor.
skydhash3 days ago
Split the windows and scroll the other windows. Or mark your current position and pop back to it after scrolling.
throwaway274483 days ago
It's slow and buggy and difficult to wrangle to the needs of modern text editing yea?
Look I live in emacs. I cannot explain to you why this is such a shitty experience. I assume there are random assholes around the world who are holding emacs back so they can view their email from a repl or some bullshit.
rudhdb773b3 days ago
I don't think your complaints are a common experience.
I've used neovim for the last 10 years, but before that I used emacs with R for many years at work and it was great, certainly not slow.
throwaway274483 days ago
Emacs is certainly capable of speedy editing; i don't mean to imply otherwise. But there isn't much explanation as to why emacs does things the way it does even if it makes the experience shittier.
skydhash3 days ago
There is just one explanation. The people who develop it like it this way and unless you want to pitch in, your very vague complaints does not really matter.
throwaway274483 days ago
Sure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
skydhash3 days ago
You’re maybe trolling. But what exactly is slow? Or are you a superhuman typing 400 words a minute? Emacs have never crashed on me (I use it daily) and there are things you just can’t speed up. Multithreading just sidesteps the problem while introducing its own can of worms. The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
throwaway274483 days ago
I'm not trolling.
How long does it take to start emacs for you?
> Multithreading just sidesteps the problem while introducing its own can of worms.
In the meantime we're all stuck waiting for package downloads. I don't know the specifics about why emacs can't move to a concurrent model but it's embarrassing at this point
> The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
Yes, it is clear the people who maintain emacs are fine with it. This is why using emacs in 2026 is so shitty.
karthink3 days ago
> In the meantime we're all stuck waiting for package downloads.
I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates.
package.el is catching up to Elpaca in features, but async installs/updates is not one of them.
Can you be more specific about your complaints? It's open source software. If there are bugs we can fix them and submit a pull request.
bitwize3 days ago
Actual multithreading, and a UI that was state-of-the-art sometime later than 1978, might be a good beginning.
jbstack3 days ago
I agree with you on multithreading. But for most Emacs users, the rich and highly customisable keyboard-driven UI (including packages like embark, which-key, transient, hydra, ivy/helm/vertico, etc.) is one of its strengths over traditional GUI IDEs. It doesn't need to be "state of the art" to be good, and there's a reason that Emacs has remained popular despite its age. Sure, it's not going to appeal to most VS Code users, but that isn't the point of Emacs.
bitwize3 days ago
Emacs isn't popular. It might've been in the 90s, but its star has faded now. It has niche appeal at best. Virtually everyone I interact with professionally views it as a dim memory best left in the past, or as something just inscrutably weird. Part of the reason why is "it's the UI, stupid". It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.) Most developers these days were brought up with Windows or Mac; they don't want to pretend to be using a PDP-11 or Lisp machine. One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
karthink3 days ago
> It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.)
> ...
> One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
I started using Emacs on a Mac recently and was pleased to discover that it is, in fact, consistent with other programs.
- Cmd-C/X/V work as expected (copy/cut/paste from system clipboard)
- Cmd-Z undoes,
- Cmd-O brings up the open-file dialog, Cmd-T opens a new tab,
- Cmd-F invokes search and Cmd-L goes to line, and so on.
It uses the same global menu bar as other programs, and setting the font from the menu works. The only thing that didn't work is using Cmd-Shift-? to search through menu bar options. This is GNU's official MacOS build, not the custom-built emacs-mac or emacs-plus packages.
Last year I helped a non-programmer get started with Emacs (for the first time) on a Mac. After a couple of weeks their only remarks were that the customize interface looks a little dated and the config/custom file has a weird format. They never brought up the keybindings or other UI as an issue. Now I understand why -- Emacs is a reasonably good citizen on MacOS.
setopt2 days ago
Just to add to your testimony, Karthik:
On macOS some of the Emacs keybindings also work system-wide. You can e.g. use C-a/e, C-k, and C-n/p/f/b in every macOS text field, like e.g. in browser text fields. This is one of the main macOS features I miss on GNU/Linux. (Actually, that subset of Emacs keybindings even works on iPad with an external keyboard.)
Aside from keybindings, there are also some packages that provide deeper integration with macOS. For example, org-mac-link can save Org-mode links to currently open emails in Mail.app. And the built-in `C-x m` can author emails that are then sent to Mail.app for further processing, if you’re not able to use mu4e and similar (e.g. strict Exchange email servers).
jbstack2 days ago
It's popular in the sense that there's still a large community which actively uses it, develops packages for it, writes about it, etc. I didn't mean to imply that it's popular in the sense that it has widespread or mass adoption.
I think the point you're missing is that Emacs just isn't meant to appeal to people who want a mouse/visual based UI. More traditional editors are "better" for those types of people, but that doesn't make them "better" in any kind of absolute sense like you are implying. There are plenty of people for whom a traditional editor is far worse than Emacs. "Better" is subjective.
I love Emacs, and while that tour doesn't quite look 1978, it sure doesn't look 2026 either. Maybe somewhere in the middle.. yup, 2002 seems about right.
Don't get me wrong, I don't mind old aesthetics, but... yes? Well I wasn't exactly alive in 1978 but all the screenshots look like they are at least 20 years old
jbstack3 days ago
Firstly, the original comment was about UI rather than aesthetics. Secondly, as with everything else in Emacs, you can customise the appearance however you want. Those screenshots are from vanilla Emacs which is admittedly rather ugly. Most people heavily customise, or use an Emacs distro like Spacemacs (https://www.spacemacs.org/) or Doom (https://github.com/doomemacs/doomemacs?tab=readme-ov-file) which have more sensible default appearance configs.
teddyh3 days ago
20 years ago was in 2006, not 1978.
throwaway274483 days ago
I'll submit more bug requests, I guess. But the emacs community is very hostile to criticism.
> Like Clojure Cider
You mean like Common Lisp Slime? When Cider started, it was based on slime, later they created a fork and even later created the nrepl protocol.
I want this but for Haskell :-) Maybe some of the amazing work on dataframe[0] and related libraries could be used for a better Haskell REPL in Emacs. I never much liked the notebook way of working, I prefer having a file of functions alongside a REPL, but time-to-graph is bad, and I don't know if there's a good solution to how the REPL forgets previously defined variables on reloading a file.
[0] https://dataframe.readthedocs.io/en/latest/exploratory_data_...
Does Haskell have the built in machinery needed for a proper REPL?
[flagged]
What's not usable about it?
You can't scroll without moving the cursor.
Split the windows and scroll the other windows. Or mark your current position and pop back to it after scrolling.
It's slow and buggy and difficult to wrangle to the needs of modern text editing yea?
Look I live in emacs. I cannot explain to you why this is such a shitty experience. I assume there are random assholes around the world who are holding emacs back so they can view their email from a repl or some bullshit.
I don't think your complaints are a common experience.
I've used neovim for the last 10 years, but before that I used emacs with R for many years at work and it was great, certainly not slow.
Emacs is certainly capable of speedy editing; i don't mean to imply otherwise. But there isn't much explanation as to why emacs does things the way it does even if it makes the experience shittier.
There is just one explanation. The people who develop it like it this way and unless you want to pitch in, your very vague complaints does not really matter.
Sure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
You’re maybe trolling. But what exactly is slow? Or are you a superhuman typing 400 words a minute? Emacs have never crashed on me (I use it daily) and there are things you just can’t speed up. Multithreading just sidesteps the problem while introducing its own can of worms. The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
I'm not trolling.
How long does it take to start emacs for you?
> Multithreading just sidesteps the problem while introducing its own can of worms.
In the meantime we're all stuck waiting for package downloads. I don't know the specifics about why emacs can't move to a concurrent model but it's embarrassing at this point
> The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
Yes, it is clear the people who maintain emacs are fine with it. This is why using emacs in 2026 is so shitty.
> In the meantime we're all stuck waiting for package downloads.
I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates.
package.el is catching up to Elpaca in features, but async installs/updates is not one of them.
https://github.com/progfolio/elpaca
Can you be more specific about your complaints? It's open source software. If there are bugs we can fix them and submit a pull request.
Actual multithreading, and a UI that was state-of-the-art sometime later than 1978, might be a good beginning.
I agree with you on multithreading. But for most Emacs users, the rich and highly customisable keyboard-driven UI (including packages like embark, which-key, transient, hydra, ivy/helm/vertico, etc.) is one of its strengths over traditional GUI IDEs. It doesn't need to be "state of the art" to be good, and there's a reason that Emacs has remained popular despite its age. Sure, it's not going to appeal to most VS Code users, but that isn't the point of Emacs.
Emacs isn't popular. It might've been in the 90s, but its star has faded now. It has niche appeal at best. Virtually everyone I interact with professionally views it as a dim memory best left in the past, or as something just inscrutably weird. Part of the reason why is "it's the UI, stupid". It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.) Most developers these days were brought up with Windows or Mac; they don't want to pretend to be using a PDP-11 or Lisp machine. One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
> It needs a far better UX out of the box and by "better" I mean "more aligned with what literally every other program you are likely to use does for UX". (Just enabling cua-mode by default, and making the user toggle on "vanilla Emacs", would go far.)
> ...
> One of the truths preached in the Gospel of Mac is that ALL programs need to be consistent with one another, and use the same visual look, menu hierarchy, and keybindings for corresponding commands.
I started using Emacs on a Mac recently and was pleased to discover that it is, in fact, consistent with other programs.
- Cmd-C/X/V work as expected (copy/cut/paste from system clipboard)
- Cmd-Z undoes,
- Cmd-O brings up the open-file dialog, Cmd-T opens a new tab,
- Cmd-F invokes search and Cmd-L goes to line, and so on.
It uses the same global menu bar as other programs, and setting the font from the menu works. The only thing that didn't work is using Cmd-Shift-? to search through menu bar options. This is GNU's official MacOS build, not the custom-built emacs-mac or emacs-plus packages.
Last year I helped a non-programmer get started with Emacs (for the first time) on a Mac. After a couple of weeks their only remarks were that the customize interface looks a little dated and the config/custom file has a weird format. They never brought up the keybindings or other UI as an issue. Now I understand why -- Emacs is a reasonably good citizen on MacOS.
Just to add to your testimony, Karthik:
On macOS some of the Emacs keybindings also work system-wide. You can e.g. use C-a/e, C-k, and C-n/p/f/b in every macOS text field, like e.g. in browser text fields. This is one of the main macOS features I miss on GNU/Linux. (Actually, that subset of Emacs keybindings even works on iPad with an external keyboard.)
Aside from keybindings, there are also some packages that provide deeper integration with macOS. For example, org-mac-link can save Org-mode links to currently open emails in Mail.app. And the built-in `C-x m` can author emails that are then sent to Mail.app for further processing, if you’re not able to use mu4e and similar (e.g. strict Exchange email servers).
It's popular in the sense that there's still a large community which actively uses it, develops packages for it, writes about it, etc. I didn't mean to imply that it's popular in the sense that it has widespread or mass adoption.
I think the point you're missing is that Emacs just isn't meant to appeal to people who want a mouse/visual based UI. More traditional editors are "better" for those types of people, but that doesn't make them "better" in any kind of absolute sense like you are implying. There are plenty of people for whom a traditional editor is far worse than Emacs. "Better" is subjective.
Does this look like 1978 to you? <https://www.gnu.org/software/emacs/tour/>
I love Emacs, and while that tour doesn't quite look 1978, it sure doesn't look 2026 either. Maybe somewhere in the middle.. yup, 2002 seems about right.
And for some reason, most of the screenshots on that page are in super low res, e.g. I see https://www.gnu.org/software/emacs/tour/images/gnus-small.pn... instead of https://www.gnu.org/software/emacs/tour/images/gnus.png , I really don't see why they'd want to make it look even worse.
And then on the other hand you have people like Nicolas Rougier https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fp... or Álvaro Ramírez https://xenodium.com/awesome-emacs-on-macos who show how great it can really look.
Don't get me wrong, I don't mind old aesthetics, but... yes? Well I wasn't exactly alive in 1978 but all the screenshots look like they are at least 20 years old
Firstly, the original comment was about UI rather than aesthetics. Secondly, as with everything else in Emacs, you can customise the appearance however you want. Those screenshots are from vanilla Emacs which is admittedly rather ugly. Most people heavily customise, or use an Emacs distro like Spacemacs (https://www.spacemacs.org/) or Doom (https://github.com/doomemacs/doomemacs?tab=readme-ov-file) which have more sensible default appearance configs.
20 years ago was in 2006, not 1978.
I'll submit more bug requests, I guess. But the emacs community is very hostile to criticism.