A CEO's Guide to Emacs (2015)(fugue.co)
fugue.co
A CEO's Guide to Emacs (2015)
http://www.fugue.co/blog/2015-11-11-guide-to-emacs.html
95 comments
I really enjoy using VSCode, it's highly configurable and ubiquitous. However, I do get concerned about handing so much control over my editor to Microsoft. While VSCode is ostensibly open source, forking it may become just as hard as forking Chromium.
You can try vscodium.com .According to their website, VSCodium is a community-driven, freely-licensed binary distribution of Microsoft’s editor VS Code.
I think it's kind of a combination - not having the tools pulled from under you, but also the device to device portability he mentions, and having all your content in text (or whatever) in a directory structure you control.
And yes, it's exactly the same feeling when using Neovim, which has it's own web browser plugins.
(He wrote the post in 2015. Wonder if he's still using Emacs now.)
And yes, it's exactly the same feeling when using Neovim, which has it's own web browser plugins.
(He wrote the post in 2015. Wonder if he's still using Emacs now.)
GUIs and proprietary protocols have killed Emacs.
Emacs isn't an editor, as the post implies, it's an environment. "You can do anything from Emacs" made sense back when everything was open and text based. Nowadays everyone is using Slack, or using an IMAP web client for mail that requires bespoke authentication, or organizer apps that automatically sync across all your devices via the cloud. All of the verticals have been slurped up by corporations who did it better in GUI, have better syncing, and have locked down the protocols needed to bridge, and now the brave Emacs user of 2024 is forced to spend lots of time not in Emacs, thus defeating the point of using Emacs.
As an editor alone I don't think Emacs is worth it. There's the old adage "They added everything to Emacs but a good editor" and I think that makes sense. If you're not going to live in Emacs for the above reasons then Vim/Neovim is a better editor with a larger community, and VSCode/Jetbrains are better IDEs that are already adopting AI, which will essentially kill off Emacs.
Emacs still has a lot of important lessons, but I feel bad for new programmers today who will never get the full experience of a text based digital life. Everything has been dumbed down for our own good, and Emacs is now nothing more than a glorified Org editor that forces you to find your own cloud syncing.
Emacs isn't an editor, as the post implies, it's an environment. "You can do anything from Emacs" made sense back when everything was open and text based. Nowadays everyone is using Slack, or using an IMAP web client for mail that requires bespoke authentication, or organizer apps that automatically sync across all your devices via the cloud. All of the verticals have been slurped up by corporations who did it better in GUI, have better syncing, and have locked down the protocols needed to bridge, and now the brave Emacs user of 2024 is forced to spend lots of time not in Emacs, thus defeating the point of using Emacs.
As an editor alone I don't think Emacs is worth it. There's the old adage "They added everything to Emacs but a good editor" and I think that makes sense. If you're not going to live in Emacs for the above reasons then Vim/Neovim is a better editor with a larger community, and VSCode/Jetbrains are better IDEs that are already adopting AI, which will essentially kill off Emacs.
Emacs still has a lot of important lessons, but I feel bad for new programmers today who will never get the full experience of a text based digital life. Everything has been dumbed down for our own good, and Emacs is now nothing more than a glorified Org editor that forces you to find your own cloud syncing.
> GUIs and proprietary protocols have killed Emacs.
I'm pretty sure, Emacs is not dead yet.
And if GUI & protocols are killing it, maybe adapting would be the way to survive?
> Emacs isn't an editor, as the post implies, it's an environment.
Bash is also an environment, but nobody calls it an editor. Emacs has an editor as the primary interface, and handling & editing text as its primary purpose. And today, any mature editor is its own environment anyway.
> All of the verticals have been slurped up by corporations who did it better in GUI,
Just saying, but GUI has little to do with this. Corps have simply more money, more manpower, more focus on serving customers (and making money). And modern Tools like GUI are a well working tool which enables them to deliver fast and userfriendly.
I'm pretty sure, Emacs is not dead yet.
And if GUI & protocols are killing it, maybe adapting would be the way to survive?
> Emacs isn't an editor, as the post implies, it's an environment.
Bash is also an environment, but nobody calls it an editor. Emacs has an editor as the primary interface, and handling & editing text as its primary purpose. And today, any mature editor is its own environment anyway.
> All of the verticals have been slurped up by corporations who did it better in GUI,
Just saying, but GUI has little to do with this. Corps have simply more money, more manpower, more focus on serving customers (and making money). And modern Tools like GUI are a well working tool which enables them to deliver fast and userfriendly.
> Bash is also an environment, but nobody calls it an editor.
Well bash has Emacs mode, so…
Well bash has Emacs mode, so…
> GUIs and proprietary protocols have killed Emacs
I have been using Emacs since 2010. What started as this 'what do I do' white screen has evolved into a powerful tool.
During this time, I have seen various other editors or IDEs all considered to be "better" but are eventually tossed aside in favour of something else.
Visual Studio (the IDE) has gone through some changes. Some for the better. However, there is also worse. It is slow and bloated.
Now we have Visual Studio Code which a lot of people seem to use, even those that judged me for using emacs a few years back. But... IDEs are better, right?
We also have Sublime Text 2 which was all the rage around 2013. Even they were laughing at me for using emacs. Now, I hardly see anyone using it.
Once in a while (in the last 15 years) I see the odd vi or vim user. They continue to exist like me with emacs. While I cannot confirm, I would not be surprised if most of these have moved to neovim or gone elsewhere.
Point is - emacs will be around for many years to come. It may never be the "best" in term of numbers but I would not be surprised if, in the next 10 years, Visual Studio Code or Neovim have moved on to some other new editor or IDE (or another vi variant, respectivelt) yet emacs is still there.
I have been using Slack properly in the last few months and I am not really that impressed with it. Sure, I am not using Emacs and I would not be surprised if there is emacs support for it. I would not be surprised is Slack is replaced by something else in 10 years. No different to other "management" tools that come and go.
So heres to Emacs. For me, it is worth it - and while things always change... emacs is likely to be about for some time.
I have been using Emacs since 2010. What started as this 'what do I do' white screen has evolved into a powerful tool.
During this time, I have seen various other editors or IDEs all considered to be "better" but are eventually tossed aside in favour of something else.
Visual Studio (the IDE) has gone through some changes. Some for the better. However, there is also worse. It is slow and bloated.
Now we have Visual Studio Code which a lot of people seem to use, even those that judged me for using emacs a few years back. But... IDEs are better, right?
We also have Sublime Text 2 which was all the rage around 2013. Even they were laughing at me for using emacs. Now, I hardly see anyone using it.
Once in a while (in the last 15 years) I see the odd vi or vim user. They continue to exist like me with emacs. While I cannot confirm, I would not be surprised if most of these have moved to neovim or gone elsewhere.
Point is - emacs will be around for many years to come. It may never be the "best" in term of numbers but I would not be surprised if, in the next 10 years, Visual Studio Code or Neovim have moved on to some other new editor or IDE (or another vi variant, respectivelt) yet emacs is still there.
I have been using Slack properly in the last few months and I am not really that impressed with it. Sure, I am not using Emacs and I would not be surprised if there is emacs support for it. I would not be surprised is Slack is replaced by something else in 10 years. No different to other "management" tools that come and go.
So heres to Emacs. For me, it is worth it - and while things always change... emacs is likely to be about for some time.
> Now we have Visual Studio Code which a lot of people seem to use, even those that judged me for using emacs a few years back. But... IDEs are better, right?
VS Code is not an IDE, it's more like the evolved GUI-Version of Emacs. And it's now 9 years old, so I would think it has established itself well for this decade.
> We also have Sublime Text 2
It's now at version 4, still in development. But being a commercial app, which is also not that cheap, you will naturally see not too many people using it. But considering they are still developing it, they seem to still make money from it, so enough people are using it I guess.
> Once in a while (in the last 15 years) I see the odd vi or vim user. They continue to exist like me with emacs.
That's a very strange observation. There are significant more (neo)vim-users than emacs-users around. They are probably the second biggest crowd in text-editor-space, only beaten by VS Code at the moment. It's far more likely for emacs to die, than for vim.
> Point is - emacs will be around for many years to come.
That's true for all of them. As long as someone maintains them, people will use them. Software will only die when they don't start anymore or the users left them. And at the moment Emacs seems more at the position where users will slowly die of old age, than Emacs not starting anymore. So another 30, 40 years, and Emacs might have a real problem.
VS Code is not an IDE, it's more like the evolved GUI-Version of Emacs. And it's now 9 years old, so I would think it has established itself well for this decade.
> We also have Sublime Text 2
It's now at version 4, still in development. But being a commercial app, which is also not that cheap, you will naturally see not too many people using it. But considering they are still developing it, they seem to still make money from it, so enough people are using it I guess.
> Once in a while (in the last 15 years) I see the odd vi or vim user. They continue to exist like me with emacs.
That's a very strange observation. There are significant more (neo)vim-users than emacs-users around. They are probably the second biggest crowd in text-editor-space, only beaten by VS Code at the moment. It's far more likely for emacs to die, than for vim.
> Point is - emacs will be around for many years to come.
That's true for all of them. As long as someone maintains them, people will use them. Software will only die when they don't start anymore or the users left them. And at the moment Emacs seems more at the position where users will slowly die of old age, than Emacs not starting anymore. So another 30, 40 years, and Emacs might have a real problem.
> VS Code is not an IDE...
I know.
> ...it's more like the evolved GUI-Version of Emacs. And it's now 9 years old, so I would think it has established itself well for this decade.
Point I am making is those using Visual Studio (before Visual Studio Code) would criticise me for using Emacs.. a text editor. They mocked me because "IDEs are better"
Roll on to more recent times.. many of said people are now using Visual Studio Code. The same people that told me "IDEs are better"
> It's now at version 4, still in development. But being a commercial app, which is also not that cheap, you will naturally see not too many people using it. But considering they are still developing it, they seem to still make money from it, so enough people are using it I guess.
I will admit I did not know there was a ST v4. I knew about version 3 (I will not get into that). I do not know anyone using it. Not suggesting noone is.. just my personal observation. I would not be surprised if many ST2 users moved to VSCode.
> That's a very strange observation. There are significant more (neo)vim-users than emacs-users around
I was talking about vi/vim.. not neovim.
I made my point with regards to VSCode and NeoVim. They are the current cool kids on the block. Not suggesting they wont be popular in 10 years time. They could be.. but large of their userbase could move onto another cool kid by then. Emacs, on the other hand (like vi/vim) will continue like they normally do.
I know.
> ...it's more like the evolved GUI-Version of Emacs. And it's now 9 years old, so I would think it has established itself well for this decade.
Point I am making is those using Visual Studio (before Visual Studio Code) would criticise me for using Emacs.. a text editor. They mocked me because "IDEs are better"
Roll on to more recent times.. many of said people are now using Visual Studio Code. The same people that told me "IDEs are better"
> It's now at version 4, still in development. But being a commercial app, which is also not that cheap, you will naturally see not too many people using it. But considering they are still developing it, they seem to still make money from it, so enough people are using it I guess.
I will admit I did not know there was a ST v4. I knew about version 3 (I will not get into that). I do not know anyone using it. Not suggesting noone is.. just my personal observation. I would not be surprised if many ST2 users moved to VSCode.
> That's a very strange observation. There are significant more (neo)vim-users than emacs-users around
I was talking about vi/vim.. not neovim.
I made my point with regards to VSCode and NeoVim. They are the current cool kids on the block. Not suggesting they wont be popular in 10 years time. They could be.. but large of their userbase could move onto another cool kid by then. Emacs, on the other hand (like vi/vim) will continue like they normally do.
> Point I am making is those using Visual Studio (before Visual Studio Code) would criticise me for using Emacs.. a text editor. They mocked me because "IDEs are better"
Maybe you failed to explain it, probably, or configure the IDE-features of Emacs? I mean, that's the point of VS Code and Emacs and others like them. They can have IDE-features, without being an IDE. And those features can have value it used well, elevating these apps above your normal plain text editor.
> I was talking about vi/vim.. not neovim.
There is no significant difference between them, and no reason to distinguish between them when talking about users and their preferences. One can move mostly freely between them with little to no hindrance.
Maybe you failed to explain it, probably, or configure the IDE-features of Emacs? I mean, that's the point of VS Code and Emacs and others like them. They can have IDE-features, without being an IDE. And those features can have value it used well, elevating these apps above your normal plain text editor.
> I was talking about vi/vim.. not neovim.
There is no significant difference between them, and no reason to distinguish between them when talking about users and their preferences. One can move mostly freely between them with little to no hindrance.
> Maybe you failed to explain it, probably, or configure the IDE-features of Emacs? I mean, that's the point of VS Code and Emacs and others like them. They can have IDE-features, without being an IDE. And those features can have value it used well, elevating these apps above your normal plain text editor.
Lots of assumptions to try and cling on to some kind of point, I guess.
> There is no significant difference between them, and no reason to distinguish between them when talking about users and their preferences. One can move mostly freely between them with little to no hindrance.
Wrong.
Lots of assumptions to try and cling on to some kind of point, I guess.
> There is no significant difference between them, and no reason to distinguish between them when talking about users and their preferences. One can move mostly freely between them with little to no hindrance.
Wrong.
I assume you're joking right? Vim/Neovim have already diverged. They have completely separate scripting languages now, config languages for the main config file, and Neovim has LSP support out of the box, removed cscope and a bunch of other built ins... They have about as much in common as Vim has with Helix.
> Vim/Neovim have already diverged.
They are still 99% the same. They still have the same mental model, shortcuts, commands...
> They have completely separate scripting languages now, config languages for the main config file, and Neovim has LSP support out of the box
I'm not saying there can't be work involved when moving from one to the other. But it depends on the user, their setup and is more akin to changing from one vim-version to another version, not like switching between two completely different editors.
From my experience, a (neo)vim-user will always be able to continue with (neo)vim or any other future flavor of them instantly on a high level out-of-the-box. Which is very different from switching to any other editor. I mean I have seen vim-users being challenged by nano, simply because it's so different from they established habits..
They are still 99% the same. They still have the same mental model, shortcuts, commands...
> They have completely separate scripting languages now, config languages for the main config file, and Neovim has LSP support out of the box
I'm not saying there can't be work involved when moving from one to the other. But it depends on the user, their setup and is more akin to changing from one vim-version to another version, not like switching between two completely different editors.
From my experience, a (neo)vim-user will always be able to continue with (neo)vim or any other future flavor of them instantly on a high level out-of-the-box. Which is very different from switching to any other editor. I mean I have seen vim-users being challenged by nano, simply because it's so different from they established habits..
> VS Code is not an IDE, it's more like the evolved GUI-Version of Emacs.
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."
Interesting way to get an acknowledgement that IDEs aren't as advanced as Emacs, I suppose, and that VSCode (as in Man Vs Code, one of the Basic Plots) is only partway to being Emacs, being a GUI version (simplification) of the core concept, as if Emacs didn't already have a GUI.
(Having a GUI being different from depending on a GUI, but baby steps... )
> And it's now 9 years old, so I would think it has established itself well for this decade.
But no guarantees about the next decade.
"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."
Interesting way to get an acknowledgement that IDEs aren't as advanced as Emacs, I suppose, and that VSCode (as in Man Vs Code, one of the Basic Plots) is only partway to being Emacs, being a GUI version (simplification) of the core concept, as if Emacs didn't already have a GUI.
(Having a GUI being different from depending on a GUI, but baby steps... )
> And it's now 9 years old, so I would think it has established itself well for this decade.
But no guarantees about the next decade.
> it's more like the evolved GUI-Version of Emacs
If you mean "evolved GUI-Version" and not also "evolved emacs" I might be able to agree. The friction in customizing vscode is too high and in some cases impossible given you have no hooks or way to order plugin load order (last I checked).
If you mean "evolved GUI-Version" and not also "evolved emacs" I might be able to agree. The friction in customizing vscode is too high and in some cases impossible given you have no hooks or way to order plugin load order (last I checked).
I think a lot of people would argue that Emacs is also slow and bloated, but makes you, the user, program most of the functionality you get from VSCode or JB out of the box. Want fuzzing finding? That's a package. Want git integration? That's a package. Want LSP? Also a package. Want to have sane defaults? Go look at 20 different init.els online and cargo cult a bunch of elisp. And after you've made your own Emacs stew spend, the next 14 years stomping out bugs and ignoring the things it still can't do, like run a multi-threaded tramp so a bad connection doesn't freeze your entire editor.
I think the people who switch from editor to editor that requires 0 config actually saved time and money by just doing their job rather than configuring their editor, and this is coming from a Vim user. Emacs is a black whole where "free" time gets sucked in never to be seen again. The big difference is as a Vim user I only had to configure my editor, you had to configure your entire operating system including Org mode.
I also am not sure about the whole Vim thing. On reddit, Vim has 3x the number of community users as Emacs and Neovim. I think Vim is still by far the most popular text based editor, but nowadays I think VSCode is unfortunately here to stay because Microsoft knows the value of having a captive developer audience.
I think the people who switch from editor to editor that requires 0 config actually saved time and money by just doing their job rather than configuring their editor, and this is coming from a Vim user. Emacs is a black whole where "free" time gets sucked in never to be seen again. The big difference is as a Vim user I only had to configure my editor, you had to configure your entire operating system including Org mode.
I also am not sure about the whole Vim thing. On reddit, Vim has 3x the number of community users as Emacs and Neovim. I think Vim is still by far the most popular text based editor, but nowadays I think VSCode is unfortunately here to stay because Microsoft knows the value of having a captive developer audience.
Emacs does do a lot more "out of the box" now than many people realize. You will still have to turn them on, I think; but you don't have to install as many external packages as you are implying there.
And the problem with "sane defaults" is that to those of us that have been on Emacs for a long time, the defaults are sane. If you were to switch them on us, that would be frustrating. You /could/ make it so that startup on a vanilla setup has a set of checkboxes for common input schemes that people select between. I'm not sure why that hasn't been done, or what other issues that would have.
As for saving time/money by "doing their job" rather than configuring an editor. This is always a tough one. I don't think people should have to spend time getting to know their editors. But, I also don't worry that people don't spend time learning to care for their cars or their plumbing. That is, it makes sense that many people want to outsource that effort to others. It also makes sense that many people like getting into that sort of stuff. And I don't know why it has to be a battle between them?
And the problem with "sane defaults" is that to those of us that have been on Emacs for a long time, the defaults are sane. If you were to switch them on us, that would be frustrating. You /could/ make it so that startup on a vanilla setup has a set of checkboxes for common input schemes that people select between. I'm not sure why that hasn't been done, or what other issues that would have.
As for saving time/money by "doing their job" rather than configuring an editor. This is always a tough one. I don't think people should have to spend time getting to know their editors. But, I also don't worry that people don't spend time learning to care for their cars or their plumbing. That is, it makes sense that many people want to outsource that effort to others. It also makes sense that many people like getting into that sort of stuff. And I don't know why it has to be a battle between them?
To further this...
Adding packages in emacs are not that hard.
The only area (in my opinion) where you have a point are newcommers to emacs. The learning curve is as steep as you want it to be. You do need to invest time to understand it and get really good at it. The key combinations, packages, etc. This is likely where many will just go to Visual Studio Code or something else.
Emacs... when you take the time to invest, the rewards are HUGE and goes beyond (the likes of) Visual Studio Code.
I consider myself an experienced emacs user. Are their better, more talented, absolute beast-like emacs users out there? Yes. More gifted than me? Absolutely. I know enough elisp to get things done quickly. If I needed to put together a new emacs install from scratch, I could get all the main bits I need in 20 mins or less.
Better news is my emacs config. Makes use of use-package and factors in Windows and Linux. Nice and clean elisp code!! I can take it wherever and use it for new installs.
My comments is not forcing people to use emacs. Can I be bias at times? Absolutely! Do I like a little light-hearted jokes about editors? Absolutely! I use to have a little poke at vim devs in the past. They did it back. We actually learned from each others methods of 'doing something' on our editors. I miss that. I am not religious to emacs but, as software goes, it is close to me. However, I am also open to something replacing it. None of the IDEs or editors available are nowhere near being a replacement... for me.
Does not mean something in the future cannot break that mold.
Adding packages in emacs are not that hard.
The only area (in my opinion) where you have a point are newcommers to emacs. The learning curve is as steep as you want it to be. You do need to invest time to understand it and get really good at it. The key combinations, packages, etc. This is likely where many will just go to Visual Studio Code or something else.
Emacs... when you take the time to invest, the rewards are HUGE and goes beyond (the likes of) Visual Studio Code.
I consider myself an experienced emacs user. Are their better, more talented, absolute beast-like emacs users out there? Yes. More gifted than me? Absolutely. I know enough elisp to get things done quickly. If I needed to put together a new emacs install from scratch, I could get all the main bits I need in 20 mins or less.
Better news is my emacs config. Makes use of use-package and factors in Windows and Linux. Nice and clean elisp code!! I can take it wherever and use it for new installs.
My comments is not forcing people to use emacs. Can I be bias at times? Absolutely! Do I like a little light-hearted jokes about editors? Absolutely! I use to have a little poke at vim devs in the past. They did it back. We actually learned from each others methods of 'doing something' on our editors. I miss that. I am not religious to emacs but, as software goes, it is close to me. However, I am also open to something replacing it. None of the IDEs or editors available are nowhere near being a replacement... for me.
Does not mean something in the future cannot break that mold.
> I think a lot of people would argue that Emacs is also slow and bloated, but makes you,
the user, program most of the functionality you get from VSCode or JB out of the box
I only use what I need. Use-Package, Org, Org-Roam, Magit, Yasnippets, and Modes for my chosen programming languages.. are a must.
all other things, like Themes, come second. Anything else are just nice additions.
Point is, I do not spend much time playing about with my config.
> I think the people who switch from editor to editor that requires 0 config actually saved time and money
Moving from IDE/Editor to another IDE/Editor will still have some form of learning curve. I stick with Emacs, based on my comments above.
> I also am not sure about the whole Vim thing.
Sure - my comment is not an Emacs vs Vi thing. I know vi/vim is still popular and, yes, I still use it from time to time when SSH'ing onto a server for a quick config change. I am expecting it to be more popular than emacs. Point is, despite neovim coming around.. I am sure vi (or vim) will still be lurking around in 10 years.. like emacs.
I only use what I need. Use-Package, Org, Org-Roam, Magit, Yasnippets, and Modes for my chosen programming languages.. are a must.
all other things, like Themes, come second. Anything else are just nice additions.
Point is, I do not spend much time playing about with my config.
> I think the people who switch from editor to editor that requires 0 config actually saved time and money
Moving from IDE/Editor to another IDE/Editor will still have some form of learning curve. I stick with Emacs, based on my comments above.
> I also am not sure about the whole Vim thing.
Sure - my comment is not an Emacs vs Vi thing. I know vi/vim is still popular and, yes, I still use it from time to time when SSH'ing onto a server for a quick config change. I am expecting it to be more popular than emacs. Point is, despite neovim coming around.. I am sure vi (or vim) will still be lurking around in 10 years.. like emacs.
>Want fuzzing finding? That's a package
No, it's built in. Want non-default fuzzy finding? That's a package.
>Want git integration? That's a package
No, that's built in. Want non-default git integration that's fancier? That's a package
>Want LSP? Also a package
No, that's built in.
>Want to have sane defaults? Go look at 20 different init.els online and cargo cult a bunch of elisp.
No, read the tutorial or install a starter kit if you must, but really the defaults are fine -- just old. You can do almost everything you want in Emacs with just Alt-x (M-x) and running commands. It's what those new editors call a "command palette" except Emacs has had one for decades.
> The big difference is as a Vim user I only had to configure my editor, you had to configure your entire operating system including Org mode.
lol what? This must be a troll post. Org Mode is not required in any way to use Emacs, and it actually has pretty decent defaults because it's actively developed.
No, it's built in. Want non-default fuzzy finding? That's a package.
>Want git integration? That's a package
No, that's built in. Want non-default git integration that's fancier? That's a package
>Want LSP? Also a package
No, that's built in.
>Want to have sane defaults? Go look at 20 different init.els online and cargo cult a bunch of elisp.
No, read the tutorial or install a starter kit if you must, but really the defaults are fine -- just old. You can do almost everything you want in Emacs with just Alt-x (M-x) and running commands. It's what those new editors call a "command palette" except Emacs has had one for decades.
> The big difference is as a Vim user I only had to configure my editor, you had to configure your entire operating system including Org mode.
lol what? This must be a troll post. Org Mode is not required in any way to use Emacs, and it actually has pretty decent defaults because it's actively developed.
Semantics. Some of the packages are included, all of them have to be turned on and configured, and hopefully the user already knows about use package and understands the syntax for customizations and keybindings. Of course, if they try to Google how to use these packages they'll realize that Eglot doesn't work with DAP, so if you want to debug anything you'll need to go download the third party lsp-mode and dap-mode, configure them, then realize everyone uses swiper, consul, etc. which you'll need to download and configure as well.
> but really the defaults are fine -- just old.
I assume this is just Stockholm syndrome. Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow. If the defaults were sane, everyone wouldn't be disabling and enabling the same stuff in their config. The defaults are not sane precisely because people complain that changing any of the defaults for a 30 year old editor in 2024 is tantamount to open source treason.
> but really the defaults are fine -- just old.
I assume this is just Stockholm syndrome. Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow. If the defaults were sane, everyone wouldn't be disabling and enabling the same stuff in their config. The defaults are not sane precisely because people complain that changing any of the defaults for a 30 year old editor in 2024 is tantamount to open source treason.
> Some of the packages are included, all of them have to be turned on and configured
I see where you're coming from, but I think this is a bit exaggerated as well.
For some concrete examples:
- Git: Emacs does have a built-in `vc-mode`, which can be used without any prior configuration by pressing `C-x v`. Or you can go to `Tools > Version Control` in the menu bar (if you haven't disabled it). Many people prefer to install Magit, but the built-in package is actually quite decent (the UX is a bit similar).
- You brought up LSP. Emacs now has a built-in `eglot` mode which connects to LSP servers, and is pre-configured to work with many of the open-source ones. You can turn it on by pressing `M-x eglot`, or go to `Tools > Language Server Support (Eglot)` in the menu bar. Many people prefer to install LSP-mode, but I think many people have also migrated to Eglot after it landed officially in Emacs.
> Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow.
I agree with you that the defaults should be modernized. For example, I think most people would appreciate if the defaults were updated to e.g. use one of the `modus` themes, automatically switch to a dark theme if the OS has it enabled, and enable a fuzzy-finder like fido-vertical-mode without configuration. All of these capabilities are already bundled with Emacs, just not turned on by default. I'd also advocate for disabling the blinking cursor and the bell - who wants that?
Just as a counter-example though, I don't have any of the specific settings you mentioned enabled:
- I dislike line numbers (they look weird if you work with soft-wrapped prose and they take up space)
- I don't like bracket matching (they don't work well with modal editing).
- I don't use the early-init garbage collector optimizations (Emacs anyway starts in a second as I use few packages, and leave it open all day so it doesn't matter).
I see where you're coming from, but I think this is a bit exaggerated as well.
For some concrete examples:
- Git: Emacs does have a built-in `vc-mode`, which can be used without any prior configuration by pressing `C-x v`. Or you can go to `Tools > Version Control` in the menu bar (if you haven't disabled it). Many people prefer to install Magit, but the built-in package is actually quite decent (the UX is a bit similar).
- You brought up LSP. Emacs now has a built-in `eglot` mode which connects to LSP servers, and is pre-configured to work with many of the open-source ones. You can turn it on by pressing `M-x eglot`, or go to `Tools > Language Server Support (Eglot)` in the menu bar. Many people prefer to install LSP-mode, but I think many people have also migrated to Eglot after it landed officially in Emacs.
> Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow.
I agree with you that the defaults should be modernized. For example, I think most people would appreciate if the defaults were updated to e.g. use one of the `modus` themes, automatically switch to a dark theme if the OS has it enabled, and enable a fuzzy-finder like fido-vertical-mode without configuration. All of these capabilities are already bundled with Emacs, just not turned on by default. I'd also advocate for disabling the blinking cursor and the bell - who wants that?
Just as a counter-example though, I don't have any of the specific settings you mentioned enabled:
- I dislike line numbers (they look weird if you work with soft-wrapped prose and they take up space)
- I don't like bracket matching (they don't work well with modal editing).
- I don't use the early-init garbage collector optimizations (Emacs anyway starts in a second as I use few packages, and leave it open all day so it doesn't matter).
> We also have Sublime Text 2 which was all the rage around 2013... Now, I hardly see anyone using it.
Maybe they upgraded to Sublime Text 4?
Maybe they upgraded to Sublime Text 4?
> Maybe they upgraded to Sublime Text 4?
Didn't know it passed version 3, being honest. Says a lot. Point still stands.
Didn't know it passed version 3, being honest. Says a lot. Point still stands.
It probably depends a lot on company culture and possibly what OSes the devs are using. Pretty much every dev in our 20+ team has it installed, as there are not many editors on Windows have equivalent editing features and are so snappy to use. However, the free trial version is not strictly permitted for corporate use, so we might be losing it soon.
> It probably depends a lot on company...
Absolutely. I am not suggesting ST is dead. It's just 10-12 years ago ST2 was big hype online. Hyped to the point that likes of Vi (or even emacs) users were moving over to it!
Today, I hardly hear about it online. It is VS Code, even in the office. I am sure if I was in the same room 10 years ago, it would be the same.. just ST2. :-)
I wonder what the "cool" thing is in the next 10 years. Likely be saying the same thing about VS Code over the next "cool kid"
Maybe other dev culture (php devs, for example) that I have not been part of are mostly using ST2/3/4.
Absolutely. I am not suggesting ST is dead. It's just 10-12 years ago ST2 was big hype online. Hyped to the point that likes of Vi (or even emacs) users were moving over to it!
Today, I hardly hear about it online. It is VS Code, even in the office. I am sure if I was in the same room 10 years ago, it would be the same.. just ST2. :-)
I wonder what the "cool" thing is in the next 10 years. Likely be saying the same thing about VS Code over the next "cool kid"
Maybe other dev culture (php devs, for example) that I have not been part of are mostly using ST2/3/4.
I'm totally with you insofar as ST isn't used much as a full IDE. But it's a great as a background text editor and I'd be surprised if not many people use it for that.
I use it to keep a TODO list, analyse and manipulate log files, record temporary notes, and edit big JSON packets. Tasks like "extract all lines which include this phrase, and then delete the first 10 characters" are straightforward. Also it's minimal, clean and feels spacious out of the box.
VS Code probably has similar features, but has a much bigger memory footprint, takes longer to start up, and looks more cluttered. If you're already a dotnet shop with VS Pro/Enterprise subscriptions then it makes more sense to use ST.
I use it to keep a TODO list, analyse and manipulate log files, record temporary notes, and edit big JSON packets. Tasks like "extract all lines which include this phrase, and then delete the first 10 characters" are straightforward. Also it's minimal, clean and feels spacious out of the box.
VS Code probably has similar features, but has a much bigger memory footprint, takes longer to start up, and looks more cluttered. If you're already a dotnet shop with VS Pro/Enterprise subscriptions then it makes more sense to use ST.
I think EMACS is a fantastic editor, partially because you can extend it however you like. And, those extensions work forever, they don't get lost every time you change teams and have to change IDEs.
No, you can't live your entire life there, but that was never a great idea. Instead, it's great for software development activities. Org mode and magit are very hard to match outside of EMACS.
The primary things you do in an IDE are debugging, browsing code, writing code, and then writing documentation. With LSP, it's now fantastic at all of those. I can write documentation easily with org mode, and GUD is a really good debugger. And I can extend GDB with Python, to simplify the common stuff I often have to do with my own data structures and types.
With emacs, a web browser, and a terminal, I can do effectively anything I need to do on a computer and do it well.
No, you can't live your entire life there, but that was never a great idea. Instead, it's great for software development activities. Org mode and magit are very hard to match outside of EMACS.
The primary things you do in an IDE are debugging, browsing code, writing code, and then writing documentation. With LSP, it's now fantastic at all of those. I can write documentation easily with org mode, and GUD is a really good debugger. And I can extend GDB with Python, to simplify the common stuff I often have to do with my own data structures and types.
With emacs, a web browser, and a terminal, I can do effectively anything I need to do on a computer and do it well.
As someone who has IntelliJ open right now for some project work, and uses vi on a regular basis (but not skilled at it)... I use Emacs regularly. Literally, 5 minutes ago I opened a couple files in Emacs, right next to IntelliJ, because it was the better tool for the job I needed to do with them.
> GUIs and proprietary protocols have killed Emacs.
They've tried, but I have been happily using it for the past 15 years.
They're trying to kill computing in general. I'm just thankful there seems to be enough people like me who won't give it up so easily.
They've tried, but I have been happily using it for the past 15 years.
They're trying to kill computing in general. I'm just thankful there seems to be enough people like me who won't give it up so easily.
I still really like Emacs. Granted, I use Doom, because modal editing is just better. But I don't need to use Vim/Neovim unless I need a quick light editor over a remote connection. There's still a lot of useful integrations and applications within Emacs. I use Calc all the time, Org, LSP is thankfully open and makes Emacs a full-on IDE, RSS reader, file explorer, by far the best Git client, and I still use it to analyze and operate on basically anything text-related.
I think it goes both ways. There are a lot more closed-down things these days, but the things that are open feel more established and professional than they ever did before.
I think it goes both ways. There are a lot more closed-down things these days, but the things that are open feel more established and professional than they ever did before.
I really meant it when I said that AI will kill Emacs. In the future every application will be connected to a backend inference engine to act as the primary or close to primary interface to the application. A calculator that can't run prompts is going to be like using an abacus in a few years. Same thing for Magit/regular git.
Emacs is able to run prompts, just like any other tool that's able to make an HTTP request. E.g., https://github.com/karthink/gptel provides hooks to both OpenAI and local LLMs, and allows you to use them anywhere—since everything in Emacs is a buffer.
There are some pretty great examples in the README.
There are some pretty great examples in the README.
This will be far far in the future. I say this as someone using gpt4 a lot daily for their programming tasks and experimenting with local models like mixtral instruct.
AI as-is is completely useless for programming, or even counter-productive.
"because modal editing is just better"... for _you_
luckily emacs gives people options
luckily emacs gives people options
It's not better for anyone except delusional people. It was created for ADM terminals whose keyboards lacked the keys vim users use to navigate in modal editing, and there's no reason for it anymore.
> terminals whose keyboards lacked the keys vim users use to navigate in modal editing, and there's no reason for it anymore.
Vim keybindings really are more comfortable if you struggle with RSI. I’ve had such issues despite having used Caps Lock as Ctrl for years, and despite pressing it with my ring finger instead of pinkie. In my case, I have big hands and often have to work from small laptop keyboards for my job, which likely makes it worse.
The 3 times I’ve tried to go all-in on Emacs keybindings, I’ve after 1-2 months developed pain in my left forearm that then took months to heal. I developed some similar pains when I tried to use Sublime Text keybindings as well, but it was worse with Emacs. I blame this on excessive chording.
Except these excursions into other keybinding sets, I’ve used mainly Vim keybindings for nearly two decades now. I never had arm pains using Vim or Evil.
All this is to say: “There is no reason for it anymore” is too dismissive. The original reason Bill Joy wrote Vi the way he did was those constraints, but it has benefits today for other reasons.
Vim keybindings really are more comfortable if you struggle with RSI. I’ve had such issues despite having used Caps Lock as Ctrl for years, and despite pressing it with my ring finger instead of pinkie. In my case, I have big hands and often have to work from small laptop keyboards for my job, which likely makes it worse.
The 3 times I’ve tried to go all-in on Emacs keybindings, I’ve after 1-2 months developed pain in my left forearm that then took months to heal. I developed some similar pains when I tried to use Sublime Text keybindings as well, but it was worse with Emacs. I blame this on excessive chording.
Except these excursions into other keybinding sets, I’ve used mainly Vim keybindings for nearly two decades now. I never had arm pains using Vim or Evil.
All this is to say: “There is no reason for it anymore” is too dismissive. The original reason Bill Joy wrote Vi the way he did was those constraints, but it has benefits today for other reasons.
It is what it is, I wouldn't deny it to anybody. But I really wish the subsection of the geek population that runs around with the Vim religion denigrating everything else would just STFU.
I've been Unixing for 30 years. If I was going to join that cult, I would have done it a long time ago.
Modal is not superior, it's just something else.
I've been Unixing for 30 years. If I was going to join that cult, I would have done it a long time ago.
Modal is not superior, it's just something else.
I don't think your denigrating people is going to help anything.
I'm not the denigrator, you're probably mistaking me for the other commenter, "shrimp_emoji"
Every single time in emacs/vim posts there’s a guy who knows better than me what is better for me, without even knowing me and my reasoning. There is a lot of reasons people use modal editing, but we didn’t realize that all of them don’t exist anymore because shrimp_emoji thinks so. Oh boy.
There are a lot of things people can potentially teach others, but typically it's a good idea to show some curiosity and learn about the use-cases of others before making sweeping statements :)
That's awfully harsh. People's brains work in different ways, and for some people separating movement from editing makes a lot of sense.
Vim's modal editing allows for wider key space and better ergonomics. Both are good to have for programming IMO.
I used to keep doom distribution around solely for magit and missed it a lot since it's the best git client by far and large.
These days, thankfully there's lazygit around which, although not integrated directly in the editor and although not as good as magit, covers the need for a decent terminal-based git client with vim-like controls.
I’ve found code generation tools a boon to my Emacs-ing because I can use them to help write Emacs lisp code for any customization I think I might need in the moment without breaking the flow of concentration towards my primary task.
> now the brave Emacs user of 2024 is forced to spend lots of time not in Emacs, thus defeating the point of using Emacs.
If you can just get your email in Emacs, you can get a lot of integration you need. Luckily, email is still a must-have for many services.
For things like slack, teams, etc... it's much much harder.
Glancing at my "emacs for everything" roam node, I was last looking at utilizing matterbridge[0] to get access to teams, slack, etc by bridging to IRC. However, more ideal would be bridging to matrix especially if attachments/etc can be bridged over.
Taking actions based upon notifications though all the way from beginning to completion, then using elisp to customize the process, is definitely where emacs has the most impact.
Coworker pasted some code? You are reading it in an emacs buffer and have a function to open the code block at point in a python buffer with a repl split to the right to test it with no effort.
0: https://github.com/42wim/matterbridge
If you can just get your email in Emacs, you can get a lot of integration you need. Luckily, email is still a must-have for many services.
For things like slack, teams, etc... it's much much harder.
Glancing at my "emacs for everything" roam node, I was last looking at utilizing matterbridge[0] to get access to teams, slack, etc by bridging to IRC. However, more ideal would be bridging to matrix especially if attachments/etc can be bridged over.
Taking actions based upon notifications though all the way from beginning to completion, then using elisp to customize the process, is definitely where emacs has the most impact.
Coworker pasted some code? You are reading it in an emacs buffer and have a function to open the code block at point in a python buffer with a repl split to the right to test it with no effort.
0: https://github.com/42wim/matterbridge
Im a relatively new developer (10 years) and I use Emacs almost exclusively. Having come to Emacs from Jetbrains IDEs I would say that it is definitely worth diving in
> GUIs and proprietary protocols have killed Emacs
For me, corporate environments killed tool choice... Locked down corporate Windows with the full O365 bubble (locked down too - so no integration with anything outside) is a hard current to swim against and I gave up resisting.
For me, corporate environments killed tool choice... Locked down corporate Windows with the full O365 bubble (locked down too - so no integration with anything outside) is a hard current to swim against and I gave up resisting.
I’ve enjoyed using Emacs as a programming editor and environment since 2011 — for JavaScript, CoffeeScript, Clojure, Bash, Racket/Scheme, Python, Perl, Nim, among others, it’s worked great and keeps getting better with e.g. the arrival of LSP support.
You can still find terminal interfaces for a lot of these things, including Slack: https://github.com/jpbruinsslot/slack-term. I don't use Emacs but I imagine you could integrate that somehow if you wanted to.
AI is integrated with emacs. You can get both openAI/ChatGPT/Copilot integration with emacs, works fine. I agree that slack and other proprietary chat interface make it harder for everyone else, but that's a problem not just for emacs.
Hell, we had eliza-mode in emacs since the 80s ;-)
In a way VSCode is kind of this generation's emacs, I guess. Scriptable, does "Everything", etc. It's just not as... magic. And it's not Free Software with the same spirit that made emacs cool.
You can, in fact, glue everything together in emacs to get a rather all-encompassing environment; IDE-like code editing, navigation, etc. even copilot and such (but yes, sans the slack and browser, etc. as you say). But I've found it will always be brittle. And, yes, back in the day I had it all inside emacs.. IRC, LambdaMOO, email, code editing. All in one place running on my 8MB 486. There's nothing like that now, but, yes, the GUI environment does it all.
It's the same reason why tiling window managers never click for me -- all the applications I use all have their own "tiling" that ends up fighting with it. CLion, Firefox, Emacs, Discord, Slack, Teams... they've all got their own internal nav, with the expectation of a typical GUI environment.
All that said... Saying "just use Vim" is kind of missing the point. I (and others) hate modal editors, and if I liked them I would have used vi back in the day in the first place as it was always one very machine I shelled into. The modal editing thing as some sort of mark of superiority or pride... is a bit of a recent obsession of a subset of nerd culture that I don't get, nor do I care to. And I strongly disagree that "but a good editor" line; the editor in emacs is great. But no, it's not vi, and no, it's not windows/mac keybindings. You have to learn its keybindings and yanking and all that.
You can, in fact, glue everything together in emacs to get a rather all-encompassing environment; IDE-like code editing, navigation, etc. even copilot and such (but yes, sans the slack and browser, etc. as you say). But I've found it will always be brittle. And, yes, back in the day I had it all inside emacs.. IRC, LambdaMOO, email, code editing. All in one place running on my 8MB 486. There's nothing like that now, but, yes, the GUI environment does it all.
It's the same reason why tiling window managers never click for me -- all the applications I use all have their own "tiling" that ends up fighting with it. CLion, Firefox, Emacs, Discord, Slack, Teams... they've all got their own internal nav, with the expectation of a typical GUI environment.
All that said... Saying "just use Vim" is kind of missing the point. I (and others) hate modal editors, and if I liked them I would have used vi back in the day in the first place as it was always one very machine I shelled into. The modal editing thing as some sort of mark of superiority or pride... is a bit of a recent obsession of a subset of nerd culture that I don't get, nor do I care to. And I strongly disagree that "but a good editor" line; the editor in emacs is great. But no, it's not vi, and no, it's not windows/mac keybindings. You have to learn its keybindings and yanking and all that.
Does anyone really script VScode in the same way as emacs? It's trivial to knock-off a little function in emacs to scratch an itch, but in VScode there's so much boilerplate to create an extension.
Yeah, I agree, and I don't personally use VSCode. But it sorta fills a similar niche, I guess.
But it's missing the powerful buffer abstraction that makes emacs so special. An emacs buffer isn't just a text editor, it's an interactive working environment, a coding scratchpad, etc. closer to how old Smalltalk or Lisp environments worked. The same buffer concept can be simultaneously a terminal, a code editor, and a REPL.
But it's missing the powerful buffer abstraction that makes emacs so special. An emacs buffer isn't just a text editor, it's an interactive working environment, a coding scratchpad, etc. closer to how old Smalltalk or Lisp environments worked. The same buffer concept can be simultaneously a terminal, a code editor, and a REPL.
> The same buffer concept can be simultaneously a terminal, a code editor, and a REPL.
On the technical side, VS Code can do the same, and does it to some degree. I mean, it's a Web-browser in disguise, it can show anything you want. But overall there is indeed not much awareness for this and not many features and plugins supporting this. It simply has more order and control on this level.
But I guess it's also just one plugin away on changing this.
On the technical side, VS Code can do the same, and does it to some degree. I mean, it's a Web-browser in disguise, it can show anything you want. But overall there is indeed not much awareness for this and not many features and plugins supporting this. It simply has more order and control on this level.
But I guess it's also just one plugin away on changing this.
There isn't really an equivalent of things like emacs text overlays and text properties in VScode, which makes it difficult to build complicated functionality in the main editor. You have to use a web view for most nontrivial things.
> The modal editing thing as some sort of mark of superiority or pride... is a bit of a recent obsession of a subset of nerd culture that I don't get, nor do I care to.
I do agree that it's overblown. But I found the bindings more "sleek" for me personally. Vanilla Emacs keybinds seemed very odd to me, and was the biggest barrier to entry when I first looked at Emacs in high school. I appreciate projects like Doom that bring it all together in a neat and (more) intuitive package.
I do agree that it's overblown. But I found the bindings more "sleek" for me personally. Vanilla Emacs keybinds seemed very odd to me, and was the biggest barrier to entry when I first looked at Emacs in high school. I appreciate projects like Doom that bring it all together in a neat and (more) intuitive package.
But one can use both emacs and jetbrains. I get value from both and use vim's modal editing in both.
> Emacs is now nothing more than a glorified Org editor
I must admit that if it wasn’t for Org, I as a long-time Vim user wouldn’t be using Emacs :)
I must admit that if it wasn’t for Org, I as a long-time Vim user wouldn’t be using Emacs :)
Evil is a pretty good editor imo
Magit is still the best git client
Org mode is the killer feature of eMacs for sure, but there’s a little more to it.
It’s just arcane to work with or work on.
Magit is still the best git client
Org mode is the killer feature of eMacs for sure, but there’s a little more to it.
It’s just arcane to work with or work on.
Org mode cannot be overstated. I started using Org Roam for personal and work note taking in the middle of last year, and besides my daily logs, I have taken literally thousands of notes. Lots of which I actually use as references at a later time.
Org has been transformative for the way I think. I spend much more of my time reasoning instead of recalling now.
Org has been transformative for the way I think. I spend much more of my time reasoning instead of recalling now.
Nice! I just started using org roam this past month.
Honestly my favorite feature is the ui mode what shows the map all of the notes. Good fun watching that grow.
Got a syncthing setup going and it’s been great
Honestly my favorite feature is the ui mode what shows the map all of the notes. Good fun watching that grow.
Got a syncthing setup going and it’s been great
Dumb comment alert.
> GUIs and proprietary protocols have killed Emacs
I used it this morning. Dired, specifically. To look through files for a meeting. Used it yesterday to edit. Meh.
> GUIs and proprietary protocols have killed Emacs
I used it this morning. Dired, specifically. To look through files for a meeting. Used it yesterday to edit. Meh.
I think they meant more for horrible communications applications such as microsoft teams and all the others that don't use XMPP.
That makes more sense, ta
This is the article I wanted to write about Emacs. Bravo.
The comparison to a bicycle is a good one. Emacs is the only software I have ever truly loved. People throw that word around a lot these days, but I mean it. I love it in the same way I love my bicycle. My bicycle is a machine that I've carefully built and maintained, it's been with me through the years, to various places, in all weathers, good and bad, and, ultimately, it carries me to places. Emacs is the only software that comes close to feeling the same way.
I wonder if the analogy might be lost on people who don't have a bicycle or any machine like it, though.
The comparison to a bicycle is a good one. Emacs is the only software I have ever truly loved. People throw that word around a lot these days, but I mean it. I love it in the same way I love my bicycle. My bicycle is a machine that I've carefully built and maintained, it's been with me through the years, to various places, in all weathers, good and bad, and, ultimately, it carries me to places. Emacs is the only software that comes close to feeling the same way.
I wonder if the analogy might be lost on people who don't have a bicycle or any machine like it, though.
I think it’s a reference to the Steve Jobs quote about the computer being a bicycle of/for the mind.
Consistent navigation and keystroke commands for content/context-appropriate basic operations have really been the foundation of my use of the emacs. Yes, there's an elisp integration to everything and Magit is (perhaps..?) the best git client period, but boy ... For example, I have gotten so much mileage out of M-x comment-region across Java, bash, C++, XML. Using Ctrl-S to inc search a dired buffer in the same way I inc search text.
And I was delighted when I first used Eclipse to discover that 90% of the keystroke commands that have become muscle memory (nav, save, multilevel undo, block copy and paste...) are the same. Same with bash of course.
I wanted to love Emacs. It’s open, it’s kind if cool, apparently it does everything, Randy in the novel Cryptonomicon uses it.
But I soon spent more time and effort optimizing and working out the kinks in my personal org-roam than doing actual work.
Now I use good old project management software (Merlin for Mac), Obsidian / Apple for notes, and a written to-do list.
But I soon spent more time and effort optimizing and working out the kinks in my personal org-roam than doing actual work.
Now I use good old project management software (Merlin for Mac), Obsidian / Apple for notes, and a written to-do list.
Being clear that you should use what works for you, I always find these narratives amusing.
I'm assuming you still have kinks in your current workflow, with the difference that there is not much you can do about it? Such that the main difference is that you aren't working on the meta side of the workflow. But you could have done that before, too, right?
That is, it seems a lot of people have a story where their main complaint of Emacs comes down to the temptation of being able to do whatever is enough of a lure to keep them distracted.
I think I get this, in the sense that it is comforting to have some decisions flat out made for you.
I'm assuming you still have kinks in your current workflow, with the difference that there is not much you can do about it? Such that the main difference is that you aren't working on the meta side of the workflow. But you could have done that before, too, right?
That is, it seems a lot of people have a story where their main complaint of Emacs comes down to the temptation of being able to do whatever is enough of a lure to keep them distracted.
I think I get this, in the sense that it is comforting to have some decisions flat out made for you.
There’s the work.
Then there’s the meta-work. (planning the work: what to do; how to do it). This is me writing a to-do list on paper or someone else typing in org-mode. It also includes thinking about what to do.
Then there’s the meta-meta-work. Setting up clever ways to plan work. This is where you configure emacs and other systems or try to find the best system. There’s a lot of leverage here, but it should never be a continuous effort, unless you like getting paid in meta-meta-dollars.
Then there’s the meta-work. (planning the work: what to do; how to do it). This is me writing a to-do list on paper or someone else typing in org-mode. It also includes thinking about what to do.
Then there’s the meta-meta-work. Setting up clever ways to plan work. This is where you configure emacs and other systems or try to find the best system. There’s a lot of leverage here, but it should never be a continuous effort, unless you like getting paid in meta-meta-dollars.
Fair on it being "meta-meta." My point is you can always stop the search for the best system, though? Just because you can change or optimize, doesn't mean you have to.
Consider if you are doing written notes, have you learned a comprehensive shorthand system? Why not? Do you stick with only lined paper? Dotted paper or grid for some things? Is there an optimal sized sheet of paper for you? (Point being you can meta-meta work in most any setting. Nothing about Emacs requires that you do so.)
Consider if you are doing written notes, have you learned a comprehensive shorthand system? Why not? Do you stick with only lined paper? Dotted paper or grid for some things? Is there an optimal sized sheet of paper for you? (Point being you can meta-meta work in most any setting. Nothing about Emacs requires that you do so.)
True, I could just stop configuring emacs and use it as is.
But who does that?
Plus, it took significant work to get the behaviour close to what I expect, whereas an annual Moleskine notebook already has 100% of what I need for $20 and zero minutes of configuration.
Merlin costs CAD 240 / year but it works out of the box too.
But who does that?
Plus, it took significant work to get the behaviour close to what I expect, whereas an annual Moleskine notebook already has 100% of what I need for $20 and zero minutes of configuration.
Merlin costs CAD 240 / year but it works out of the box too.
Welcome back to the club. I've been using Emacs continuously for almost three decades, 99.9999% of the time text-only (whether Linux console, X terminal console, xterm, or SSH client) on a remote server. My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs. I tried Gnus a couple of times for Usenet but stayed with slrn because of Emacs's lack of multithreading. I've never tried Gnus for email because VM has always met my needs.
VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.
* sends URLs I select (all from the keyboard) to the web browser
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* searches my archived mail at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
VM isn't perfect. I'm sure that I could do all of the above with Gnus, and quite possibly am missing out on other features that VM lacks. Overall, though, I really feel like I have a superpower for email handling with it.
VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.
* sends URLs I select (all from the keyboard) to the web browser
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* searches my archived mail at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
VM isn't perfect. I'm sure that I could do all of the above with Gnus, and quite possibly am missing out on other features that VM lacks. Overall, though, I really feel like I have a superpower for email handling with it.
For me my "emacs" is my home-manager managed home directory. It's less monolithic, and yes, comprised of a bunch of random apps. But it's a thing I've crafted over years. I rock various apps with various configurations, but at this point it feels like home. I now ask, like a picky little diva, what OS I get to use at new jobs I apply for, because I don't want to rebuild my home.
I recognize that emacs can run on all operating systems, but my "home" extends out past my terminal, and my text editor. It includes random apps that just don't have an equivalent i.e. my browser, my music service, and my work issued chat app.
I like to be able to manage ALL of that all the same way, and I can with home-manager, nix and linux.
Someone tell me what I'm truly missing with emacs.
I recognize that emacs can run on all operating systems, but my "home" extends out past my terminal, and my text editor. It includes random apps that just don't have an equivalent i.e. my browser, my music service, and my work issued chat app.
I like to be able to manage ALL of that all the same way, and I can with home-manager, nix and linux.
Someone tell me what I'm truly missing with emacs.
If you are happy with what you have, you don't need to buy into other things.
Maybe a time will come in your life when you values align with emacs, maybe it wont. Keep an open mind when/if the event happens.
Maybe a time will come in your life when you values align with emacs, maybe it wont. Keep an open mind when/if the event happens.
hugoroy(1)
aj7(1)
inferense(2)
jmclnx(1)
In 2024 someone should write "A CEO's Guide to Obsidian".
A lot of tools that are commonly depended on today will change on their own schedule. Nice ones will give you warning ahead of time that a change is coming, but you can't opt out of the change. APIs get deprecated. UIs get reorganized. There's not much you can do. With emacs there's an expectation that what worked for you 20 years ago will still work today. And in rare instances where that's not true, you can just not upgrade to a newer version of emacs.
Working in emacs definitely gives a feeling of control. If anything is ever going to replace emacs (or neovim, which I don't use but I understand is similar), it will have to give the same feelings of control, in addition to the same sense of focus that comes from an uncluttered UI.