"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."
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.
Lisp made me weird. Every day I say something like "Rabbits are machines for turning grass into rabbits" and my wife just rolls her eyes.
([Rabbits], Grass) -> [Rabbits]
I never used a real Lisp Machine, but I'd love if someone who did can confirm this.
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 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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
Then when you sync your Emacs config to your laptop, those sharp edges remain gone.
Examples like this, especially those widely meaningful to everyone, are nearly impossible to craft.
It's like seeing different paths of movement before trying parkour and after training a few weeks.
What if another program edits the file? What if you accidentally pull up notepad.exe and edit it?
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.
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?
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.
I don't know any other editor that can do that.
Just making a joke that HN loves 1. emacs and 2. websites that are just a .txt file.
I hate no margins and use the Goyo vim plugin to make my editing experience more pleasurable.
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...)
Abnry, may I ask, what you use this plugin for?
edit: I was using readermode lol. The site does not look good at all on mobile.
Oh I see it looks bad in Firefox on mobile. Fair enough.
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.
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 am afraid I'm missing something.
You are not.
Nowadays I just use crappy little text editors for small notes and JetBrains IDEs for dev work.
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.
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?
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  and start reading SICP  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  and start reading SICP  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.
A real(world) Lisp is Clojure these days
afaik every modern IDE has this discoverability functionality. I use shift-shift and control-control autocomplete command menus all the time in JetBrains.
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.
See this comment too: https://news.ycombinator.com/item?id=23673299
Note, many still use emacs for what the GP described and more.
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.
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".
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.
[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.
Me too, and for me too.
What do you use that doesn't allow jk for normal mode? I found it works with most programs in which I use vim bindings nowadays:
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.
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.
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.
Which features does VS Code have but Emacs don't?
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, 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.
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.
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.
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.
How could you emulate emacs? Just the keybinds would miss the point.
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
Doom Emacs: https://github.com/hlissner/doom-emacs
Doom Emacs themes: https://github.com/hlissner/emacs-doom-themes (can be installed standalone but not sure if they disable the toolbars etc)
Is that just the default installation with better choices in the settings? I should have been more patient Emacs and persistent in configuring it.
- better-defaults (removes the toolbars/etc): https://github.com/technomancy/better-defaults
- doom-modeline (a nicer-looking modeline - that's the bar at the bottom): https://github.com/seagle0128/doom-modeline
- base16-chalk theme from base16-theme
All of the above packages are in MELPA.
And then the transparent titlebar is:
(add-to-list 'default-frame-alist '(ns-transparent-titlebar . t))
(add-to-list 'default-frame-alist '(ns-appearance . dark))
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 has had structural editing for lisp how long?
Plus, it's nice to fallback to ctags or ripgrep if your lsp server dies
They are still represented as text in 99% of editing interfaces, and you have to work with that representation.
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.
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.
> 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.
See if you find any features or extensions that aren’t available on notepad++...
My .emacs configuration is based on vim style modal shortcuts that make me faster than a mutant: https://github.com/tinku99/dotfiles/blob/master/init-public....
I also use org-mode as a minor mode for autohotkey code editing, by changing the outline character from * to ; ... https://github.com/tinku99/ahk-org-mode
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 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.
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.
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.)
Worthy of mention, of course, is Spacemacs, which made Emacs approachable to me, someone who hadn't used much beyond Notepad++ and Eclipse before then.
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.
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.
Linux and Kubernetes are structured the same way- nobody is using that out of box on it's own
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.
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.
Emacs is absolutely a household name, at least in the world of text editors…
I’ve never had a conversation with a software developer where they didn’t know what vim or emacs are.
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%?
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.
4.5%. So not many but it's certainly "among."
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.
1) Who cares about being a household name. Vain goals serve no one
2) You didn't specify one actionable change.
Please quote where I asked anyone to do anything. I merely explained why emacs is not popular and why in my opinion it will never be.
This is sad to me because I quite like emacs, and if I had the capacity to fork it I would.
It is not that easy, but the effort you invest in learning emacs will pay off eventually.
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.
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.
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
Check it out, if you didn't know about it.
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.
"Simplicity. From the creators of <<in order to create a text editor, let's create an OS first>>"
BTW, I love and hate emacs at the same time.
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?
And if you restrict yourself to markdown-compatibilty, why not just write in markdown?
- 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.
I sure as well wouldn't. It confuses me thoroughly.
I've found you can get pretty close if you combine it with Jupyter notebooks. When you use jupytext  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.
There's also really good support in Emacs for interacting with Jupyter, too https://github.com/dzop/emacs-jupyter
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 , though I haven't personally used it.
That is not true anymore. CommonMark is the formal spec everyone follows now, including most major sites out there.
> If I wake you up at 3AM would you remember the format of links? is it parentheses first or brackets?
Well, yes. Markdown is super easy to remember.
> LaTeX support. I can write some complex math formulas.
On top of CommonMark you can add extensions to render LaTeX just fine (like MathExchange does, for instance).
GFM, ExtraMark, MultiMarkdown, MarkdownExtra, Gitlab, Taiga, Showdown, Markua, CommonMark, RMarkdown, etc., etc.
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.
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.
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.
And there’s parsers for many languages like: https://github.com/200ok-ch/org-parser
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 . (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.
(also i never understood why collapsible nested lists make such a big difference)
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.
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.
I have that problem with my systems. I was hoping he would explain the solution specifically.
Versus Vim 18 MB:
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.
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.
Check out the develop branch though. Last I checked master was waaaay behind.
Look's like Vim is just too bloated for the modern minimalism focused user.
I have a little bit of difficulty justifying that on my SSD main drive.
114 MB for what is effectively an IDE for the long tail of programming languages is very easy to justify.