Hacker News Reader

Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to:

+ Help you realize how _you_ best deal with information.

+ Help you manifest your realization through _rapidly_ molding Emacs into your conceived model.

It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today:

  You'll get the most out of Emacs if you treat it as an 
  investment and put in the time to learn at least some Emacs 
  Lisp so that you can confidently explore and customize the 
  rest of the system. You don't need to become an expert 
  overnight, just learn enough to navigate the system (which 
  is self-documenting and geared towards helping you perform 
  that navigation).

Yes, it may feel weird or out of touch with contemporary aesthetics but that's really because it doesn't come with strong, tunnel-like notions of _how you should think_ and _how you should work_.

It is not easy today to come to terms with a tool that's simply designed to help you craft a computing experience, since we've been so conditioned to expect somebody else's model be there from the beginning:

https://xristos.sdf.org/why-emacs.txt

At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible

It doesn't get in the way at all. Once you understand what's going on, it is a huge productivity boost.

I've been using and programming Emacs for ~12 years. After all this time, I am at the level where it really feels like an extension of myself, almost like a cybernetic extra sense that I can put to use as I see fit. Practically, as I go about my daily programming, if I feel something is off and could be improved, I have a pretty accurate idea of how long it'll take for me to implement it. Usually it's not that long and frequent 10-15 minute diversions of this sort happen multiple times a day. It simply means that the process works as expected, I'm approximating an ideal -temporal- mind model.

A few times a month, I'll do more extensive work, focusing on a number of long-term projects or exploring various ideas I've had and put down in my notes. All this work is geared around helping me manage information more effectively. I'm an information junkie, hopelessly addicted to the Internet and that's by choice. I wouldn't give it up for nothing.

Emacs is the tool that makes the difference since this continuous feedback loop of me adapting Emacs to help me deal with more and more information, allows me to keep up. Being an information consumer is easy today, you simply sit back and absorb what's being blasted at you. Being plugged into numerous signal sources and managing that information _on your own terms_ is the tricky bit and where Emacs shines while most other tools fall flat, since they're either too constrained or lack the necessary programmability.

> I've been using and programming Emacs for ~12 years. After all this time, I am at the level where it really feels like an extension of myself...

The problem is that these days, you could use vscode or atom for a month or two, and get that same feeling. Emacs from scratch is not a great use of time anymore.

Maybe so, but the ceiling with those tools is very low. I simply can not do what I do every day with Emacs using vscode or atom. I know why you compared them, but I feel that these comparisons are meaningless. A category error.

Emacs is simply something else.

What are some examples? I'd say the ceiling is marginally lower (maybe) than emacs, but the learning curve to extend is orders of magnitude more approachable.

And I'm not sure the ceiling is actually lower.

Almost everything I do on the computer happens inside Emacs, using programs written in Emacs Lisp:

Writing code, reading/sending email across ~30 email accounts spread out over different services, reading newsgroups, mailing lists and RSS feeds, maintaining a presence in 7 different IRC servers with ~30 channels total, using a variety of connection methods, watching and filtering certain twitter feeds, controlling external applications through Apple Events [1], file management local and remote, remote system management, local virtual machine management, note taking, calendar, agenda, notifications, bookmarks for external applications (Chrome and Preview), password manager, version control, music playing.

I can keep going. The only programs besides the OS and Emacs I use on a regular basis are Google Chrome, Preview.app, VMWare, Calibre, mpv, bash/ssh, Unix command line tools (less and less) and my bittorrent client written in Common Lisp.

I've almost finished an Emacs Lisp controller for Chrome, allowing me to bring a lot of information (e.g. tabs) into Emacs in order to rapidly manage it on my terms. I've done the same for Preview.app. I treat it as a dumb vessel that does the rendering. The actual information (filename, metadata, current page, date etc) is extracted from it, stored and manipulated in Emacs. That way I don't rely on Apple to dictate how I'm allowed to use my computer. I can experiment with different paradigms and find the one that fits me best. Emacs is the magic that makes all of that happen.

[1] https://github.com/atomontage/osa

That speaks to the general breadth of the emacs extension/package ecosystem, which is impressive (but somehow not as impressive as you'd like), but how many of these things did you engineer yourself? And how many these things could not be implemented in modern editors? I'm not sure any couldn't be. Most already are.

Extensibility was emacs' killer feature when its main competition was vim and vimscript - that's just not the situation anymore.

Emacs main competition in the noumenal realm of ideas wasn't vim, but the commercial Lisp Machines mainly Symbolics. They were superior but technical superiority doesn't mean much in the domain of "Worse is Better" [1].

I didn't write all of the Emacs Lisp programs I mentioned, but I did go through most of them, changing the way they work to fit how I wanted to use them. This was an iterative process that is still ongoing.

What should impress you is not the breadth, but the paradigm itself as expressed in Lisp. You can probably write an IRC client in JavaScript and have it in VSCode. But that's not what I'm talking about. We're not ticking boxes down a feature list here to say "JavaScript can do that!". We're talking about a paradigm, and specifically about interactive development with a short feedback loop through Lisp which is "a difference that makes a difference" [2]. But in order to truly understand this, you have to go through the process. Philosophical truths can not be transmitted like pieces of eight.

[1] https://www.dreamsongs.com/WorseIsBetter.html

[2] http://www.informationphilosopher.com/solutions/scientists/b...

VSCode is quite restrictive in how it can be extended actually.

Atom is much better, and feels closer to Emacs in terms of allowing you to extend and modify almost every part of it.

That said, Emacs is just the king. Not only can you really just change absolutely everything, it is really easy to modify it all at run-time on the fly, which even in Atoms isn't quite so.

I had settled on Atom for a while, but the slow performance and high memory use made me switch to Emacs.

It gets in the way of your programming immediately - the friction involved in bootstrapping a viable emacs environment that unlocks all the potential everyone is always going on about, is very high.

Deep diving into emacs is not a productivity booster - its a hobby that one does for its own sake, if that's the kind of thing that floats your boat.

At the point where you find yourself dinking with Emacs and making excuses to yak shave instead of getting your work done -- which, given that it's Emacs and makes most other tools seem positively stone-knives-and-bearskins by comparison, is in practice a quite tempting trap to fall into.

The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.

Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.

Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.

Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.

I can understand that. I just like to tinker too much :). Going at it with a goal in mind would be a good idea

Wow, and here I was using Emacs to edit (usually) text files.

"I don't care about org mode"

Thanks for specifying this and confirming my observations. My experience has been that Emacs users are much more likely than users of other text editors to be researchers and other avid note-takers who do care about tools like Org mode. For example, I have a personal knowledge base that includes several thousand Org files containing my notes.

It's not a coincidence that the creator of Org mode is an astronomy professor[1]; whereas, the majority of the most popular VS Code extensions[2] that aren't from Microsoft seem to have been created by web developers whose portfolios include no research or non-web code repos.

My point isn't to disparage the users of VS Code, but to point out that a tool like Org mode is unlikely to be developed for editors like VS Code or appreciated by the users of such editors.

When TextMate was the flavor of the month editor that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for TextMate". It never happened.

Afterwards, when Sublime Text was the flavor of the month that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for Sublime Text". It never happened.

Now that VS Code is the flavor of month, I'm waiting for an "Org mode for VS Code". But all I've seen is an unmaintained extension[3] that provides roughly 1-2% of the features of Org mode[4].

[1] https://staff.fnwi.uva.nl/c.dominik/

[2] https://marketplace.visualstudio.com/search?target=VSCode&ca...

[3] https://marketplace.visualstudio.com/items?itemName=tootone....

[4] https://orgmode.org/org.html

I'm a researcher, and I have a git repository for my notes, which I edit using markdown. It supports latex math, tables, cross links, labels, and html if I need to do anything fancy, like inserting images, videos, etc. (youtube embedded video? no problem). I can edit them from any device, and they get sync'ed everywhere via git.

I can also read them from everywhere, and markdown renders super nicely.

I take markdown over org-mode everyday. I used to use org-mode 15 years ago, but today that's pointless for me.

Can you elaborate, please? How do you use latex, images and cross-links in markdown?

$$ for latex

![]() for images

[]() for links

cross-links is supported by some editing tools. (For example I use MacDown it does that.) It is not part of the MD spec. I do not use org-mode, but I know it well enough to admit it is unbeatable.

As others have mentioned:

* $$2^n$$ for latex, renders fine on all browsers

* ![]() for images

* []() for links, including cross-links

    ** The link syntax is [<text to link>](<link path>), so for example [this is a link](http://google.com)

    ** Markdown ## Headers have an anchor with their name (e.g. `#Headers`), so you can cross-reference any other 
    section of any other note in the git repo by just using [see this section](./path/to/other/note.md#that-section)

I have a simple CI service on my git repo that checks for broken links, so that if I move a file I get a CI error if there are broken links to it.

One of Emacs' strongest points is its ability to nicely integrate things other than "just editing code" into your workflow. As the half-joke goes, it already has a mode for everything. So in that sense, your question kind of comes off as "I only care about basic features that every editor has. What am I missing?"

With that said, even if we ignore Magit and Org, and just look at dumb code/text editing, Emacs has some pretty rare niceties. I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo". The interactive insertion and inspection of unicode characters is also nifty.

> I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo".

This feature is built in to all JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.), most popular web wikis (Confluence, Notion, etc.), Google's web Office suite, and Microsoft's web office suite. It's available as a plugin for VS Code.

It's also built in to MacOS (Time Machine), Windows (File History), Dropbox, SpiderOak, and Sync, though some of those require it to be enabled and it doesn't work with keyboard shortcuts.

> The interactive insertion and inspection of unicode characters is also nifty.

When does this come in handy?

Emacs will always be there for you.

Personally, I can't move because of the rich set of text editing commands. Some of it seems silly, like word transposition, or jumping over sexps. But with Emacs, it feels like it's just an extension of my mind, most of the time. I had the same feeling some time after I learned touch typing.

I think it really comes down to having the patience to learn how to extend your personal Emacs setup with the built in programming language: Emacs Lisp. From personal experience I can say that learning the basics of Emacs Lisp turned my relationship with Emacs from "preferred" to "nothing else measures up"

Ever other editor has a programming language for modifying it. What makes emacs special? couldn't you script all those other editors to do the same things?

I'd certainly feel my editor was amazing if I scripting 50 custom features but I wouldn't consider my editor better if I can script those same 50 features in any editor. I'd just consider the cost of switching high and not confuse that with whether one editor is better than another.

Have you used magit? How about slime? Org mode? Other editors don’t have those

> magit

Lots of editors have git plugins. The question is, what can you do with magit that you can't do with those?

> slime

This is a pretty niche need, but sure. I would agree that people writing most Lisps (excluding Clojure) are better off using something like Emacs.

> Org mode

The fact that my editor doesn't have this is a feature for me. I want something with a clickable GUI that syncs to my phone, gives me reminders, and can be shared with coworkers when necessary.

I've recently been using ClickUp, and it's been fantastic. I can run it in a window next to my editor. I'm not sure what the setup is missing that Org mode doesn't deliver, but I do know that Org mode is missing a lot that ClickUp gives me.

> The fact that my editor doesn't have this is a feature for me. I want something with a clickable GUI that syncs to my phone, gives me reminders, and can be shared with coworkers when necessary.

Check out Orgzly from F-droid repos.

OK, I checked it out. I'm still not seeing reminders integrated with the notifications on my phone, nor am I seeing anything that the people on my marketing team would touch with a 10-ft pole.

There are lots of tools I'd use if I weren't programming for work and didn't have a team of mixed technical skills, and perhaps Emacs fits into that category.

> what can you do with magit that you can't do with those?

It's not the "what", it's the "how". Magit enables extremely fancy workflows with great simplicity, and its UI is self-discoverable and well laid-out. Magit has the best UX of any git tool.

> its UI is self-discoverable and well laid-out. Magit has the best UX of any git tool.

Which others have you tried?

The way you described Magit is exactly how I would describe SmartGit and also the built-in git features of several IDEs, including the Jetbrains family and Visual Studio (although I dislike Visual Studio because it's slow).

The main ones I've used for some time are the git CLI (which should be counted as a git toolset too), Sourcetree, the GUI inside IntelliJ, and Magit. I currently use Magit + the git CLI for some quick commands.

For me, Magit code staging is the best I've tried: staging whole files is as easy as staging single lines, which means my commits are more meaningful. Magit also allows me to use some fancy features without having to remember they exist, thanks to the well-thought command popups. Last, it's integrated with Emacs: this means I can move through code and write my commit messages in a familiar, coherent way.

The final advantage for me is that Emacs and Magit are forever. They will live longer than any other tool out there.