The Second Golden Age of Emacs
batsov.com
batsov.com
So it’s, like, not an accident that emacs can leverage this :-D. Though I never see anyone giving him credit.
Thanks steve for all the things.
That is cool. I was thinking just today (without knowing it was the intention) that LSP has meant I moved from an IDE to an editor with plugins (Kate, not Emacs), because an editor now has so much more of what the IDE can do.
He was ahead of his time on dev tooling. I'm still using js2-mode to this day.
semantic-mode almost, a-a-a-lmost did something similar (mostly based on LR incremental parsing) but was Emacs-only and never gained enough traction.
Tree-sitter is decades ahead of both. It's hard to compare js2 to a modern GLR incremental parser generator of Tree-sitter. I am not even talking about the size of the community building grammars useful in all the editors out there.
- A guided tour of Emacs: https://www.youtube.com/watch?v=lkIicfzPBys
- Emergency Emacs: https://www.youtube.com/watch?v=6ZWp05OW1c0
Which is not to say that Yegge and others haven't created some nice things. They have. I tend to see it more that they succeeded at problems previous people had either failed at, or had a much more limited success. Progress is not always new things. Nor is similar effort always informed by each other.
For example, Eglot and use-package being part of Emacs core.
Additionally, there's also just many new plugins for the base-level things. I never thought there would be alternatives to completion frameworks like Helm or Ivy, until new ones came out. It's all been very exciting.
The one that I think makes most change is treemacs - this gives you a tree view at the side of the window of files.
> many new plugins for the base-level things
GP mentions Helm and Ivy. These "completion frameworks" are editor-wide, full-blown rich and ergonomic UI enhancements, each with its own philosophy. Each one is an island though - you have to buy into their philosophy wholesale[0]. At some point, however, the community identified the various paradigms and patterns in those completion UIs/frameworks, and where they map to existing core Emacs ideas, and a new breed of libraries were born - Corfu, Vertico, Embark, and many others, each of which provides a single piece of the equation, and deeply integrates into built-in Emacs APIs whenever possible. As a result, you can now mix and match those libraries to replicate something like Helm or Ivy, that works better, is more flexible, and more friendly to code against.
This is perhaps less interesting for casual users, but it means an important philosophical shift in community, towards more targeted and composable plugins. For casual users it just means more powerful, stable, better cooperating plugins.
--
Okay, I lied. Let me talk about Org Mode. My favourite little feature, which I miss from literally any other software I'm using (like Microsoft's To Do I've been using lately for ad-hoc personal things[1]), is `org-extend-today-until`. Made by and for people like me, who always find themselves reviewing plans after midnight, it's a variable you can set to make Org Mode extend "today" past midnight. See: http://doc.endlessparentheses.com/Var/org-extend-today-until.... I set mine to 3 (as in 03:00).
Flexibility of Emacs means people just implement random stuff like this in the first place - features not relevant to Minimal Viable User, but very useful for a subset of users.
--
[0] - Though in Emacs land, this just means it's only tad more annoying to extend, modify or repurpose pieces of those frameworks.
[1] - Org Mode is the bestest, but still has so-so mobile support; currently MS To Do is just the least annoying tool for private planning on the go.
That's pretty neat. Now I'm trying to remember how I live without it.
Pick any other tool. Plan something with it. Wait until it's late. Feel the frustration.
Serious question. What does org-mode give us which Google Docs doesn't?
* One ..
* Two ..
* Three ..
Now mark them as TODO items, with one being in-progress:
* TODO One ..
* TODO Two ..
* INPROGRESS Three ..
In Emacs you can then view your calendar, or org-agenda, which will have the current day and all items on it.
You can add a deadline to an item, and it will jump to that day on the calendar/agenda.
Can you keep track of simple items in google docs? Absolutely. Can you make them appear on a google calendar? No. (Yes I realize Google has todo-app, and that does. Even with recurring scheduling, but that's not tied in to google docs either)
Easy examples, any source that is delimited with `#begin_source language` will have whatever the editor would do for `language` in the delimited section. Searching the file is exactly like searching any other file. Committing it to source is trivial, as it is a somewhat normal text file.
And while org is not a perfect static site generator, it works surprisingly well for it. https://taeric.github.io/challenging-my-filesize-intuition.h... is a fun example I did not too long ago showing off some of the benefits.
That last actually shows how emacs can be treated like what a lot of folks use jupyter for. With the main difference that the "on disk" form is a somewhat normal text document using fairly trivial markup.
In this deeply nested Reddit comment, when someone said: "Imo emacs shines when editing, not writing.", I tried giving a few practical examples of how I use Emacs for writing plain text. I'm just gonna list the use cases without specifics, you can click the link below and find details of each package if you're interested. Note that this is a single aspect of things for which I use Emacs. Many other possibilities are abound.
Emacs is incredibly incomparable for writing. I don't even try to type anything longer than three words in anything else. I always try to find "edit-with-emacs" feature wherever I go - I built one for Mac, then I wrote one for exwm, then I did the same for stumpwm . I recently started using AwesomeWM, and now I have it there too. If I'm ever forced to work in Windows, I can promise you, finding a way to edit with Emacs would be the very first thing I will try to solve.
When I'm typing in Emacs, I have:
- Spellchecking. When I mistype the previous word, I would just tap the comma twice, and it autocorrects it. If I need to actually insert comma, I'd use comma and space (which I always do anyway)
- I have thesaurus.
- I have Google Translate, for which I don't even have to switch the keyboard layout, meaning if I want to translate from Russian, it would automatically switch the layout to 'ru' and back to English when it's done
- I can check the etymology and definition of any word.
- I can count the number of sentences, words and characters.
- I can keep an eye on my writing with writegood-mode, it can look for duplicate words and use of passive voce, and perform Flesch–Kincaid readability test.
- Until recently, I was using Grammarly to check the text, these days I simply send it to chat-gpt, and it even shows me the diff upon completion.
- I can toggle "distraction free, zen mode", for writing.
- I can launch a web search on any selected text.
- There are various ways how you can preview the markdown.
- You can write helpers like wrapping a region in a collapsible section, or create "code sections" without any hassle.
- You can edit the code sections in their language environment, with syntax highlighting and REPL.
https://www.reddit.com/r/emacs/comments/1aey0eo/they_are_sur...
Eglot is a package that works with LSP (Language Servers). There is another one called lsp-mode.
Eglot is integrated within Emacs over lsp-mode because it was specifically made to use existing hooks that Emacs has.
What this means is that you'd use the base Emacs command for finding a reference, and Eglot will populate the source for that command.
Whereas with lsp-mode, it has it's own command you'd run for finding reference. I do think you could also write code to have lsp-mode populate Emacs commands.
That being said, my impression is that Eglot has better integration with Emacs - which is why it became part of Emacs core.
(It's been a while since I've reviewed the Eglot vs lsp-mode discussions, so anyone feel free to correct me).
Use-package is a package for setting up your Emacs configurations. It allows you to place settings for individual packages in nice little sections. It's mainly used for organization but you also gain a plethora of options as well, like deferring to load a package until you open a file that requires it.
You also don't technically need to configure Emacs by hand by writing code lines. You could always do M-x customize and change settings that way. Emacs will auto-generate code from that and place it at the end of your configuration file.
That being said, this becomes quite messy to look at - so people prefer to use M-x customize to find the setting they want, and then they write it by hand in their config.
A big usage of use-package that I love is that you could specify specific settings that tell Emacs to enable it through M-x customize. If you don't know what I mean by that - that is totally ok. You'll learn about this more if you ever dive into Emacs and want to configure your own settings.
And hey, no editor does Emacs key bindings emulation as well as Emacs itself.
Joke aside, the key bindings work in a lot of places outside of emacs, which unfortunately are slowly eroding away.
Keybindings are all a crapshoot when it comes to working with different platforms though. macos is notably frustrating in this regard.
Try the experimental compose interface https://xenodium.com/a-chatgpt-shell-compose-ux-experiment
I found myself using it the majority of the time.
I need to review the current state, but back about half a year ago, when I evaluated them all, I had a lot of "fun" getting them to talk to Azure OpenAI (instead of OpenAI). Or even to allow to override the system prompt. Granted, those were early GPT-4-by-invite-only days, but still.
Still, the most important takeaways are that:
- Emacs community can and does react quickly to any new development;
- Sure, early on the packages may be somewhat half-baked, but it's not that hard to improve/fill in/fix them on your own, with config tweaks and maybe a pinch of simple Emacs Lisp code, even if you barely know anything about programming. That's in contrast to just about any other editor or program, where this is just not possible.
It took about a week to finally get used to paredit-mode (and rainbow-parens, because…) but once I did it is the most productive I have ever felt, I keep trying to find that experience again.
Unfortunately the dynamic types and slow build system (lein) made the build step quite tedious (this was 11-12 years ago) - but in terms of expressing ideas, man - paredit + lisp style was amazing!
I personally suspect that the big reason behind Emacs' resurgence is the feeling lately that computing is no longer responsive to user needs. That it's all about designing, and redesigning, and redesigning again, interfaces to make pretty screenshots, with the user being totally downstream and hardly even a factor in the minds of whatever designer has been assigned to work on the product most recently.
Emacs by contrast gives you an ugly interface that cares about function almost to a fault, that you can then make your own. It gives you the tools to look inside what the program is doing and change its appearance, its functionality, how much or how little information it shows, what that information is, etc.etc. All without constantly shifting under your feet, even with the significantly accelerated development over the last few years.
I do have some concerns about that last part to be honest, with Emacs seeming a little too eager these days to add features that seem to violate its underlying philosophy or design, but it doesn't seem like big, breaking changes are happening on the regular, so for now it's still a platform you can develop atop of as an individual, and feel like you understand and can at least partially map out in your mind.
In short, it presents a philosophy and experience of computing that you don't get very often anymore, even in open-source, especially if you're not a fairly advanced programmer already.
So, why should you try Emacs in 2024?
...
You’ve got a lot of time to kill.
The most important medium through which we convey ideas, information, and even emotions is text. Often, programmers place a greater emphasis on the formal language of precise and structured nature of programming languages. They may even become emotionally attached to a single programming language. Notoriously, most people overlook the importance of plain, simple, unstructured text. The value of taming the wild nature of plain text (even before programming languages) is underestimated.
Find Graydon Hoare's post "Always bet on text", it's revelatory.
There is no equivalent in any other communication technology for the social, communicative, cognitive and reflective complexity of a library full of books or an internet full of postings. Nothing else comes close.
I myself spent years trying things like Evernote, OneNote, Google Keep, Notion, Workflowy, Apple Notes, Zoho Notebook, and countless other tools.
There were always some factors that made me switch. Initially I decided to learn Emacs, thinking it's just another code editor. It took me quite some time to master it to the point that I can now bravely try to implement some wildest ideas. I came for a specific tool for coding, instead, I found a world of incredible possibilities to manage text, any text, not just programming. All my notes, all my writing, my browser history, retrieving YouTube transcriptions, Anki cards, pdf annotations, emails, rss feeds, and of course, coding, all that I do in Emacs.
Why? Because it is not only extremely powerful and allows me to be immensely efficient. It also gives me enormous pleasure, allowing me to perform things my way. If frustration could be measured in wasted fiscal expenditure, Emacs would've saved me quite significant amount of money.
Yes, that long-term satisfaction and liberating power were not granted to me. I had to spend many hours, days, and months of learning until I felt empowered. But that is a lifetime investment that is unlikely to ever diminish. Even if Emacs itself becomes obsolete, the mindset it helped me develop will remain. I will never be the same again. No other highly specialized tool will sway me to pay for it or waste my time, unless it is as extendable as Emacs. And there's nothing today that comes even close. Anyone who says otherwise either doesn't know the limitations of their tools or is unaware of the capabilities of Emacs.
OK that's an exaggeration, I have dabbled with org-mode and use magit, but really for editing code, it's pretty much same as it ever was for me.
MELPA isn't user friendly - I don't mean in the usability sense. The maintainers routinely remove packages that are being used. Breaking your end-user's dependencies for non-security related reasons seems unusual for a package repository. If it goes into MELPA and a user has downloaded it, it should stay there for basically forever or as long as feasible.
Performance - emacs is noticeably slow even on latest Apple hardware and I can't seem to get to it to an acceptable performance level. The bar for acceptable for me is VS Code.
Is it plain Emacs that's noticeably slow, or Emacs after installing 3rd-party packages? Some of the popular ones are very performance-costly.
That is completely wrong. I'm using Emacs back since when I was compiling it on 486 with 8 MB of RAM. nativecomp is the single biggest speed boost I saw Emacs ever getting. Using Emacs on the same machine with nativecomp on or not was night and day (a Core i7-6700 in my case: maybe the difference would be less noticeable nowadays but I couldn't tell as I now only ever run nativecomp and compile it with nativecomp on).
You're the first person I ever hear saying nativecomp doesn't make a difference.
I compile Emacs from source specifically to get nativecomp because of the obviously perceptible difference in performance. Maybe you have a much faster computer than the rest of us?
In the unlikely case where emacs -q is still slow, use Emacs Mac Port (https://github.com/railwaycat/homebrew-emacsmacport/releases...).
This is at least 2x perceivably faster than VS Code on Mac.
Hmm. I have quite the opposite complain. Why is when I install a single extension that enables Vim navigation in VSCode there's quite noticeable typing latency? And it's not a single plugin, I tried multiple. While my Emacs instance where I use over 300, built-in and third-party packages still feels quite snappy.
I'm not saying that Emacs built in such a way that it is impossible for a package to degrade its performance, that can happen, but if you know how to use the built-in profiler it's not that difficult to find the culprit and either remove it or try to find a workaround.
While typing this comment I googled, TIL - VSCode has very impressive Perf Tools suite for profiling. That makes it even more surprising, why would the authors of those Vim plugins, and I'm not talking about some obscure and esoteric thing, but supposedly popular, demanded feature, ship it with such obvious deficiency?
Observing this latency after adding just a single extension, frankly makes me question the long-term viability of using VSCode as my main code editor.
Learning vim definitely has its use.
But both vim and emacs have lost the code tooling wars long back. You can configure emacs and vim to to anything. And that is not a win vim/emacs users think it is. Nearly all the programmers out there don't want to spend time on sub projects, just to bring their tools to bare minimal working standards modern tooling provides out of the box. vscode just works, it works out of the box, for 99% of the use cases out there and it works phenomenally well.
Plus the whole idea of being able to write out code faster, or navigate faster made sense in UI paradigms of the old, where there were no windows, and a overall better UI experience. These days coding and navigation speed aren't even in the ballpark of factors that slow me down as a programmer.
And yeah, Org mode. Unfortunately Google docs do way more, and you don't have to remember dozens of commands to just make simple tables, add dates and bullet points.
In many ways Richard Stallman had an idea that emacs should have really had a WYSIWYG facilities. But Google Docs go even one step further as everything is saved on a cloud and you don't really have to worry about losing anything at all.
Emacs on the other hand is a great time pass hacking tool, if you are bored or just want to work on something cool.
Ah yes. Those very precious programmers, who can’t be expected to configure a non-proprietary tool, because they are too busy making another dopaminergic app at their corporate job. The medium is the message, I guess.
1. Solve the problem using a tool.
2. Solve problems that a tool has.
It should not be a surprise people pick 1.
The main point you're missing is that at some point in your career, inevitably, you'll collect so many tools in your toolbelt that you might become overwhelmed.
There are tools for debugging, searching, formatting, converting, documentation, device control, synchronization, networking, databasing, containerization, security, etc.
Most tools operate with data. And most of the time that data doesn't stay in the context of the same tool - you have to pass it somewhere else. The common approach of unexperienced devs is to become "a copy-n-paste programmer". No, not someone who grabs the code from StackOverflow. I don't know if SO has much value in 2024, I stopped using it a source of valuable knowledge long ago, I do occasionally find clues there, rarely complete answers, perhaps the complexity of my questions has changed, but I'm going off the rails here...
So, anyway, at some point you'd become more efficient in enabling tools to exchange data. Experienced Vimmers use terminal tools with piping, etc. Some of them develop really neat and powerful mini-automation workflows.
Emacs is another amalgamating medium that can be used for the same purpose. People with shallow understanding of Emacs often get grumpy for Emacsers wanting to do "everything in Emacs". Matter of fact, it's not about doing everything in Emacs, but rather doing everything _through_ Emacs. And that can be quite effective too.
So tell me, why is it so difficult for you to accept that Emacs is just another tool, not a replacement for some other specialized single-purpose tool, and that it is quite good at what it does - that is to work as a "glue" to orchestrate many other tools?
Maybe VSCode is truly better in that aspect than Emacs. I don't know. I have yet to find out. So far, people have been claiming that it just works better as a code editor in specific languages, but I haven't heard it being used as a "tactical unionizer" that can talk to many other tools in a way that Emacs does.
I honestly can't deny or approve this message because I haven't yet used VSCode extensively. But I have used many "phenomenally good" tools in the past. Borland stuff in the 90s was fantastic, MS Visual Studio in 2010s had some awesome features, IntelliJ IDEs today are amazing.
Over the years I've developed a distaste for proprietary products. Not because of money, it's rarely an issue. I happily paid for using IntelliJ products, even though I don't use them anymore, I still believe that they were worth every penny.
Perhaps it's debatable but the price for using Photoshop maybe is fair. Photoshop is a truly exceptional tool in its own category. I don't know any other tool that comes close, proprietary or open-source. Photoshop is the most creative graphics tool. But that's my opinion of an occasional, amateur graphics designer.
The reason for my distaste for proprietary tools for professional programmers is the lack of freedom to tweak, the right to repair, whatever you call it. I firmly believe that programmers should be able to program their tools.
Again, maybe VSCode already is as darn hackable as many people claim it to be. From my limited experience, I got the feeling that today it lacks some extensibility capabilities I'd like to see. But it's evolving fast, the pace of its development is quite impressive. Maybe in a few years, it could truly be crowned as the most hackable devs tool that outshines even Emacs. For me, Emacs is like Photoshop for programmers. It's the most hackable software product that you can tweak to perform any kind of crazy shit. But again, that is my opinion and a lot of people maybe would disagree.
Maybe Google Docs gives you the satisfaction and feeling that it lets you do more, not for me.
- Google Docs doesn't have vim navigation and I need that in my editor. Trying to convince me otherwise is like punishing a child for being born left-handed.
- Google Docs cannot handle my pdf annotations, I can't read a book while simultaneously taking notes. I mean I can, by having them in separate apps, but I won't be able to jump to the page from my notes and vice-versa. I can do that in Org-mode.
- In Google Docs I can't have code snippets that perform computations. I can't send a http request, then get the results and feed them to some Python, process that data through Clojure and spit out a diagram in .png. I can do this in a single org-mode document.
- I can't keep my Google Docs Zettelkasten-style, similar to Roamresearch, Obsidian or Loqseq. I can do that in Org-mode.
- I can still use Google Docs and link them from my Org-mode documents, I can't do the opposite.
- While typing in Emacs, I can automatically correct my previously mistyped word by tapping the comma twice. I don't think anything like this even remotely possible in Google Docs.
- I can fetch a definition, list of synonyms, etymology, translation of any word with a single, simple keystroke while I'm writing text in Emacs. I don't know how to do that in Google Docs.
- I can select a region of text and feed it to ChatGPT, asking it to fix mistakes, rephrase, simplify, etc. In place. No copying, switching, pasting. I simply select, press a few keys - voila. It even shows me the diff of what's changed.
- I can't encrypt my documents with my GPG key in Google Docs. I can't store my docs in a git repo. Even though Docs provide a great way of restoring and tracking history, I don't think it's grepable. Org-mode and Emacs manage my documents in git with git-auto-commit-mode, without my supervision.
- I can't easily export my Google Docs to Anki. My anki cards are stored within my notes - they are not separate entities that I have to manage in a different app.
- Google Docs can't manage my dotfiles. All my config files for zsh, bash, command-line tools, package-managers, etc., all kept in a single Org-mode document. Literate programming allows me maintain my dotfiles in a very convenient fashion. Whenever I need to bootstrap a new machine, I only need to install Emacs, fetch my dotfile.org, and "tangle" the files - it creates all of them with their proper permissions, taking care of differences between systems - some parts are only relevant in Linux and not Mac.
- Google Docs doesn't understand specific type of tokens. For example, when I type RFC-1035, I can immediately browse it in the opposite window. Emacs automatically knows that it's a document 'Domain names - implementation and specification'. In Google Docs, I have to store a direct link. Similarly, if I have a piece of text that looks like mikjagger/sweetthing#144 - Emacs automatically knows that it's a PR/Issue for some repo on GitHub. I can browse it without even opening the browser. You'd think that doesn't happen a lot, I do that almost every day when talking to my colleagues.
Well, someone who knows Google Docs really well, maybe they'd say something like: "for 1, 2 and 3 there's an extension you can use, other things are just useless shit, nobody cares about it", and they'd be missing my point.
The proprietary tools may be truly great for most people who might be content with their tools. But most people don't know what makes me happy. Feeling in control does it for me. When tiny things like being able to call any external tool and make Emacs do the bidding for me, is extremely liberating, empowering, and delightful. I never have to feel like "ah, everything I wanted is here, and if not, then I have to want less".
> Google docs do way more
It's an illusion you want to believe. I believe a different one - that whatever I want, I can make Emacs do for me.
I wouldn't go so far as to call native-comp feature a gimmick, but you probably won't see noticeable UI performance improvements with it. On the Mac, --with-metal support may give it a bit snappier feel but it depends on the hardware, you may try both, with and without and compare.
Matter of fact, Emacs with native-comp flag may give you an impression of things being super slow right after the startup, because it often has to recompile packages asynchronously, the process of which you can observe in *Async-native-compile-log* buffer, it's normal for Emacs built with native-comp to be a bit laggy for a minute or two at the startup, but you don't have to restart Emacs very often. native-comp benefits can be observed when using things like lsp-mode, where it brings some good perf improvements, sometimes it's worth it, but you also have to expect things to break, and quite often, native-comp relies on libgccjit, and MacOS updates often break the toolchain dependencies, and it can be highly annoying if you like to update Emacs packages often, especially when using something like Doom or Spacemacs, but it's not Emacs' fault. It's great that we have the option to disable native-comp completely without having drastically reduced performance, most of the time, you won't even notice it.
Also, one thing I always recommend doing on the Mac, which is absolutely unrelated to Emacs is this:
```bash
# "Set a blazingly fast keyboard repeat rate, "
defaults write NSGlobalDomain KeyRepeat -int 1
# "Set a shorter Delay until key repeat"
defaults write NSGlobalDomain InitialKeyRepeat -int 10
# disable accents on key hold
defaults write -g ApplePressAndHoldEnabled -bool false
```
Async compilation does not slow down the startup time, it's not what I said. My Emacs instance also starts very fast, that is a signature feature of Doom. But do check your buffers, there will be *Async-native-compile-log* there.
What I'm saying is that when you start it, while it's running compilation asynchronously you may feel some slight, almost unnoticeable (or super noticeable - it's subjective) UI performance dip, it's not a big deal.
use-package, hands down. my decades old rat's nest of a config actually became organized and emacs starts instantly now
similarly, being able to configure emacs with a real programming language was a game changer compared to vim with vimscript. this is not so much an issue now with neovim, but i still prefer elisp :P
Now? There is one left (yes, I switched to VS Code :() who still uses Emacs and there are even more Vim users (not admins!). And whenever I read something about Emacs online it's mostly Magit (I don't get that, I either use the CLI or a real GUI frontend) or Org-Mode (not for me either).
For C++ maybe.
For C most used Vim
(FWIW I like Vim; this isn’t an example of an Emacs fan touting their advanced ide-like editor).
>You’re a curious person and a constant tinkerer who likes playing with (insanely cool) vintage software.
>You want to experience life outside the mainstream.
>You’ve always wanted to learn a bit of Lisp.
>You want to build an editor that’s uniquely tailored to your needs and preferences.
>You’ve got a lot of time to kill.
Is this sarcasm?
I think focusing on the killer apps might have hooked me more than that closer!
That said, it's pretty easy to put your Emacs config on the back-burner for a long time once you have things how you like them, and it becomes a much more OPTIONAL time sink at that point.
Using something like Doom Emacs could even prevent it from really ever being much of a time killer, but in my experience, once one is bit by the customization bug, one doesn't -mind- the time sink so much because the fruits of your labor are worth it
To illustrate this, I'm a heavy emacs user. I've been using emacs more or less exclusively since 1999 (I had two years where I forced myself to use vim to make sure I'd really given it a fair shake), including org-mode, using gnus for my email client, and writing code pretty much every day (with magit, helm, and projectile, tramp for working on remote servers). Here's:
~/.emacs.d <master> » git log --pretty=format:"%h %ad %s" --date=short|head -n 20
6795c07 2023-12-23 rust-mode
dd241ec 2023-10-24 full screen automatically on mac
1cf8287 2023-10-22 mac stuff
bc1e456 2023-10-22 conditionally set home dir
e7d3577 2023-10-22 mac font size
f8ba89c 2023-10-22 add ligature stuff
7ef9bce 2023-10-22 add ligature.el
1aaf1e1 2023-05-06 gitignore some stuff
de56154 2023-05-06 update the other capture template entries
948d2ea 2023-05-06 capture template works differently now
5b2d34e 2023-05-06 copilot
00991ae 2019-12-28 whitespace
d334506 2019-12-28 don't need the other conditional either
95ffdf7 2019-12-28 still working
23378b8 2019-12-28 oh... working now?
c1fb771 2019-12-28 that works fine again
caf80c0 2019-12-28 removing recenter seems to help
04eba58 2019-12-27 setup
171f175 2019-12-27 weird
05c4163 2018-03-14 terraform/hcl mode
Evil-mode is not the only way. There are other approaches like devil you might want to check out.
https://susam.github.io/devil/ * make it fast (magit is the benchmark, if magit becomes fast emacs is fast, for those who dont know magit is slow, very very slow)
* add more UI stuff (graphical tree browsers, tables , etc ..)
I get that it might be slow if you're trying to use it to automate something complex, as some part of a server, etc. but it more than keeps up with me.
WSL might make things faster.[1] IIUC, the problem is that starting new processes is much slower on Windows than on Linux/Unix and Magit relies heavily on that. This seems to have plagued Git tooling more generally but maybe this got fixed since then.[2]
[1] https://emacs.stackexchange.com/a/58444
[2] https://github.com/magit/magit/issues/2395#issuecomment-1710...
For example, Magit tries to display tags (in addition to branches) in the refs buffer, for the project that has too many, yeah, that may be slow. The solutions is simply to remove the hook
(remove-hook 'magit-refs-sections-hook #'magit-insert-tags)
Emacs is a Lisp machine made to run Elisp byte-code. It's not a final product built with some C and Elisp that you may never need to learn. You do need to have at least some basic understanding of Elisp.
Even if someone is impatient, they could develop inner curiosity and type in ChatGPT "what happens when Emacs opens a buffer". Basic understanding of standard hooks and hooks in general, advising functions, etc. is all required for you to be the "user of Emacs". No wonder we see people claiming to have used Emacs for over a decade and still switching to VSCode. Turns out, most of them never wrote a single Elisp package, or ever understood how some copy-pasted magical elisp snippet ever worked. I can't claim to be a chef or even good at cooking if all I ever do is microwave pizza. Even if I did that for twenty years.
I'm not saying that everyone using Emacs should know how to setup Gnus, master keyboard macros or should be able to whip up a new minor mode in zero-gravity. But please try the built-in Profiler. Learn how to use describe-command, describe-key, etc. It is not that difficult.
I guess you're supposed to have some version of Emacs already installed? Because the "Download" doesn't appear to include a binary, and the "Installation" just appears to set up your ~/.emacs.d/ folder.
Funny, I presumed that an "Emacs Distribution" would include Emacs.
I prefer Doom (https://github.com/doomemacs/doomemacs) to Spacemacs. However I haven't looked at Spacemacs for many years; perhaps it's now on par with Doom.
Que Emacs is an OS jokes.