I published this project a few minutes ago and I was about to do a "Show HN" for this project here. As soon as I submitted my "Show HN" post, my submission got redirected to this post and I realized that todsacerdoti beat me to it by a few seconds! In any case, thank you, todsacerdoti, for posting this here!
Do you have advice about installing emacs without package manager/ compilation tools into the linux system that currently cannot have those and probably will not have those. I am looking for the easiest and safest way to do it . I do not want to break or brick the running arm based linux system. I do not want to interfere with it's main function but still want to be able to try emacs there. What is the best way to achieve minimal dependency setup?
I am still relatively new to gnu/linux and I understand that I can unpack package let's say debian package and install each lib. manually but it seems like a big headache, is there any easier way? I am looking for something like copy everything into one directory without a need to register each lib in the system?
If your goal is to try out emacs on that system by working on files that you have inside it, you could install emacs on something else and then use the built-in TRAMP functionality to work on that system remotely, as if it was local. It works transparently over SSH.
Might be an easy way to do it without changing too much on your restricted linux box.
I agree with everyone else that usually you won't want to install this on a system without a package manager.
However, I also hate it when I want to do something and everyone just tells me not to do it. So the general way to do it would be to get the source code and build it yourself. You will run into issues with versions of libraries being wrong, and this will be hard to fix. Here is a stack exchange story on the topic: https://unix.stackexchange.com/questions/472989/how-to-build...
If you try this, you will learn to appreciate package managers more.
If you're experienced you'd download and install all the dependencies, perhaps via "/opt", where a local package-manager would not interfere.
But honestly? If you're new to using Linux then you should use the supported approach by your system. If you're running Debian, for example, "apt install emacs". If you're running CentOS "yum install emacs".
Trying to do things outside the confines of the package-manager seems like an odd-constraint. I can appreciate it might make some sense, but when there are so many dependencies installed - fetching/building/installing them all one at a time is going to be very fiddly and annoying, even for a somewhat-experienced user.
>But honestly? If you're new to using Linux then you should use the supported approach by your system. If you're running Debian, for example, "apt install emacs". If you're running CentOS "yum install emacs".
Thank you for your advice. The system doesn't have package manager and installing one doesn't seem like safe option at least until I'll be fluent with what exactly package manager does. On debian machine I did what you've suggested. This is not debian nor CentOS. It's embedded solution. In such case it seems like easier to install only emacs. I've already installed some custom application with libs and it was a headache. I wrote my own custom application for it and there I just link statically everything I need to have less trouble with installing.
If you have SSH access the best solution would be to install emacs on your client and edit remotely. Tramp allows you to edit remote files transparently. Setup key based auth if you can, add an entry for you device in client's .ssh/config, then editing is as easy as opening "/ssh:hostname:/path/to/remote/file" with C-c C-f
Could you not inhibit the startup screen? I get wanting to have a "clean" setup but if anyone is using this there is a good chance they don't know emacs all that well already and links to the tutorial are good for them.
(use-package dashboard
:ensure t
:config
(dashboard-setup-startup-hook))
To replace the startup screen with a list of recent files, bookmarks, and Projectile projects you've recently visited.
Remember, though, that just like this document describes, a big part of Emacs is not running it repeatedly, but rather starting it just once and keeping it alive basically forever; you're only rarely going to see the startup screen if you're doing orthodox Emacs.
In the sense that use-package should pretty clearly be bundled with Emacs by now, sure. You don't need Projectile installed to use dashboard (I barely use Projectile, and have it turned off in my dashboard thingy).
Sure! This is addressed in the line-by-line explanation where it mentions:
> (setq inhibit-startup-screen t)
> If you are a beginner to Emacs, you might find the startup screen helpful. It contains links to tutorial, manuals, common tasks, etc. If you want to retain the startup screen, comment this line out.
I think the point of a template is that you can change everything yourself, it is not a library you install with a package manager and are expected to leave alone. Given the good explanation of what is going on, I think disabling the about page is a fair decision.
I have an issue (on MacOS, not Linux) with trying to read pdf files from Firefox, as it only lets me set packed apps (.app) as commands to run for specific downloads. I have tried and tried and no solution is completely satisfactory (unlike linux, where I just set emacsclient and it works). Do you have any configuration for this on MacOS?
This is well written, and I learned stuff (the trailing spaces and end-of-buffer indicators).
Modern Emacs configurations tend to revolve around use-package, which wraps up the package installer logic at the end of this configuration and makes it somewhat declarative. Just going by the standards of r/emacs or places like that, it'd be unusual to see a .emacs that didn't ultimately boil down to a bunch of use-package clauses configuring stuff like LSP, Magit, company, ivy, and yasnippet.
If I was going to add just one thing to this starter configuration, it'd be a single example of use-package, to make it clear how to add and configure a package the user just read about online --- it's just such a big part of how Emacs is used now.
+1 for use-package being the only thing that's missing. I'm delighted at how nice this guy makes Emacs look and work with only built-ins (ido in Emacs 27, and fido-veritcal in Emacs 28 go a long way to increasing Emacs' ergonomics imo) but since they're reaching for some installed packages, might as well throw use-package in there to foster further growth.
(If I'm not mistaken, use-package almost made it into upstream Emacs, but they're blocked because one company won't give away the copyright for one contributor to use-package to enable it to be added to Emacs. For the larger Emacs community, I hope that happens soon!)
There will also be icomplete-vertical. Maybe not as good as community/userspace solutions, but many built-ins saw tons of usability improvements. Aside from one or two things, project.el now covers most of the important projectile functionalities. And magit is magit, but for simple things vc.el might be enough. Also the amazing Modus themes finally stopped my theme hopping.
In elisp side, the generic seq.el/map.el and new string functions are now almost enough to not need reaching out to "missing stdlib" such as dash.el/s.el etc.
i actually think icomplete-vertical is great—except one thing. the rotation of candidates i find more visually disturbing than what vertico or selectrum does. +100x for modus’ being amazing. cheers to prot on his great work
If I may, my conf https://github.com/Nathan-Furnal/dotemacs uses use-package quite extensively with lots of things I learned along the way. It's a bit large since I have anything from programming to writing in there but it's mine =)
On this topic, I'd like to mention my own "alternative" to use-package, setup.el: https://www.emacswiki.org/emacs/SetupEl. I write "alternative" in quotes, because it is not really the same thing, just a different way to tackle the issue of using a generic macro to simplify a personal configuration. While use-package has a flat, declaraive structure (for some package, these are my hook, this is the code to run before, this is the code to run after, ...), setup provides a few context sensitive macros that get expanded to regular code. That means you can mix in regular logic a lot easier, and the implementation is far simpler.
Also it is avalaible on GNU ELPA, so you don't need to configure MELPA before downloading it.
> to make it clear how to add and configure a package the user just read about online
The how to configure part would be interesting. Because you literaly never know. Perhaps it's a setq? Or an add-hook? Or a function call? Or a major edit mode? Or a minor edit mode? Or perhaps setq-default? Or setting a variable to t, or perhaps to 1, or perhaps to some other value? Or...
Ahh, I finally get to flex. With our powers combined, me and a random unknown dev successfully set up a Python REPL that has access to emacs. I.e. you can program emacs via python:
Maybe this'll be the boost you lurkers need to get your butts into one of the coolest editors. "Not your dad's editor" -- new emacs slogan, probably. /s
It launches emacs, then uses the (relatively) new dynamic modules feature to start a Python runtime, which can then import a library that accesses emacs.
But to my surprise, Python can also import whatever you already have `pip3 install`'ed. I imported jax and did some high speed calculations in lisp. Just kidding, I really did import jax, but it'll take a bit more work to be able to pass numpy arrays to emacs. :) But it's "just" a matter of making some kind of RPC system so that (+ a b) ends up calling back into python to do the addition. Then the circle will be complete -- elisp from python (already done), and python from elisp ("exercise for the reader").
For real though, go throw that fella a star on his github repo. The most surprising thing was that this project has been quietly on github for like two years already. It was sitting at zero stars when it popped up in one of my random google searches.
That's very cool, but I've personally greatly enjoyed learning and programming in Emacs Lisp. Not only does its ability to immediately evaluate and hot-patch anything work very well with the way it's used in Emacs, but also it was a learning path to a family of languages which is very interesting and unlike mainstream Algol-based ones.
The answer, though, is that I'm not going to bother making a repo and a website and packaging this up in a nice way, so it's always going to seem unrelated to whatever emacs thread I happen to post it on. Or I could just not talk about it, which has worked well for me in the past.
It seemed semi-related, because the goal of the OP and the goal of this is the same: to get new people into emacs. Old emacs veterans have no need for an ~/.emacs. But I really didn't intend to steal susam's thunder -- sorry -- it just wasn't marked as a Show HN.
I bet he’s been waiting a few weeks for the right HN thread to share this new Emacs discovery. Seems only peripherally related to OP as “cool Emacs stuff” but I think he found the right audience. As a daily Vim user I’ll be pulling up Emacs again to give all of this a try.
One thing I always like to note when it comes to the topic of emacs configurations: Mine has steadily gotten smaller and smaller the longer I used emacs.
I'm a relatively new user. I started with Spacemacs, switched to doom emacs, and more recently finally crafted my own config.
The evolution of my .emacs.d was a constant "Do I really need a plugin/preconfiguration for this?" and for me the answer was "no" most of the time once I researched it, so I removed it and either switched to the default, or emacs builtin functionality.
Nowadays my config is ~130 lines as well, which includes a few lines of documentation and notes since my config is an org file.
If I had to trim it down further (or set up a config from scratch to get to work as fast as possible) I'd say that I could trim it down to only a few lines.
Spacemacs was what convinced me to switch from vim to Emacs. However, I found Spacemacs to be unstable and regularly had all kinds of annoying issues. This is quite some years ago, so perhaps things have gotten better.
However, having experienced Evil, Magit, general.el etc. there was no way back. For a while I used my own Emacs configuration that emulated many parts of Spacemacs, but was far more stable.
However, maintaining my own configuration became a bit of a drag. Every time you need another package, you have to figure out how it works and how it can be integrated nicely with Evil/general.el, etc. So, one day I decided to try Doom and I haven't really looked back. It has many of the perks of Spacemacs (sane defaults, space-driven shortcuts), but has been very solid and stable.
I rolled my own emacs config when I started out, for the first 3 years or so. When I saw spacemacs I liked the entire kitchen sink approach, it opened my brain up to a lot of the functionality of emacs/packages that I wasn't touching.
When I saw Doom Emacs though I was kind of skeptical at first (this was about 5 years ago), it seemed to have a lot less batteries included, but I gave it chance anyway, longing after the understanding I got when I wrote my own config. I've been entirely happy daily driving it since. Doom Emacs just seems to have a different philosophy than Spacemacs, it's more like a really well designed configuration framework for emacs on which there are nice layers on top instead of the more monolithic Spacemacs approach. I can easily configure it to my needs, write my own custom modules, and hack on it. It really does a sane job updating and managing the packages, something I would waste too much time on with Spacemacs. So to me is that it seems lower level and better software, yet I still get the preconfigured functionality that allows me to quickly go take an emacs install from zero to hero in a matter of minutes. And did I mention? It's fast.
doom emacs lazy loads modules, and everything they do they consider "performance" when adding packages. Mine config loads on a 6 year old PC in 0.5 seconds. Also they make it a bit more manual to update and control when you want to sync/update. The "doctor" feature has helped me find "broken" install reasons. I don't think it's a "knock the ball out of the park" against space-emacs, but I like the way it works better. It also works well with jit and the new "native emacs" branch. It think they are also working closely with emacs-ng on another branch of emacs which is much more radical.
I eagerly tried this out, and unfortunately it doesn't fix the biggest stumbling block for me: Emacs's tab behavior. Coming from Vim, I never. ever. want to hit Tab and see nothing happen. Regardless of how strongly my editor thinks it knows best, hitting Tab should insert some spaces. I'll even accept indenting the current line the first time I hit Tab. But if I hit Tab a second time, follow my other preferences and insert some character(s).
And in 5 years I can't for the life of me configure this! No solution transparently sets this default for all time. Every new fucking file type I try to edit needs me to go around in circles fixing this stupid behavior.
Sigh. Back to Vim, I guess. I don't understand why this doesn't come up more often in all the blog posts about transitioning to/from Emacs.
Fighting against idiomatic Emacs keybindings is an uphill battle, but the hill is not very steep. The recipe that works for me:
1. Bind the behavior you want in the global map. (global-set-key (kbd "<key-here>") #'the-action-you-want)
2. Any time you encounter a mode which overrides this key, press C-h k <key-here>. It will tell you the name of the map in which the key is bound (usually foo-mode-map). Then, add: (define-key foo-mode-map (kbd "<key-here>") nil). This will unmap the key from the mode's map, revealing the binding in the global map.
>I don't understand why this doesn't come up more often in all the blog posts about transitioning to/from Emacs.
Because most people who use Emacs like this behaviour.
Also considering that this post promises a relatively vanilla editing experience, you shouldn't expect a solution to your particular problem.
> And in 5 years I can't for the life of me configure this!
It is not that hard to solve this. It is extremely easy to map any key in Emacs. You can just map Tab key to insert a tab if that is what you want. It will be like two lines of elisp.
Edit: The reason most Emacs users don't find the tab behaviour a problem is: a, Emacs indents correctly more often than not and b, you can insert a literal tab character when you want using 'C-q Tab'.
You want to create a minor mode (minor mode overrides major mode key bindings) and have the minor mode enabled globally. use-package has a bind-key* function that does this I think. Something like (check the syntax, I haven't tested it)
I think the problem in your lobste.rs post is that you have (bind-key* "Tab" ...) instead of (bind-key* (kbd "tab") ...). I don't think your define-key solution works because I think it can be rebound by major or minor modes. I think bind-key.el is required by use-package so if you have use-package you should have it. If you don't have use-package you should install it.
I'm not at a computer with an emacs installation so I can't try it out myself. I would try binding to a regular key (e.g. "q") while debugging to try to reduce the possible problems.
I think you'll find that remapping tab everywhere like that is going to break a lot of things though (navigating fields/links, expanding sections, etc). You might want to just remap the key by explicitly listing the modes you care about.
The #emacs channel on libera (previously freenode) used to be amazing but since IRC waned it's become less good but if you're lucky and during busy times you might still find someone there that can give you a better solution.
Thanks a lot! Yeah, I'm already realizing I need to be careful what I wish for, because I can't tab complete anymore after C-x C-f. I think I'm going to follow the process outlined by CyberShadow: https://news.ycombinator.com/item?id=29726398#29728696. I'm not hung up on getting this perfectly automated, just want to not have to think about this the next time I run into it.
Someone above pointed out that you can remap it for prog-mode which (I think) programming modes derive from so (again, I think) if you remapped it there you would cover the programming modes. Then you could add the few other modes that aren't covered. You would define a list of the modes and loop over them in your init.el to remap them.
The other thing you might want to try is to remap the function indent-for-tab-command to insert-tab.
No! I've somehow never encountered `tab-always-indent`, according to my detailed past records. It actually looks like `(setq tab-always-indent nil)` should get me pretty close, according to the documentation.
"If the value is t (the default), the command normally just indents the current line. If the value is nil, the command indents the current line only if point is at the left margin or in the line’s indentation; otherwise, it inserts a tab character." (https://www.gnu.org/software/emacs/manual/html_node/elisp/Mo...)
Unfortunately this doesn't immediately work as described (Mac OS, GNU Emacs 27.2). When the buffer x.c looks like this (^ showing point):
int main(void) {
aaa
^
Pressing Tab now does nothing. I wonder if I need to do something to add this to c-major-mode. I also don't yet understand `setq-default`.
We've hit comment depth limit, but check out M-i (tab-to-tab-stop), other people seem to declare that that is the solution for them (and they rebind it to tab per mode).
Ah, yes, this ([c-]tab-always-indent) seems to work. On both my machines. I'm slightly leery of declaring victory, but this might do the trick for me. I think the major reason I care about this so much (I don't have any unique-snowflake indentation approach) is being able to indent prose inside comments. This approach would buy me that. Let me run with it and see how it goes. Thanks again.
Update: now nothing is working. I think maybe it's because I switched machines from Linux to Mac. Nothing is working on Mac OS running GNU Emacs 27.2 installed using `brew install`. I'll circle back in a few hours and post a more careful update describing what I see on each machine (if that matters) with each of the solutions.
Have you tried hooking self-insert-command to the modes you'd use it on? Like prog mode and fundamental. The only corner case I can think of is if you'd like to tab-insert in org-mode and also expand headings using tab.
I have been a vim user all my programming life which is not very long. Can you please provide me straight-to-the-point, opinionated, no words twisted, maybe personal reasoning why I should use Emacs over vim?
This is a very honest question.
EDIT: This question is more- what motivates you to be an Emacs-er? Why do you use it? I would love to hear your reasoning behind choosing and sticking with an editor.
Thanks to umanwizard for the answer. Someone else said that it is best to experience it yourself. But you have to understand that mastering a new editor is a non-trivial time commitment. I am willing to put the time and effort given it is worth it. That is what I am trying to find out.
Someone on HN said just some days ago- you cannot simply be a tourist in Emacs and hope to get everything that is good with it.
Well, the "editor wars" are silly. You should use whatever you prefer. That said, I started using Emacs a few months ago, and can explain what I like about it.
Emacs is not really "an editor" in the sense that vim is; it is more like a platform for building custom IDEs. It's built from the ground up with customization and exploration in mind. Want to know how some function works? It's very easy to jump to the code where it's implemented and start reading. Have you ever thought "I wish my editor did this or that" ? In emacs you can just write the code to make it do whatever you want.
Other editors support plugins, but they're not nearly as seamlessly integrated into the core editor as they are in emacs. Emacs is mostly written in elisp (which is the same language that plugins are written in) so there's basically no difference between plugin code and emacs itself, they are all just running on the same elisp vm in the same namespace.
so much this. as another commenter posted, you can configure emacs to just "be a vim" with evil mode anyway, so you can treat it like it's vim, and when you see a package somewhere that does something cool, add it. the thing that emacs gives you that vim doesn't is limitless extensibility. as an editor, vim probably has better bindings (it does in my opinion at least), but there's no reason you can't have all the cake.
Check out evil mode [0] which brings vim keybindings/modes into Emacs, so you will have easier time checking out emacs and making your own opinion. I still use both, vim for quick edits/on the systems where I don't have an emacs config.
For me the reason to prefer Emacs would be its extensibility and ability to modify pretty much any behaviour. I'm no fan of elisp, but it's much more reasonable than vimscript.
This sounds really interesting. So, even if someone chooses to migrate to Emacs, they can still be in-practice with vim. So, when they need to work on someone else's computer or SSH into a server, they will still not lose any efficiency.
I moved from vim to emacs using emacs doom. Which is a configuration of emacs that makes it feel a lot like vim. Its a good place for vimmers to start imo.
However, its a good idea to stop using emacs doom at some point and get your hands dirty with configuring emacs. This just makes the transition more gradual.
I was a hardcore vim user for many years, and switched to Emacs a few years ago.
It’s hard to give a concise, objective reason as to why. My best attempt would be something like “vim is a great editor, but emacs is a great ecosystem”.
I always felt like vimscript got in my way. If I wanted to do something out-of-the-box if was overly difficult to even start. I know there are vimscript wizards out there but it never clicked with me.
Emacs, by contrast, feels like it has no limits. If I can imagine it, I can get emacs to do it. I wasn’t a fan of lisp at first but honestly I have come, over the years, to actually enjoy it.
The thing that really sucked me in though was org-mode. I haven’t found anything like it anywhere else. I use it to manage my team, my projects, my side-hobbies, and my extensive collection of notes. The agenda is amazing and capture templates pull it all together. In the beginning org-mode was what kept the learning curve from driving me away, and now I really can’t imagine using anything else anymore.
Oh, also, tramp is killer. I used to ssh into a sever and open vim there. Every time I was annoyed that my extensive vim config didn’t exist there, but it wasn’t practical to port that sucker over everywhere. Now I just connect from my local machine over tramp. I don’t have to deal with config mismatches, editing happens locally so I don’t have to deal with input lag, and it’s so seamless that I don’t actually miss out on anything. I can edit the file system, open a terminal, run shell commands, whatever.
I think that we limit ourselves when the question is either/or.
Personally I use JetBrains for work and for languages that I'm still learning (Ruby and RoR), vscode for almost anything web because their support for JS is unreal. I use vim for pretty much every config file and quick edits, and will find myself pulling up vim when I need to make some more complicated edits on a file since macros on vim are AWESOME.
And then I use emacs (with EVIL) for beancount files and it works phenomenally for that! I have used it for some Elixir and it just works!
Emacs is really less of an editor and more like a framework/platform/dare I say OS? It allows you to customize and build on top of it like no other software I've come across.
So I'd say, if you are up for exploring check out emacs (I would just start by installing EVIL instead of trying to learn all the "chords" that emacs uses by default) and enjoy the journey!
Trying a new editor isn't so much fun to this old dog.
Also trying all the fun and interesting things in the world would take thousands of lifetimes: choose wisely how you spend your time (which is the most limiting resource many of us have in this world).
I use Emacs, but not exclusively. It's my daily driver but I'll still open VS Code sometimes, and I'll still do a bunch of stuff in nano or Vim if I need to.
What motivates me? The lisp-based config is a big one, I can learn how to configure Emacs and the knowledge of lisp is transferrable outside of it. I enjoy hacking on Emacs that way because I also like lisp.
It's also been 10 years and I'm just used to some of the emacs conventions. I don't use vim keybindings, I have a minimal config that sets up language modes and syntax. It's comfortable for me.
So the simple explanation is that I find joy in working with emacs, and as much as I find joy in working with other tools too, I still come back to the joy that emacs offers me. It's a comfortable and familiar environment for the things that I spend the most time on, and I use other tools for everything else.
I've been using some vi-like since around 1990. I guess I'm still using a vi-like as I'm now using emacs with evil-mode for most things.
What got me to switch was developing in common lisp. I hear things have much improved, but at the time the best setup for vim was a really hacky tmux (or maybe gnu screen?) repl that was spawned and vaguely controllable from vim. I started by just using emacs as a lisp REPL on steroids, and then started to do more with it.
My fingers know more vim key combinations than my brain, and they refused to change for emacs. evil-mode didn't exist yet, so I settled on using viper (an older vi-like mode) and any time my muscle-memory did something that didn't work, I figured out how to add that particular key binding. It was super hacky, but Worked For Me to let me use emacs for lisp dev and vim for everything else.
From then on it was all downhill; there were so many things that you could do in vim, but were harder and the vim packages tended to be less polished than the emacs packages. Neovim seemed to recognize some of the issues with extending vim, but (at the time) was really a terminal-first editor. Now that I could switch between the two without my fingers complaining, when something was better on emacs, I added that to my "list of things I do with emacs."
Eventually most of what I do is in emacs rather than vim, and I reach for emacs first. I had to engrave some music for my son the other day; I've used lilypond (kind of LaTeX for music) in the past so I decided to try it with emacs. Turns out lilypond ships with an emacs mode that does all the basic things, plus registers a command for running lilypond on the current buffer. Tile my pdf viewer next to emacs and I can see the results with a single command.
I can (and have) set up a similar thing with vim, but the community around emacs seems to really take seriously that emacs is more of a gui toolkit with really good text support, while the parts of vim community is suspicious of any significant new functionality to vim that isn't specifically about editing text.
When I was choosing the next editor to settle on and invest into, what convincingly swayed me towards Emacs was the number of reports of vim users who later moved to Emacs, vs. the number of reports of users who moved in the other direction.
I like using Emacs because it does everything. Sometimes not well and you have to let it go, for example I wouldn't imagine managing Java projects in Emacs. But there's a world of discoverability and learning in Emacs that's unmatched in my opinion. The writing experience is especially excellent, I write all my notes and presentations in Emacs, they can be linked together, compiled to PDF or Word, use interactive code blocks and much more, it's fascinating.
It also made me interested in subjects I didn't know about like knowledge management and the history of Lisps, thanks to its community.
I use Emacs because it's the superior tool for editing ~/.emacs.d/init.el[1].
For me, it's just fun. I like writing lisp. I like how Emacs by default presents you with a *scratch* buffer meant to be used for trying out customizations and extensions to the editor. I like how I can modify almost any behavior of the editor to suit my own idiosyncrasies. I like the extremely high quality of the community[2][3][4]. I like how the LSP protocol means that I can benefit from considerably more advanced IDE style functionality than I could even a few years ago. I even like the archaic Emacs style key-binds. However, I do at a bare minimum remap capslock to control and I've been exploring other options like configuring space to input space on a tap and control when held down.
They're just incredibly different programs. I'd say use Emacs if you wanna be able to deeply customize your experience. The flexibility Emacs gives is much superior to anything you get with Vim.
I use both. Vim is my to-go setup, with a minimal config, and an assurance that I can count on it being installed on almost every server I am working on. Emacs is my home court, where it is open all the time with about 100 various files open, and with all my organization and productivity tools available.
Vim is absolutely worth learning for the workflow alone, it's just a really good editor at heart. Emacs is worth learning for the fact that it can do almost anything, and can do them well (even emulate vim :)
> This question is more- what motivates you to be an Emacs-er? Why do you use it?
I did a bunch of quality time with TECO on the PDP-10.
I started using emacs-like editors back in 1985 under Coherent or so when DGC wrote MicroEMACS, which is now MG on most systems. EDIT: this was a replacement for good old ed.
Later, under Dec Unix I used emacs . I have stuck with emacs ever since as it does what i need it to and is easy to add functionality and automation for many tasks.
i filed my taxes with emacs and org mode need i say more? :-) .
I imported bunch of csv's in org mode table added formulas to it and used it as spreadsheet all the while adding my own comments that will not be visible in the final version and than merged them and exported it back in json format which is understood by the tax software. I also exported it in html format for external viewers(who don't have emacs)
That's cool, vanilla Emacs can be great depending on your needs, specially for getting used to Emacs. I wonder if there are similarly clean configs that includes more important packages, besides Witchmacs.
This config is notably missing conservative-scroll, which I consider essential. A light theme option would be nice too (whiteboard is great). Other important configurable builtins are electric pairs, y-or-n-p, ispell and mouse-yank-at-point.
If you're using this, beware default redo is very unintuitive, and installing undo-tree is a probably a great idea. And it enables emacs server, you might prefer daemonizing instead.
Looks nice as a simple zero-dep setup. That said, I would recommend one of the modus themes[0] as an alternative when Emacs 28 comes out, since they're built in to that version. They're amazingly thorough and accessible.
Though with `use-package`, it has become incredibly easy to make even complex setups self-booting (assuming you have an internet connection available anyway). It adds all of 5 lines (or 8 if you need melpa) which is rather incredible for the value it provides.
I use straight combined with use-package and it's great. I don't really need to since I rarely hack on packages in the way that straight imagines you would, but I like the middle ground it introduces.
I know with use-package you'd do all this in the macro with config and init, but especially when it comes to dependent packages I prefer having things flat as opposed to nesting them.
My config is apparently 333 lines but a lot of that is whitespace and comments for grouping, plus the bootstrap code which I incidentally use for publishing my blog.
> I know with use-package you'd do all this in the macro with config and init, but especially when it comes to dependent packages I prefer having things flat as opposed to nesting them.
>
> My config is apparently 333 lines but a lot of that is whitespace and comments for grouping
The reason I like `use-package` even for global concerns (I actually have a `(use-package emacs)` e even though that's pretty much entirely global setqs) is it provides some grouping structure and encourages keeping each item in the proper place.
`:ensure` is also pretty much essential as that's what does the bringing-up (ensuring the package being enabled and configured is actually installed locally).
That way the menu is only disabled in the terminal. Beginners might find the menu useful when running a GUI on Windows or Linux—I certainly don't mind the menu on macOS as it is always there for Emacs.app (regardless of the value of menu-bar-mode).
But note also that an Emacs instance can open frames on multiple displays. This is not necessarily that hard to get if, for instance, you start with some X frames and then invoke emacsclient in a terminal in a way that causes it to open a character-cell frame there. window-system is documented as a terminal-local variable for this reason, and similarly the display-foo-p functions take an optional selector argument.
Which means that if you care about that, querying any of those once from your init file will not necessarily do what you want, and you should consider attaching to something like after-make-frame-functions. The global menu-bar-mode explicitly states that it applies to all current and future frames, too; toggle-menu-bar-mode-from-frame seems to be the per-frame version.
But if it's just cosmetic and you don't care about some variance in that case, then whatever. :-)
I guess I didn't get the memo. I don't see what was wrong with `window-system' as it allowed stuff like `(eq window-system 'mac)' and `(memq window-system '(mac ns x))' which is nice if you're using different OSs/environments and need tailor your config.
If you are trying to check what OS you are running wouldn't system-type be better? (eq system-type 'darwin) You could be running X on multiple different systems. Although I checked the output on netbsd and openbsd, both return berkeley-unix as the system-type... which isn't quite as helpful. At least I know if I'm on gnu/linux vs a BSD I guess. The docstring helpfully lets me know that a value of gnu means I'm running on Hurd. It also recognizes gnu/kfreebsd apparently because you can't throw a rock without hitting one of those.
I have `(menu-bar-mode 0)` in my init.el and I get no menubar on macos, emacs@plus installed with homebrew. Agree though that it's stays out of the way and I might re-enable it just for mac
I’m running the Yamamoto Mitsuharu version of Emacs.app so maybe it is patched to ignore (menu-bar-mode 0).
I recall having my menu bar disappear on some other version of Emacs.app in the past, but I think it was from setting menu-bar-lines to 0 in the frame properties.
I think you should be able to replace the "disown" with "nohup", thus making the startup script POSIX compliant.
A general question would be what version of Emacs you are targeting. As even Debian stable distributes 27.1, you could make use of newer features such as fido-mode (instead of ido and ido-everywhere). Then the package configuration doesn't need the package-initalize either (On that topic adding NonGNU ELPA would also be nice). Also, what it the point of just displaying the current time for two seconds?
Using "nohup" was my first choice too. Unfortunately, it does not prevent the Emacs process from dying when we kill the shell from which we launched Emacs. If the shell is killed, Emacs dies too. I have confirmed this behaviour on macOS 10.15.7 + Zsh 5.7.1 as well as Debian 10.0 + Xfce 4.12 + Bash 5.0.3. As a result, I was forced to use "disown" to ensure that the Emacs process continues to run even when the shell dies.
By the way, fido-mode is something I am going to add to this configuration in future, so thank you for the suggestion. I do use fido-mode myself in my personal Emacs configuration. However while publishing this project today, I could not make up my mind today whether I should still keep ido-mode around while suggesting fido-mode to beginners.
In my personal config, I have both ido-mode and fido-mode enabled in my configuration. For file searches, ido-mode seems to be superior. For example, ido-mode can search deeply nested subdirectories recursively for a match, something I have not been able to do with fido-mode yet.
An update to the previous comment. It is true that typing `nohup emacs &` directly into the shell does not help, i.e., Emacs dies when the shell dies. Example:
The parent of the emacs process is still bash, so when bash dies, Emacs dies too.
However, invoking `nohup emacs &` from another shell script does work. The PPID of Emacs gets assigned to 1 and Emacs continues to keep running even after killing the shell. Example:
In the second experiment, the parent of the emacs process is the init process, to it continues to run successfully even after the shell or terminal exits.
To summarize, yes, we can use nohup in the startup script and make it POSIX compliant.
Perhaps of interest, I wrote something similar a few years ago for my university in German: https://wwwcip.cs.fau.de/~oj14ozun/src+etc/init.el (here a HTML version https://wwwcip.cs.fau.de/~oj14ozun/src+etc/init.el.html). My intention was to demonstrate different configuration patterns. It even tries to configure Gnus to work OOTB for our university mail accounts. I should probably update it for Emacs 27.1 and change a few things where my tastes have changed.
Awesome. My .emacs very slowly accumulates little bits that I like every time I find pages like this. About once a year I find something new that I like and I add it. At this point, my .emacs is about 80 lines (not counting comments) accumulated over the years since the 1990s. The only packages it depends on are programming language modes that aren't distributed with emacs itself.
My vimrc is similar - just around 50 lines accumulated over the same time period since the 90s.
I recently went back to emacs to try working out some problems in SICP. And the first goal I set for myself is not to go down into emacs config hell.
I went for the simplest thing I could set up: paredit, aggressive-indent, parens-mode, chez(inferior lisp)
So far so good, but one thing I noticed, I had forgotten paredit commands, and emacs isn't very pleasant if you don't have things in your muscle memory.
By and large emacs is best system you can use if you are writing lisp.
When I began using Paredit for the first time, several years ago, I could never remember which key sequences slurp and which ones barf. Then I made up some mnemonics.
C-( and C-) have parentheses that look nice and round. They expand the current s-exp to consume other expressions. Nom nom nom!
C-{ and C-} don’t look nice and round. They have braces which look a bit wiggly. They shrink the current s-exp and barf expressions.
These mnemonics have served me and others I have shared this with very well.
This is really nice, but for me there's one thing that keeps me away from emacs, and its good multi cursor support.
Very frequently, I'll want to perform this kind of process:
1. I search for some frequently occurring string or regex in a file.
2. Get a series of cursors for every result of that search.
3. I'll know that it's possible to do a manipulation of all these lines, but frequently it's not immediately obvious how, so I experiment a bit at this point. Frequently I end up doing things like manipulating the cursor to delete sections of the line, and modify the shape and order of some elements. This requires I can select portions of text, cut them, and paste them in a different part of the line. So each cursor needs to have its own clipboard. I also tend to do things like add variables to the cursors. Sublime has a nice way to have incrementing integers so the first cursor inserts a 1, the second inserts a 2, etc. There are all sorts of little tricks like this. One appeal of something like emacs would be having a simple language to write stuff like this quickly myself.
4. After experimenting, I complete the manipulation. If I fail the first time, I undo, and do it again.
This kind of thing takes less than 15 seconds for me, but it saves a ridiculous amount of time.
It's really useful during this to actually be manipulating all lines at once, since it lets me see where assumptions I have about the data I'm manipulating is incorrect.
I've tried every multi cursor package I've seen in emacs, and I've tried to figure out how to get this kind of thing down through macros, but the live editing of multiple lines seems invaluable and keeps me in Sublime/VS Code. I'd love to know if I'm doing something wrong with macros, there's a solution to what I'm trying to do, or if realistically my best bet is to stick to what I know.
There's an incrementing counter for regexp-replace, a way to manually enter a part of each replacement, and other goodies.
Personally I only use capture groups, no counters or other stuff.
I do like using M-p to edit my previous failed replacement before trying again. Sometimes I use a simple replacement as a test, undo it, then edit it to add further modifications.
Thank you so much! This is exactly what I was looking to find out. I had no idea I could trigger custom behaviors like this using regexp-replace. I’m going to need to get quick with it, but this should be enough of a reason to really work on making the switch.
I have not tried the multiple cursors package, but regarding the problem of manipulating several lines at once with instant preview, you could look at the visual-regexp package:
Try macro record / macro playback. While saying this I hate that I’ve never properly learned how to debug a recorded macro, or manage them better, but they largely suit my use cases.
I thought by the time you get to .emacs in current versions, the package manager is already initialized?
Also curious on the benefits of single space for sentences. I confess I don't use abbreviations that need periods often; but I also don't use many commands that work on sentences. (And, I do still use two spaces for sentences.)
I have both an early-init.el and init.el in my .emacs. In the former I turn off package loading on startup, but also set most UI variables so menus etc are turned off before the frame is shown (stuff you might once have done with Xresources). This is also where you might do more extreme performance related tweaks (e.g. to the GC) if you really care about startup time. My init.el then does package-initialise and is mostly use-package calls.
That is your.emacs.d, I presume? I am still mostly carrying around a .emacs and not using init.el.
That said, played with this some today and I see that I can get my startup down to about 5 seconds on my old netbook. Not too bad, all told. (This computer is hilariously slow.)
esup is a great way to see where the time is going. It's not really a big deal in the grand scheme of things but it's also a good way to learn about autoloads etc.
Thanks for this, I found a few things to investigate adding to my own config.
I have a question about the server/client mode:
> Experienced Emacs users run a single instance of Emacs and do all their editing activities via this single instance.
What's the motivation for running it this way? I think the repo should explain why, especially since it's targeted at newbies. Also because it looks like a lot of effort was put into explaining how and discussing the em script that makes it more convenient.
For what it's worth, I'm an experienced Emacs user, and I don't run a single instance. Instead, I start lots of new instances. As best I can tell, the motivating factor for a single instance is startup speed. However, I'm satisfied with my startup speed and haven't felt the need to improve it with server/client mode.
My initial motivation for using daemon mode was start up speed as my config had ballooned. I got it under control later, but emacs also got faster later so it was mostly moot in the end. Speed is no longer a motivator for me.
There are a few uses, for me, of daemon mode that have kept me using it.
First, like tmux and mosh, emacs daemon is persistent. Should I accidentally close it but not really intend to close it, everything is still there. Useful if you use emacs for more than just editing (like an IRC client). In that instance, all my buffers are still present and anything that needs ongoing execution will continue to happen.
Second, I never got used to using emacs as my shell. So I drop back to the shell for most of my filesystem navigation and running various CLI tools. With the daemon running in the background, this means I can close the client, navigate or run programs, and reload the client with everything in place or while opening a new file.
Third, I often use multiple daemons, one for each project/language. I use the shell to go to the project root and launch a new (named) daemon. Then when navigating around the project in the shell, I can open a file for editing using the appropriate client incantation. This lets me keep a full emacs daemon running but with only the appropriate buffers and subprograms (useful when dealing with interactive languages like Lisp or Erlang, where I may also have a project-specific REPL running).
Fourth, I use magit and tmux. So I usually split my window into two panes with editing/navigation/CLI activities on the left and magit on the right. The magit instance gets to share the same kill ring and buffers as the editing instances on the left. I know I could do the same by splitting the frame left and right the same way, but this has become my preferred interaction. Plus, since I don't use emacs' shell mode I often further subdivide the panes anyways, like editor in the top left, magit on the right, and shell in the lower left with fswatch running tests continuously.
I suppose that if I just did everything in emacs (including the shell and file system navigation) then it would be less useful. But I don't, so it's very useful.
Thanks for this great explanation! These do sound like useful reasons for daemon mode. My workflow is pretty different, so some of these wouldn't apply to me, but it does give me a lot to think about plus some potential workflow tweaks.
The multiple daemon approach is intriguing. I don't think I've run across anyone discussing that before, although a quick search turns up a few posts/threads that I've missed.
I used Emacs for everything, until I got chronic pain in my left pinky and went back to "traditional" editors. I've been willing to give it a go again in cua-mode, but couldn't find the time yet.
And yes, I have tried to replace left-ctrl with capslock, but it was annoying as well.
I maintain a somewhat extensive Emacs config, and I've kept a lot of the default key commands. I find them incredibly ergonomic, and as a bonus you'll find it's the default in most terminals.
I use the side of my palm for C, it doesn't take long to get used to and allows you to keep your fingers on the home row. Obviously this transfers to CUA or any other standard/config that utilizes C.
Do you use a laptop keyboard? Pressing control with the left side of the left palm is just so natural I don't understand why people even use their pinkies, I think I started doing that even before using emacs.
Well, it wasn't that much annoying, but I would sometimes have to use other people's (customer's) computers and I kept pressing Capslock hoping it would be Ctrl like an idiot :)
Besides that, can't remember if it was on Linux or Windows, but there was an input lag when using Capslock as Ctrl. I had to wait like 1s for it to register. Mostly unusable, and I used both systems a lot at the time.
Yeah, relying on that when you use foreign keyboards makes life difficult. I take an in-between approach and redefine just a couple of keys such that I can get away with just few lines of config.
I used emacs ever since grad school days, and was reluctant to switch to an IDE (specifically JetBrains / Pycharm) but finally invested a few days to switch, and now I would never use emacs as an IDE. There are a couple scenarios where I still like using emacs:
* for quickly opening and editing a file without using a bloated IDE, especially on remote Linux machines.
* for magit (git tool inside emacs) which is honestly a super power for those who know it.
As I switch jobs and machines I keep looking for a “quick” config , and I find doom emacs suits very well.
Emacs is complex enough that learning it and elisp si comparable to learning linux and bash. I mean it has package and process management, logs and everything.
As a new emacs convert after 20 years of vim I will try one day to start from scratch for learning purposes. But just like I would not use LFS for work I would not use vanila emacs either. I use debian distro for linux and doom for emacs.
I'm sure doom and spacemacs are great, but the idea that vanilla emacs is just too hard to use isn't true. Doom and spacemacs are just layers of complexity on top of a very simple concept - install and configure some packages. Using this template you can see there is no black magic there and how easy it is to add packages.
You don't need to know any elisp for that. I've been using emacs for years and probably couldn't write a "hello world" in elisp. Configuring packages can be done in the configuration GUI, or else it is just setting some variables - I think I've only ever used 3 eslip functions - (setq), (add-to-list) and (add-hook).
Honestly the hardest part of emacs is finding which packages are quality and worth installing. This is where I find doom/spacemacs/prelude emacs useful. I browse their repos every now and then to see what packages are worth trying out - and install them with the built in `package-install` command.
Sure, but the layers you list there significantly simplify those tasks. I'm not sure spacemacs/doom/etc significantly simplify using emacs. They are an alternate abstraction of roughly equal complexity.
You can get a long, long, long way into Emacs without even a faint understanding of elisp. Lots of people get into Emacs because they want an extremely programmable editor, but most people get into it because they can draft off the programming that other people do.
I was trying to switch to emacs, but one thing that drove me nuts was the start up time. I had installed spacemacs, and I prefer my text editor to start up immediately. I could not find the setting to disable checks against the internet on every start up.
I think this is a step in the right direction. It's definitely a better initial experience of emacs (including Doom/Space), but even after trying this out I experienced several (emacs-core) frustrations.
Just now I experienced: weird keymaps (C-? C-? to do things, including exit... do I have to Google keymaps, read docs about keymaps, remap keys to my own preferences, or just memorize existing keymaps?), signaling EOF (normally Ctrl-d) doesn't quit (gives a weird error "mark not set"), not knowing which buffer I'm looking at or how to list/switch buffers, no (initial) mouse support, no idea how to search and replace, no idea if spawning multiple cursors is possible.
All that in a span of ~5 minutes. I'm not trying to hate on emacs, just trying to list some pain points of the UX.
I'd be willing to give another emacs dotfile a shot, but I think it'd have to be even simpler than this one.
I tend to use sane emacs when Im on a new system and just need to be up and running real fast and dont have my current dotfiles, but this looks like it is pretty awesome! Good stuff and well done!
