I've been dabbling with emacs for a number of years now, and I felt that my init/config file was pretty hefty at (currently an all-time high of) 186 lines. Then a few years ago I encountered Sacha's and my mouth literally dropped. I've always wanted to ask, and here's as good a place as any. Is her config an outlier in its size and breadth? I feel like it almost has to be.
I've been using Emacs for ~15 years and my configuration is more than 20k lines of code that I've personally written plus
comments. Occasionally, I will factor out parts of my config and release them as Emacs Lisp libraries.
I would expect any heavy Emacs user, fully immersed in the Emacs-is-an-extensible-environment paradigm to operate in similar fashion.
If you live in Emacs and interacting with it every day there is always something to tweak and it just grows organically. I don't think a big config file is an outlier. Not because it's necessary but simply because it's so much fun to scratch a small itch with a few lines of elisp which you couldn't do in other editors.
My config[0] for example is 10k lines with >1k commits.
Ten years and just north of 1,000 lines of self-written code; 1,500 if you count the ~300 lines of custom.el and ~200 for a hastily copy/pasted copy of find-dired hacked to do Spotlight searches.
To be fair, I try to go through it every year or two and mercilessly cull everything I haven't recently used, and refactor what I do; including everything that has been in my init at some point or another would easily double, and possibly even triple, this number.
Keep in mind the org stuff makes that config file look much bigger than it really is.
Though, 186 does sound surprisingly low if this is truly just 186 lines applied to vanilla Emacs.
My bindings file is a little over 200 (one binding per line). custom-set-variables block is 170.
Total across a few files is around 3-4k. But some of that is config code, patches/modified versions of functions from other packages and simple wrappers. It accrues rather easily. Actual original code that does something non-trivial is probably below 1k.
Mine is about 6 months old, after I switched from Spacemacs to Vanilla Emacs. Currently wc says there are 487 lines in init.el, and 37 in custom.el.
I don't do the org-babel->tangle->init.el thing (yet?). That would probably triple the amount of text involved.
I do have a bunch of nice-to-have todo items that would mean writing code for my Emacs instance. If I had to guess I'd say it would add another 1,000 to 2,000 lines somewhere.
I also share my config between 3 different operating systems; Mac, Windows, and Linux. So a small amount of those lines are just "(when os-is-mac)(when os-is-win)(when os-is-gnu)" choices.
Your config should be as big as you need it to be. I’ve been using Emacs for 20 years and I tend to use features with default keybindings and stick to a small number. There’s no right way to do it
The talk by Sid Kasuvajhula is an absolutely fascinating presentation about extremely flexible object-oriented interfaces, organized in a multi-hierarchial manner -- so very nicely exploiting the compositional structure inherent in the content we operate on.
Wow. This is so cool. Sometimes you come across concepts that makes total sense once you know it, but then keep asking yourself why wasn't it discovered way before. This a great example of that.
EMACS was developed on ITS, a multi user timesharing operating system with no security. I developed a complex init file (in TECO of course) which was a compiled module in my home directory.
One day I changed something in an incompatible way and received complaints. Unbeknownst to me there was a community of people who linked (symlinked) directly to my init file and whose workflows were disrupted by my change.
Were there any interesting consequences? Like did you consequently avoid making disrupting changes to your own init file, or did people agree to make copies instead of rely on links?
It can be (consider that some Emacs power-users used to do most things in Emacs, including email, Usenet, etc.), but this reminded me of something...
Many years ago, some new founder I knew asked to see my elaborate .emacs file. I was reluctant, because it had some slightly sensitive info in it , as well as unreleased bits I might turn into packages. But he reassured me he just wanted to see how I'd done some things, to inform some non-Emacs thing he was about to build, and he'd keep it private.
Sometime later, one of the developers at his startup happened to mention that "everyone" uses my .emacs file.
Today, that person I let see my very personal .emacs has sold the original startup, and is CEO of a different business you've heard of, but I received nothing from the indiscretion. :)
> (consider that some Emacs power-users used to do most things in Emacs, including email, Usenet, etc.)
We still do. Consider that I have coordinates for weather in my .emacs, and yes, I should probably externalize that, but FFS, sharing my own incredibly personalized and personal configuration files was not first on my mind when I did that.
You want snippets, that will be useful to someone other than me? Fine. But there's no contradiction in arguing for openness in infrastructure and privacy in personal affairs.
Wow, send a bill to the company and ask them to renew their site license for the emacs config. Or opensource what you can of it and remove the competitive advantage they have.
As much as I'm a fan of Emacs, I don't think a .emacs file had much to do with that startup's success. He just wanted to see the UX and features that were possible for a particular purpose, for ideas and competitive analysis. But I did opensource a minority of the bits. :) https://www.neilvandyke.org/emacs/
Totally believeable. I had one research prototype that invoked an Emacs process for every Web CGI request. To get that kind of R&D rapid development productivity, I then had to start building out libraries for Scheme. :)
I simply separate user/machine specific things into separate files, and don’t commit them to public repository (https://github.com/alexott/emacs-configs - it wasn’t updated for a long time, and it needs to be rewritten to modern stuff - first line was written 25 years ago)... But this may allow sharing, and even contributions...
I take advantage of the fact that a .emacs file has higher precedence than a .emacs.d/init.el file for this. All the common stuff lives in the .emacs.d directory and is under source control. The little bit of work/machine specific stuff I have goes in the .emacs file, which wraps a
(load "~/.emacs.d/init")
My home machines don't need anything special, so there's no .emacs file and the .emacs.d/init.el file just gets loaded directly.
The talk about gaming in Emacs is particularly interesting to me, because I think there are possibilities here that haven't been adequately explored. With XELB, the X client library used by EXWM, it's possible for Emacs to quickly draw arbitrary geometry at screen resolution without a C or dynamic library extension. Some testing I did when I fooled around with it showed that it would be fast enough to use as a simple 2D game engine.
It's great to see there were new Emacs users and developers coming on board, judging by the age of some of the presenters. Emacs has been proclaimed dead many times, I think it has long future ahead of itself. Yes its aged, and dated. But also very powerful. And cools things can still happen (gccemacs as an example).
I never used emacs beyond simple text editing. I’ve seen people do quite a lot of cool stuff with emacs though so I do want to start using it. Are there any good tutorials to look at? I’m mostly interested in the software dev pipeline.
"Extend Emacs to Modern GUI Applications with EAF"
I hadn't heard of this one before, and it's hugely interesting. A shame that it can't ever make it into core because of licensing issues.
Similarly I'd love it if it was more possible to embed Emacs into other applications, like IDEs. That way IDEs could focus on what they do well, and still have a good text editor.
lsp mode has come a long way and that feels like i am embedding and ide inside of emacs. With dap mode I get a debugger too but I havent really gotten around to learning how to set that up.
It is extremely nice, but still feels a bit hemmed in by the "everything is a grid of characters" paradigm. Just a soupçon here and there of actual GUI elements (some kind of popover for LSP highlights, for example) would go a long way for making Emacs even better, IMO.
Thanks for sharing! For anyone that's gone through these, which are most worth watching? I haven't made emacs a regular part of my work yet, but I'm always curious to see what's going on in the community for it.
I also discovered this a few days before the event. Great stuff! Following it live was really cool. Special shoutout to `andrea with "Your Code as a Crime Scene/Analyze code quality through Emacs"
Great to see a couple of talks on org. I know a couple people (including myself) who don't use Emacs as a main editor but use org to manage tasks, ideas, projects, etc.
Today's Emacs experience. "I have a lot of stuff I have to study for work.. I wish there was an efficient way to make my notes into an anki deck.” ” oh theres a blog post about org mode captures too export in anki readable HTML” .. half a day and no study later I have something not half as good as the blog described kind of working.. the blog just says look at my init.el of you don't get it.. who has the time
Over the years I have exchanged messages and worked with many of the speakers at this conference, but I have never had the opportunity to meet any of them in real life. It is so nice to finally see their faces and hear their voices. Thanks, Covid, I suppose.
I would like to use emacs and org mode to organise my life. But I think without it being useful on mobile phone, for me is a no go. I will keep using Google calendar for now.
You can install Termux on Android devices and use Emacs there. I use it on more or less read only on the smartphone and actively on a tablet. Both rsync with my desktop from inside Termux.
I was very much in the same boat. I’m on iOS, and found beorg, and it is simply splendid. Very active development, powerful customization available, etc.
yes for iOS, I suggest you take a look at beorg, it is quite nice for quick editing and note taking. Of course the real magic truely happens when org is paired with Emacs but the app is quite useful for basic tasks.
I used vscode since 2015 and have now switched to emacs. Yes, vscode is easier to configure and use right away, but that's not always a good thing. I was fully dependent on so much tooling which I didn't understand in the slightest. When you're cranking out react apps that's probably fine.
With emacs I actually need to read documentation. I need to have some sort of understanding of what I'm actually installing. It's frustrating at first, but overall has made me much more aware of what's going on. I've learned so much throughout the process and it has made me a better developer.
I'm a heavy org-mode user. I'll also pop into emacs for comment formatting, macro-running, and the occasional column-based copy/paste. Plus an auto-numbering function I wrote when I wore a younger man's clothes. Plus a colorful highlight mode (which I wrote) + htmlize for sharing said highlights, also from my callow youth.
Other than that, yeah, 100% VS Code for typescript and regular VS + ReSharper for my regular life.
Oh, also, emacs for Haskell. And whatever other weird language.
Well thats the thing with Emacs, its an extremely good Tool: Editor, browser, file manager, git frontend, notes, calendar, etc.. etc... you call it! but its also extremely old and outdated tool.
I used Emacs for years and one day i realized i had a huge .emacs file and spend lots of time maintaining it, that's when i was conviced it was not the editor for me or I was using it wrong. I moved to sublime, vscode and now im giving vim/neovim a try.
As much as i liked Emacs i dont see myself using it again soon.
Well thats the thing with my table saw, its an extremely good Tool; ripping, cross cutting, router table, many different materials, coving cuts etc. etc. you call it! but its also extremely old and outdated tool.
I used my table saw for years and one day realized I had accumulated a lot of very detail knowledge of how to use it and spend lots of time maintaining it, thats when i was convined it was not the tool for me or I was using it wrong. I moved to a hand-held jigsaw, then a crosscut saw, and now im giving a handsaw a try.
As much as I liked my table saw, i dont see myself using it again soon.
The fundamental difference in your analogy is that the table saw is a single use tool optimized for precisely one thing. It requires little maintenance or training (compared to emacs, anyway) and has been optimized for this one thing so much that it's hard to imagine something that is faster, safer or more reliable.
The same cannot be said of Emacs. It is a general purpose tool on a rapidly evolving platform. Its C interpreter is starting to show its age, it requires some tinkering (and many outside tools) to interact with on mobile devices and as the world moves on it feels like it's trying to keep up with specialized tools. I'm an Emacs user, but I will also argue that the comparison with a table saw is not a fair one.
It matters a lot to me that several of the interesting parts of vscode are proprietary and not free or open source. In particular the liveshare and remote features are proprietary. Many extensions contain proprietary parts, like the c# debugger.
What's there to talk about? You install it and suddenly you have the same programming language features that everyone else does, but in an editor that can actually manipulate text.
Yes - in general both eglot and LSP are pretty much "out of the box". The biggest factor though, is entirely dependent on how good the various server implementations are.
Having used it in quite a few different languages now it varies greatly; but you can hardly blame Emacs for that.
Although I am not a VSCode fan (hoping for the day it gets rebooted into React Native), Microsoft's C and C++ LSP support is quite good, as they are pushing it for WSL, Linux cloud and GitHub based development.
C++ depends heavily on the build system, and it offers no opinion about the build system. That's the problem I've always run into trying to use clangd on a project that wasn't designed for clangd -- there's some Make rule that's important but doesn't fit into their model.
The people having success with language servers are using a language that bundles a build system, which is common in more modern languages.
