A CEO's Guide to Emacs (2015)
fugue.co
fugue.co
However, this learning is foundational and compose with almost everything you want to do as a programmer. When you start using line/words based edits, performing a git rebase becomes much faster and comfortable. You start 'grokking it'. On the other end of the spectrum, you have colleagues who are 'experienced programmers' who use VSCode and therefore need help any time they don't understand the messages git spew out to them when pushing the git button does not work. It's one example, but you'll learn regex, vim, maybe even some lisp!
With all that said, I've been learning some emacs and even though it taught me a lot, the experience has been bumpy. I loved Spacemacs shortcuts design, but I've encountered multiple bugs that make it hang at boot, etc. I'll probably restart with emfy or something like that soon.
In the case of emacs though, the problem to me is the continuous learning curve. You ALWAYS and CONTINUOUSLY have to invest time. Every time you want to use a new language, try a new plugin, etc. you need to learn a bunch of shortcuts. I think this is detrimental to actually becoming more efficient at using your IDE.
With VSCode, I can quickly try a dozens of plugins without having to learn all the bindings, and if I really want to use a few long-term I can just fuzzy search the commands and get a reminder of what the shortcut is.
The example you give with git is about investing your time learning git, not investing your time learning emacs. I use git on the terminal within VSCode.
Not at all. First, you learn Emacs Lisp. Then, you don't need to learn anything else related to Emacs, EVER.
> Every time you want to use a new language, try a new plugin, etc. you need to learn a bunch of shortcuts. I think this is detrimental to actually becoming more efficient at using your IDE.
No, not at all. Just rebind the defaults - the defaults are what suited the author of the package, and being a different person in different environment there's very little chance they would suit you. So, instead of learning how others do things, just pick keys you want to use, and write a hook for every new mode to bind those keys to the functions you expect of them. Once you know even just a little Elisp, it's a trivial thing to do - literally 10 minutes on the longer side.
> I can just fuzzy search the commands and get a reminder of what the shortcut is.
I do the same in Emacs all the time. Press Alt+x and start typing, Helm will display keybinding next to the (fuzzily matched) command names (doing it this way is often faster(!) than pressing the key combination, which can involve multiple keys in a row, in a so-called chord). From the same interface, you can jump to the command source and display its documentation, too.
> The example you give with git is about investing your time learning git, not investing your time learning emacs. I use git on the terminal within VSCode.
I think the OP meant specifically the interactive rebase, where you're expected to replace the leading word in each line with one of a few choices. Of course, Magit is the answer here, so you don't even need the advanced ways of navigating and replacing text.
That's false. You can continue to invest time, but you do not need to. Additional investment yields additional rewards, of course, but there are plenty of folks who just use Emacs as a glorified nano, knowing how to save and how to quit and not worrying about too much else.
I think perhaps folks who are used to systems with limited potential are confused when dealing with a system with unlimited potential. You no more learn everything you can do with Emacs than you enumerate the integers: instead, you use the bits you need, as you need them.
> Every time you want to use a new language, try a new plugin, etc. you need to learn a bunch of shortcuts … With VSCode, I can quickly try a dozens of plugins without having to learn all the bindings, and if I really want to use a few long-term I can just fuzzy search the commands and get a reminder of what the shortcut is.
What are you talking about? Among the virtues of Emacs are consistent keybindings and fuzzy search for commands.
I do not get all these folks who think they know everything about Emacs when they clearly have never used it.
It's all wonderfully subjective.
You get the extensibility of emacs, but with the ergonomics of 'just' a text editor.
https://karthinks.com/software/batteries-included-with-emacs...
> This article gets why Emacs is awesome so right, that, to be honest, there's nothing to add.
> I'm always amazed by the people leaving Emacs for a few years to then come back and falling in love with it once again. Only very good tools make us feel like that. Everything else is nostalgia.
A CEO's Guide to Emacs (2015) - https://news.ycombinator.com/item?id=18652629 - Dec 2018 (1 comment)
A CEO's Guide to Emacs (2015) - https://news.ycombinator.com/item?id=15753150 - Nov 2017 (172 comments)
A CEO's Guide to Emacs - https://news.ycombinator.com/item?id=10642088 - Nov 2015 (62 comments)
Anyone who hasn't looked at VS in a while I'd highly recommend it, just spending some time removing the bloat can make for a real clean experience.
That just sounds like a bug, not an inherent deficiency of emacs.
Curious what language, mode, and of you had custom config.
You can't be further from the truth. I was a power Emacs user for almost a decade with virtually no Elisp knowledge. I could set variables, but as an example, couldn't write a loop or function.
Of course, once you know elisp, you'll find excuses to use it.
https://www.gnu.org/software/emacs/manual/html_node/eintr/in...
I think they are referring to the integration of VSCode with Docker. I.E. build, deploy and run your project in a clean container environment quickly using a workflow that is intuitive to VSCode users.
That being said, I know for me it would be fairly trivial to workout this same type of integration for myself with Vim. Although I am not an Emacs user I am positive it wouldn't be difficult to do something similar. I don't really see this as a feature I would ever care to implement or find important for myself.
EDIT: to be clear, I am a Vim user and do not find VSCode intuitive at all -- but I have seen how it seems to really work well for a lot of people
https://www.gnu.org/software/emacs/manual/html_node/tramp/in...
https://www.gnu.org/software/emacs/manual/html_node/tramp/Cu...
What‽ S-expressions are head-and-shoulders better at declarative configuration than JSON. Compare these two options (the JSON is from https://cloud.google.com/appengine/docs/admin-api/creating-c...):
{
"deployment": {
"files": {
"example-resource-file1": {
"sourceUrl": "https://storage.googleapis.com/[MY_BUCKET_ID]/example-application/example-resource-file1"
},
"images/example-resource-file2": {
"sourceUrl": "https://storage.googleapis.com/[MY_BUCKET_ID]/example-application/images/example-resource-file2"
},
}
},
"id": "v1",
"handlers": [
{
"urlRegex": "/.*",
"script": {
"scriptPath": "example-python-app.py"
}
},
],
"runtime": "python27",
"threadsafe": true,
}
(app (deployment
(files (example-resource-file-1 "https://storage.googleapis.com/[MY_BUCKET_ID]/example-application/example-resource-file1")
(images/example-resource-file2 "https://storage.googleapis.com/[MY_BUCKET_ID]/example-application/images/example-resource-file2")))
(id v1)
(handlers ("/.*" (script "example-python-app.py")))
(runtime python27)
(threadsafe true))
Given equal experience with reading json data and lisp data you'd almost certainly prefer the much shorter (but lossless) lisp data.
hmm... do you know about M-x customize ?
> Node development environment running inside a container with VSCode. I don't even know if you can do that with Emacs to begin with.
Install docker-tramp.el and then `C-x C-f /docker:image_name: RET` to open a dired buffer in the container.
`M-x shell RET` for a shell in container.
Use this often? Make a bookmark with `C-x r m bookmark name RET`, then next time get to it from your bookmark list accessible with `C-x r b`.
For example, there will be more posts about how they mimicked most of the functionality of VSCode or a Jetbrains IDE than about any actual code they wrote (other than elisp).
Given that I am naturally drawn to polishing my tools rather than actually using them, I am afraid that if I try Emacs my time,attention, and productivity will be sucked into the black hole of optimizing my Emacs workflow instead of actually executing my workflow.
Need I say anything more?
You bolt literate programming onto it.
Then you tell your code blocks they can send input and output to each other via text in the document. Now you've got an excruciatingly well documented multi-language pipeline.
Then you get the source data for all your analyses in real time from [wherever they came from].
Then you render it _beautifully_ with your dependency graph documentation generated from graphviz (which graph data was newly inferred on this very run).
My first org-mode killer app, years and years ago was a monthly billing collection and analysis for a backup system I was running. The first pass took me a week to figure out how to collect and analyze. A few iterations later it was literally open the org-mode document and tell it "Do the thing". All my intermediate work was shown, everything was clear and open to inspection, and beautifully typeset. And I could generate it as HTML if they wanted it in a web page. (at the time they wanted PDF).
This is one of the ways org-mode is great. There are others. :)
It's primarily two things:
1. A markup syntax
2. a TODO manager. It's flexible enough that you can come up with your own custom TODO workflows (e.g. GTD, etc). You can do queries on a fair amount of metadata to construct your TODO list.
In support of all that, it has good table features (you can do spreadsheet like functionality in them), code management (execute source code blocks similar to Jupyter, but you can have code in multiple languages communicate with one other), link to just about anything (with a bit of setup, I can even link to Outlook emails). While in the middle of your work, you can capture notes and/or TODOs and have them filed away in the appropriate file and location within that file.[1] Finally, you can export into many formats (I don't write pure LaTeX any more - I always export an org file to LaTeX).
Example of a simple thing I do.
I read an email. It contains actionable information. With a keystroke, I create a TODO item in org mode, which contains a link to the email. Later when browsing my TODOs, I have access to the context.
Likewise, I'm reading an article in Chrome/Firefox, and I want to file it away for some reason. With a click on a bookmarklet, it sends the URL and related info to Org mode in Emacs and it is filed away.
A more sophisticated example that required some elisp: I take meeting minutes at work. Any time something comes up where a TODO is assigned to a person, I hit a keystroke and type in the TODO. It finds the heading called "Action Items" for that particular meeting and files it there. At the end of the meeting, I export the minutes into HTML or Word and email it out.
Every time I (re)turn to a language or other text-based thing, I could very easily (and often do) get sucked into a tinker-thon trying to perfect my vim experience.
I've had to accept that I just have to use the IDE du jour (or de la majorite, more accurately) to get up and running. Though you bet I'll lose some evenings to getting a vim setup working.
There's no way you're going to appreciate the power of either editor after using it only a few times.
- the main value of vi is editing speed. It’s just much more efficient to edit text this way. Have you ever realized you needed to make a bunch of changes to a file and then sort of groaned at how much legwork that will be? Maybe you even don’t bother because it doesn’t seem worth it? vi usually makes short work of these. It’s hard for me to overstate how big of a productivity impact this has had for me: it makes sure the mechanics are never the bottleneck in my coding process. The editor can keep up with me.
- the most common painpoint with vi is that you don’t get all these snazzy IDE features. That’s why sometimes people run IDEs with vi keybindings which are never quite exact; they want features like language-aware renames and other refactoring support that vi lacks, so they make a tradeoff. But this is actually improving rapidly, thanks to the proliferation of language servers and their rapidly improving support in Neovim. I hope that soon I will no longer have to think about these tradeoffs.
At any rate, everyone should write code in whatever tool they like most, but that’s been my experience with it.
If it is purely mechanical type changes I would just use sed or find and replace, otherwise I think scrolling with a mouse and clicking tends to be fast enough. Could you explain a bit more about how it could be faster?
Probably best to see it in action to fully appreciate it.
But it really is a lot of faster. I've watched colleagues edit code with the mouse (e.g. move this "if" block under that "else" clause or what have you) and I will say it's much, much slower than I would do in vi. They are not incompetent or clumsy; I would have been slow with the mouse too. In fact, I'm editing this comment with a keyboard and trackpad and it feels awkward and slow.
Here are a few ways in which these actions just happens faster vi:
1. jumping around in the file using your keyboard. Taking your hand off the keyboard, moving the mouse to the right spot, clicking there, putting your hands on the keyboard, and then typing is a lot of movement. In vi, you have lots of tools to just move around, i.e. to do the part you do with the mouse. You have incremental search, bookmarks, jumplists, keys for jumping to the delimiter match, or the next code block, or jumping to a line number or function definition. There are EasyMotion-style plugins that let you jump quickly to whatever you're looking at on the screen. And many more. These are all optimized to be just a couple keystrokes away. They take time to learn and become fluid with but they give you a kind of total, effortless control over what part of the file you are editing.
2. Just good keyboard-centric editing basics. Putting aside all the ways you can move around a file (or files!) and all the ways you can repeat similar actions in different parts of the file, you also just get to be quicker making specific edits. You can _probably_ do all of this with readline-style keyboard shortcuts in other editors (e.g. replace this word with another word without double-cliking it with a mouse), but vi forms a sort of interactive language for doing these edits, and the way vi works just causes you to learn them and use them consistently.
3. Fine-grained control of editing actions. This is the hardest one to explain. Modal editing has the property that your actions are sort of transactions. You are in normal mode, you take some action that puts you in edit mode, you do some typing, and then you leave edit mode and the thing you did is now a block of action. It can be undone as a block and applied again elsewhere as a block. So for example, if I want to replace "}," with ");" on like four lines, I can do that by doing it once and applying it three more times to each line (using "."). Sure, you could also do that with a find-and-replace tool, but just operating that menu isn't worth the overhead for four lines. In vi, that's just how you edit; it's by-the-by, with no special effort required.
4. For more complex repeatable actions, you have macros (which is sort of like a second-level of text editing transaction), vi's strong regex support, actions that work on rectangular selections, and plugins for multiple cursors. One way to think about the sed case is: what if you didn't have to reach for another tool and it was instead sort of conceptually integrated into your everyday editing experience? It would be much lower friction to reach for, so you'd use it more and more efficiently.
There's more, but I think that's the important ones, or at least the ones I think have given me the most mileage. It's all easier to show than tell, and of course YMMV.
I haven't had an emacs config for >25 years.
Plus, I can usually work in someone else's Emacs session and most people can work in mine. (Yes, they almost always comment on how it's odd to not have their customizations, but they're not tripped up by mine.)
There are definitely people who wind up messing around more than anything else, and people who don't blog about the work they actually do since their blog focuses on Emacs, but it isn't hard to avoid that. A new language isn't quite the one click plugin of VSCode, but with lsp-mode it's actually pretty close. Perhaps 4 lines of config, plus extra keybindings you can grow organically.
I don't think it follows that just because you blog about something, it means you spend the majority of your time doing it.
In both cases I probably add to or tweak them about once a year.
It’s not a tools fault if you can’t resist tweaking it. If anything, that indicates that you’re not actually optimizing a workflow if that optimization step is actively disrupting a workflow. Self discipline is a good thing to build up for workflow optimization, far more than any tweak to a dotfile.
Personally I can't live without a few neovim packages like auto complete and switching files and searching text in a project etc.
I completely agree with the set it and forget it approach though. But if that's the case I think vim/neovim might be your best bet.
What languages do you program in, and do you use code completion/debugging?
I find that code completion is a huge productivity boost for me, as well as having a good interface to a debugger (just the debugger portion of the IDE in Jetbrains justifies the price in my mind).
In addition, smart annotations where the IDE will annotate a function call with the names of the parameters is a huge boost in languages that do not have names parameters (for example C, C++, Rust).
In addition, when you are doing type inference (auto in C++, and let in Rust), having the IDE automatically annotate the variable with the inferred type gives the best of both worlds - allowing me to avoid boilerplate and committing to a type, while also easily allowing me to see what the type is.
I am not sure I can easily get all that out of Emacs or Vim.
The best is that I can use the standard Emacs commands I'm familiar with to use LSP. E.g. Per your example, I can use the describe-thing-at-point command, which is in Emacs for the longest time, to show the inferred type of the variable at the cursor. I can use the same command to show the signature of a function. Lsp-mode hooks into the old command to do the magic based on language context.
Same with the company-mode. Since it's a generic completion framework, I'm already familiar with its commands and key bindings. It works the same for all languages and other editing mode. E.g. in writing English, the completion command would pop up a list of word choice.
Indeed, that does seem to be the community of people who blog about emacs. It's a shame because it makes emacs look complicated to the beginner.
But like many users I have a short init file with very few customizations: In my case mainly removing all the chrome and other bells and whistles so emacs looks like it did back in the 1970s. And it works great!
If there isn’t already a good mode for what you want to do, Emacs is good only if you want to write the mode. For instance Haskell support in Emacs is not great; the most-used mode is not part of GNU Emacs and falls well short of the quality standards of the modes GNU ships. I found myself trying to do Haskell in Emacs because I already used Emacs for Orgmode. This was a mistake. I was better off doing Haskell in Vim.
So for stuff that has a good mode—Org, lisp, C, mail if that is your kind of thing—use Emacs. Otherwise don’t bother, unless you like programming your editor.
I hate this meme and wish it would die.
Emacs is a perfectly suitable editor that happens to have really bad defaults because the developers are mostly out of touch grognards.
With a modest amount of effort, emacs could be made to have appealing aesthetics and sane defaults, but because eMaCs Is An OpErAtInG sYsTeM it stays bad.
Sure, for some peoples use cases. Also “modest amount” isn’t really true for new users. The time it takes to look up potential configs, figure out how to make changes, play around and see if that’s what they want from their editor, and in general figure out what’s possible doesn’t really happen in a “modest amount” of time.
> “>Emacs is not so much an editor as it is a tool well-suited for writing custom editors.”
There is nothing wrong with this comment, it is a correct statement because emacs by your own admission is a flexible tool that can be modified to one’s liking. For a lot of people that means tailoring it around their workflows/uses before it’s actually useful to them.
I'm saying that the developers could, with modest effort, provide a dramatically improved out-of-the-box experience for 80% of users that obviates the need for a lot of config futzing.
I'm asking because I learned its defaults before windows had the market prevalence that it does, and it just doesn't seem all that different from an outside perspective.
I think the term 'grognard' is not helpful to your case. When I read it I find myself assuming that you're dismissing the experiences of people whose context starts before yours. You might prefer to give a different impression.
There are dozens of low hanging fruit.
Off the top of my head:
- dispensing with the absurd references to Alt as Meta that haven't been relevant for 35 years
- bringing the terminology in the documentation into the 2000s by fixing what's called window, a pane, etc.
- including CUA mode as default for ease of onboarding windows users
- including per-pixel/smooth scrolling which AFAICT is only available via the emacs-mac port
- updating the graphical interface to make it look modern and sophisticated instead of the current look which can best be described as "abandonware chic"
- improving handling of large files with long lines so the editor doesn't choke
- setting the gc threshold to a much higher value
- the yes/no vs y/n thing that literally everyone rebinds
- make middle click insert at the cursor instead of where the mouse is
I'm certain there are dozens of others.
It would seem you and I have very little common ground.
The master branch (Emacs 29) has this in `pixel-scroll-precision-mode` and it seems to perform better than the emacs-mac implementation.
The main problem, as they often mention on the mailing list, is that the manpower is low. There is no reason they don't want to solve the large technical problems, like very large files.
I guess most people know by now, but Emacs’ keybindings were designed for a specific keyboard that had way more keys that usual: https://retrocomputing.stackexchange.com/questions/495/what-...
As Emacs was ported, they replaced dedicated keys with chords and sequences and we ended up in this mess, instead of at some point doing a full review of the default keybindings to match the input devices we actually have, merging in the conventions that had developed in the meantime.
After three decades of use, I have internalized those defaults because I keep having to use Emacs in its default configuration from time to time, have remapped many keys in my workstation, bound custom functions and all that. It’s still a paper cut, and also prevents me from recommending Emacs to more casual users.
Being different too much can be bad too. Emacs has not much big fails, but many small things which lead to being bad by thousand little cuts.
> When I read it I find myself assuming that you're dismissing the experiences of people whose context starts before yours.
Why does it matter? Nobody want's to take your emacs from you. The discussion is always about bringing in new people, and why people leave emacs. And that emacs has a problem with this is not new. Emacs is always swinging between hype and death, and it's not like this has become much better over time.
The difference is I'm not a zealot.
You're not actually understanding what I've written, if this is your takeaway.
Also: Emacs user here, for more than a decade. My opinion: the defaults in Emacs are horrible. They were set in different times, on different computers, with different keyboards. They should get changed. I think most users agree with that. The problem is that whatever we would change the defaults to, it would estrange a part of the community. So nothing gets done. Advanced users don't see the point of struggling, since they already have everything rebound to the keys/menus/toolbars/etc. they want and need. New user see the need, but don't have the skills. It's really a Gordian-knot type of problem.
As an aside: similar thing goes on with Emacs' terminal support. It's obvious that maintaining compatibility with display technology from the '70s takes a real toll on both developers time, and improvements that would be possible if not for that compatibility. But then you get a huge crowd that uses Emacs via SSH somewhere, and they go rabid if you mention anything about dropping the terminal support.
Just some shmuck whose identity is all wrapped up in his text editor.
Kinda sad really.
Why defend somebody who's quite literally asking for it? Doesn't make sense.
Used it enough until 2005 to get it several features burned on my brain.
Nowadays I really don't see the point, and ironically neither does the creator of XEmacs.
https://www2.computerworld.com.au/article/207799/don_t_use_e...
Yup. And not entirely coincidentally it uses Lisp, which is not so much a programming language as a tool for writing custom programming languages.
I've been using Emacs for twelve years now.
I don't recall having ever blogged about it, unless we count occasional longish HN comments, usually helping answer a fairly specific question.
Selection bias may be vastly skewing your analysis here, is what I'm trying to say.
I spent a few tens of minutes setting up LSP for the languages I use, a few hours browsing and trying out themes, and then I maybe spend less than an hour a year on my config
Are we reading the same articles at all? Most of the Emacs posts I see are about extending features that lesser editors could only dream of supporting (using it as a window manager, media center, GUI etc.).
I always find it suprising how far anti-Emacs zealots will go to try and cast GNU+Emacs is a bad light. Somehow the fact that the GNU+Emacs community cares enough to share their configuration tips is a "bad" thing, rather than just being indicative of a supportive and friendly user community.
I guess if you are stuck in proprietary, telemetry-ridden editors like M$ vs-code, or sublime text, somehow you have to convince yourself that the grass truly isn't greener on the other side, and this is just one such coping mechanism.