Buying into the Emacs Platform (2018)(two-wrongs.com)
two-wrongs.com
Buying into the Emacs Platform (2018)
https://two-wrongs.com/why-you-should-buy-into-the-emacs-platform
135 comments
> I see a lot of people who come to Emacs from Vim expecting Evil Mode to be the panacea for Emacs. It's not. At the end of the day, it's still Emacs
Yes. I've been Emacs guy for close to two decades now, and switched to Evil about four years ago, because Vim controls are just better, no two ways about it. However you still need to escape back into Emacs every now and then to do various un-Evil'd tidbits. That's easy for me, but would be problematic for someone who expects Evil to (as you put it) "fix Emacs".
Yes. I've been Emacs guy for close to two decades now, and switched to Evil about four years ago, because Vim controls are just better, no two ways about it. However you still need to escape back into Emacs every now and then to do various un-Evil'd tidbits. That's easy for me, but would be problematic for someone who expects Evil to (as you put it) "fix Emacs".
I had a similar path to Emacs: became really proficient with Vim, avoided Emacs since everyone I knew hated it, saw someone doing things with incredible speed and efficiency in Emacs at Enova (hi Kyle) that I had never imagined could be done, tried Emacs myself, and spent weeks customizing it to become extremely fast with rapid development in Clojure using CIDER.
But now that I do vanilla front-end dev, I have found VS Code to give me nearly all the same productivity I had before, but with practically no configuration, and in an editor that actually has reasonable per-pixel scrolling. (Emacs added per-pixel scrolling in 2017 but still got it wrong somehow.)
But now that I do vanilla front-end dev, I have found VS Code to give me nearly all the same productivity I had before, but with practically no configuration, and in an editor that actually has reasonable per-pixel scrolling. (Emacs added per-pixel scrolling in 2017 but still got it wrong somehow.)
What is the utility of per-pixel scrolling in a text editor?
In some mysterious psychological way that I don't fully understand, per-pixel scrolling helps me to mentally keep my place significantly faster and easier than per-line scrolling.
It's just pleasant to have. I sometimes scroll text with touchpad and it's never a good experience in Emacs.
Similar to the two sibling posters, I find pixel-scrolling (particular with the weighted momentum feeling you get on macos) to be more visually comfortable and easier to track.
I found it frustrating in spacemacs that I couldn't get this set up properly (and I'm not even sure if it's possible too). Everything else in emacs was eye-opening and fun.
I found it frustrating in spacemacs that I couldn't get this set up properly (and I'm not even sure if it's possible too). Everything else in emacs was eye-opening and fun.
Being a vim guy myself, I only use Emacs (Spacemacs, to be precise, so as to get rid of all those a-x a-y a-z a-m-s-x type shortcuts and replace them with something ergonomic) as a git client - because Magit is the best git client out there.
I’ve tried using Spacemacs as a main editor for a while, but it’s too much of a mess, and if anything goes wrong (and it often does) you’re stuck with obscure lisp tracebacks, thanks but no thanks, I’ll use vim or kak as the actual text editor. I also noticed I spent an enormous amount of time constantly tweaking my spacemacs config as opposed to doing actual work.
I’ve tried using Spacemacs as a main editor for a while, but it’s too much of a mess, and if anything goes wrong (and it often does) you’re stuck with obscure lisp tracebacks, thanks but no thanks, I’ll use vim or kak as the actual text editor. I also noticed I spent an enormous amount of time constantly tweaking my spacemacs config as opposed to doing actual work.
if anything goes wrong (and it often does) you’re stuck with obscure lisp tracebacks
Is Spacemacs really that broken? I use the same GNU Emacs configuration across Windows, FreeBSD, Ubuntu, CentOS, and macOS, along with packages like tramp, magit, slime, and python-mode, and the worst thing that's happened in recent memory is that either jinja2-mode or salt-mode (I forget which) doesn't indent things the way I like.
Is Spacemacs really that broken? I use the same GNU Emacs configuration across Windows, FreeBSD, Ubuntu, CentOS, and macOS, along with packages like tramp, magit, slime, and python-mode, and the worst thing that's happened in recent memory is that either jinja2-mode or salt-mode (I forget which) doesn't indent things the way I like.
Spacemacs is that broken. The problem is that Spacemacs tries to impose its own shortcuts onto other emacs packages that may or may not know about spacemacs. For modes that perform extensive customization of their own, spacemacs alterations to emacs can result in some very weird behavior. For example, markdown-mode's highlighting, will, for mysterious reasons break when used with spacemacs [1].
The other problem with spacemacs is that if you're trying to use another emacs package, now you have to look up two sets of documentation. You have to look up the package's documentation to find the command that you want to execute, and then you have to look up the documentation for the relevant spacemacs layer to figure out what spacemacs has remapped the command to.
I tried to use spacemacs as a transition path from vim to emacs, but I found that I had much more success by just "ripping off the bandaid", remapping caps-lock to ctrl and spending a weekend forcing myself to relearn how to perform my most commonly used vim commands in emacs.
[1]: https://github.com/syl20bnr/spacemacs/issues/11790
The other problem with spacemacs is that if you're trying to use another emacs package, now you have to look up two sets of documentation. You have to look up the package's documentation to find the command that you want to execute, and then you have to look up the documentation for the relevant spacemacs layer to figure out what spacemacs has remapped the command to.
I tried to use spacemacs as a transition path from vim to emacs, but I found that I had much more success by just "ripping off the bandaid", remapping caps-lock to ctrl and spending a weekend forcing myself to relearn how to perform my most commonly used vim commands in emacs.
[1]: https://github.com/syl20bnr/spacemacs/issues/11790
I also have had issues getting Spacemacs up and running (with Windows), what has worked better for me as a Vim user is to just use vanilla emacs and install the evil vim mode plugin only.
That's what I like about doom-emacs. It's also Evil experience, but without bloat.
Have you looked at Vimagit? I haven't used it but it's supposed to imitate magit in Vim.
Sadly, it's not even close.
* Spacemacs, to be precise, so as to get rid of all those
Are you aware of Emacs with evil mode (i.e., Extensible VI Layer)?
* https://www.emacswiki.org/emacs/Evil
Are you aware of Emacs with evil mode (i.e., Extensible VI Layer)?
* https://www.emacswiki.org/emacs/Evil
Spacemacs uses Evil (and adds a lot of stuff (or bloat, depending on your point of view).
There's also Evil-collection which aims to better integrate Evil with a lot of other packages and features.
There's also Evil-collection which aims to better integrate Evil with a lot of other packages and features.
If Spacemacs is broken, not using Spacemacs sounds like a good solution. Juse Emacs' standard keybindings, they're easy enough to learn.
No thanks.
I've had several bouts of trying to learn emacs throughout my life.
It isn't necessary to list all the benefits, sure, there's a lot. Yes, I get it's "extensible" and you can write little elisp programs to do just what you want.
Here's the obstacle: Motor skills. It just takes way to long to first memorize reams of commands and then to train your fingers to issue those commands effortlessly. In the meantime, searching, "apropos" and googling stuff isn't an attractive thing to do when you have _actual_ work to do.
That's a serious obstacle and no listing of all the awesome-ness of emacs is going to convince many of us to put in that kind of effort.
I've had several bouts of trying to learn emacs throughout my life.
It isn't necessary to list all the benefits, sure, there's a lot. Yes, I get it's "extensible" and you can write little elisp programs to do just what you want.
Here's the obstacle: Motor skills. It just takes way to long to first memorize reams of commands and then to train your fingers to issue those commands effortlessly. In the meantime, searching, "apropos" and googling stuff isn't an attractive thing to do when you have _actual_ work to do.
That's a serious obstacle and no listing of all the awesome-ness of emacs is going to convince many of us to put in that kind of effort.
> isn't an attractive thing to do when you have _actual_ work to do.
Leaning any new tool when you have work to do is never an attractive thing. Whether that's an editor, a language, an issue tracker, or any tool. There is always a period of learning that is less productive, but the hope is that after learning the new tool your overall productivity is higher, resulting is more gains in the long run.
Emacs out of box comes with menus and toolbars (underrated features) to accomplish most basic commands, so you shouldn't have to memorize a whole bunch of stuff to start being modestly productive. I think it's way ahead of vim in these regards, you don't have to learn a whole new paradigm of "modal editing" to get even the basics done.
Leaning any new tool when you have work to do is never an attractive thing. Whether that's an editor, a language, an issue tracker, or any tool. There is always a period of learning that is less productive, but the hope is that after learning the new tool your overall productivity is higher, resulting is more gains in the long run.
Emacs out of box comes with menus and toolbars (underrated features) to accomplish most basic commands, so you shouldn't have to memorize a whole bunch of stuff to start being modestly productive. I think it's way ahead of vim in these regards, you don't have to learn a whole new paradigm of "modal editing" to get even the basics done.
In my experience it was about 3-4 weeks of forcing 100% use before vim became more effective than regular text editing, but a lot of the pain was gone after ~1.5 weeks.
Then you know it for life. Unquestionably worth it.
Then you know it for life. Unquestionably worth it.
It only took me like a week to get used to vim. I obviously still don't use it to its full capabilities but i can use it like a normal text editor now.
Emacs by comparison makes no sense to me.
Emacs by comparison makes no sense to me.
The vim operation+movement paradigm is pretty intuitive once you grok it. I’m not really sure if I ever “got” emacs.
I had a similar experience to yours until I realized that the extensible part also means you don't need to use the builtin commands and shortcuts. I have been using emacs for 10 years (used vim for about 12 before that, using emacs with evil-mode now) and, to this day, I have to google 'how to quit emacs' when I am faced with a vanilla emacs :)
I just feel it's "my" editor more than any other editor I've ever used.
edit: typos
I just feel it's "my" editor more than any other editor I've ever used.
edit: typos
> I just feel it's "my" editor more than any other editor I've ever used.
So true! When I first tried to get into Emacs it was as a somewhat seasoned programmer who wanted to play with a Lisp other than Scheme. I've read the built-in tutorial and almost ran away in horror. I get it - for non-programmer users, yes, it makes sense to try to teach them the usage of an editor. I lost quite a lot of time trying to remember exotic chords like C-u C-x ^ a and so on, but it was ultimately meaningless - not one such shortcut remains in my config.
Emacs is an IDE for Emacs Lisp written in Emacs Lisp (and it's incredibly powerful at that, BTW). In other words, it's a bunch of APIs you can call, and it also gives you the place where you can interactively execute any elisp code and see the effects immediately in the same instance of the editor. It's obvious in hindsight, but I believe I'd get into Emacs much faster if I started with Emacs Lisp manual or maybe "Writing GNU Emacs Extensions" book instead of going through the Emacs manual (huuuuuge!) first and trying to bend my habits to fit the vanilla Emacs.
I think most programmers who wish to switch to Emacs should try to do it the other way: start with learning Elisp syntax and Paredit, then learn about modes, hooks, and key-maps and start hacking your own config. Everything else - buffers, windows, fringes, faces, what-have-you - you'll learn as needed when you need to implement a particular command which deals with them. Pull in a healthy amount of plugins then read their source - or just read the source of Emacs, as you can jump to definition of any function in one click, even if it's written in C - and before long you'll have a comfortable environment to work in, with all the features you learned to love from your previous editor. And that's when the fun part start: exploring Emacs features that you've never seen or heard about, wrapping external tools and streamlining their workflows, exploring the huge pile of add-ons.
So true! When I first tried to get into Emacs it was as a somewhat seasoned programmer who wanted to play with a Lisp other than Scheme. I've read the built-in tutorial and almost ran away in horror. I get it - for non-programmer users, yes, it makes sense to try to teach them the usage of an editor. I lost quite a lot of time trying to remember exotic chords like C-u C-x ^ a and so on, but it was ultimately meaningless - not one such shortcut remains in my config.
Emacs is an IDE for Emacs Lisp written in Emacs Lisp (and it's incredibly powerful at that, BTW). In other words, it's a bunch of APIs you can call, and it also gives you the place where you can interactively execute any elisp code and see the effects immediately in the same instance of the editor. It's obvious in hindsight, but I believe I'd get into Emacs much faster if I started with Emacs Lisp manual or maybe "Writing GNU Emacs Extensions" book instead of going through the Emacs manual (huuuuuge!) first and trying to bend my habits to fit the vanilla Emacs.
I think most programmers who wish to switch to Emacs should try to do it the other way: start with learning Elisp syntax and Paredit, then learn about modes, hooks, and key-maps and start hacking your own config. Everything else - buffers, windows, fringes, faces, what-have-you - you'll learn as needed when you need to implement a particular command which deals with them. Pull in a healthy amount of plugins then read their source - or just read the source of Emacs, as you can jump to definition of any function in one click, even if it's written in C - and before long you'll have a comfortable environment to work in, with all the features you learned to love from your previous editor. And that's when the fun part start: exploring Emacs features that you've never seen or heard about, wrapping external tools and streamlining their workflows, exploring the huge pile of add-ons.
This is excellent advice. I may make another go at it.
Like you, I've tried before. After a day or two of trying to remember alt-command-blah-blah-blah every time I wanted to do something simple, I gave up. Then I started mousing around which totally defeated the purpose of trying to pick it up.
I also found (at least 7-8 years ago) the windows Emacs to be terribly slow. Hopefully that's not still true. That also effectively kills the learning experience after a while.
Like you, I've tried before. After a day or two of trying to remember alt-command-blah-blah-blah every time I wanted to do something simple, I gave up. Then I started mousing around which totally defeated the purpose of trying to pick it up.
I also found (at least 7-8 years ago) the windows Emacs to be terribly slow. Hopefully that's not still true. That also effectively kills the learning experience after a while.
> alt-command-blah-blah-blah
C-h f
And then I type sort of what I want (with helm or ivy, it's a fuzzy match) and select it from the list, which brings up it's documentation and what keystrokes call it.
There is also `where-is` if you remember the name, or `M-x` (or `M-:`) if you don't mind typing it out.
C-h f
And then I type sort of what I want (with helm or ivy, it's a fuzzy match) and select it from the list, which brings up it's documentation and what keystrokes call it.
There is also `where-is` if you remember the name, or `M-x` (or `M-:`) if you don't mind typing it out.
I’ve basically used Hydra (as opposed to Evil) for creating a series of mappings that make sense for me.
How to quit vanilla emacs: select “Quit” under the File menu.
If you’re using macOS, you can also select “Quit Emacs” under the application “Emacs” menu, like every other macOS app.
If that wasn’t an option for you, very likely you’re not in vanilla emacs, or you’re in a particularly ancient emacs (which happens, but is as easily avoidable as using vim, VS, Sublime, etc.)
If you’re using macOS, you can also select “Quit Emacs” under the application “Emacs” menu, like every other macOS app.
If that wasn’t an option for you, very likely you’re not in vanilla emacs, or you’re in a particularly ancient emacs (which happens, but is as easily avoidable as using vim, VS, Sublime, etc.)
> Here's the obstacle: Motor skills. It just takes way to long to first memorize reams of commands and then to train your fingers to issue those commands effortlessly.
Do you know VI? You can use viper-mode and use it as VI. And it's not a handful of keystrokes as the likes of Eclipse implement, it's a full blown VI mode.
Your comment about "apropos" tells me you have never ever tried Emacs help system. There is a nifty tutorial, you can search for commands, functions, what have you. Need to know what happens when you type a keystroke, even down to the source code if you want? describe-key. Need to know anything about your enabled modes? describe-mode. And so on. There are more describe commands, but I never had to memorize them due to completion.
The only times I feel like using something like VSCode are:
– Learning a new and popular language: as of late, you can find nice extensions which sometimes even integrate installation of external commands, so you have a working system out of the box. Since I'm learning, I don't yet know what I need. This use-case is diminishing as of late due to Spacemacs.
– When I feel the need to have something "fancier" in terms of UI widgets. For instance, the popup golang help that VSCode provides is less disruptive than having a pop-up buffer. This is just a case of being attracted to eye-candy, which the exclusively text-based does not provide by design (although it can display graphics to some extent).
That's it. I always end up going back to Emacs as it provides so much more. And specially when interacting with Git, Magit is wonderful and far better than any applications I have seen - including the command line. Org-mode is always at my fingertips.
One thing though. If you are unwilling to learn Emacs because you are happy with your environment and you have other priorities, that's perfectly fine. If you are unwilling to learn Emacs _even though you feel that there are benefits_, then that's not a good sign. We need to learn new things all the time to stay relevant and productive. If there is a new tool, language or process that will improve your professional life, you are doing a disservice to yourself by refusing to learn.
Do you know VI? You can use viper-mode and use it as VI. And it's not a handful of keystrokes as the likes of Eclipse implement, it's a full blown VI mode.
Your comment about "apropos" tells me you have never ever tried Emacs help system. There is a nifty tutorial, you can search for commands, functions, what have you. Need to know what happens when you type a keystroke, even down to the source code if you want? describe-key. Need to know anything about your enabled modes? describe-mode. And so on. There are more describe commands, but I never had to memorize them due to completion.
The only times I feel like using something like VSCode are:
– Learning a new and popular language: as of late, you can find nice extensions which sometimes even integrate installation of external commands, so you have a working system out of the box. Since I'm learning, I don't yet know what I need. This use-case is diminishing as of late due to Spacemacs.
– When I feel the need to have something "fancier" in terms of UI widgets. For instance, the popup golang help that VSCode provides is less disruptive than having a pop-up buffer. This is just a case of being attracted to eye-candy, which the exclusively text-based does not provide by design (although it can display graphics to some extent).
That's it. I always end up going back to Emacs as it provides so much more. And specially when interacting with Git, Magit is wonderful and far better than any applications I have seen - including the command line. Org-mode is always at my fingertips.
One thing though. If you are unwilling to learn Emacs because you are happy with your environment and you have other priorities, that's perfectly fine. If you are unwilling to learn Emacs _even though you feel that there are benefits_, then that's not a good sign. We need to learn new things all the time to stay relevant and productive. If there is a new tool, language or process that will improve your professional life, you are doing a disservice to yourself by refusing to learn.
I'm not sure why you're recommending viper mode when evil exists.
Personally I like to bind virtually everything to a sequence of keys starting with a leader key instead of control this alt that coltrol the other thing.
Hydras further provide an attractive discoverable menu to remind you of what options are available.
Major mode hydra let's you define a hydra per mode and pops up the correct one based on the mode you are in.
https://github.com/jerrypnz/major-mode-hydra.el/blob/master/...
A useful thing is that it's possible on all major platforms to bind modifier keys like for example shift to produce a different symbol when pressed and released instead of held in combination with another key.
https://gist.github.com/tanyuan/55bca522bf50363ae4573d4bdcf0...
This means that for example you could use left shift to start global sequences and right shift for mode specific operations preferring short sequences for common operations.
Example lshift -> b switch buffers lshift -> f r find recent files
Because these can be bound to unused global keys example f13 if your keyboard lacks such they can be bound globally and work everywhere regardless of mode or with or without evil.
Because of the friendly visual indication see the pictures of major mode hydra even if you don't recall a binding you don't need apropos to find it.
For functionality that you haven't bound fuzzy matching makes it easy to find said functionality and call it in one step.
Hydras further provide an attractive discoverable menu to remind you of what options are available.
Major mode hydra let's you define a hydra per mode and pops up the correct one based on the mode you are in.
https://github.com/jerrypnz/major-mode-hydra.el/blob/master/...
A useful thing is that it's possible on all major platforms to bind modifier keys like for example shift to produce a different symbol when pressed and released instead of held in combination with another key.
https://gist.github.com/tanyuan/55bca522bf50363ae4573d4bdcf0...
This means that for example you could use left shift to start global sequences and right shift for mode specific operations preferring short sequences for common operations.
Example lshift -> b switch buffers lshift -> f r find recent files
Because these can be bound to unused global keys example f13 if your keyboard lacks such they can be bound globally and work everywhere regardless of mode or with or without evil.
Because of the friendly visual indication see the pictures of major mode hydra even if you don't recall a binding you don't need apropos to find it.
For functionality that you haven't bound fuzzy matching makes it easy to find said functionality and call it in one step.
Abo-abo's Emacs packages are truly fantastic. One that I personally love is Ivy-mode (with Counsel and Swiper): https://github.com/abo-abo/swiper
He is the shit. I have several times independently discovered something nice to discover it was yet another contribution.
I understand that your experience is yours but I also believe that you might be going about it the wrong way.
First, you don't REALLY need to know anything but Meta-X and Control-XS, Control-XF, Control-XC to get going. Those aren't really that hard to remember or make muscle memory for, IMO. It IS hard to have to go back a bit to re-integrate how to do things in a new way if you're already happy with your existing workflow, so if there's no value for you, then... don't use it. Use whatever works for you.
First, you don't REALLY need to know anything but Meta-X and Control-XS, Control-XF, Control-XC to get going. Those aren't really that hard to remember or make muscle memory for, IMO. It IS hard to have to go back a bit to re-integrate how to do things in a new way if you're already happy with your existing workflow, so if there's no value for you, then... don't use it. Use whatever works for you.
I would like to add control-g to the list. It is frustrating for new emacs users that it can be easy to get stuck. Control-g is the general "quit" which will get you back to editing text from most annoying situations.
Mashing ESC also works.
ESC ESC ESC (translated from <escape> <escape> <escape>) runs the command keyboard-escape-quit (found in global-map), which is an interactive compiled Lisp function in ‘simple.el’.
ESC ESC ESC (translated from <escape> <escape> <escape>) runs the command keyboard-escape-quit (found in global-map), which is an interactive compiled Lisp function in ‘simple.el’.
Yes, I definitely missed that one. Good catch.
That's how I feel about Visual Studio Code. I've tried it several times, and it's fine for what it is, but I don't see how it's worth it to relearn to do the Visual Studio Code way all the things I currently do the Emacs way.
Furthermore, there's little to no chance of me being able to type up a little program in Visual Studio Code, eval it on the fly, and add it to my config instantly. You have to write a plugin, because of the model the editor uses for extensions. And that's the difference between an extensible editor and an editor for which extension is an integral part of the workflow.
And virtually no other editor or IDE I know of has the equivalent of M-.
Furthermore, there's little to no chance of me being able to type up a little program in Visual Studio Code, eval it on the fly, and add it to my config instantly. You have to write a plugin, because of the model the editor uses for extensions. And that's the difference between an extensible editor and an editor for which extension is an integral part of the workflow.
And virtually no other editor or IDE I know of has the equivalent of M-.
> Here's the obstacle: Motor skills. It just takes way to long to first memorize reams of commands and then to train your fingers to issue those commands effortlessly.
You don't have to use the builtin keys. I don't. There is Spacemacs, evil mode, etc. so you can use VI keys if it works better for you.
Emacs is about making it work like you want. Emacs adapts to you, not the other way around.
You don't have to use the builtin keys. I don't. There is Spacemacs, evil mode, etc. so you can use VI keys if it works better for you.
Emacs is about making it work like you want. Emacs adapts to you, not the other way around.
The time investment is worth it. Once you ease into the keybindings you rarely think about it, well at least for the most common things you do.
The single greatest thing about Emacs is the robust basic modes, which most other modes extend from. So far I haven't used anything as good, although I feel the gap is lessening with VSCode.
I really dislike switching between mouse and keyboard. Emacs's consistency and mouse-free operation speaks to my heart the same way Mark Zuckerberg wears the same shirt every day, it's one less thing to think about, and that's why I love it.
The single greatest thing about Emacs is the robust basic modes, which most other modes extend from. So far I haven't used anything as good, although I feel the gap is lessening with VSCode.
I really dislike switching between mouse and keyboard. Emacs's consistency and mouse-free operation speaks to my heart the same way Mark Zuckerberg wears the same shirt every day, it's one less thing to think about, and that's why I love it.
Spacemacs is better about this, it shows possible continuations while you issue the command. Not to mention that vim keybindings are much saner.
This being said, I've abandoned Spacemacs for VSCode (with amVim). I feel really diety about this, but at least "jump to definition/declaration" in C++ works like it should.
This being said, I've abandoned Spacemacs for VSCode (with amVim). I feel really diety about this, but at least "jump to definition/declaration" in C++ works like it should.
Have you tried https://github.com/emacs-lsp/lsp-mode which works with C++ ?
Thanks, but I finally managed to get CLion to work with the compilation database I manually generate from a Rube Goldberg build system I use at work, so I might just stick with that.
To me the serious obstacle that vanilla emacs is not that powerful at all.
The article lists over 20 extensions you need to install to "feel the power". And every emacs user will have their own set of extensions, carefully curated. Everyone ends up with rather huge init.el setups with increasingly bizarre and arcane settings.
After over two years of using emacs and a 437-line init.el[1] of my own I gave up when one day it stopped properly displaying cyrllic text in jabber.el and some extension minor update broke something major.
[1] https://gist.github.com/dmitriid/4078311
The article lists over 20 extensions you need to install to "feel the power". And every emacs user will have their own set of extensions, carefully curated. Everyone ends up with rather huge init.el setups with increasingly bizarre and arcane settings.
After over two years of using emacs and a 437-line init.el[1] of my own I gave up when one day it stopped properly displaying cyrllic text in jabber.el and some extension minor update broke something major.
[1] https://gist.github.com/dmitriid/4078311
>And every emacs user will have their own set of extensions, carefully curated.
You'll find a lot of common extensions amongst power users. If you browse Emacs blog posts often, you'll see the same names popping up. For an overall view, I recommend Sacha Chua's weekly Emacs news:
https://sachachua.com/blog/2019/06/2019-06-03-emacs-news/
And BTW, a number of the extensions listed on this submission (Org mode, calc, dired, etc) come packaged with Emacs - although for Org mode I really would recommend installing a more up to date version.
To keep your init.el sane, I strongly recommend you keep your init file as an org mode file and use org-babel-load-file to load it. My init file is probably 1500 lines long, but it's very well organized as an org mode file.
You'll find a lot of common extensions amongst power users. If you browse Emacs blog posts often, you'll see the same names popping up. For an overall view, I recommend Sacha Chua's weekly Emacs news:
https://sachachua.com/blog/2019/06/2019-06-03-emacs-news/
And BTW, a number of the extensions listed on this submission (Org mode, calc, dired, etc) come packaged with Emacs - although for Org mode I really would recommend installing a more up to date version.
To keep your init.el sane, I strongly recommend you keep your init file as an org mode file and use org-babel-load-file to load it. My init file is probably 1500 lines long, but it's very well organized as an org mode file.
You provided a “yet another list if extensions” (from literally hundreds of such lists).
Nearly every single one of those extensions needs to be set up, configured or tweaked in a certain way (the ways differ from extension to extension and how to tweak/configure them can often be found only after some rigorous googling).
And so, you end up with an init.el which is 1500 lines long (which is a magnitude more than some of my standalone production code :) ) or more (I’ve seen some huge monstrosities).
So in my case this led to a sort of fatigue in the end, and I gave up.
Nearly every single one of those extensions needs to be set up, configured or tweaked in a certain way (the ways differ from extension to extension and how to tweak/configure them can often be found only after some rigorous googling).
And so, you end up with an init.el which is 1500 lines long (which is a magnitude more than some of my standalone production code :) ) or more (I’ve seen some huge monstrosities).
So in my case this led to a sort of fatigue in the end, and I gave up.
I would definitely say that if you're looking for an editor where everything just works to your satisfaction with minimal tweaking, then Emacs is not for you.
I do think you have cause and effect mixed up here. I have customized a lot of stuff because I can. With most other editors/IDEs, I'm stuck. Yes, their configs are much shorter, but only because there is very little to configure over there. I switched to Emacs because with every other editor I used, there was something that really annoyed me and I didn't want to live with it.
>So in my case this led to a sort of fatigue in the end, and I gave up.
You were probably trying to do too much too fast. My init.el evolved over a decade. I'm sure I spent a lot less than 1% of my overall time on Emacs tweaking it. Probably not even 0.1%. I did an initial setup, and started using it for real work. Every so many months, I'd read about a new package and decide to try it out.
>You provided a “yet another list if extensions” (from literally hundreds of such lists).
When you say that, I can tell you're not even trying, given how I explained why this is not just another list of extensions.
To give you an analogy, there are hundreds/thousands of lists out there on productivity apps for Android. Yet you're not going to get even hundreds of different apps listed there. There are hundreds of sites listing the best image editing software, yet that doesn't mean you'll find hundreds of image editing programs listed.
And really, if you feel like you're drowning in those lists, then just don't look at them. I don't read Sacha's Emacs news every week. Life gets busy, and I ignore it for months at a time. Every once in a while, when work is slow, I go to it to see if I can learn something new.
Emacs is a platform. Don't view it as "configuring". View it as installing useful apps. When I first installed Linux, it was "Holy cow! The package manager has so much software!" Saying there are too many packages out there for Emacs is like saying there are too many packages out there for Linux.
I do think you have cause and effect mixed up here. I have customized a lot of stuff because I can. With most other editors/IDEs, I'm stuck. Yes, their configs are much shorter, but only because there is very little to configure over there. I switched to Emacs because with every other editor I used, there was something that really annoyed me and I didn't want to live with it.
>So in my case this led to a sort of fatigue in the end, and I gave up.
You were probably trying to do too much too fast. My init.el evolved over a decade. I'm sure I spent a lot less than 1% of my overall time on Emacs tweaking it. Probably not even 0.1%. I did an initial setup, and started using it for real work. Every so many months, I'd read about a new package and decide to try it out.
>You provided a “yet another list if extensions” (from literally hundreds of such lists).
When you say that, I can tell you're not even trying, given how I explained why this is not just another list of extensions.
To give you an analogy, there are hundreds/thousands of lists out there on productivity apps for Android. Yet you're not going to get even hundreds of different apps listed there. There are hundreds of sites listing the best image editing software, yet that doesn't mean you'll find hundreds of image editing programs listed.
And really, if you feel like you're drowning in those lists, then just don't look at them. I don't read Sacha's Emacs news every week. Life gets busy, and I ignore it for months at a time. Every once in a while, when work is slow, I go to it to see if I can learn something new.
Emacs is a platform. Don't view it as "configuring". View it as installing useful apps. When I first installed Linux, it was "Holy cow! The package manager has so much software!" Saying there are too many packages out there for Emacs is like saying there are too many packages out there for Linux.
In that configuration, would your "real" init.el file still exist? Is the org-mode init invoked from the 'real' init.el?
Yes. You execute the org-babel-load-file function in your real init.el, while keeping almost all of your config in that org file.
Mostly this article, in addition to hearing about how good emacs is from various others, I want to try emacs. On that note, what you're saying sounds really useful - my .vimrc file is organized by folds to due to it's size. However, as a ~30min old emacs user, I have no idea how do do what you said. For example, is there a way to 'org-babel-load-file' when I open my init.el? When I try it by pressing M-x org-babel-load-file then typing ~/.emacs.d/init.el, I get a message "Wrong type argument: stringp, nil"
edit: would you mind posting a sample of your init.el file so I can see how you organize it?
edit: would you mind posting a sample of your init.el file so I can see how you organize it?
This is the line in my .init file:
(org-babel-load-file "/path/to/config/emacsconfig.org")
* Behavior
** Make Unique Buffer Names
When two files of the same names are open, make the buffer names nicer.
#+BEGIN_SRC emacs-lisp
(require 'uniquify)
(setq uniquify-buffer-name-style 'reverse)
(setq uniquify-separator "/")
(setq uniquify-after-kill-buffer-p t)
(setq uniquify-ignore-buffers-re "^\\*")
#+END_SRC
** Prevent Shell Prompt from going to the bottom of buffer
#+BEGIN_SRC emacs-lisp
;; Prevent shell prompt from always going to the bottom of the window!
(remove-hook 'comint-output-filter-functions
'comint-postoutput-scroll-to-bottom)
#+END_SRC
*** Emacs Template for Source Code Blocks
I just type <se at the beginning of a line and it gives a source block
of Emacs lisp
#+BEGIN_SRC emacs-lisp
;; Make a template for emacs lisp.
(setq org-structure-template-alist
(cons '("se" "#+BEGIN_SRC emacs-lisp \n?\n#+END_SRC\n" "<src
lang=\"emacs-lisp\">\n?\n</src>")
org-structure-template-alist))
#+END_SRC
> To me the serious obstacle that vanilla emacs is not that powerful at all.
There is no such thing as "vanilla" Emacs. Treat the scripts installed out of the box as a suggestion only.
> Everyone ends up with rather huge init.el setups with increasingly bizarre and arcane settings.
That's called customization. Those little warts are small tweaks done over time to tailor the editor to your liking.
The other warts can be removed by using something such as spacemacs. You can install a whole lot of packages nicely configured by adding a single line.
I threw away double digit megabytes of scripts (because I was vendoring everything before ELPA) for Spacemacs and haven't looked back.
There is no such thing as "vanilla" Emacs. Treat the scripts installed out of the box as a suggestion only.
> Everyone ends up with rather huge init.el setups with increasingly bizarre and arcane settings.
That's called customization. Those little warts are small tweaks done over time to tailor the editor to your liking.
The other warts can be removed by using something such as spacemacs. You can install a whole lot of packages nicely configured by adding a single line.
I threw away double digit megabytes of scripts (because I was vendoring everything before ELPA) for Spacemacs and haven't looked back.
Very nice list, thank you for the writeup and for sharing this!
One interesting thing about the Emacs modes listed here is that many one of them are by themselves already enough to justify the use of Emacs for at least someone in specific application domains.
For example, there are statisticians who do not use much of the breadth of Emacs, except for the listed ESS mode, and who do a lot of their work in that mode. The same for magit, Org mode, calc, dired, Tramp and others.
In addition to this richness in features and flexibility, a major attraction of Emacs is that switching between all these aspects is instantaneous.
One interesting thing about the Emacs modes listed here is that many one of them are by themselves already enough to justify the use of Emacs for at least someone in specific application domains.
For example, there are statisticians who do not use much of the breadth of Emacs, except for the listed ESS mode, and who do a lot of their work in that mode. The same for magit, Org mode, calc, dired, Tramp and others.
In addition to this richness in features and flexibility, a major attraction of Emacs is that switching between all these aspects is instantaneous.
And with org-mode you can start to weave them together using the source blocks! I’ve been doing a fair bit of numerical code lately, and being able to have a Maxima repl, org, and my C source all in the same place has been amazing.
I used Emacs for 15 years. I've been off of Emacs for about 5-6 years now and I won't ever go back.
Here's why:
1. Refactoring. The refactorings in IntelliJ are amazing. Amazing. The ability to say (yeah, this class is now called Foo instead of Bar) and have everything automatically changed is outstanding. This is a basic example of course but you can also do things like remove a function parameter, and also do things like lookup reverse symbols.
2. Stable. IntelliJ is just amazingly stable. Part of this is that I had to write elisp to get Emacs to do stuff that IntellJ just already provides for me. Everytime Emacs would upgrade I would have to upgrade Emacs.
3. Pair programming. I could NEVER work with other engineers on their code and vice versa. We just didn't speak the same language.
Now mind you I also created a lot of the code you use in Emacs. I co-created EDE for example.
Here's why:
1. Refactoring. The refactorings in IntelliJ are amazing. Amazing. The ability to say (yeah, this class is now called Foo instead of Bar) and have everything automatically changed is outstanding. This is a basic example of course but you can also do things like remove a function parameter, and also do things like lookup reverse symbols.
2. Stable. IntelliJ is just amazingly stable. Part of this is that I had to write elisp to get Emacs to do stuff that IntellJ just already provides for me. Everytime Emacs would upgrade I would have to upgrade Emacs.
3. Pair programming. I could NEVER work with other engineers on their code and vice versa. We just didn't speak the same language.
Now mind you I also created a lot of the code you use in Emacs. I co-created EDE for example.
Even if you don't use emacs for coding Java, etc. it can be still useful, e.g note taking, task management with org mode.
Java is more like assembly language programming at this point in software history.
You shouldn't be editing Java with any editor, let alone emacs.
This is because if you are using 3 frameworks, and 30 classes with DI and reflection, just to post a json to a http end point, you should be using an IDE to handle that kind of madness.
You shouldn't be editing Java with any editor, let alone emacs.
This is because if you are using 3 frameworks, and 30 classes with DI and reflection, just to post a json to a http end point, you should be using an IDE to handle that kind of madness.
That's more of an architecture problem rather than an intrinsic characteristic of Java though. I'm not a fan of the language, but I think the latest versions added some nifty features that make working with the language not as bad as it used to be.
I'm using Emacs for my daily tasks, both writing and programming. One question I have to more experienced Emacs users: Can you recommend an email client? It needs to be able to display html mails. Currently, I use claws-mail and am fairly happy with it, except for the search. I've got about 30,000 mails in the inbox and full-text searching them takes too long.
Is there a way to transition my claws-mail folders to Emacs, or ideally use both programs at the same time for a while?
The article recommends notmuch-emacs. But I'm afraid of 2 things, (i) loosing existing mails in the transition (due to e.g. faulty conversion tools), and (ii) that after a complicated transition I'm not happy with the new setup. Any recommendations? Is it possible to use the claws-mail email inboxes directly in Emacs?
Another thing is org-mode. I never really managed to get deep enough into it to really see the benefits. I've even bought the printed org-mode manual, but the setup seems so complicated. Can someone recommend a good "light" tutorial for it? What are you using it for?
Is there a way to transition my claws-mail folders to Emacs, or ideally use both programs at the same time for a while?
The article recommends notmuch-emacs. But I'm afraid of 2 things, (i) loosing existing mails in the transition (due to e.g. faulty conversion tools), and (ii) that after a complicated transition I'm not happy with the new setup. Any recommendations? Is it possible to use the claws-mail email inboxes directly in Emacs?
Another thing is org-mode. I never really managed to get deep enough into it to really see the benefits. I've even bought the printed org-mode manual, but the setup seems so complicated. Can someone recommend a good "light" tutorial for it? What are you using it for?
> Another thing is org-mode. [...] Can someone recommend a good "light" tutorial for it? What are you using it for?
I would recommend starting using Org just for note taking, using its outline capabilities. It's simple and avoid being overwhelmed and buried in features. One tutorial for this is [1], but even then it has advanced parts you can ignore at first. There are many Org tutorials, at some point it's best to just pick one and dive in instead of looking for the best one and ending up paralyzed by choice (a problem sometimes with Org and Emacs...).
Then once familiar with this you can extend your usage in various directions: add TODO and agenda for GTD, use it to export to nice web pages with a "read the doc" theme [2], etc.
[1] https://sachachua.com/blog/2008/01/outlining-your-notes-with...
[2] https://github.com/fniessen/org-html-themes
I would recommend starting using Org just for note taking, using its outline capabilities. It's simple and avoid being overwhelmed and buried in features. One tutorial for this is [1], but even then it has advanced parts you can ignore at first. There are many Org tutorials, at some point it's best to just pick one and dive in instead of looking for the best one and ending up paralyzed by choice (a problem sometimes with Org and Emacs...).
Then once familiar with this you can extend your usage in various directions: add TODO and agenda for GTD, use it to export to nice web pages with a "read the doc" theme [2], etc.
[1] https://sachachua.com/blog/2008/01/outlining-your-notes-with...
[2] https://github.com/fniessen/org-html-themes
I use mu4e. No better way of ripping through emails and getting down to inbox zero. When there's an email I need to action I can very quickly turn it into an org-mode task, and then archive it, knowing the task will contain a link to the email body. I rarely have more than 10 emails in my inbox.
Org-mode is like a Swiss army knife. I honestly started using it, unaware of the whole GTD functionality. I was using it as an alternative to markdown, as it allowed me to use CSS with the exported HTML. Then I learned of the GTD aspect and started using that as well. Now I have my init file written in org-mode using babel to drag out the lisp.
Org-mode is like a Swiss army knife. I honestly started using it, unaware of the whole GTD functionality. I was using it as an alternative to markdown, as it allowed me to use CSS with the exported HTML. Then I learned of the GTD aspect and started using that as well. Now I have my init file written in org-mode using babel to drag out the lisp.
For email I like mu4e. I set it up to use Imap it is a bit slow to load up. I had the same fears about losing email, I just created an additional gmail account and forwarded, played around with it till I wasn't concerned anymore.
For orgmode I like this website
http://doc.norang.ca/org-mode.html
You don't have to do everything, I just started adding pieces of his .emacs file one at a time until I was happy with way it worked. Very nice if you want to do GTD type open task reviews on a recurring basis.
For orgmode I like this website
http://doc.norang.ca/org-mode.html
You don't have to do everything, I just started adding pieces of his .emacs file one at a time until I was happy with way it worked. Very nice if you want to do GTD type open task reviews on a recurring basis.
Notmuch is excellent. I guess if your email is in maildir format, you can use it directly within Notmuch.
One thing that sets Notmuch apart from other MUAs is that it never ever touches your email files.
One thing that sets Notmuch apart from other MUAs is that it never ever touches your email files.
For email in Emacs, I've previously used VM, and also Gnus for a while, paired with BBDB addressbook and some of my own add-ons.
VM mostly worked very well (and Gnus was probably more powerful than any forum software/site you've ever seen), but there were a few pros&cons of preferences, including being tired of having so much in one Emacs process, so I moved.
One of the biggest downsides of moving email out of Emacs is that I lost the utility of BBDB. Which is doubly a shame because it was written by JWZ, yet Netscape Communicator and later Mozilla things that should've been influenced by JWZ have much-much less useful addressbooks.
(I made this when I moved: https://www.neilvandyke.org/bbdb2tbird/ )
VM mostly worked very well (and Gnus was probably more powerful than any forum software/site you've ever seen), but there were a few pros&cons of preferences, including being tired of having so much in one Emacs process, so I moved.
One of the biggest downsides of moving email out of Emacs is that I lost the utility of BBDB. Which is doubly a shame because it was written by JWZ, yet Netscape Communicator and later Mozilla things that should've been influenced by JWZ have much-much less useful addressbooks.
(I made this when I moved: https://www.neilvandyke.org/bbdb2tbird/ )
If your emails are in anything other than mbox format, then notmuch will not modify your email files - it merely builds an index for them so you can query. That should take care of your search needs.
As for HTML email, if you mean HTML converted to text, then notmuch will do it. If you mean show it as proper HTML, it won't. It can also show images inline (although my setup stopped years ago and I haven't debugged why). To be frank, I don't like how it converts an HTML email to text - it doesn't even preserve links (i.e. it shows the text only, and not the URL it links to). I need to look into how I can improve it.
But despite these headaches, I still use it. It's good.
As for HTML email, if you mean HTML converted to text, then notmuch will do it. If you mean show it as proper HTML, it won't. It can also show images inline (although my setup stopped years ago and I haven't debugged why). To be frank, I don't like how it converts an HTML email to text - it doesn't even preserve links (i.e. it shows the text only, and not the URL it links to). I need to look into how I can improve it.
But despite these headaches, I still use it. It's good.
> One question I have to more experienced Emacs users: Can you recommend an email client?
Contrary opinion from an experienced Emacs user (parts of my init.el are older than many users in this forum): I used to be a fan of Gnus, but then noticed that dragging attachments into E-mails is such a productivity booster than I switched to Mail and haven't looked back. If you are on a Mac, the combination of seamless drag&drop everywhere, Mail.app and LaunchBar simply does not compare to what you get inside of Emacs.
I do feel some regret, because I liked the customizability, but facts speak for themselves: I do things much faster with Mail.app.
Contrary opinion from an experienced Emacs user (parts of my init.el are older than many users in this forum): I used to be a fan of Gnus, but then noticed that dragging attachments into E-mails is such a productivity booster than I switched to Mail and haven't looked back. If you are on a Mac, the combination of seamless drag&drop everywhere, Mail.app and LaunchBar simply does not compare to what you get inside of Emacs.
I do feel some regret, because I liked the customizability, but facts speak for themselves: I do things much faster with Mail.app.
Interesting. One of the reasons I switched to mutt (well, neomutt) is that it is faster for me to work with attachements from a cli. This is mostly due to tab completion, which for commonly accessed locations is practically muscle memory. Takes me forever to to click my way there.
I often don't even know what the filenames are for my attachments, or where they are in the filesystem. Some are ephemeral.
I'm guessing you haven't worked with MacOS? Most people coming from a Linux/UNIX backgroupd (I was one of them) tend to assume that MacOS doesn't offer much, especially for advanced users, which isn't true. You can do many things significantly faster on MacOS.
In my case, I drag/drop attachments from other applications, from the filesystem, or from LaunchBar (finding things in LaunchBar is way faster than manually navigating through an entire path using tab completion).
I'm guessing you haven't worked with MacOS? Most people coming from a Linux/UNIX backgroupd (I was one of them) tend to assume that MacOS doesn't offer much, especially for advanced users, which isn't true. You can do many things significantly faster on MacOS.
In my case, I drag/drop attachments from other applications, from the filesystem, or from LaunchBar (finding things in LaunchBar is way faster than manually navigating through an entire path using tab completion).
You can drag attachments into Emacs from other programs, I do this on Linux at least
The Android client Orgzly is a good introduction to the scheduling/to-do side of org-mode.
There's also the compact org-mode manual at https://orgmode.org/guide/
I use org-mode for to-do lists, nested lists with to-dos scattered among them, scheduling stuff, and habits (repeatable variable schedule tasks). Orgzly does a lot for me already, and spacemacs+org-mode lets me edit however I want. I also use spacemacs+deft for quick notes, and org-capture for quickly entering new to-do items.
There's also the compact org-mode manual at https://orgmode.org/guide/
I use org-mode for to-do lists, nested lists with to-dos scattered among them, scheduling stuff, and habits (repeatable variable schedule tasks). Orgzly does a lot for me already, and spacemacs+org-mode lets me edit however I want. I also use spacemacs+deft for quick notes, and org-capture for quickly entering new to-do items.
Google this. You'll get a lot of good results.
site:news.ycombinator.com intitle:"email client"
I didn't really understand org-mode for a long time either - my problem was that I would read tutorials which gave very detailed descriptions about the various theoretical abilities of org-mode, which are like tools, but left up to the reader the task of determining an overall "goal" or workflow to be accomplished using these tools. So I ended up just working in a single org-mode file, not really understanding which tools I might like to use, how I could use it as an organizational system.
For me, the lightbulb moment came from a couple of blog posts called "Building a Second Brain in Emacs and Org-Mode" [0][1], which outlined an actual workflow (based on Getting Things Done or GTD [1]) and explained how org-mode enhanced it. If you follow along, you may find it helpful to see the author's actual emacs configuration (especially the parts that relate to org-mode) [3], the templates he uses to create projects and e.g. weekly reviews [4], and a talk he gave at an Emacs meetup about his workflow. It could be a little more organized in a single place, but this is the best "tutorial" I've ever found about org-mode.
After implementing this myself, I've found that I use certain parts of it a lot, and other parts not at all. I also found that I prefer to periodically refile org-mode notes into a "knowledge repository" (a series of text files in my org-mode directory), rather than in evernote as suggested, and that this is best managed/browsed (for me) using Deft [6] rather than org-mode itself. So I've also managed to extend the system for my preferences a bit.
Sorry for the brain dump - hopefully this answers your question a bit.
[0] https://praxis.fortelabs.co/building-a-second-brain-in-emacs...
[1] https://medium.com/@tasshin/implementing-a-second-brain-in-e...
[2] https://en.wikipedia.org/wiki/Getting_Things_Done
[3] https://github.com/mwfogleman/.emacs.d
[4] https://gist.github.com/mwfoglemanhttps://github.com/mwfogle...
[5] https://www.youtube.com/watch?v=Bpmkeh4D98s
[6] https://github.com/jrblevin/deft
For me, the lightbulb moment came from a couple of blog posts called "Building a Second Brain in Emacs and Org-Mode" [0][1], which outlined an actual workflow (based on Getting Things Done or GTD [1]) and explained how org-mode enhanced it. If you follow along, you may find it helpful to see the author's actual emacs configuration (especially the parts that relate to org-mode) [3], the templates he uses to create projects and e.g. weekly reviews [4], and a talk he gave at an Emacs meetup about his workflow. It could be a little more organized in a single place, but this is the best "tutorial" I've ever found about org-mode.
After implementing this myself, I've found that I use certain parts of it a lot, and other parts not at all. I also found that I prefer to periodically refile org-mode notes into a "knowledge repository" (a series of text files in my org-mode directory), rather than in evernote as suggested, and that this is best managed/browsed (for me) using Deft [6] rather than org-mode itself. So I've also managed to extend the system for my preferences a bit.
Sorry for the brain dump - hopefully this answers your question a bit.
[0] https://praxis.fortelabs.co/building-a-second-brain-in-emacs...
[1] https://medium.com/@tasshin/implementing-a-second-brain-in-e...
[2] https://en.wikipedia.org/wiki/Getting_Things_Done
[3] https://github.com/mwfogleman/.emacs.d
[4] https://gist.github.com/mwfoglemanhttps://github.com/mwfogle...
[5] https://www.youtube.com/watch?v=Bpmkeh4D98s
[6] https://github.com/jrblevin/deft
The way I see it, there are two major approaches to IDEs - Extendable text editors (of which Emacs is the best example) and Visual Studio knock offs.
There is no right or wrong answer, but I like the Emacs way.
There is no right or wrong answer, but I like the Emacs way.
I'd put it slightly differently, but I guess it is the same idea.
There are two major approaches to software development: 1) powerful text editors (vi, Emacs) or 2) IDE.
Powerful text editors are universal, but up to now their language support was often subpar compared to IDEs. They tend to do well for niche languages with no dedicated IDE, as then they're the reference editors. But for mainstream languages on can usually find IDEs with better language specific support. Still, they shine in pure editing power and after an initial investment you can use them for anything text based.
Then an IDE can have the best language support for some usually small set of languages, but is not as powerful as a vi or Emacs for pure editing.
That's the situation so far, but I see this changing thanks to the language server protocol [1]. It's the pattern seen in portable compilers, where a universal IR avoid a MxN explosion with M languages front-ends and N target ISA. Except here one avoids the M editors times N languages by having a universal protocol between an editor and a LSP server for a language. What the LSP allows is decoupling your editing front-end from the language support back-end (the LSP server).
All this is a bit young, and moving fast, but in time it offers the possibility of a no-compromise experience: use the best editor for you, and still get the best language support available. It's already possible to extract Eclipse Java support, or Microsoft Python support, and use it with any LSP compliant editor for example, with some ad-hoc work. In time, all this should get more streamlined. Which makes me happy to have invested into Emacs ;)
[1] https://microsoft.github.io/language-server-protocol/
There are two major approaches to software development: 1) powerful text editors (vi, Emacs) or 2) IDE.
Powerful text editors are universal, but up to now their language support was often subpar compared to IDEs. They tend to do well for niche languages with no dedicated IDE, as then they're the reference editors. But for mainstream languages on can usually find IDEs with better language specific support. Still, they shine in pure editing power and after an initial investment you can use them for anything text based.
Then an IDE can have the best language support for some usually small set of languages, but is not as powerful as a vi or Emacs for pure editing.
That's the situation so far, but I see this changing thanks to the language server protocol [1]. It's the pattern seen in portable compilers, where a universal IR avoid a MxN explosion with M languages front-ends and N target ISA. Except here one avoids the M editors times N languages by having a universal protocol between an editor and a LSP server for a language. What the LSP allows is decoupling your editing front-end from the language support back-end (the LSP server).
All this is a bit young, and moving fast, but in time it offers the possibility of a no-compromise experience: use the best editor for you, and still get the best language support available. It's already possible to extract Eclipse Java support, or Microsoft Python support, and use it with any LSP compliant editor for example, with some ad-hoc work. In time, all this should get more streamlined. Which makes me happy to have invested into Emacs ;)
[1] https://microsoft.github.io/language-server-protocol/
Also, IDEs tend to have better framework support (it's nearly impossible to write Java code without one because you want an IDE that knows about Spring or Hibernate and can make all the Gradle stuff work), but that's economics - it's easier to sell an IDE than to sell an Emacs minor mode (which would end up having to fit in a with set of other things that may or may not conflict with what you have).
> That's the situation so far, but I see this changing thanks to the language server protocol
It’s really interesting how LSP shifts what I’ll call “Visual Studio only features” into all editors, while at the same time you had Microsoft being the ones who initially pushed for LSP-adoption.
I wonder how many internal discussions they had on this subject before saying “Go”.
It’s a fantastic initiative and I’m glad it’s there for me, in my Emacs today.
It’s really interesting how LSP shifts what I’ll call “Visual Studio only features” into all editors, while at the same time you had Microsoft being the ones who initially pushed for LSP-adoption.
I wonder how many internal discussions they had on this subject before saying “Go”.
It’s a fantastic initiative and I’m glad it’s there for me, in my Emacs today.
LSP is fine and all, but as a one-size-fits-all protocol I'm guessing it will never reach the level of flexibility and extensibility required to implement something like IDEA/Rider level refactorings, hints, and the general level of "code understanding" by the editor. It's a bit hard to explain, but JetBrains' IDEs really feel like they understand your code. It feels more like editing an engineering diagram, or tinkering with a mechanical contraption, and less like editing free-form text (which code is definitely not). That's how it should be, I believe.
Visual Studio-like IDEs are a dead end. There is little revenue opportunity in them and a huge downside in losing relevance in the overall developer mindshare.
How many of us would be using a Microsoft IDE/text editor if it were not for VS Code?
How many of us would be using a Microsoft IDE/text editor if it were not for VS Code?
The millions that use and will continue to use Visual Studio?
Visual Studio is great for developing on Windows software that'll run on Windows or XBox.
Feels like a dead end to me. The ecosystem has colossal inertia, but it's easy to see the lack of future.
Feels like a dead end to me. The ecosystem has colossal inertia, but it's easy to see the lack of future.
So, you propose to give up on Visual Studio because in 20 or so years maybe Windows and XBox won’t exist? Or?...
Also, speaking of IDEs. There are also Jetbrains’ IDEs and XCode. Can’t speak for XCode, but IDEA offers capabilities that Emacs can’t even begin to approach.
Also, speaking of IDEs. There are also Jetbrains’ IDEs and XCode. Can’t speak for XCode, but IDEA offers capabilities that Emacs can’t even begin to approach.
I have already given up Visual Studio because none of my work is intended to run only on Windows and Xbox.
Practically everyone that does C++ or C# development on Windows?
And ironically, I'd argue that Visual Studio Code despite the name is more of a member of the former (it is basically an Atom clone) than it is like traditional Visual Studio.
I'd say the two approaches are:
- Editors that prioritize text operations
- Editors that prioritize AST structure operations
IDEs are the latter.
- Editors that prioritize text operations
- Editors that prioritize AST structure operations
IDEs are the latter.
I remember giving Emacs a serious go 5 years ago. I really wanted to like it but the archaic mode switches[1] were just too much when you are used to the convenience of Ctrl+C and Ctrl+V (I'll call these "modern shortcuts").
I've tried using ErgoEmacs[2] but what I've learned was that it doesn't really play nicely with all the other extensions.
It's a shame because I've wanted to find something a bit more powerful than nano for config and code updates on remote machines.
[1] http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html
[2] https://ergoemacs.github.io/
I've tried using ErgoEmacs[2] but what I've learned was that it doesn't really play nicely with all the other extensions.
It's a shame because I've wanted to find something a bit more powerful than nano for config and code updates on remote machines.
[1] http://ergoemacs.org/emacs/emacs_kb_shortcuts_pain.html
[2] https://ergoemacs.github.io/
You can use CUA mode: https://www.emacswiki.org/emacs/CuaMode
I also highly recommend Spacemacs. If VI isn't your thing, it is still great to use it, just set it up in Holy mode using Ivy.
What it adds (on top of a great default config), is bindings which start with M-m (that's Alt+m). For almost everything. Like saving your file is M-m f s (that's Alt+m release, f release, s release).
I also highly recommend Spacemacs. If VI isn't your thing, it is still great to use it, just set it up in Holy mode using Ivy.
What it adds (on top of a great default config), is bindings which start with M-m (that's Alt+m). For almost everything. Like saving your file is M-m f s (that's Alt+m release, f release, s release).
Sure, but with a leader key in vim set to 'f', I can save with f-s (that is, press the f key and then the s key), which after a month is next to automatic
You’re arguing about vim shortcuts in reply to a description of what one can do if one doesn’t want vim shortcuts. Note that the equivalent in vim is not really f s, but ESC f s, because in most modes where one might do M-m f s, most characters insert themselves, the equivalent of insert mode in vim.
Note also that in regular emacs one can do C-x C-s (ie holding control press x then s).
Note also that in regular emacs one can do C-x C-s (ie holding control press x then s).
As a former Vim addict of over 12 years: to those who would like to try to move to Emacs, and Spacemacs doesn't cut it, try Doom!
https://github.com/hlissner/doom-emacs
It is a much thinner configuration, and you will learn Emacs instead of layers and Spacemacs conventions.
It only took me about a week of deliberate use to adapt my work flow and get used to it, and it has been my primary editor for nearly a year now.
https://github.com/hlissner/doom-emacs
It is a much thinner configuration, and you will learn Emacs instead of layers and Spacemacs conventions.
It only took me about a week of deliberate use to adapt my work flow and get used to it, and it has been my primary editor for nearly a year now.
At first glance, I thought this would be an Emacs tutorial superimposed on top of the Doom engine, ala DOOM as a Tool for System Administration.[0]
[0]https://www.cs.unm.edu/~dlchao/flake/doom/
[0]https://www.cs.unm.edu/~dlchao/flake/doom/
“I don’t care what editor you use for source code – you can use Quick basic for all I care – but look, you have to know that Magit exists. Even if you don’t use Emacs in any other capacity, you may want to use it for Magit.”
There are exactly two instances of “Magit” in this web page and I just quoted both of them.
There are exactly two instances of “Magit” in this web page and I just quoted both of them.
A quick web search brings me to Magit’s page, which tells me that Magit is “A Git Porcelain inside Emacs” which just creates further questions. How does one make delicate pottery out of a version control system? In what circles is “a porcelain” a synonym for “user interface”?
The Git documentation refers to everything Nicely Shaped that is tacked on to the core git functionality as "porcelain" [0]. (Pretty much everything that we normally use when interacting with git counts as porcelain.)
0: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
0: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
I can get over "porcelain," but the Magit site would certainly benefit from better organization. You can skim the entire landing page without gaining much sense for what it's all about, and then it turns out that if you just click on the first screenshot on that page, you end up at "A visual walk-through" https://magit.vc/screenshots/, which is much more helpful. But you have to mouse over that screenshot and notice that the pointer changes in order to even realize that it's a link.
As far as I can tell, it's only in git circles. Git refers to its command line interface as "porcelain" to distinguish it from the "plumbing" that is the .git folder.
So, emacs is a platform for text-based programs to do things that i already have other stable, reliable, and familiar programs to accomplish. I’m not sold. I need a better value proposition before i feel sold to spend my time climbing that learning curve.
>text-based programs
Not text based, it has buttons, widgets, can embed pictures and graphics.
>reliable, and familiar programs to accomplish
In emacs these bits of code are integrated, so I could, for example, save an IRC chat as buffer, edit it, and send a e-mail. Or open an interactive REPL of maxima, for example, copy result to latex having embedded previews for formulas, and then compile it to pdf (and preview in emacs).
Different parts could be combined in any possible way with elisp code. You can easily call any email-related or rfeed-related function from your code at any time.
Not text based, it has buttons, widgets, can embed pictures and graphics.
>reliable, and familiar programs to accomplish
In emacs these bits of code are integrated, so I could, for example, save an IRC chat as buffer, edit it, and send a e-mail. Or open an interactive REPL of maxima, for example, copy result to latex having embedded previews for formulas, and then compile it to pdf (and preview in emacs).
Different parts could be combined in any possible way with elisp code. You can easily call any email-related or rfeed-related function from your code at any time.
The question is: is it worth it? Trying to figure out all those functions, setting all tose modes, and then programming them the way you described.
Especially when all you just described can be done with regular copy-paste between dedicated programs if needed.
Especially when all you just described can be done with regular copy-paste between dedicated programs if needed.
> Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don’t seem to care about the magnitude of the event, only the quality.
> The more you feel that you can control your environment, and that the things you do are actually working, the happier you are. When you find yourself frustrated, angry, and upset, it’s probably because of something that happened that you could not control: even something small.
https://www.joelonsoftware.com/2001/10/24/user-interface-des... is actually a great argument for Emacs (even though the only time Emacs is mentioned there is an example of inconsistencies in keyboards shortcuts with other editors).
> The more you feel that you can control your environment, and that the things you do are actually working, the happier you are. When you find yourself frustrated, angry, and upset, it’s probably because of something that happened that you could not control: even something small.
https://www.joelonsoftware.com/2001/10/24/user-interface-des... is actually a great argument for Emacs (even though the only time Emacs is mentioned there is an example of inconsistencies in keyboards shortcuts with other editors).
I've been a vim guy for 5 years now. And last month I tried to switch to emacs. But it just didn't feel natural for the following reasons:
1. My usual coding session would involve Vim+Tmux, on trying the same with emacs. I was seeing some lag(although small, but noticeable).
2. I am very used to the key strokes "g-d, g-D" in vim to quickly move around calls/declarations of functions. For that emacs makes use of Ctags, which is more versatile but not great for a quick lookup.
3. I have had better luck with Vim's linting plugins like ALE and haven't found similar plugins for Emacs which was eventually a major game changer to switch back to Vim.
On the other set of tools:
- Org-mode and latex-preview-pane-mode are the 2 set of tools which I have integrated into my workflow and they are very suitable to me.
- ERC is also pretty neat.
- I have tried Magit and although seems useful, for my use case of Emacs currently doesn't hold a lot of promise.
- Switch to Gnus, mu4e as mail clients replacements is too painful, at least to a Thunderbird user.
1. My usual coding session would involve Vim+Tmux, on trying the same with emacs. I was seeing some lag(although small, but noticeable).
2. I am very used to the key strokes "g-d, g-D" in vim to quickly move around calls/declarations of functions. For that emacs makes use of Ctags, which is more versatile but not great for a quick lookup.
3. I have had better luck with Vim's linting plugins like ALE and haven't found similar plugins for Emacs which was eventually a major game changer to switch back to Vim.
On the other set of tools:
- Org-mode and latex-preview-pane-mode are the 2 set of tools which I have integrated into my workflow and they are very suitable to me.
- ERC is also pretty neat.
- I have tried Magit and although seems useful, for my use case of Emacs currently doesn't hold a lot of promise.
- Switch to Gnus, mu4e as mail clients replacements is too painful, at least to a Thunderbird user.
Regarding your first point, do you mean that you try running emacs inside a tmux inside a terminal?
If that is the case, I would recommend not doing that. The emacs gui will give you more colours, images, thinner window borders, better keyboard shortcuts (eg a difference between C-m and RET), mouse controls (if you ever want them), as well as potentially less lag.
The analog to the vim-in-tmux workflow is to instead keep emacs always open in the gui, run somewhere between none and all shell commands from emacs (depending on how you feel), and have a terminal in another window (as you might for web browsing or email) for more prolonged terminal things. One might skip this somewhat by running shell (or even term-mode) in emacs.
Similarly, for editing remote files one uses tramp to ssh from inside emacs and edit files whereas with vim one sshes into the remote box and runs vim.
If that is the case, I would recommend not doing that. The emacs gui will give you more colours, images, thinner window borders, better keyboard shortcuts (eg a difference between C-m and RET), mouse controls (if you ever want them), as well as potentially less lag.
The analog to the vim-in-tmux workflow is to instead keep emacs always open in the gui, run somewhere between none and all shell commands from emacs (depending on how you feel), and have a terminal in another window (as you might for web browsing or email) for more prolonged terminal things. One might skip this somewhat by running shell (or even term-mode) in emacs.
Similarly, for editing remote files one uses tramp to ssh from inside emacs and edit files whereas with vim one sshes into the remote box and runs vim.
[deleted]
> I have had better luck with Vim's linting plugins like ALE and haven't found similar plugins for Emacs …
Did you try flycheck?
Did you try flycheck?
I am currently only using Emacs for org mode, and overall it works great for taking notes, keeping track of tasks, and outputting documentation.
However... I would _love_ to see a GUI version of just org mode which would combine a few features of OneNote, well I would be happy if it only made adding pictures better!
However... I would _love_ to see a GUI version of just org mode which would combine a few features of OneNote, well I would be happy if it only made adding pictures better!
If only Emacs had become the VM of the web rather than Chrome! I'm more than ready to trade our impending soyberpunk police-state dystopia for a case of carpal tunnel syndrome.
I bookmarked this. I have been using Emacs since I bought a manual around 1980, but, the article mentioned a few packages I didn’t know about.
This happens all the time to me.
The other day, I found my old hitchhiker's guide to the galaxy infocom image (interactive fiction) and it turns out someone wrote some elisp that lets you play it in emacs.
(that said, elisp isn't a very expressive language for me, python is my favorite language right now)
The other day, I found my old hitchhiker's guide to the galaxy infocom image (interactive fiction) and it turns out someone wrote some elisp that lets you play it in emacs.
(that said, elisp isn't a very expressive language for me, python is my favorite language right now)
A good resource for anyone who wants study Emacs further or try out things, I found this very helpful for me: https://emacs.zeef.com
I used emacs for years and had accumulated about 10000 loc init.el over that time.
With my new employer I'm forced to use notepad++ on Windows. The difference in actual productivity: zero!
Emacs is a nice hobby but when you want do get shit done it won't help you being more productive except for some rare corner cases.
So don't buy into the Emacs Plattform. Maybe just learn the basics because sometimes it is the only editor installed. If you spend more than two hours on it you are wasting your time.
With my new employer I'm forced to use notepad++ on Windows. The difference in actual productivity: zero!
Emacs is a nice hobby but when you want do get shit done it won't help you being more productive except for some rare corner cases.
So don't buy into the Emacs Plattform. Maybe just learn the basics because sometimes it is the only editor installed. If you spend more than two hours on it you are wasting your time.
I've used emacs for 25 years, and I kinda agree, actually.
What keeps me using it is precisely that it's been stable that long. Given that I don't really need that many features, it's been nice to not have to change editors, what, 5 or 6 times in that period of time?
I've got some very light customization to expose the macro features more conveniently, and like three or four keybindings for my major languages I work in.
Other than that, part of what keeps me in emacs is that it supports SSH'ing to remote systems to edit things very well, so I can use my desktop editor in all kinds of environments with everything I'm used to, no matter where I'm having to edit something, as long as SSH can get to it. While there are other editors that can do this to some extent, I find that when it's nominally "time" to switch to New Editor of the Half-Decade it's often a missing or poorly-implemented feature.
Also, as strange as it may seem, a lot of editors aren't all that great at editing 5 files at a time. They certainly can, but they're not that great at it. Emacs is pretty good. I don't even use any funky extensions for it.
I still don't really know elisp. I've seen emacs wizards, and I'm not one, despite 25 years with it. Given that editor features aren't really that important, why not pick one decent tool and stick with it? At least then I'm not surprised when I have to pick up a new tool and, oh, crap, it doesn't do networks, and, tabs, seriously, tabs for multiple buffers with no keyboard access based on names? No.
(I do also know enough vi to get around in it when I have to use it on some system for some reason.)
What keeps me using it is precisely that it's been stable that long. Given that I don't really need that many features, it's been nice to not have to change editors, what, 5 or 6 times in that period of time?
I've got some very light customization to expose the macro features more conveniently, and like three or four keybindings for my major languages I work in.
Other than that, part of what keeps me in emacs is that it supports SSH'ing to remote systems to edit things very well, so I can use my desktop editor in all kinds of environments with everything I'm used to, no matter where I'm having to edit something, as long as SSH can get to it. While there are other editors that can do this to some extent, I find that when it's nominally "time" to switch to New Editor of the Half-Decade it's often a missing or poorly-implemented feature.
Also, as strange as it may seem, a lot of editors aren't all that great at editing 5 files at a time. They certainly can, but they're not that great at it. Emacs is pretty good. I don't even use any funky extensions for it.
I still don't really know elisp. I've seen emacs wizards, and I'm not one, despite 25 years with it. Given that editor features aren't really that important, why not pick one decent tool and stick with it? At least then I'm not surprised when I have to pick up a new tool and, oh, crap, it doesn't do networks, and, tabs, seriously, tabs for multiple buffers with no keyboard access based on names? No.
(I do also know enough vi to get around in it when I have to use it on some system for some reason.)
Once or twice a quarter I'll end up with a relatively mechanical task that I can do with a keyboard macro, query-replace-regexp/dired-do-find-regexp-and-replace. That normally saves me at least 30-45 minutes compared to either doing it manually or writing a script.
The parent mentions notepad++, which offers similar regexp and macro functionality.
I don't know notepad++, so I don't know if you can open any file in it from any directory just by typing the file name. I never navigate directory structures when opening files, because emacs completes files for me from any directory on my computer, and it saves me a lot of time, because I can open any file literally in seconds.
It would set back my productivity a lot if I had to use the open file dialog for this.
It would set back my productivity a lot if I had to use the open file dialog for this.
---- TLDR ----
I completely agree with the others who say:
People complain about memorizing emacs keybindings, but most of the time I just call the command name with M-x command-name. Only if I find myself using it often I bother memorizing or setting a keybinding for it.
As for why I use emacs, I started using it for org-mode, which I considered it's only killer feature at the time. Since 1 year ago I started learning elisp and I think only now I can see what's the whole point of emacs.
In just 1 year of (beginner-level) elisp I wrote 75 files containing elisp functions to help myself with dozens of tasks that comprise:
Another common complain is that emacs tends to become slower as you add more and more packages. As a spacemacs user, I noticed that too. For this reason when I don't need spacemacs goodies I use multiple, different emacs configurations (with evil-mode though).
This is how I do it:
1 - Make a new ".emacs.d" user directory somewhere
2 - Make a new "init.el" user file inside it
3 - Add to the beginning of init.el :
You could achieve the same result using cask, which would be more elegant imo, but takes a couple of seconds more to start.
---- part 3: use elisp to call other languages
As for elisp, once you have learned enough of it (not much), if you are determined not to use it, there are different ways to call other languages from it:
I completely agree with the others who say:
- learn elisp instead of learning "emacs"
- if you want to memorize something, just learn the name of the command: if you use it very often then learn/define a keybinding for it
People complain about memorizing emacs keybindings, but most of the time I just call the command name with M-x command-name. Only if I find myself using it often I bother memorizing or setting a keybinding for it.
As for why I use emacs, I started using it for org-mode, which I considered it's only killer feature at the time. Since 1 year ago I started learning elisp and I think only now I can see what's the whole point of emacs.
In just 1 year of (beginner-level) elisp I wrote 75 files containing elisp functions to help myself with dozens of tasks that comprise:
- move/mirror parts of ascii diagrams
- automate some tasks just clicking on custom org-mode links
- wrap ammonite-term-repl to get Ammonite completion for scala scripts [1] [2]
- add rudimentary support for kawa scheme to geiser (my first pull request ever (still waiting for response))
- control video player from within emacs while I'm writing subtitles
Another common complain is that emacs tends to become slower as you add more and more packages. As a spacemacs user, I noticed that too. For this reason when I don't need spacemacs goodies I use multiple, different emacs configurations (with evil-mode though).
This is how I do it:
1 - Make a new ".emacs.d" user directory somewhere
2 - Make a new "init.el" user file inside it
3 - Add to the beginning of init.el :
(setq user-init-file (or load-file-name "path-to-init.el"))
(setq user-emacs-directory (file-name-directory user-init-file))
emacs -Q --load "path-to-init.el"
You could achieve the same result using cask, which would be more elegant imo, but takes a couple of seconds more to start.
---- part 3: use elisp to call other languages
As for elisp, once you have learned enough of it (not much), if you are determined not to use it, there are different ways to call other languages from it:
- clojure through cider plus clomacs
- common lisp through slime
- shen through shen-elisp [3]
- different compiled languages through dynamic modules:
- C (example at [4])
- go (example at [5])
- ... many others I haven't investigated...
- Plain elisp is faster: I don't know the implications
- I wanted to focus on elisp so I can contribute better to other elisp projects
[1] https://github.com/zwild/ammonite-term-repl
[2] https://github.com/spellcard199/ammonite-term-repl-completion
[3] https://github.com/deech/shen-elisp
[4] http://kitchingroup.cheme.cmu.edu/blog/2017/07/08/Adding-numerical-methods-to-emacs-with-dynamic-modules/
[5] https://mrosset.github.io/emacs-module/Vim is life.
I recently tried to switch from vim to Emacs with spacemacs. I enjoyed it until I discovered Emacs has no support for tabs (ui tabs, not the character ;). I went back to vim mainly due to that, but still miss magit....
If you want to try again, just install the "tabbar" package (in MELPA, and in most Linux distributions too). Like most things with Emacs if it's not built-in there's likely a package for it.
Emacs is kind of like an editor construction kit with a basic sample, and making your own Emacs variant is part of the experience IMHO. It's not to everyone taste of course (and that's ok). If not, there are Emacs distributions like spacemacs but their choices can't fit each person perfectly.
Emacs is kind of like an editor construction kit with a basic sample, and making your own Emacs variant is part of the experience IMHO. It's not to everyone taste of course (and that's ok). If not, there are Emacs distributions like spacemacs but their choices can't fit each person perfectly.
> until I discovered Emacs has no support for tabs (ui tabs, not the character ;)
It may not be built-in, but saying Emacs "has no support" for tabs when there are at least three (if not more) plugins which provide them is a stretch. Personally, I use elscreen, but forked and changed so that tabs are displayed in a reserved window instead of on the header line.
There are some lacking features in terms of GUI display, especially compared to newer editors, but other than that Emacs supports the widest array of features and sometimes even a couple competing implementations for them.
It may not be built-in, but saying Emacs "has no support" for tabs when there are at least three (if not more) plugins which provide them is a stretch. Personally, I use elscreen, but forked and changed so that tabs are displayed in a reserved window instead of on the header line.
There are some lacking features in terms of GUI display, especially compared to newer editors, but other than that Emacs supports the widest array of features and sometimes even a couple competing implementations for them.
You can have many things going at the same time, and select between them using the buffer menu. I find the devotion of yet another chunk of screen real estate to the tab list rather a waste, but shrug aesthetics.
C-x C-b
shows you the list of tabs ("buffers") and lets you select from them easily. As a bonus, the title portion isn't compressed to incomprehensibility when they get numerous.
C-x C-b
shows you the list of tabs ("buffers") and lets you select from them easily. As a bonus, the title portion isn't compressed to incomprehensibility when they get numerous.
I use tabs to switch between window configurations.
Say I code in Python, with docs and shell windows on the right. Then I want to quickly take a look at git history. But, if I start magit, it will hijack the window configuration and my carefully placed/resized windows will get messy. So, I open a new tab and start magit there. Now, I can switch between the two tabs - ie. window/buffer layouts - with a single key.
The fact that I mention saving the layout of windows should hint that I know you can do this in vanilla Emacs by saving and restoring window configurations, but it's much less hassle with tabs. Also, you can hide tab bar (as well as menu bar and button bar) when you don't need it, and it's actually quite handy when you do need it.
To each their own of course, just saying there are good uses for tabs in Emacs, unless you want to delegate this to your WM and launch one frame per window config.
Say I code in Python, with docs and shell windows on the right. Then I want to quickly take a look at git history. But, if I start magit, it will hijack the window configuration and my carefully placed/resized windows will get messy. So, I open a new tab and start magit there. Now, I can switch between the two tabs - ie. window/buffer layouts - with a single key.
The fact that I mention saving the layout of windows should hint that I know you can do this in vanilla Emacs by saving and restoring window configurations, but it's much less hassle with tabs. Also, you can hide tab bar (as well as menu bar and button bar) when you don't need it, and it's actually quite handy when you do need it.
To each their own of course, just saying there are good uses for tabs in Emacs, unless you want to delegate this to your WM and launch one frame per window config.
> To each their own of course, just saying there are good uses for tabs in Emacs, unless you want to delegate this to your WM
You mention window configurations, and you say " it's much less hassle with tabs." You can assign a single key to switch between window configurations too and then it's practically the same, isn't it?
You mention window configurations, and you say " it's much less hassle with tabs." You can assign a single key to switch between window configurations too and then it's practically the same, isn't it?
Yeah, not "practically", but simply "the same" - that's exactly how half of my tabs (elscreen.el) is implemented (the other half being creating, displaying and updating the "tabbar"). In other words, if you use winner mode, or have a couple of custom wrappers around window layouts and use those, you're practically already using tabs, just without a tabbar! ;)
hum, tabs for frames, not buffers basically. That seems useful. What's your setup?
Not frames but window configurations (the things you can save with C-x r w and restore with C-x r j), although one can also save the frame configuration too.
Aquamacs (http://aquamacs.org) get's it tabs from somewhere...
My solution is eyebrowse-mode, which lets you switch quickly between window setups...I never need to recreate an exact layout in the long term, so it’s more than enough to save and switch on the fly
With the built-in winner-mode you can go back to the previous window layout with C-c left.
Logging into "work" systems and typing "emacs" == "command not found". Typing "vi" opens a useful editor.
It's not that I hate emacs or have some aversion to anything except vi/vim. The problem is that vi is everywhere, and by mastering the always-available editor, I always have my tools at hand. On foreign systems, or highly regulated systems that I can't add software to, this is a huge advantage.
It's not that I hate emacs or have some aversion to anything except vi/vim. The problem is that vi is everywhere, and by mastering the always-available editor, I always have my tools at hand. On foreign systems, or highly regulated systems that I can't add software to, this is a huge advantage.
True, but the workflow you describe is not the natural one for Emacs.
Emacs has a built-in package called TRAMP [1] for remote work. You don't log into a distant server and open Emacs there, you use Emacs on your local PC and open the remote file naturally, using a syntax like /method:user@host:/path/to/file, but most often /-:host:/path/to/file (when using SSH access set as default, with your local user name). Except for the special file path it's just like for a local file.
Then when launching a shell command, or a full shell, or a grep or compile or whatnot from a buffer editing a remote file, Emacs will automatically launch the command remote machine too. That makes the experience rather transparent. It's possible to have multiple buffers editing files on different machines at the same time.
[1] https://www.gnu.org/software/tramp/#Quick-Start-Guide
Emacs has a built-in package called TRAMP [1] for remote work. You don't log into a distant server and open Emacs there, you use Emacs on your local PC and open the remote file naturally, using a syntax like /method:user@host:/path/to/file, but most often /-:host:/path/to/file (when using SSH access set as default, with your local user name). Except for the special file path it's just like for a local file.
Then when launching a shell command, or a full shell, or a grep or compile or whatnot from a buffer editing a remote file, Emacs will automatically launch the command remote machine too. That makes the experience rather transparent. It's possible to have multiple buffers editing files on different machines at the same time.
[1] https://www.gnu.org/software/tramp/#Quick-Start-Guide
Yes vi is there on systems where you don't have Emacs. Vi is simple enough to remember the commands you need if this ever happens, and this is not really a reason to eschew something more powerful everywhere else.
As the sibling comment says you should try editing remote files with the editor running on your computer. Tramp provides this transparently for Emacs. You don't have to manually log in to edit remote files.
I want to believe the friction comes if you try to "fix" Emacs too early.
You kinda have to conform to the Emacs way when learning it and leave all of your assumptions at the door. I see a lot of people who come to Emacs from Vim expecting Evil Mode to be the panacea for Emacs. It's not. At the end of the day, it's still Emacs and people run into friction because they expect it to be Vim-ish all over or they want to force Emacs to be Vim.
Personally, I came from Vim to Emacs via Spacemacs. I was a bit of a zealot about Vim until I tried Emacs. I left all of my expectations behind and I was pleasantly surprised by many things inside. Were there things I disliked? Of course. But, I wasn't looking for an excuse to hate it.