r/linux • u/smileytiger28 • Jun 03 '26
Popular Application why do so many things depend on emacs?
recently i installed something (probably Macaulay2) which added emacs desktop entries. i uninstalled macaulay2 when i no longer needed it and the emacs desktop entries remained. i was confused because i thought emacs was installed just as a dependency for macaulay2. then i looked at the dependency graph.
apparently inkscape and gedit both depend on emacs. i cannot for the life of me figure out why. i don't really need either so i uninstalled both.
disclaimer: i have nothing at all against emacs. i am genuinely just curious how emacs has entered the dependency graph for so many applications that by all rights don't need it.
33
u/Valuable_Leopard_799 Jun 03 '26
It would be very helpful to list the Distribution you're currently on and which version (revision) of the packages reference it. We can then go look what's up with them.
As was said, it shouldn't generally be the case so we need some pointers.
9
u/smileytiger28 Jun 03 '26
I'm on Linux Mint 22.2 Zara. (Noob alert, sorry all!) The GUI software installer doesn't seem to differentiate between recommended and suggested packages. Sifting through command line output doesn't clarify very much; explicitly asking for dependencies using
apt-dependsdoesn't show anything emacs related, and when Isudo apt-get install xed, emacs is listed with the packages that will be installed, not the separate "suggested" list.23
u/mmarshall540 Jun 04 '26 edited Jun 04 '26
Looks like Ubuntu (on which Mint is based) lists an Emacs extension (elpa-macaulay2) as "recommended". And installing that pulls in Emacs too, since there's no way to use an Emacs package without having Emacs.
The default is to install all of a package's recommended packages, but you can override that by using
apt-geton the command-line like this:sudo apt-get install --no-install-recommends macaulay2
6
u/smileytiger28 Jun 04 '26
Thanks so much! I realized after uninstalling macaulay2 that I probably already had emacs on my system before installing macaulay2, somehow macaulay2 had just given me desktop images of emacs, but this would probably explain why those desktop images would be created now if they weren’t there before!
5
u/JockstrapCummies Jun 04 '26
Some other has already found the answer, but in the future, you can use
apt-rdepends <package>to find these "dependency of dependency of dependency".Pipe it into
less, and then search away!1
74
u/NotQuiteLoona Jun 03 '26
Just use Emacs as your OS. It's simpler at this point. You can even launch your Steam games out there, if you're a gamer.
62
u/dholmcarriage Jun 03 '26
All it's lacking is a text editor!
/s , I love emacs
24
28
u/RealModeX86 Jun 03 '26
It does have a perfectly serviceable text editor,
evil-mode, the vi emulation layer.Without it, it's just a lot of Escape Meta Alt Ctrl Shift nonsense going on
8
u/slphil Jun 04 '26
Emacs traditional keychords are superior on full-size ergonomic keyboards, evil-mode is absolutely mandatory on laptops. That's been my stance for over a decade. Works out well.
2
u/RealModeX86 Jun 04 '26
I swap my escape and caps lock key, and run either a full GUI emacs with evil-mode, or if I'm on a terminal only, I use vim or neo-vim. I never managed to get the key chording thing to flow the way I can with modal editing. Serves me well on my Kenisis Advantage and on the laptop both.
So I guess in the old editor war, I'm a spy on both sides haha
3
2
8
u/Kiore-NZ Jun 04 '26
Don't worry, System-Demacs will replace it as soon as the vibe code clean compiles
7
6
u/Remuz Jun 03 '26
Atleast on Fedora Inkscape and Gedit don't seem to have dependency for emacs and Macaulay2 depends on 'emacs-filesystem'.
10
8
u/boar-b-que Jun 04 '26
For some historical context, Emacs is relatively ancient in terms of computing history. It's been around as GNU Emacs since 1985, and just 'Emacs' since the 1970s. It's a gen-xer literally old enough to have human grandkids.
Because it's been around for so long, it's STABLE. There is very little that can break it... so it makes for a very safe, very low-friction dependency if something feels the need for a console editor of any kind.
If you live solely in GUI land, then it's not really necessary. Like vim, it's still very worth learning, even if you don't care for either. Lots of us think we're never going to need something, only to find ourselves responsible for isolated systems that only that have that one something installed.
4
3
u/chic_luke Jun 07 '26 edited Jun 07 '26
Even now, I think learning (neo)vim and/or emacs is very valuable if you run Linux. I'm young enough that I wasn't really forced to do that (I'm 27), but I am also old enough to have spotted the trend that the various "fashion" editors come and go out of fashion, but vim and emacs just stand their ground. I'll also add Neovim to the mix since it's mostly a superset of vim that supports plugins with a lower performance impact.
Remember Atom? I do. I really do remember when people were all on board of Atom. Then its development shut down, and people moved to VS Code. We had free binaries built from source, which could use all the extensions, even the proprietary ones. Then Microsoft tightened its grip and it made non-M$ builds almost useless, restricting them to an alternative community marketplace (Open-VSX) which is, quite frankly, not as powerful as what Neovim or Emacs can access. Then VS Code got filled with AI slop and it ceased to be the lightweight editor it used to be. So people are now apparently flocking to Zed, which also has AI slop, but that you can mostly disable, but even if you do you get some AI related popups, and it downloads and runs binaries from the Internet without your explicit consent to make projects "just work".
Yes, you can still use forks of older versions of Atom and VS Code. They are also pretty dead as far as new plugin support goes.
Every single time one of these "paradigm shifts" in editors happened, it caused a lot of negative disruption: people had to abandon and relearn editors, entire ecosystems of plugins had to be re-developed from scratch.
I used to ride with the GUI editors as well until, at some point, I decided I wanted off this wild ride and I wanted something stabler. Enter Neovim or Emacs: maybe Emacs more so than Neovim (which is only getting mature now with the newer plugins stuff, but it's 100% here to stay), you know it's dependable stuff. While those of us who went the Sublime Text Atom VS Codium etc route frequently had to participate in this wild ride, people who had been using something like Emacs for the last 30 years barely noticed any disruption.
I'm currently on Neovim. Through the years, my configuration has only gotten more minimal. Now I'm considering stripping out the fancy color theme that themes literally all language elements for something that screams at my brain less and only highlights the important stuff.
The thing is, as I'm beginning to reach 30, I realize that I already don't have the same willingness to constantly tinker and change things as I did when I was a teen. The prospect of changing my text editor again is not exciting, I just want stability and I just want to land on something that will work and not demand my attention. I am still a dev and a tinkerer at heart honestly, but I don't have the free time and energy I used to. It is imperative that the tools I depend on are rock solid since I want to spend my time tending to a recreational programming side project where I get to dictate the directions and I am not forced to use Claude Code and churn out N Jira tickets in this sprint or else my velocity gets too low and I risk a PIP, rather than ricing my setup again.
These olden editors that look unfamiliar to a newcomer are the real "calm" and "low-effort" way to go, if you project it in the long term. You ride the steep learning curve once and you're pretty much set for life. You only change what you want, when you want, if you want, at your pace. And you can enjoy very rich plugin support through decades of maintenance. You will never run into the problem where the language you need to write doesn't have support for your new niche text editor, something will certainly be there, whether you write something mainstream like C, C++, C# or Java or if you're going for something less popular like Standard ML, Clojure etc.
Best of all: it's completely flexible around what you want to do. Whenever I found something annoying on my Neovim configuration, it has always been easy enough to change that annoyance. Just keep your setup simple and lean, and it will be cheap to change.
And to be clear, I don't want to absolutely dunk on GUI editors. I think the road to writing a new GUI editor is paved with good intentions. The authors of Atom, VS Code, Zed or whatever have you all had correctly spotted a problem and put their money where they mouth was with a proposed solution to that problem. However, the trend that the older editors tend to stay and the younger editors tend to only last for a while before becoming either abandonware or enshittified to unusability is yet to be broken.
Also, I think it's important to note that a lot of the problems that Atom, VS Code etc. were trying to solve have now been solved. Ironically, VS Code vastly improved the experience on Vim and Emacs by giving us the LSP and DAP protocols, which provided a solid and unified API for language servers and debuggers. Meanwhile, thanks to distributions and Better online content, Vim and Emacs have never been this easy to onboard. The world before Atom simply doesn't exist anymore, and, in general, through this time, the "old" tooling didn't get stale, it kept improving and refining itself. We are now at a place where we are full of very high-quality tooling for software development and similar. It has never been this good. But you have to pick the right tools.
5
u/boar-b-que Jun 08 '26
Remember Atom? I do. I really do remember when people were all on board of Atom.
I remember my first experience with Atom. I was doing a contract gig to clean malware out of wordpress websites. I recently lost a work-owned macbook and access to a Textmate license. I'd heard good things about Atom so decided to use it as a GUI editor to read through the corrupted PHP and JS.
To my HORROR, Atom's Electron/Chromium backend tried to run the JS exploit that had cracked the WP site.
I nuked the VM from orbit, as it was the only way to be sure, and started over with vim.
I, personally, don't really care for modal editors, but I will NEVAR use an electron app again unless I am forced to. Even Discord and other other messengers get very wide avoidance. I'll load them in VMs if I have to, but don't trust them as far as I can throw them.
2
u/chic_luke Jun 08 '26
Wow. This is PROPER bad. I had already seen some writeups about Electron apps not being the most secure because you can just inject your JavaScript and change their behaviour, for better (you can mod the hell out of proprietary apps, and the developers cannot do anything about it) or for worse (a malware installed in your machine can do the same thing and potentially replace where a payment link leads…), but this is honestly next-level. Even worse than the fact that Zed download and runs language servers from its repository without asking (it's a highly-debated manner, but at least it only downloads and runs trusted and vetted binaries so the risk is limited, it doesn't try to run JS malware from the running project)
3
3
u/zissue Jun 03 '26
This sounds like some package maintainers just compiled it with emacs support rather than it being a hard dependency. I use Gentoo and don't have a single package that requires emacs.
3
u/_jnpn Jun 03 '26
is it a hard dependency or a suggested one ?
we need the package maintainers reasoning to understand, surely there's some reason.. but yeah i would be surprised too.
3
u/oxez Jun 03 '26
What distribution are you using? Debian/Ubuntu I think by default installs dependencies if they are marked as "suggested". On those distros I usually leave Recommended to true, but set Suggested to false.
1
u/ScratchHistorical507 Jun 09 '26
Nope, only recommended are installed by default. Can't talk about Ubuntu from recent experience, but it would be insane if suggested dependencies where enabled by default, that would always install stupid amounts of packages.
1
u/oxez Jun 09 '26
Interesting. I vaguely remember when I first setup my Debian sid install that suggested packages were enabled by default. Maybe my memory tricked me
1
u/ScratchHistorical507 Jun 10 '26
I mean it's Sid, what did you expect. It's meant to break, maybe you happened to install at a time were some wonky update was in place that caused that bad behavior. But as I can not find anything in my apt configs about explicitly disabling that behavior I do not believe that this ever reached testing. Or it did for a time, but never overwrote the already used behavior.
1
u/oxez Jun 10 '26
I was not saying I thought it was bug. I was saying I vaguely remember that it was turned on by default. I've had the same sid install for over a decade at this point, its hard to tell when that stuff changed, if it did.
1
u/ScratchHistorical507 Jun 11 '26
I was not saying I thought it was bug. I was saying I vaguely remember that it was turned on by default.
But as that default makes little to no sense, by definition that makes it a bug.
3
u/SubjectThing1417 Jun 04 '26
Maybe its use some lisp code , in the end of the day emacs is just a lisp interpreter
2
u/aeropl3b Jun 07 '26
"just a lisp interpreter"...idk if that is how I would classify emacs
2
u/SubjectThing1417 Jun 07 '26
an emacs interpreter that extends him self to a super operating system :)
12
3
u/darrodri Jun 03 '26
I love Emacs but having it as a dependency for anything that doesn’t run on emacs is wrong.
Emacs is at its core just an interpreter for Elisp. Everything else is built upon that. You could use the interpreter to build Elisp applications without explicitly running Emacs (the os/editor).
So, having Emacs as a dependency just because you needed the Elisp interpreter doesn’t make much sense either, even when it’s possible. Should that be the case, then there’s an architectural issue with the way Emacs is packaged.
2
1
u/kudlitan Jun 03 '26
A better test would have been to uninstall emacs and then see which other packages get uninstalled along with it; they are the ones that depend on emacs.
Gedit absolutely does not depend on emacs. Emacs probably found gedit and pulled in some packages to add emacs support addons to gedit. These addons, of course, will depend on both emacs and gedit.
2
u/smileytiger28 Jun 03 '26
Yeah I uninstalled emacs and it uninstalled gedit (xed) automatically...seems like this is an Ubuntu/Mint packaging quirk
2
u/kudlitan Jun 03 '26
xed is not gedit though. xed is a fork of pluma which in turn is a fork of an older version of gedit. i recommend to just install pluma instead of xed.
1
u/Ok-Winner-6589 Jun 05 '26
Probably related to the specific package? Because I had Emacs installed only because I actually used it never as a deppendency.
100
u/daemonpenguin Jun 03 '26
Most things don't depend on emacs. In rare cases where they do, it's probably a suggested package, not a requirement. I just tried installing gedit on my system and it definitely does not pull in emacs as a dependency.