Emfy: Emacs for You – Quickly set up vanilla Emacs for editing

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.

Thank you for the line-by-line explanation! That’s incredibly helpful for new users and helpful even to moderately experienced users.

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?

Hi!

Thanks a lot for this.

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?

Just in case. Thanks again!

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 =)

+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!)

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...

I don't get what this has to do with OP?

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.

this is just a bizzare and unrelated post

> I'm a relatively new user. I started with Spacemacs, switched to doom emacs, and more recently finally crafted my own config.

I use Spacemacs (and I like it). For people who switched over to Doom Emacs, I like asking them why did they switch over? What were your reasons?

I too am interested in the Tab question

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.

Edit: Try this:

  (defun indent-for-tab-command ()
    (interactive)
    (insert-char #x20 4))

>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'.

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.

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)

      (require 'bind-key)
      (bind-key* (kbd "tab") (lambda () (insert "    ")))

And you should probably construct the number of spaces from the tab-width variable.

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.

Like many things in life, the only way to truly know is by experience.

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.

The 'should' in your question is doing a lot of work. You should do what makes you happy.

Sometimes that means trying new things to see what makes you happy!

You should keep using vim; there isn't a straight-to-the-point reason why you should switch from vim to Emacs, or vice/versa.

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.

[0] https://github.com/emacs-evil/evil#readme

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!

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 :)

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, 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.

You may enjoy https://youtu.be/JWD1Fpdd4Pc, presented by someone who hopped over from Vim.

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.

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.

[1] Haha, only serious.

[2] https://protesilaos.com/emacs/dotemacs#h:7b39c38c-ae23-4385-... has a nice list.

[3] https://github.com/rougier#emacs-hacking

[4] And there are so many more. https://old.reddit.com/r/emacs/ is a good community too, despite its parent site's reputation.

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.

To maintain your sanity, I recommend Doom Emacs.

My initial reason for using Emacs was Org Mode.

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.

Yes, Org Mode.

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)

> 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.

> Looks nice as a simple zero-dep setup.

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.

Note that `window-system' is deprecated in favor of `(display-graphic-p)'.

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

Or the even newer XDG-compatible ~/.config/emacs/init.el

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.

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.

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.

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:

https://github.com/benma/visual-regexp.el

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 always use regexp-replace for this.

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.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Re...

You can (setq package-enable-at-startup nil) in early-init.el to stop package loading before you get to init.el.

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.

I am very interested in this particular use case. What turned out to be annoying about it?

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.

Swap control and alt so that you can hit Control with your thumb. The thumb is much stronger than the pinky.

You can use emacs with vim-keys or any other config you like.

I never used the built in keys for cursor movement (I use the arrow keys), buffer switching (I define my own more efficient key), etc.

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.

Why not use right-ctrl in combination with keys on the left hand side? If the answer is "because there is no right-ctrl", that can be changed.

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'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.

Pick whichever, it wouldn't be emacs if there wasn't at least 3 ways to do something.

read this for a complete answer https://www.gnu.org/software/emacs/manual/html_node/emacs/In...