Whenever there's an Emacs thread on HN, I want to post the following quote from Neal Stephenson's "In the beginning was the command line":
"It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer--i.e., if someone else is getting paid to worry about how your words are formatted and printed--emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish."
> emacs outshines all other editing software in approximately the same way that the noonday sun does the stars
What makes Emacs genuinely great? Not that it was built a long time ago and withstood the test of time. Not the fact that it is absolutely free to use, distribute and extend. Not that it doesn't have tons of bugs (it does), or has superb support for every known programming language (it does not).
To understand what makes Emacs so awesome, to learn and master it, one simply needs to embrace the single fundamental truth about it. Emacs based on Lisp. And please don't make a mistake - I am not talking here about a programming language. I am talking about an idea - one of the most magnificent ideas in computer science. Embrace the awesomeness of that idea, the fluidity, and malleability of the structure. Accept it with all its incredible power and some unavoidable flaws - and you will gain superpowers. Which is not necessarily a good thing. Let me explain.
There's a scientific term "umwelt" that biologists use to describe the world as experienced by a particular organism. Every one of us has this "umwelt" - our "subjective view of the world." Our umwelt is limited by our physical and mental capabilities, past experiences, and social circles we grow up and live. e.g., your subjective understanding of Renaissance Art would drastically differ from when you're taken to a museum at the age of three, and when you go there as an adult, or after studying art for fifteen years.
Learning and understanding Lisp expands your umwelt. You will start seeing things differently. It doesn't inevitably make you a better programmer; it might, but doesn't guarantee it, just like suddenly gaining the ability to see things in the infrared spectrum not guaranteed to make your life better.
Finally, once you embrace the idea of Lisp, soon enough, you find out - humans have yet to invent a better Lisp environment than Emacs.
And that's what Emacs is - it is not just an editor, it is not a mere IDE. Most importantly, it is a Lisp environment - living, "breathing", dynamic and malleable. That's what makes it so extensible. And that's what makes it so versatile. And that's why it will never die.
If you are a programmer, you are using [a subset of] Lisp already. Every single programming language that in use today was influenced by Lisp. Sadly, most of them dropped the main and arguably the most powerful feature of Lisp - homoiconicity.
Thank you for introducing me to the term "umwelt". Over the past few years I've come to believe there's no such thing as objective reality at all—that it just feels that way when enough subjective viewers agree about what is true—and it's amazing to have a word for this for the first time.
I was including the whole academic background around this usage that I can use as a conversation springboard, but thanks for teaching me a second thing today :)
I have a suspicion, which I have never verified, that the things that make emacs great are basically the things that made Lisp Machines great back when those were a thing - that emacs is best viewed as a Lisp Machine embedded in a modern operating system.
I never used a real Lisp Machine, but I'd love if someone who did can confirm this.
EXWM or StumpWM+Emacs, since the window managing bits are pretty small compared to other tasks (manipulating text of various sorts) that one would use Emacs for.
Lisp machines were indeed a whole other level. Everything integrated with everything. We're getting closer though with emacs in stumpwm and eaf. There's plenty of room for scope in extending stumpwm.
GNU Emacs is just an example of extensible Lisp software running on top of an operating system. Lisp software, which sometimes provide integrated IDE features. Other examples: Autocad and some other CAD systems, OpusModus ( https://opusmodus.com ), ... There are also other Emacs variants with a similar idea. The original Emacs variants which introduced the idea of a Lisp written extensible Editor were EINE/ZWEI on the Lisp Machine (written in Lisp Machine Lisp) and Multics Emacs (written in Maclisp for the Multics OS). There were and are a multitude of Lisp systems with integrated editor / IDE written in itself - the most elaborate examples are the commercial Lisp IDEs coming with Allegro CL and LispWorks.
GNU Emacs provides an application programming environment based on an editor-like paradigm (windows, text buffers, programmable modes, ...) and integration of external tools. This toolkit has then been used to implement its own IDE.
Most people haven't seen extensible Lisp-based software. For another example look at Smalltalk-based software, which also comes with its integrated development environment - which is largely written in Smalltalk itself.
Actual "Lisp Machines" differ from GNU Emacs in many ways: They were actually real computers: real hardware - sometimes even specialized hardware like the 36bit / 40bit tagged memory of Symbolics Lisp Machines - the machine used specialized memory cards for that. These systems had a Lisp Operating System covering all layers of the operating system and its applications. They provided an editor (often a variant of Emacs) as one application, but the user interface was mostly not based on text buffers in windows with modes. Historically most Lisp Machine software was written in rich Lisp dialects, often making heavy use of OOP.
There are a bunch of ways GNU Emacs talks to the surrounding operating system: direct calls to the OS, running external programs, connecting to external applications over the network via some protocol (an example would be the SLIME IDE for Common Lisp, which connects GNU Emacs to an external Lisp via a network connection), ... Some GNU Emacs applications can be largely implemented with internal functionality and occasional calls to the OS or other applications.
On a Lisp Machine (the ones which existed so far) everything runs inside a shared memory heap where most stuff is implemented in Lisp: process scheduler, network stacks, disk drivers, file system, printer drivers, graphics, user interface, other programming language compilers, ...
Summary: GNU Emacs shares a bunch of features with other extensible Lisp software, including the software side of Lisp Machines. GNU Emacs does not work or looks like actual historical Lisp Machine systems (MIT Lisp OS, Symbolics Genera, LMI / TI Lisp OS, Xerox Interlisp-D / Medley, ...) .
I once wrote a long comment on Hacker News about how I wasted 2 years on trying to learn emacs. I wish I could go back and stop anyone from ever reading it in case I put someone off from trying it.
I was in a weird place at the time and scapegoated emacs for my lack of productivity. Don't get me wrong it is possible to spend a lot of time fiddling with your config files for emacs.
I picked emacs up again after I quit my last job (quitting made me almost immediately a happier person). I decided to only use packages that would help me to write code, and EVIL mode. So lsp-mode (and the associated lsp-servers), flycheck for syntax highlighting, DAP for debugging & breakpointing code, magit for git and Projectile for project management.
I read the documentation thoroughly for each plugin to actually see what it was doing, and many times jumped directly into the source code of the plugin to see how it was moving under the hood. I started using org-mode to document my journey into each plugin and grew really fond of the ability to collapse points under headers and freely move the headers about in the file with a few keystrokes.
I loved that I could create my own IDE using emacs-lisp. I have a completely minimal interface with just the mode-line and the pane of text. No gaudy menus, no enormous always present side panel, no top bar. Just me and the text. When I start the program it loads an empty window. There are no distractions in emacs, and no incentive to ever add them. And if Stallman ever decided to sell out, I have a fork of the code at its current version which I could use forever.
I jump between backend and front end code in emacs and due to the hooks and mode setup, it always knows the right things to turn on to make it easier to work on that specific chunk of text.
Emacs is an alien technology. It has so much power I didn't know what to do with it at the start and that scared me. I dedicated a bit of my life to it, and now I am confident knowing that if I pick up a new language in the future I will be writing it in emacs.
I wish someone did a thorough comparison of emacs with the newer extensible editors, such as Sublime. Is there something substantial that Sublime users are missing?
I'll give two examples to showcase features other editors are missing - ownership over the editor, and the extent to which you can build on top of existing primitives.
1. Can you change where the command palette shows up in Sublime? In emacs (M-x is our Command Palette) I can not show it, I can show it as a full width pane that takes up 50% of the screen, or I could recreate the Sublime Text look and feel (top of the screen X width, Y height). This looks like a toy example but I'm trying to show that there is not a single part of emacs I don't have control over.
2. Okay how would you do the following in sublime;
Your company is getting into credit checking. As such you now are beholden to certain rules and regulations around the safety of your code, and now your product owners want an update every time CreditCheck.java is modified by someone. They want to be notified in a Slack channel and also by email. They don't care if the top 30 lines are changed, but anything after that is important.
In emacs, I would make a hook for CreditCheck.java that any time I saved the file, it would run through the changes, check if there is a diff from line 31 onwards, and if so send a slack notification and send-mail the diff to the product owners.
I would just open my settings.org file and add the emacs-lisp to do this and I wouldn't even need to restart to avail of it - I could just load-file and have it working. All within emacs. You could do this via a tangle of shell commands sure - but emacs lets you do it emacs-lisp with ease.
Programming in the real world is full of stupid like processes like this, and emacs makes it easy to accommodate them. (Not saying that you should accommodate them, but the real world can be messy)
I think that most companies would not find it adequate for the compliance regulations to be implemented "client-side". Mine would certainly answer your question: "how would you do the following in Sublime" with: "not at all", or: "please don't".
As for your former point of configurability; all power to you; I think that there is a spectrum where many folks choose to be more on the end of the spectrum where there is paved roads of using an editor that looks a certain way through the consensus of its users. Instead of picking between a super-configurable editor and one that isn't, I think many users choose between two less so configurable editors (I imagine IntelliJ and VS Code are good examples) for the one that just suits them better than the other.
You are missing the forest for the trees here - and I imagine that's by choice.
I'm not saying emacs shines as an audit trail - I am saying the processes by which you work can be incorporated within emacs very easily, in a way that is unmatched.
I can see why people tend to ignore questions around specificity of why they like emacs - the goalposts never stop moving.
> You are missing the forest for the trees here - and I imagine that's by choice.
To flip this around, I'd say you're fascinated by the forest when someone else just needs a tree.
I understand the excitement and the freedom you're describing. What I think you're missing is that if others don't see a need for what you're describing it not only doesn't sound useful but sounds like the tool is definitely not aimed at them. This is not them being deliberately obstinate.
In the classic spirit of tortuous car analogies for technology - there is a benefit in having a car you are able to maintain yourself. But when asked why this car and not another if the examples all sound like "You could add six steering wheels and put a tyre on top and have the horn play jingle bells only on christmas if you wanted!" then it immediately puts people off.
Sorry but I entirely disagree with you here given the context - I am answering the question "Is there something substantial that Sublime users are missing?".
What I described is a substantial benefit of using emacs over sublime text.
If you are a programmer there are many benefits to total control over a system, and the ability to compose new functionality from a solid foundation of base functions. Now, you could happily use emacs forever without ever using that control, but the difference is with something like Sublime control you don't even have the freedom to make the choice as to whether you want to or not. It's out of your control, which is a downside when compared to emacs.
The OP wasn't asking why would anyone want control they were asking what are the benefits of emacs in comparison to sublime.
> What I described is a substantial benefit of using emacs over sublime text.
I think you're _assuming_ "more control" is a substantial benefit for them.
> The OP wasn't asking why would anyone want control they were asking what are the benefits of emacs in comparison to sublime.
Right, but if you don't see a strong use case for that control it isn't a benefit. The examples you gave were of changing the UI in a way I am not interested and a way of triggering emails and slack messages when I save a file which would be actively harmful.
Giving me the ability to do something I do not want to do is not beneficial. It's like telling me a car is better because it's so modifiable I can install a Margaritaville. That would be a bad change to me so it's not selling me on the benefit of this car.
> Giving me the ability to do something I do not want to do is not beneficial.
Expecting that an example should be tailor-made is not very beneficial, either. When I go out to buy a car, and the salesman tells me the trunk is big enough to fit a grown pig, this information is of use to me. Not because I smuggle livestock, but because this gives me a good idea of what the capacity is.
I'm not expecting a tailor made example, but as you say one that I can compare to my own situation.
Obvious things would be like vims make command - I'm not going to turn around and say a webpack example isn't relevant because I'm a python guy as I can see a direct parallel. But lots of this is standard and in major ides, or well written and tested plugins are available.
Saying I can send emails on a file save is not that useful as I can't see any reason I'd want to do that. I'd definitely not want to throw together a regulatory setup - that should not be something solved there (margharitaville comparison).
Broadly - it's not necessarily that the rest of us are missing some incredible wonderous world because we're too blind to see. It may simply be that the freedoms afforded are of little value to us.
Edit - I think I've got it sorted in my head why I don't care as much about this.
My problems are typically shared by lots of other people, and so solutions that suit me are readily available. I don't enjoy building my tools as much as I enjoy solving other problems with them.
It's the same reason I got rid of my mythtv setup and just bought something that worked to play videos. It was less flexible but did what I actually wanted better than my own setup and didn't require me to build and maintain it.
But just because I CAN do something in emacs that I would make a systemd service for now, isn't a good argument for WHY I should use it. Is it easier to add that functionality? Faster? Is it because you get some benefit from everything being in one program? What benefits does it offer?
I don't need my text editor to send email, monitor file changes, be an IRC client, and make me toast. Or do I? What difference does it make what programs do those things, as long as they work well and I can extend the functionality as needed?
You don't, there's an MTA for that, but for composing mail, filtering mailbox, searching and other text-related tasks Emacs has much superior interface.
> be an IRC client
Messaging consists mostly of text editing, especially in IRC, which doesn't have fancy stuff like stickers, GIFs, videos.
> What difference does it make what programs do those things, as long as they work well and I can extend the functionality as needed?
A consistent, self-documenting, extendable interface.
Why do you imagine it's by choice? It was requested that someone come up with an example of what you can do in Emacs that you can't do in Sublime and the examples given were unrealistic. Do you have a more realistic scenario where Emacs could do something Sublime, or VS Code, or Atom could not?
> I think that most companies would not find it adequate for the compliance regulations to be implemented "client-side". Mine would certainly answer your question: "how would you do the following in Sublime" with: "not at all", or: "please don't".
Yep, exactly. The most natural solution to this problem is some kind of git hook on the git server. Nobody cares about the changes I make locally before I push them to a branch.
Okay, so we need to make sure that anyone that could ever potentially edit this file has this exact same configuration setup and is using emacs?
That's dumb and flaky. You sound like one of those guys that spends thousands of hours customizing/tweaking things instead of just accomplishing tasks.
You could imagine that it's a rule in the company where GP works that programmers have to notify the boss when they change CreditChecking.java. GP's colleagues who are not using emacs would have to do it manually, while GP would do it automatically.
I never understood what people mean by the joke "emacs is a great operating system, all it needs is a decent text editor" but after reading your post I'm starting to.
If you're not on desktop Linux, and you don't have years of experience using emacs, I'm not sure there's a great reason to switch to it from Sublime (or any other extensible editor) just on the merits.
I tried emacs many, many times over the years, and always ended up going back to something more modern because I liked them better -- BBEdit, TextMate, Sublime, etc.
(I'm leaving aside the FOSS arguments here, which are reasonable and fair; I just mean workflow/feature reasons.)
All that said, I did end up converting to emacs eventually, about 5 years ago. Why?
OrgMode.
I couldn't find anything else that did what I really wanted in terms of note-taking and to-do tracking, and what I wanted seemed to me to be pretty simple: I wanted to be able to write in plain text, keep notes in multiple files, use outlining, and have some kind elaborate searching tool that would filter through them and show me the lines I'd marked as to-do.
Interleaving the notes with the todos was mandatory for me -- I need context.
Obviously, I could write something simple to do this, but OrgMode is built around this idea from the getgo and works BEAUTIFULLY.
And to the best of my knowledge no such equivalent exists for Sublime, or any other extensible editor.
Today I needed to be able to insert the current date in emacs and I found the lisp code to do so online, hacked it to give the output I liked and then added it to emacs - the program I used to edit the code with? The same running version of emacs that I loaded and tested the code with.
I am always looking for a better editing experience, who knows what I might be missing.
Yet, after visiting Goyo's github, reading the README, looking about, I still have zero idea what this plugin does.
How/what is made distraction free, by this plugin? How is vim distracting prior to its use?
A shout out to all, in a thread where the word umwelt is used... actually explain to others, what your code is actually for.
Not just some marketish, slogany statement such as "Distraction-free writing in Vim".
(Some might say, hey.. just look at the code. Naw. I have better things to do, than delve that far into a whim. I don't have the time. Literally, not to spend on all the quick looks I might take as such links. Say what your stuff is, people. Don't make it a mystery...)
Make the terminal full screen then run Goyo for a distraction free experience. It adds margins on right and left like in Word to center the text, except in vim there isn't a toolbar on top or gray space on the sides.
If you use eww in Emacs, the readability of that post would be exactly as you wanted it to be, given that you've spent enough time configuring and tweaking your Emacs theme. Emacs (in general) is not for everyone - but it can be that perfect tool, that is truly perfect just for you.
Honestly at this point it is usually easier for me to read the raw org-mode source file in an emacs buffer than to wade through whatever random web rendering and author has picked when they export to html.
It'd be hard to argue that it ISN'T "readable." Maybe some would think it's ugly (I don't), but objectively speaking it's ticking every "readability" box.
On mobile it's very difficult to read because the font is too small and line width is too long, so I have to choose between squinting or scrolling back and forth and back and forth and.. (or use Firefox's reader mode). I don't mind plain text, but this site is several orders of magnitude harder to read than http://motherfuckingwebsite.com
I do most of my HN browsing in the app [Materialistic], so I usually first look at articles using the built-in webview, then open externally in Firefox if that doesn't render correctly (which is unfortunately common. Not sure why, but I'm inclined to blame either the app or webview; for example, Wikipedia is served as a static site but renders as a blank page). In this case, they both rendered the same way (but was able to read the page with FF's reader mode).
Legible might be a better word? The giant, viewport spanning, line-width mixed with dense line-height makes it harder on eye for some people, myself included.
The point is that there is no margins. On my screen the lines are 275 characters long! This is 2-4x more standard formats. You don't need to break the lines up, you need to wrap them sooner with styling.
There must be an package where you can give url and emacs will display the article in org-mode format. Even better would be a package for reading hacker-news, surely there must be one.
EDIT:
In fact there is a package called hackernews. You can open links inside emacs using text-based browser. No readability issues there.
I use text files to organise myself but I use notepad++ to edit them.
I have tried to learn emacs a couple of times but I am really unmotivated - don't see any case where it would help me. I am afraid I'm missing something.
An anecdote on what you might be missing. There is nothing concrete that not using org-mode would cause you to miss out on, it is rather the possibility of being able to access one of countless workflows that have been built on top of it.
When I started to use org-mode it was because I needed to generate a gant chart and I wanted a text format. I haven't used that functionality every again. Since then I have used org-mode for a variety of things, but never all at once, always a little piece at a time. Typeset a thesis in latex? Execute analysis code in a reproducible way? Write DRY bash scripts and tangle (compile) them? Run and log the output of one-off commands on remote servers so that if you ever have to do it again you have a record of it? The list goes on and on.
Last week I was told that I needed to start keeping track of the time I spend working on different tasks. Despite keeping todo lists I have never used the org clocking functions, ye there they were there, just a C-c C-x C-i and C-c C-x C-o away. Integrated into my workflow when I needed it with all of 30 seconds of effort and two key combinations of overhead.
Emacs is useful because countless others have encountered problems the likes of which a single person only rarely dreams. Not only that but they have probably already implemented a solution that is fairly easy to find once you encounter the problem and in 80% of the cases can be used unmodified.
Yes, you and all the rest of us are missing something. It is impossible NOT to miss something and no tool can solve that for you. The question to me is whether you want to spend your time learning a tool and integrating with an ecosystem where you never have the possibility of benefiting from the things that others did not miss.
I needed to hear that; articles like this give me FOMO for emacs and lisp and the like, but the learning curve intimidates me. It wouldn't be the first task tracking application I'd be trying.
Right now I use intellij for my main development work; I use some keyboard combinations where applicable (and changed the keymap to Sublime Text because I've used it and its derivatives (vs code mainly) for the better part of my career.
I don't have a dedicated flow for task tracking. Right now for work we use Phabricator, it's a bit awkward because it's a heap of independent modules built on top of each other, but it met our requirements (free, open source, self-hosted, not shit).
For a while I used a todo.txt addon in Sublime Text, which worked great; haven't been able to find a good alternative to it.
Used Wunderlist for a while, but I couldn't find my finished tasks without paying and it's been discontinued. Same with Todoist, minus the discontinued-ness.
Anyway, I don't think keyboard-based tools for me; I'm pretty good at typing if I do say so myself (~120wpm according to online tests / typeracer and co), but I haven't developed the mental capacity to remember all the keyboard shortcuts for emacs or vim.
I also didn't grow up with *nix systems, commandline only became a thing once I started my education and career ~15 years ago.
> articles like this give me FOMO for emacs and lisp and the like, but the learning curve intimidates me
Lisp is great and you should learn it. (If you want.)
You don't need emacs for that - just find a scheme interpreter in a web browser [0] and start reading SICP [1] until you get bored. That's all the effort you need to get the mind-expanding effect. This approach is also way more fun.
If you really like it, move on to a "real" Lisp.
> Anyway, I don't think keyboard-based tools for me
Honestly, me neither.
At least, not the way they were when I used emacs as my "daily driver." Why? Because the MacBook trackpads are so precise and fast that "using the mouse" is no longer an impediment.
If you ever try to use a pre-2000 mouse and operating system with their horrible (compared to now) tracking and accuracy, the claim that mice slowed a developer down makes total sense. Nowadays? Not so much.
But you to have to know where to click. And that's the biggest problem with so-called "modern" UIs - it lacks discoverability. Either you memorize all menus and dialogs, or you have to seek out the functionality you need each time you can't remember anything. And sometimes these dialogs change, so you have to rediscover everything once again.
In Emacs, it's enough only to remember basic movement shortcuts. The rest of commands could be discovered easily with M-x and which-keys.
> You don't need emacs for that - just find a scheme interpreter in a web browser [0] and start reading SICP [1] until you get bored. That's all the effort you need to get the mind-expanding effect.
One of the main reasons I moved to Emacs (11 years ago) was Common Lisp and SLIME.
> If you really like it, move on to a "real" Lisp.
> In Emacs, it's enough only to remember basic movement shortcuts. The rest of commands could be discovered easily with M-x and which-keys.
afaik every modern IDE has this discoverability functionality. I use shift-shift and control-control autocomplete command menus all the time in JetBrains.
> but I haven't developed the mental capacity to remember all the keyboard shortcuts for emacs or vim.
In Emacs - you don't have, there are a lot of packages which make the discoverability a breeze - counsel-M-x, helm-M-x for exploring all commands with corresponding shortcuts and also which-key, which allows you to automatically pop up the "next steps" in your current state.
How about having a mental capacity to remember all menus/dialog boxes in your IDE?
> > I am afraid I'm missing something.
> You are not
You are missing an entire world treated as text and a consistent and an endlessly configurable interface for everything you can pull into your emacs Borg.
Yes, but you don't like, need that to be, I dunno, a complete programmer or person. Which is how the "cult" (tongue-in-cheek) treats it, and why this person has FOMO.
There are tons of examples of programming wizards and productivity gurus who don't use emacs. And you'll encounter lots of people who can't get shit done but who fiddle endlessly with emacs or vi or whatever configs and believe they have some super efficient direct connection from their brain to their computer.
Some of the best, most productive programmers I know use notepad, and some of the worst use emacs. ymmv.
> Yes, but you don't like, need that to be, I dunno, a complete programmer or person.
Yeah? I'm not sure how meaningful this argument is here since you can just get by with nano and a terminal.
> Which is how the "cult" (tongue-in-cheek) treats it, and why this person has FOMO.
I frequent the places that the "cultists" would most likely be and the prevailing theme is "if your workflow works, keep it, but emacs could do X for you".
> There are tons of examples of programming wizards and productivity gurus who don't use emacs.
Yeah, but that doesn't mean Emacs wouldn't make them less or more productive.
I don't think I've seen the "you need emacs" strawman your arguing against in practice.
> And you'll encounter lots of people who can't get shit done but who fiddle endlessly with emacs or vi or whatever configs and believe they have some super efficient direct connection from their brain to their computer.
Would those people be more or less productive without emacs? I find answering questions like this for myself difficult, I can't imagine trying to decide others would be better off not using an editor.
Isn't saying lots of people exist that would be more productive without the kind of presumption that annoyed you from the Emacs cult?
> Some of the best, most productive programmers I know use notepad, and some of the worst use emacs. ymmv.
Right, which is why I commented what the other user was missing and not "you need this".
Emacs is an enormous investment but every time I'm forced to use another editor or IDE I'm reminded how much it pays off. Fundamentally, all Emacs does is treat the whole world as text. Everything from that point forward is about giving you (or allowing you to build) tools to manipulate text in a way that is natural and powerful for you.
This doesn't sound particularly earth-shaking, but it really is. Think of a language like Ruby or especially Clojure, where there are a few core data structures, but many things that leverage them. This means that every time you learn part of the Ruby Array API, or a useful function to work on Clojure sequences, you get to use that _everywhere_. So all of Emacs' basic interactions (and they may seem weird to begin with but they're honestly just trying to save your wrists some pain) work everywhere. You can always trust your intuitive, spatial model of the thing you're looking at. Search backwards in a text file, find some text, select it, copy it, go back to the end and paste it. That works exactly the same in a shell. It works exactly the same in a database client. Or SSH'd into a server. Or replying to an email. Same gestures when entering commands, same gestures moving around in autocomplete popups.
Everything you learn with Emacs (and later, everything you write with elisp), has a little incremental benefit to your power and productivity manipulating text. Except everything is text, and so it all multiplies together.
For whatever reason, I've been trying VSCode on Windows the last couple of weeks, coming from an Emacs on Linux background. I cannot tell you how painful I find it, even after making a pretty good attempt to map all the keys correctly (snarky sidebar, sorry: every editor and IDE has really good Vim key bindings, but terrible Emacs support. I used to feel bad about this until I realised it was a sign that Vim people clearly didn't use Vim that much, whereas Emacs people never leave Emacs). But VSCode begins at a completely different level of abstraction to Emacs. It doesn't want to show you a text-based UI everywhere, and implement tools to manipulate text. It wants to show you windows and panels and configuration screens and extensions with their own behaviour. Everything is modal and different, some windows are special, and you can't just navigate around the same way everywhere.
So, sure, this isn't for everyone, but it's what I love about Emacs, to the point that the many regular indignities it forces on you (hangs if you're not careful about large files, abysmal performance of various things on Windows because of the overhead of starting processes, and sure, the learning curve for some people) are bearable because everything is so natural.
> snarky sidebar, sorry: every editor and IDE has really good Vim key bindings, but terrible Emacs support. I used to feel bad about this until I realised it was a sign that Vim people clearly didn't use Vim that much, whereas Emacs people never leave Emacs
[vim user] Usually I don't get baited by the holy war, but this one got me good, well played.
I don't use other editors much, but my experience with them has been that they usually do have good basic vim keybindings, but only for the default keys, and never with support for configuration; I have k-j and j-k mapped to esc, so I don't have to take my hands off the home row to leave insert/visual mode, and not being able to do that is terrible. So I don't use vim keybindings even if they are available -- it's more frustrating to put my brain in "vim mode" and then have some things missing, than to just use the default settings.
Also, it's always been weird to me how it's emacs vs vim. Vim is a text editor; emacs is an IDE and an operating system. When I'm working I'm constantly ctrl-z-ing out of vim to use other tools.
Emacs is suffering from the same problem Perl is suffering offlate. Emacs was invented for a world where Text was everything. These days programming languages are designed around tooling. This is very much true for languages like Java, Python, Go. The programming tool needs to have a lot of sane builtin defaults and extensions.
The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does. This is also true in part for vim. The whole idea of one having to press less buttons to move text around is really a solution for a problem that doesn't exist in the modern world.
Emacs is still very good in things like Keyboard macros, and M-x Occur etc. Basically text manipulation stuff. The thing is that kind of text manipulation work isn't common anymore.
Having said that, I'd be very happy if there was a good default keyboard macro system in vscode. Or in general some emacs features ported to vscode would be really neat. Some features in emacs would make great feature ideas in vscode.
> Emacs was invented for a world where Text was everything.
Text is still a large part of computing.
> These days programming languages are designed around tooling.
Every time I see a language which requires a lot of tooling to use it comfortably, usually it's bad designed one
> The whole idea of one having to press less buttons to move text around is really a solution for a problem that doesn't exist in the modern world.
I think the idea is not about having to press fewer buttons, but to bother your brain with unnecessary things as little as possible. With Emacs, you don't have to remember "where the hell is this command and what is the shortcut for it?", you type M-x (especially if you use plugins like counsel or helm) type some related words and that's it. You don't have to know how every function works - M-x decribe-function at your service! Not enough? You can always jump to definition and take a look at it.
> The thing is that kind of text manipulation work isn't common anymore.
You still write programs in text, the commands you give to computer ARE text too, even "modern" menus are nothing but text.
> The thing is that kind of text manipulation work isn't common anymore.
Emacs has LSP plugins, if that's what you are talking about
> Or in general some emacs features ported to vscode would be really neat.
> Emacs was invented for a world where Text was everything.
Given that you're still on a computer, what do you think isn't representable as text in one way or other? You can drag and drop images from a browser into Emacs[1], and it will download the image to a sensible (and configurable) location, add a link to the file and display it inline.
> The other problem is speed of typing is irrelevant
Yes, but having an interface which is reasonable and configurable is important for managing cognitive load, and Emacs excels here.
Doing less work is pretty much the programmer creed. But that statement has several dimensions. Including having to do less configuration and tweaking work.
I think a modern lisp based editor, with concurrency/threading built in. With Racket/Clojure/CL backend with modern controls builtin would be all we need.
You still keep the emacs spirit, but with modern outlook.
> I think a modern lisp based editor, with concurrency/threading built in. With Racket/Clojure/CL backend with modern controls builtin would be all we need.
Sure, but it's the same as the "replace (La)TeX" problem: part of the value of the ecosystem is the huge collection of packages/extensions.
But if there was a reasonable way of porting packages over to a CL/Scheme new editor base, I agree that would be good.
> Including having to do less configuration and tweaking work.
Sure, but a bad, unconfigurable tool is more work.
> Emacs was invented for a world where Text was everything.
Text still is mostly everything for all of my backend programming, note taking, etc.
> The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does.
Typing speed is far from the most important part. It's the consistent interface for everything, reduction of cognitive load, and everything being available at your fingertips in emacs.
> snarky sidebar, sorry: every editor and IDE has really good Vim key bindings, but terrible Emacs support. I used to feel bad about this until I realised it was a sign that Vim people clearly didn't use Vim that much, whereas Emacs people never leave Emacs
How could you emulate emacs? Just the keybinds would miss the point.
Is there a way to run Emacs on MacOS with an updated interface? Running Emacs in the terminal limits the functionality, but the GUI versions I've tried are garish-looking to me.
By garish-looking do you mean with the default white background and awful looking buttons?
I installed the Doom Emacs configuration and it looks really great and modern on macOS. I think you'd like it! Definitely worth a quick install to see what is possible - you can always go and make your own configuration based on that if you want
I used a few packages to get me there (though some of it can be done through configuration, it was just easier that way). The relevant bits in my config are:
On a similar note, I have found on Linux that just switching to a virtual terminal and running Emacs in text mode is an absolutely wonderful way of achieving deep focus without distractions. Obviously not much use if you need a web browser on your second monitor though.
But I don't work with text. I work with semantically meaningful code.
I don't need better manipulation of meaningless context-free lexicographical symbols. I need better manipulation of context-specific, meaningful, rich objects. I spend very little time on the former, and almost all of my programming time on the latter.
emacs used to treat the whole world as text. now it treats .jpg files as images, and based on the extension, not the magic numbers. it's mildly infuriating.
I only really use emacs for Org mode and Org mode extensions. It wasn't too hard to learn just enough emacs for that. The motivation comes from how fast and convenient org mode is as a journal and a static site generator, compared to other tools, and having all my documents in plain text for future proofing.
yes, exactly. i don't even pretend to know a shard of what's available in emacs. i think of it like being able to afford a full-size, professional mechanic's toolbox: you won't have a clue what half of those tools do, but if you run into some weird problem, you can figure out the tool and solve the problem without buying something else.
Don't worry about it too much. If your workflow works for you, go nuts with it.
But should you one day find yourself needing an informational omnitool that can be adapted to the task at hand while you work with it, you will find that there is simply no substitute for Emacs. And that's the difference between an extensible text editor and Emacs. A few lines of Emacs Lisp and some Unix plumbing can get you very far -- and you can debug it in production, dynamically updating the Lisp code as you use it.
One thing I like more about Vim is that its ideal for quick edits in the command line. I don't my whole Emacs init for that. Maintaining two sets of configurations on Emacs is not as simple as it should be.
Try configuring your environment so you run constantly within your Emacs, and use tramp to get to those quick edits. I do reach for vim when I'm on like an airgapped or DMZ'd system, so I totally know what you are saying. Tramping out to nearly all my servers has let me retain for longer the threads of flow established within my Emacs session.
Lately, I've been experimenting with CRIU preserving my tmux'd Emacs session state. So unless an OS update hits libraries my Emacs session needs to reload, I should be able to maintain a better relocatable resumable state than even the Emacs desktop alone could.
This says nothing about the matter at hand. The concept of category is useful, regardless of its impreciseness.
And some categorizations are better than others.
> Nothing’s in the same category when you look deep enough into them.
That’s also patently false: many things belong to the same category. Everything that exists belongs to the existent category, for example.
I say this as an avid emacs user: Emacs has a real problem in that it's very powerful but the, let's say, spiritual leader of the project (Stallman) is so wildly divorced from the real world because of his personal choices that he really has no idea what makes a compelling UX vs what makes a complete mess of arcane incantations. On top of that, the documentation is only suitable as a reference for someone who already knows emacs, so it's hard to learn.
To wit: Again I really really like Emacs as a piece of software, and I've been using it for like 10 years now. Maybe 3 or 4 of those years I've been using it reasonably seriously and even I find my eyes glaze over because of how dense and unapproachable the documentation is.
On top of that, being a political project, Stallman actively resists certain improvements to Emacs that would for example make it work better on my Mac, because my Mac is nonfree and Stallman would rather have an objectively poorer piece of software than one that "encourages" using MacOS.
And of course the other senior people in the Emacs project don't want to go against Stallman, so emacs is doomed to being a mediocre niche text editor with unrealized potential to become a household name.
If someone wrote an open source clone of Emacs that adopted some sane defaults, modern UI conventions, and dropped all the political BS it could be so much better.
Alas I don't have the skill nor the time to attempt such a thing.
Edit: hey how about a substantive reply rather than drive-by downvotes?
I'm genuinely puzzled about why posters like this want to make Emacs into some kind of household name if only it would do some random thing that they want.
I'm a die-hard Emacs fan, but it's a tool. It works well -- really well for a lot of us. For the rest, honestly, I don't care very much about evangelizing Emacs because I have a lot left to explore about using it first. There is 20- and 30- year old elisp out there that still runs perfectly well on a modern Emacs and probably solves some of your problems. Rendering a crop of the latest fly-by-night emoji is honestly the least of my concerns (with reference to the MacOS thing), although I personally disagree strongly with Stallman's stance in that matter.
I agree about the docs being dense and somewhat unapproachable, a lot could be done towards making elisp easier to approach. I think a big problem here is the unapproachability of any Lisp (not just Emacs Lisp) as a scripting and configuration language. In fact, I wonder if (Clojure being the first), elisp is the second most popular scripted Lisp in existence.
> Rendering a crop of the latest fly-by-night emoji is honestly the least of my concerns (with reference to the MacOS thing), although I personally disagree strongly with Stallman's stance in that matter.
Of course you do. This policy doesn't benefit you in the slightest, and since you are a macOS user already, all of your experience is telling you that this policy doesn't work.
But this particular policy is logical, and it doesn't really hurt Emacs. And, who knows, perhaps one day some talented/bored macOS developer will become so unhappy with Emacs not showing the latest fashion of emojis, they will go on and implement that support in Free libraries that are used for text rendering on GNU/Linux, and contribute it upstream.
> If someone wrote an open source clone of Emacs that adopted some sane defaults, modern UI conventions, and dropped all the political BS it could be so much better.
Emacs does have sane defaults. Did you mean instead you want defaults that remind you of the defaults in other (younger) programs that people might be more familiar with? That can be useful to gain more users. But it doesn't require an Emacs "clone", just an Emacs package with the settings you want. This approach is actually pretty popular: many people use CUA mode, Evil or even a distribution like Doom or Spacemacs. There's no need to change Emacs just to change a few defaults.
There are also package that address the "modern UI conventions" part of your complaint too to some extent, and again, distributions like Doom and Spacemacs include some of these packages. (Personally I only care if UI is practical and efficient, not if it is modern, but I do understand that some people like modern UIs for their own sake.)
> If someone wrote an open source clone of Emacs that adopted some sane defaults, modern UI conventions, and dropped all the political BS it could be so much better.
Worthy of mention, of course, is Spacemacs[1], which made Emacs approachable to me, someone who hadn't used much beyond Notepad++ and Eclipse before then.
You have to understand that Spacemacs, Doom, ErgoEmacs, Prelude, etc. are not products. They are collections of recipes. And bare-bone Emacs is not a product either. Emacs is a kitchen where you use Lisp to bake your own editor/IDE/frankensteinian toy.
Using Spacemacs or Doom doesn't liberate you from learning Lisp and Emacs internals.
> Using Spacemacs or Doom doesn't liberate you from learning Lisp and Emacs internals.
Yes it does, for me anyways, for the most part. While I definitely plan to dive deeper, I'm using plenty of Emacs stuff via Spacemacs, and I've customized plenty of stuff by copy/pasting incomprehensible elisp snippets.
Sure, but 'using' Spacemacs is still perfectly possible without learning Lisp and Emacs internals. I use magit, orgmode, tramp, and I'm in Emacs for significant chunks of the day. I'd say that doesn't only mean that I'm a proper 'user' of Emacs, but that I'm pretty serious about it!
Of course as a Lisp weenie I do intend to dive into Emacs and honestly part of the reason I don't is that I'm afraid I'll end up spending way too much time diving and tinkering.
I don't disagree. I greatly appreciate Emacs now that I know (5% or less of) it, but I don't think I could have gotten here if Spacemacs hadn't provided sane defaults for packages and keybindings.
That's the makings of great open source software- you have something very lightweight and unopiniated at the core, and distributions can pack all of the features and opinion they want on top of that to target more specific use cases. This allows you to keep the opinion downstream of the core project, so changes by people with different opinions can still find their way upstream.
Linux and Kubernetes are structured the same way- nobody is using that out of box on it's own
And that’s fine, because Emacs is not meant to be an opinionated “app” or product. And that’s exactly what makes it so fantastic, in a landscape filled with crud that’s simple out-of-the-box, and then puts you in a straightjacket forever afterwards.
Been reading Wittgenstein's Tractatus the past few days and your comment reminded me of the beginning (quoting from memory, not exact words) - "this book will perhaps be understand only by those who've already had the thoughts expressed in it or similar thoughts" :)
Emacs kind of gives me that same vibe. I used it for many years to organize my research but still have a hard time remembering key strokes and such .. though i dont have a similar issue with vim whose modal interface I find rather pleasantly compositional. So I get both the sense of power and flexibility, and the chaos of it.
If all you think it needs are sensible defaults, try just bending said defaults.
I'm somewhat curious what choices of Stallman's you think are holding it back. Feels more alive to me than it has ever felt. And that branch that is using gcc to compile elisp is a delight.
I concede I expect there are choices made that could be bad; but I suspect most of the choices people think matter, don't. Which is why i highlight the compiling elisp branch. A complete rewrite would not have had as much of an impact. And, frankly, I feel elisp is easily as good of a language as any proposed choice. Better than most.
It doesn't follow Apple UI guidelines. In 1984 we learned that having one, single, mouse-driven UI paradigm for all programs, handed down to us by our superiors in Cupertino, was an objectively superior mode of interaction with a computer, saving many lives' worth of time and brainpower over the years. Yet somehow, Stallman remains so empathy-deprived as to be stubbornly unenlightened by this knowledge.
I just suspect that people here on HN are coming from the upper portions of the software developer spectrum in terms of experience, aptitude, enthusiasm, and training--there are plenty of other people in the world who do software development but lack some of those things. For my own part, I graduated with a bachelors in computer science having only heard Emacs mentioned once in a course (at the beginning of the second course in the intro sequence) by a particularly enthusiastic professor, and I never heard anyone talking about Vim or Emacs at my first job, where everyone more or less had to work exclusively with Visual Studio and an in-house IDE.
I'd say there is a fair few beginner Linux users who have followed a tutorial on OMGUbuntu or stackexchange who know of VI but will never hear of emacs.
> I'd say there is a fair few beginner Linux users who have followed a tutorial on OMGUbuntu or stackexchange who know of VI but will never hear of emacs.
Ok.
But of those people who stick with vi for more than 6 months, how many of them have yet to hear of emacs at that point? Maybe 5%?
The software developers I asspciate with today in the enterprise world fall in one of two camps:
1) Emacs? What is that? Looks like it came out before I was born. No thank you, I need something modern.
2) Emacs? That's still around?! I remember that from my Vax days...
Either way, few of them would countenance the idea of using Emacs to do professional software development in 2020. The vast, vast majority of developers out there use either a large feature-rich IDE like Visual Studio, IntelliJ, or Eclipse... or they use Visual Studio Code.
my entire MAAS development team at Canonical are emacs users. we also have those who use vi or even visual studio. it's all about what works for you, i guess.
My teachers in highschool knew what Office was and how to use it. I doubt most teachers now have heard the name VS code and don't know why they'd want it.
You are asking others to make something that you want that they don't want and not giving them anything in exchange (money, time, code). Then saying "ALAS" I wont make these changes myself only complain on the internet about them. These vague wondrous changes will make Emacs a "household name".
1) Who cares about being a household name. Vain goals serve no one
2) You didn't specify one actionable change.
You are right if you are comfortable with your editor you're not missing a lot. I tried Emacs for a while it's nice and comfortable the moment your brain get used to the keyboard shortkeys though since it's a different word you start running everything in Emacs and it becomes your OS. Why it can be a problem is another story. Anyway I switched back to use different tools for different jobs. For taking notes and managing them I use Joplin it supports markdown, todo lists, etc. and you can even copy paste images into the editor. Lots of other features as well as sync with different backends.
I have been using zim wiki. Its essentially just a basic text editor but it has a tree view for your files and supports basic syntax including check lists. I have found this suits basically all of my needs.
I have used many popular and some esoteric editors and IDEs (some of them today would be considered forgotten). The last one was IntelliJ that I used very extensively. To the point of finding some undocumented features. I have participated in many conversations regarding plugins. I have almost started building my own. I was pleased with it. JetBrains does make an incredibly powerful IDEs.
After almost seven years of using IntelliJ, I switched to Emacs.
Emacs taught me something about myself that no other editor/IDE done before. It helped me to discover my hidden predilection. I realized that I am a tinkerer. You may say: "Aren't we all? We make software because we are tinkerers..." But there are two kinds of developers: non-conformist tinkerers and consumer-tinkerers.
People who end up using Emacs are those who would choose Gentoo or Arch, first of all, because "fuck Windows" and "Ubuntu is lame", and then because they can do some crazy stuff like hijacking display brightness beyond default limits (because one time they had to stare at it, sitting on a beach). Sometimes they hook up their garage doors to a DB, so they can collect data and analyze it later. Or they build their own mechanical keyboards. Etc.
Emacs taught me to abhor repetition and mundane tasks. It taught me that anything can be automated. Even Hell and Chaos can be automated. In that case, you simply end up having an automated hell and chaos. There are so many tiny examples, like whenever I'm writing something let's say in Python, and I would like to search for a code snippet on GitHub, I would simply select a piece of code in my editor and search for it - Emacs would navigate to GitHub, pass the string and even set the language to Python. Or whenever I need to create a new branch, I don't need to think about the name, I can use the ticket number and Emacs would request the issue tracker and create a branch name based on ticket's title. Or I can create a Gist (public or private) by pressing a couple of keys. And many, many more.
I can watch anyone using their favorite IDE and whenever they do something so trivial, something they've been doing for a long time, and very often I'd think - "Oh, I know, more efficient way of doing the same thing" or "Ah, I've been doing it the same way for years, maybe it's time to improve it. I just realized that this is not efficient enough." But it's not just about efficiency - when you add a tiny bit of automation to your task, it becomes so much less frustrating.
Of course, it is possible to have the same mindset and never get into Emacs. However, Emacs offers hundreds of tiny pieces to satisfy your needs. People say: "Emacs takes a long time to learn", but in reality - it would take you longer to become a true power-tinkerer using any other ecosystem of tools.
But it is also totally okay not to be a power-tinkerer. I know many developers who don't use any fancy ways of doing things, but they are still quite impressively, very productive.
Whenever there's an Emacs thread I feel really bad like an impostor, because I'm using Emacs daily for work and hobby for the past 15 years now and still only use only 5 to 10 functions regularly. Heck, I can't even remember the keyboard combo for getting help about a mode. When I have to install a new package, I use Melpa and copy&paste init code for the .emacs file from the web. If it doesn't work or breaks, I usually just use another package because it's too hard to fix the error. My .emacs file is a total mess and I have no idea what 50% of the code in it is doing. Do I need it or should I comment it out? I don't know.
Two years ago I tried to start using org mode and bought the printed org mode book but it just turned out to be too complicated and too much time to adapt all the publishing settings for me to be of any use.
For a while I used a Bibtex tool which was weird to use, and now I'm using KBibtex again.
I guess what I'm trying to say is that Emacs is a great editor but I wish someone made an AI-powered assistant called "clippy" for it that makes suggestions for commands one might use when working in Emacs. I just can't remember all those keyboard shortcuts for every mode.
I felt the same way for a long time. And then I've started doing one very simple thing. I've created tasks.org file, and whenever I find some use-case, something I don't know how to do or even not sure if that's possible - I would just add an item to that file. Then I would ask questions - on emacs.stackexchange, on r/emacs, in slack channels, in mailing-lists, etc. Slowly, I have started using other Org-mode features. I started writing my own emacs-lisp snippets. Even though I still haven't mastered Emacs, today, I share Emacs tips with my colleagues and other people. If I may suggest - don't try to "boil the ocean." Emacs is huge. Nobody truly masters every aspect of it. Just do it slowly. Start with a simple list.
Look into Spacemacs - it addresses a lot of what you want.
It understands file extensions and automatically downloads curated sets of packages for what you're editing (no more arcane copying and pasting)
The key bindings are set up so that pressing the first part of a key chord brings up all the things the next part of the key chord could be in the mini buffer
Sounds like the package which-key [1] might help you out. (It comes pre-configured for those who use Doom Emacs, but I was using it in my personal config for awhile.). From the about: which-key is a minor mode for Emacs that displays the key bindings following your currently entered incomplete command (a prefix) in a popup.
Yeah, I firmly believe more software should be built on top of emacs to leverage its power and expressiveness behind a dicoverable interface for people who are too busy or have a life.
I think you're confusing "simple" with "easy." You may be looking at the controls of a military helicopter for the first time - switches, knobs, buttons, joysticks, etc. and probably feel very confused. But ask any experienced pilot, "Why can't all that be replaced with a single touch-screen interface? Wouldn't that be so much friendlier and intuitive?" they'd look at you like you're out of your mind. For them, those controls are probably the most efficient interface they can imagine.
There's a strong correlation between things that are confusing for the beginners, but over time become incredibly simple to use and things that are easy to start with, but over time they become cluttered, inefficient and frustrating to use. Emacs and Org-mode are not easy to learn, but they can simplify a lot of things later.
I have burned myself with orgmode exactly because of the deceptive simplicity. It did not pick up some important TODO items because of my slight misformatting.
I'd absolutely buy this if you made it support inline LaTeX fragment rendering (as emacs does[1]). Without it, it's sadly fairly useless for me as a math student. A subset of LaTeX would be sufficient, such as that supplied by KaTeX[2]
FWIW you can set up sync to phone pretty easily, Orgzly is a org-mode client for Mobile working surprisingly well, supporting dropbox and many other backends for sync, plus both Emacs and Orgzly support pasting images. As far as I'm concerned I've set up syncthing to sync my org files between my devices.
For Android, I've found using termux to install Emacs, and then keeping a Bluetooth keyboard in my car has come in useful for impromptu note taking sessions. Or knock out a quick blog post. I keep my org folder source controlled in a private repo in Azure DevOps, which makes syncing between my devices easy enough, and have it set up to continously deploy my blog to an AWS S3 bucket.
> Network: Since I'm set up to send email, IRC, Mattermost, etc., directly from my org-mode tasks, it's easy to track where I am.
I'd like to know more about this because it's something I struggle with while using org-mode. I want to have some sort of bidirectional link between org mode and Github issues for my projects; new issues should arrive in my "inbox" org file, and I'd like a simple way to update the status or commentary around issues from inside org-mode.
Does anyone know of good tools for this sort of thing, or should I take the plunge and really write a lot of elisp?
I'm afraid it's macros and elisp, but don't forget that you can write a good amount of useful elisp by recording macros and saving them in your .init file.
org-sync [0] is all that I could find when I went to look into this last week. It does not have all the functionality that I would want (e.g. comments should be begin_src markdown blocks), but could serve as a start for something more, and it might meet your needs as is.
Unfortunately, org-mode is only a portable format if you stick to bare-bones org-mode; if you start using any of the "power-features" unique to org-mode you're stuck.
And if you restrict yourself to markdown-compatibilty, why not just write in markdown?
- Markdown is not consistent across the platforms that support it. If I wake you up at 3AM would you remember the format of links? is it parentheses first or brackets?
- Extensibility. e.g.: I got tired of manually typing description of links when I insert a link to a GitHub issue, I just wrote a tiny snippet that automatically retrieves the title of that issue.
- Literate programming. For example: I can have a python snippet that when I evaluate, results would be piped it into another snippet in SQL that retrieves data from postgress, and then I can send a http request to a remote API based on what's in DB, and then use that to build a chart. Can you do that in Markdown?
- LaTeX support. I can write some complex math formulas.
- Exporting. I can turn my Org-mode file(s) into a reveal.js presentation, into a book, or a web-blog.
> Literate programming. For example: I can have a python snippet that when I evaluate, results would be piped it into another snippet in SQL that retrieves data from postgress, and then I can send a http request to a remote API based on what's in DB, and then use that to build a chart. Can you do that in Markdown?
I've found you can get pretty close if you combine it with Jupyter notebooks. When you use jupytext [1] or similar to synchronize the markdown and ipynb then it works quite nicely.
Oh and as far as LaTeX / exporting is concerned, just use pandoc, you can export it however you want basically.
Doesn't that require you to jump back and forth between browser and editor? also, does Jupyter support running multiple kernels in the same session? Org-babel allows you to mix and match languages freely.
Well you can edit the markdown in the regular jupyter browser. They haven't embraced plaintext in quite the same way emacs did though (so for some niceties you do need to use a browser, similar to how you need to use the emacs-gui to embed images).
Coincidentally I haven't really managed to get the equation rendering right in emacs, the org-latex-preview seems quite slow. It's unfortunate that emacs isn't able to take advantage of things like KaTeX, there are historical reasons for this but still.
Mixing languages seems to be possible [1], though I haven't personally used it.
I can promise you, there will be more flavors and extensions in the next 20 years. And if I'm still alive then and we don't invent anything drastically different from keyboard input, I'd probably still be using Org-mode. Among thousands of others.
GFM, Gitlab and others you list are CommonMark plus extensions, which is what I said.
What is the problem? It is like saying JSON is useless because YAML exists, or that ISO C, C++, Fortran, IEEE 754, etc. are all useless because compilers and chip companies implement extensions.
You're still comparing just one aspect of Org-mode with Markdown. You're trying to convince me as if I was a pro-photographer and you'd tried to convince me that .jpeg is a fine format and everyone uses it and it's more popular, even though I'd still prefer RAW. Using .markdown is not appealing for me because .org allows me to do way more. If you're not convinced, then perhaps you don't need it. But don't expect me and thousands of other users of .org to switch, we'd be like: "Sorry, but you don't know what you're talking about". No offense.
Actually, YAML is probably worse than JSON, but JSON is really crappy compared to EDN. It's unfortunate that JSON has become the lingua franca for services, because it's really a stunted, primitive thing.
While I might have been concerned about this at one point in time, emacs and gcc are some of the most ported pieces of software in existence. That said, there have been some discussions about trying to work toward a specification for how things like org-babel should work so that other platforms can replicate the behavior inside of emacs. However, as others have stated elsewhere in the comments, once you accept emacs into your life there isn't really much incentive to spend time standardizing interfaces for things that can be handled more informally and as needed by the users. As a result those efforts need some internal incentive (like better or clearer documentation) to have development time allocated to them.
I'll have to disagree here. I'm using org-mode files even as a Vim user. Because compared to Markdown it has more basic syntax features and is fully compatible with LaTeX, making it both convenient and more powerful than Markdown.
Non-Emacs parsers aren't remotely complete or correct but the same applies to the huge variety of incompatible Markdown extensions and parsers in my experience. Some support tables, some don't, some can't handle standard table of content references.
And while you are right in that the interactive features of org-mode are Emacs exclusive they still are an advantage in my view: they are optional, independent of each other and documented. This means I was easily able to reproduce one of those features with some scripting in Vim while still keeping it conforming with the standard.
I think .org is a fantastic format because 100% of even its most advanced features are still rooted in plain text representation of the information, while its syntax is basically a superset of LaTeX, providing convenient shortcuts of the most common elements of text documents. This makes it universally readable and powerful when needed.
There is another Emacs package "pdftools" which is very underrated. It's amazing package, and just like org-mode pdftools will also be useful for the next several decades
I was but a wee lad of seven years when my father took me to a closet in our family office/craft room space and gave me a login to a FreeBSD machine running there. He showed me how to use Emacs and mutt—I sent my first email via a TUI.
It's been almost two decades since then, and I still use Emacs every day. I only recently got into org-mode. Boy was I missing out. I felt like a wizard compared to my classmates and peers, but now I feel like I've seriously leveled up.
What motivated me to learn how to use org-mode was a nice solution that worked on mobile. My favorite org-mode client for mobile is beorg [1]. (No relation to the app, other than a happy customer.) For general note files, I generally use Working Copy.
If you'd like to get into org-mode but are held back by the experience on mobile, give beorg a try. You will thank yourself.
I'll just say I opted to write my own org-mode syntax file(for syntax highlighting), file linking and time tracking for Vim instead of using the vim-orgmode plugin. That's enough for my personal org-mode based wiki and some organisational tasks.
The vim-orgmode plugin's performance was absolutely abyssmal when I last tried to use it, with input delays above a full second in some situations.
Not that great in my experience, good enough to read and navigate through org files, but lacks many features and has performance issues. vimwiki https://github.com/vimwiki/vimwiki is probably the best note-taking plugin for vim.
I've been using vimwiki daily for the past month after I saw it mentioned here on HN. It's really changed a lot and has replaced the method I had before that involved VScode markdown snippets. It's nice to be able to directly link between my diary / task lists and my general knowledge base that contains code snippets and information about my projects, etc.
I have had a few stints of trying out emacs. I used spacemacs, doom and rolled my own. It never gained any traction for me. I think the reason for this, is that the amount of time I would put into memorizing all the shortcuts and control / meta combinations, setting up all the lisp plugins (and then remembering their control key / meta combinations) is just not worth it for the time lost setting up and learning for the productivity gained. I am better to just use an IDE with all its bells and whistles and for general terminal work my old simple VIM set up easily does the job.
As far as org-mode, meh. I really don't see whats so amazing about collapsible to-do notes anymore. As for email, listening to music etc, I am sorry, but browsers do that job very well and with zero time needed to scour around blogs trying to get them to work.
> The unwieldy part came with all the repeated tasks, and tasks that got carried over from one day to the next (or didn't get finished). I had to copy yesterday's file, change all the key info, sort out the todo list, erase yesterday's journal, and generally do far too much work to keep my journal up.
I have that problem with my systems. I was hoping he would explain the solution specifically.
no offense, but i thought i would take to heart your tips about my abysmal format. falls under the category of "release early, release often." kinda like the borg, but without nanoprobes.
Justify in terms of what, exactly? At current disk prices, 114 megabytes costs less than a third of a US penny. Even at minimum wage, you'd make that in under a second.
surely someone of your pedigree can understand, not everything is about money. Why should I use something 6 times larger? Without a benefit thats just software bloat from where I sit. and GNU is known for this, from glibc on up.
Unless you are actually running out of space, why is that even a criteria? Unless two programs are exactly feature-paired, why would you even think about how much storage they take up? The only explanation is that your work has made you think about space taken by programs for legitimate reasons and you are unable to think outside that mindset - when the cheapest phones ship with 50-100x more space than that, when a single minute of video from a regular persons phone could take up this much space, when the regular user consumes 10x that bandwidth every day in the internet? Who cares if it's 100 MB?
This is a tangent, but I wish storage was that simple. Too many devices come with non-expandable storage and don't have very big options to start with, even if you're willing to pay well above the normal rate.
You can have Vim in Emacs with Evil Mode. IMO Emacs bindings are terrible no matter what and modal editing saved my career from an early death by wrist injury. But on top of Vim bindings you also get an entire, programmable IDE. I guess it's kinda big but like, so are most IDEs? But you can get many features at a lighter weight than other ones.
Like yea if literally the only thing you wanna do is edit plain text and maybe at most have syntax highlighting, use plain old vim with some .vimrc setup. If you're finding yourself installing plugins to make vim be more like an IDE, at that point, just install an IDE, and no IDE handles vim bindings better than Emacs imo (and this is from extensive testing), so, there, use Emacs.
> and modal editing saved my career from an early death by wrist injury
The fun thing is I stopped experiencing wrist pain after I switched from Vim to Emacs (with ±native bindings), partly because I moved Ctrl to Caps almost instantly, partly because I stopped using a lot 3rd party apps (e.g. XMPP/IRC clients) which required mouse.
Oh interesting - the Ctrl caps change was something I picked up when first playing with emacs (before I knew any vim) and it was a game changer for me, even though I was just using mostly native vscode bindings at that time. I used to think even if I didn't end up switching to emacs, it'd always at least have given me that.
"It is written in Lisp, which is the only computer language that is beautiful. It is colossal, and yet it only edits straight ASCII text files, which is to say, no fonts, no boldface, no underlining. In other words, the engineer-hours that, in the case of Microsoft Word, were devoted to features like mail merge, and the ability to embed feature-length motion pictures in corporate memoranda, were, in the case of emacs, focused with maniacal intensity on the deceptively simple-seeming problem of editing text. If you are a professional writer--i.e., if someone else is getting paid to worry about how your words are formatted and printed--emacs outshines all other editing software in approximately the same way that the noonday sun does the stars. It is not just bigger and brighter; it simply makes everything else vanish."