5 ms·
Julia Snail – An Emacs Development Environment for Julia Like Clojure's Cider
- throwaway27448 7mo ago[flagged]
- tadfisher 7mo agoWhat's not usable about it?
- throwaway27448 7mo agoIt'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.
- rudhdb773b 7mo agoI 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.
- throwaway27448 7mo agoEmacs 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.
- skydhash 7mo agoThere 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.
- throwaway27448 7mo agoSure, but why would you intentionally make such a slow and buggy editor? I don't buy the idea that this is on purpose.
- skydhash 7mo agoYou’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).
- throwaway27448 7mo agoI'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.
- karthink 7mo 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. https://github.com/progfolio/elpaca https://github.com/progfolio/elpaca
- Antibabelic 7mo agoCan 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.
- bitwize 7mo agoActual multithreading, and a UI that was state-of-the-art sometime later than 1978, might be a good beginning.
- teddyh 7mo agoDoes this look like 1978 to you? <https://www.gnu.org/software/emacs/tour/ https://www.gnu.org/software/emacs/tour/>
- PhilipRoman 7mo agoDon'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
- jbstack 7mo agoFirstly, 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/ https://www.spacemacs.org/) or Doom (https://github.com/doomemacs/doomemacs?tab=readme-ov-file https://github.com/doomemacs/doomemacs?tab=readme-ov-file) which have more sensible default appearance configs.
- teddyh 7mo ago20 years ago was in 2006, not 1978.
- internet_points 7mo agoI 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.png https://www.gnu.org/software/emacs/tour/images/gnus-small.pn... instead of https://www.gnu.org/software/emacs/tour/images/gnus.png 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%2Fpbg8rzynfn9e1.png https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fp... or Álvaro Ramírez https://xenodium.com/awesome-emacs-on-macos https://xenodium.com/awesome-emacs-on-macos who show how great it can really look.
- HexDecOctBin 7mo agoYou can't scroll without moving the cursor.
- skydhash 7mo agoSplit the windows and scroll the other windows. Or mark your current position and pop back to it after scrolling.
- deleted 7mo ago[deleted]
- internet_points 7mo agoI 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_analysis_primer.html https://dataframe.readthedocs.io/en/latest/exploratory_data_...
- kgwxd 7mo agoDoes Haskell have the built in machinery needed for a proper REPL?
- miroljub 7mo ago> 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.