Mastering Emacs
masteringemacs.org
masteringemacs.org
If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.
But I hadn't touched my config for three years before that! I've been using Emacs for 15 years and you definitely get to a point where you don't need to tweak it every day. 3 years is the kind of time some people would switch to a completely new editor. I have, in a way, except it still supports all the workflows that have become familiar over the years.
"M-x magit" get a nice list of the status of the files in the current branch.
After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date.
At a previous job the head engineer flagged the number of commits I was making as an issue since I must be wasting a lot of time pushing incremental changes. When I showed him that it took me about as long to push changes to my branch as it did to save the file he was flabbergasted that one could use git without pain.
Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind
I'm curious if anyone has tamed the weird inconsistencies of how new frames (or is it windows? Can never keep the terms straight) pop up. For instance a CIDER error buffer shows up using some completely different black magic than magit
Seems potentially workable. Youd just jump back to the last buffer a lot of time, but that's quick and intuitivr.
Ex: In Magit when committing it now first shows a "changes" buffer that you have to kill and then you can get to the buffer where you write the commit message. Not a biggie but prolly breaks the original UI design
https://www.masteringemacs.org/article/demystifying-emacs-wi...
To be honest I've never played with this part of Emacs. The way I use it I'm fine with the default. But if not it's possible to take control of Emacs internal windows management.
(setq magit-display-buffer-function 'magit-display-buffer-fullframe-status-topleft-v1)
(setq magit-bury-buffer-function 'magit-restore-window-configuration)
(add-to-list 'display-buffer-alist
'("\\*Magit*\\*"
(display-buffer-reuse-window display-buffer-in-direction
(direction . bottom)
(window . root)
(inhibit-same-window . t)))*Then maybe keyboard macros. Define anything you can input in a "tiling" way on your keyboard as a macro to let the editor perform it repeatedly. Approximate quote from coworker: "Sometimes you do things inconveniently, but what you do in Emacs was highly efficient."
Then running vterm inside emacs and searching and copying from the vterm buffers to use text elsewhere.
Of course org-mode as an extremely neat way of managing information and to do. I use it every day, a lot. I use it for notes, for to-do, for time tracking, for literate programming, for devops, for creative writing, and probably more.
Then the pain I get, when I see people closing their vscode, just to reopen it in another directory ...
Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.
That my biggest beef with VScode and IntelliJ. Why on earth I can’t have multiple projects open and switch between them as fast as in Emacs / Vim with Tmux Other than that I could somewhat live with modern editor, but I’m switching constantly between 5 different projects and VSCode solution to have single workspace makes navigation an awful experience
- Check to see that there isnt an MR outstanding bysomeone else ( using https://github.com/isamert/lab.el )
- (Optional) Cherry pick the commit from another stream where it may be fixed (magit-cherry-pick)
- Often massage the code (emacs cedet)
- Commit the code (magit)
- Submit a build (local built in code, elisp calling a local binary)
- Tag the build as the correct type (magit)
- Update the jira status (org-jira again)
- Wait for testing to complete, watch (eww)
- Email the requester on test results (wanderlust)
I also use:
- Some slack client for emacs (i dont remember the name)
- slime connected to nyxt brower so that I can automate some of the garbage that requires javascript.
Its enough for me to complete my day to day work.
>Does it allow one to do everything one can do in browser Jira?
I dont think it can do the dashboards and reporting metrics, but for the 'issue' work yes.
> Set custom fields
Yes. Although i had to maintain a map of custom field names to what they actually were, or you'd see cf_023042432 as the name.
> handle multiple boards
I don't use jira this way to know what it means, is that the same as multiple project prefixes (if so yes, i dont know what boards are).
What's really important about all of this is, it's all Emacs. Every magit buffer, every org-capture buffer, it's all just Emacs buffers and they're all configured the way you like. If you need to do a regexp find and replace while you're capturing a note, you can. If you make a typo in a note, in a commit message, in an email or anything else, it's spell checked and you can correct it with the same key you always do. This integration is the real magic.
And those 5 tools would likely beat Emacs in their individual area.
At the end it's all a tradeoff between low fringe with somewhat good enough performance, or high fringe for stellar performance. Sometimes you need it, sometimes not.
Well, that's the real issue for me. I spent a month an a half working on "configuring" NeoVim. I got it to a somewhat ready to use state for my usual workflows. But I still had a big pile of tasks in my backlog to actually get it finally 100% mine.
Then I discovered Helix, which doesn't need any configuration, no plugins to play around with. Builtin LSP, Builtin Fuzzy Finding of files, TreeSitter and the list goes on.
Even though it's still not fully checking all the boxes I need to have a 1 to 1 mapping of my previous workflows to what Helix offers. I find not having to build my own editor out of the Lego pieces and always needing to improve what it can offer me, makes the editor actually enjoyable.
IMO, VIM, NeoVIM and Emacs should start looking into implementing a bit more than just the barebones, some of these new features that people are accustomed to in 2023, and more and more will flock to these good editors.
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
Helix is different from Lunar in the sense that the features it comes with are part of the core editor and the editor still feeling like an editor
Maybe 2 lines, if you otherwise would not use company-mode.
1 line requiring lsp-mode.
1 line setting lsp diagnostics provider.
1 line adding lsp mode to python-mode-hook.
2 lines enabling the linter (if you want that) (I use flake8).
2 lines for setting an additional shortcut.
23 completely optional lines for marking some variables from .dir-locals as accepted/safe.
1 optional line for changing the color of the breadcrumbs header line.
Approximately 2/3 of a page, including all optional config I have.
The only thing which hold me back to really learn it, were the stories about repetitive strain injuries: https://news.ycombinator.com/item?id=36718793
Control with the thumb was the original configuration when emacs was built.
Without wanting to be a troll, that's exactly what happened to me within 3 days after switching to emacs.. So I reluctantly terminated my emacs experiment early and switched back to vim..
But if you say that they are the least import part of Emacs, I might revisit it when I have the time. Thank you for the tip.
(2 means eMacs specific, 1 means general. Sorry slightly confusing.)
Eg (1) macOS by default shares some eMacs key bindings.
(2) It is not originated from it because initially those keys aren't where they are now.
Solutions are
1. Remap the keys to solve (2) 2. Programmable keyboard (for every key bindings) to solve (1)
From OP of your link: http://xahlee.info/kbd/i2/palm_control_key_youngstabber_2013...
When I learned emacs I just learned the tiny handful of motion commands: fwd, back, up down, by character, line, paragraph, code unit; plus opening and saving files -- basically the same power of Atom or Sublime or such. Then because of how emacs works I'd learn a new command from time to time and wonder how I lived without it. Even now 45 years later, I learn a new capability every few weeks, though of course Emacs is a lot more capable than it used to be!
A book like this is great, of course, once you're already comfortable with it.
Currently, I rely on VS Code for coding, but turn to Emacs for text editing, macros, and text transformation with Elisp.
For a fast track to mastering Emacs, Mickey's book is a must-read.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
And that's why I can't switch. That and magit.
VS Code's goal is to get the low-effort 30% of devs who want something that will just work right out of the box, while providing enough functionality/customization to attract a significant fraction of the remaining 70%. And given that, it's pretty good.
But I'm skeptical it will ever be as good for someone who does want to make the investment in something like Emacs.
Tempted by the 29% discount on the book, Mastering Emacs is a well-polished emacs blog
The things that drove me back to vim were basically:
- Poor mercurial support. Monky is supposed to be like Magit but lacked support for staging individual hunks or any of the hg evolution commands. This forced me to use terminal modes which...
- ...The terminal modes are absolutely atrocious half baked pieces of crap. The only advice I really got on this was that using the terminal modes is "not the emacs way".
- I found it to be very opinionated about the style of C code I was writing. It tries to automatically indent things in very specific ways and god forbid you want to change the level of indentation of a block. You can change the way emacs indents your code in your config, but again, god forbid you ever want to do something slightly different to your config.
- Working with panes (windows), buffers, tabs etc. is a pain. You close a buffer and it disappears from the screen and is actually still open, and it pops up again when you wanted to go to something else.
This sounds like a bad review but I did for the most part enjoy using it. I just liked vim with tmux more.
(I'm a Vim user, but have sometimes half-pondered the thought of getting into Emacs, (using evil-mode of course), for the org-mode & co)
Emacs is also extensively documented and highly discoverable - even within Emacs. There is a built-in tutorial (like vimtutor). And once you get past a few lessons using their info pages or website, you will have enough skill to pull up the documentation for all core features. The info pages are often books on their own right.
I personally never felt the need for a book. That said, I do recommend buying the book to support the author. Their articles on the masteringemacs website are pleasant and high quality stuff.
I have read the book and it is the best Emacs book I know of. Highly recommended.
I recommend you simply make an alphabetic list of various Emacs commands.
You will see the correspondence between many of the commands depending on the modifier (Ctrl, Alt, Ctrl-Alt, etc.) that is used.
Listing Control then Alt (Meta) we have: A - Beginning of Line, Beginning of Sentence; B - Back one Character, Back one Word; D - Delete Character, Delete Word; E - End of Line, End of Sentence; F - Forward one Character, Forward one Word.
and so on.
Most of the letters chosen are mnemonic so they are easy to remember.
Once you have memorised the standard Control and Alt letter combinations, plus a few more such as \, (space), and / and you will find the commands just "fit". They are "in your fingers".
They are also usable on the command-line, bash defaults to using Emacs editing commands as well.
1. Like you, I am coming from vim (or using vim bindings in any editor I use). evil-mode is great but the book is focused on vanilla emacs movements and text manipulation and so there's good chunk of the book devoted to that which wasn't applicable to me. 2. This is more of a nit, but I do get a general tone that the book sees having to use elisp as a kind of drawback. Maybe I'm reading too much into that, and it is certainly still the case that you will have to do a lot of configuration to get a setup that works for you. But for me my interest in lisp is part of what makes me interested in emacs so I wish it didn't shy away from it as much.
That said I still found it overall worthwhile for understanding the building blocks and terminology. Also now is a great time to play around with a fresh emacs install. The 29 release has a bunch of goodies that make it easier to build towards and IDE-like experience with many out-of-the box pieces. It comes with a language server (LSP) client, native tree-sitter integration, and a nice declarative package management system that doesn't require any third-party deps (though you can swap the underlying engine to a third-party one if you need the extra features)
One thing I turn to VS Code these days for is Jupyter / Quarto notebooks.
It's not possible to have the same development workflow with Quarto and Org-babel since you can't run/rerun code chunks up to your current cell and automate figure management (for Org-babel).
I think these are not difficult to implement but these days I just want to use something that has these features out of the box and that notebook space is rapidly changing.
No issues with plotting figures in emacs-jupyter
https://github.com/emacs-jupyter/jupyter#org-mode-source-blo...
I would love someone to do an Emacs distro which integrated ErgoEmacs into it from the beginning: https://ergoemacs.github.io/
No, CUA-mode is not enough.
I used to know one or two dozen totally different editors in the 1980s, some radically different, such as Acorn's two-cursor system, with a source cursor and a target cursor.
There was no standardisation; this was necessary if you wanted to be able to edit text on any random platform you came across. I also worked with one or two dozen totally different operating systems in those days, from Netware to RISC OS to EPOC16 to CP/M to AIX 2 to OS/2 1 to GEOS to TOS/GEM to AmigaOS.
Now, it's different. In the 1990s there was a huge wave of standardisation. Most of those OSes went away and the few that survived adopted standard UIs.
IBM CUA became the industry-standard UI, for DOS, Windows 2/3/95/NT upwards, for Linux with Qt or Gtk based GUIs, for much of Mac OS X, for OS/2 2.x and upwards.
The same base menu layout. The same keystrokes: Ctrl-S saves, Ctrl-O opens, Ctrl-F finds. Yes even on a Mac (but it's Cmd-S, Cmd-O, Cmd-F, but it's very easy to adjust.)
I no longer have to know a dozen editors. I know one UI and it works on every editor from FreeDOS to Windows 11 to macOS to KDE 5.27 to Xfce, LXDE, LXQt, Cinnamon, MATE.
(OK, not GNOME, but that is just one reason among many that I don't use GNOME.)
It is the industry standard and it has been for a third of a century.
Any new editor I might try must conform to it, or I am not wasting my time.
I don't care how much legacy it has. I don't care how powerful it is. I don't care if it will break 40 years of tradition.
It's meant to be infinitely customisable. So customise it. If the user has any existing config file at all, fine, honour it, turn off all the new stuff and start in 1976 mode. No problem. I have no config. I am 100% happy for that to stay for those who know it.
Big notable ones:
* The menu tree.
* The keystrokes to access the commands in that menu tree.
The terminology. I do not have a meta key. You don't have a meta key, either. No new computer since the 1970s has a meta key. I'm a keyboard collector with a deep fondness for clicky mechanical keyboards; in daily use I use a keyboard from 1991. It predates USB and the "Windows" key. It doesn't have a meta key.
Here's the Wikipedia entry on CUA: https://en.wikipedia.org/wiki/IBM_Common_User_Access
Which, incidentally, I expanded from a stub about 18 years ago.
Another excellent piece of evidence that cua-mode is inadequate is that ErgoEmacs exists: https://ergoemacs.github.io/
It's actually not bad, but it's a total pig to try to install and configure unless you are already an Emacs guru.
for me the appeal of emacs is that it is so very cyberpunk and that it makes me feel like a hacker. seriously. also reducing the tool set appeals to my natural inclination towards minimalism.
Others would use tramp mode, and open multiple remote sessions within a single emacs. This makes it easy to cut and paste between systems.
I'm in my late 20s.
There is not a single modern tool that beats Emacs in ease of customizability and extension.
Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.
Long after you relearn your IDE workflows twice over, we'll still be using emacs.
And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.
We want to keep using our tools and get work done, not keep up with the Joneses.
Yes, if you're talking about a timeframe of ~50 years, use vim and emacs. I just don't care that level of future proof.
There isn't any compromises that make vim or emacs less useful than those tools with much less longevity. They are just as good as an editor to even those who don't care if they will be around 50 years from now.
But that's the point: I don't want to take a significant amount of time to learn and configure an editor. I want a IDE that works well almost out of box.
Maybe my opinion will change if one day I decide to try a more batteries-included vim/emacs like Doom.
Wellllllllll....
I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".
Or do you mean more like changing how editor looks, how many windows/panes/tabs are displayed and where are they displayed?
This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate.
This makes Emacs very "malleable", and it's likely easier than with most other tool to change it in custom, specific ways. It may seem dangerous, but it comes from a culture where this extensibility is very front and center, with documented design pattern to support it (hooks, customization settings...).
Count before you post; Emacs now boasts over 300,000 lines of C.
"Encompassing Massive Amount of C Source"
Emacs 29.1, excluding the test directory; top ten languages:
all SLOC=2618374 (100.00%) LLOC=182918 in 2584 files
elisp SLOC=1188181 (45.38%) LLOC=0 in 1566 files
man SLOC=501820 (19.17%) LLOC=0 in 48 files
C SLOC=387169 (14.79%) LLOC=159681 in 317 files
Texinfo SLOC=288384 (11.01%) LLOC=0 in 182 files
Lisp SLOC=175786 (6.71%) LLOC=0 in 1 files
Objective-C SLOC=18289 (0.70%) LLOC=8480 in 8 files
Tex SLOC=16031 (0.61%) LLOC=0 in 23 files
m4 SLOC=10436 (0.40%) LLOC=0 in 133 files
shell SLOC=6819 (0.26%) LLOC=0 in 28 files
C++ SLOC=6240 (0.24%) LLOC=2924 in 5 filesThe C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative".
In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.
Good tools change the way you work because they make certain workflows possible. If it was that easy for you to tweak your editor, you would too.
Because it's thought out and polished by decades of use.
Because it's extensible.
Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?
Maybe for whatever work you do your IDE works better for you.
In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.
The same applies to Visual Studio (not vscode).
vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.
If I need autocomplete (which I actually don't like that much), LSP works well for my needs.
PS. Try Doom Emacs and evil-mode:
Been using Vim for a few months now but I was checking out eww the other day (along with learning more about emacs in general) and it’s certainly interesting…
Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.
There are certainly some constrains on what plugins can achieve due to nvim being exclusively a TUI, but in my opinion the pros of the editor outweigh the cons.
As to what makes me choose neovim over vscode with a vim plugin, it's a combination of things. One thing I love is that neovim is extremely easy to configure. I also enjoy that everything follows vim rules, rather than some things like file trees or consoles having their own unique rules. I have also become dependent on some vim plugins that don't exist in vscode.
Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?