A "minimal working" Emacs setup
As a long time Emacs user, I again switched back to Emacs after a few months using Vim exclusively. The deal breaker is, as I write more and more stuffs other than program code, the pain of using non-Latin input method with Vim became unacceptable. Also as I have been learning Common Lisp for a few months, I feel that for me writing Emacs Lisp might be more fun than writing Vim script. And I can finally have 100% power of slime[1] mode.
Make it start fast both from terminal and as GUI app
The startup latency of Emacs is fairly high. Compare to Vim, you can clearly feel a bigger latency with similar amount functionalities setup in vimrc or init.el. If your use case is starting an Emacs instance in GUI mode, do everything in it, and only exit Emacs at end of the day, the startup latency should not be a problem. But if sometimes you do the work/poke around the system in a terminal, and need to edit some small files quickly and then exit the editor, then you need a way to get rid of this issue.
To smooth the experiences, I use Emacs's daemon mode and two simple shell script wrappers of 'emacsclient'. I put both these wrappers in my PATH.
File '$HOME/.local/bin/e':
#!/usr/bin/sh # Start Emacs --daemon if not started already; open in terminal mode. exec emacsclient -a "" -nw "$@"
File '$HOME/.local/bin/egui'
#!/usr/bin/sh # Mainly for using with dmenu or other system launcher. # Start Emacs --daemon if not started already; reuse or create new GUI frame. exec emacsclient -a "" -r "$@"
These two wrappers are basically the same, excepts 'e' use '-nw' option to make it always start in current terminal, and 'egui' use '-r' to make it start a GUI (frame) if there is not an existed one. The '-a' option with an empty string as value, tells 'emacsclient' to start an Emacs daemon if there is not already one started. This is just an example to demonstrate the simple idea, you may want to create different wrappers for your specific usage scenarios.
With this setup, now you can 'e file' from inside terminal and 'egui' from dmenu or other system launcher, without even noticing the latency.
One possible caveat is that as Emacs daemon is a single long running instance for all your editing, you might get more and more buffers opened inside it. I usually delete the file buffer immediately after an ad-hoc editing. For project(see the next section for project in Emacs), once I finished working on it, I close all buffers of that project. Also, it's easy to deleting unused buffers at once in Emacs's buffer list buffer.
"Essential" packages
Packages should be included incrementally, only when you really need them. Copying somebody's dotfile entirely from internet or including a lot of packages recommended by some blog posts, will only make your Emacs unnecessarily slower. Thus the section title has "essential" quoted - bare Emacs works well, there no package that is absolutely needed.
However, there are still two packages - projectile and ivy - I would like to recommend. They won't make you Emacs look fancier, they just let you perform the most frequently performed actions in Emacs much more easier.
Projectile let you perform actions at project scale easily - opening files, find buffer, bulk close buffers, etc. A project is just a directory has certain properties - projectile package explained the concept clearly in its documentation[2].
Ivy[3] is a interactive completion interface. But I prefer to see it as a more general purposed fuzzy finder - let you find files, buffers, commands easily.
One more package you may want to have a look is use-package[4], especially if the number of your packages go beyond a handful, or you need to reproduce your Emacs setup on multiple machines. It makes package management more easier.
Notmuch Emacs interface as email client
The discovering of Notmuch[5] Emacs interface is a surprise for me. Although I only have been using it for about two weeks, I feel I'm probably going to stick with it. Its interface and default keybindings are intuitive, it searches fast, customizing with Emacs Lisp is much more pleasant than with a shell like language (yes, I'm a shell scripting hater).
Most importantly, the underlying idea of managing emails via tag system is so nature and brilliant. There is no need to care about emails come from which email account, are inside which IMAP folder, and so on - although you can if you really want to: with notmuch's 'path:' and 'folder:' search terms. Just "M-x notmuch", and jump to the interested tag and hit Enter. And while in the emails list buffer, tag your email as you like.
A basic setup could be:
(use-package notmuch
:hook ((message-setup . mml-secure-message-sign-pgp))
:bind (:map notmuch-search-mode-map
("K" . (lambda ()
"mark message as killed"
(interactive)
(notmuch-search-tag (list "+killed" "-inbox"))))))
This setup enabled default pgp signing when sending mail, and added a single key binding to mark unwanted emails as 'killed'. I also put the following into notmuch pre-new hook:
#!/usr/bin/sh notmuch search --output=files --format=text0 tag:killed | xargs -r0 rm
So emails marked as 'killed' will be actually deleted before next 'notmuch new'.
If you use mutt and manage your emails offline (locally), I encourage you to give a try of notmuch Emacs interface. As you already have 'mbsync' and 'msmtp' or similar tools setup, setting up notmuch is an easy step.
For more information, there is nice writing up on stackexchange[6], and notmuch also has an emacstips[7] page.
Others
You probably also want to tune a few settings of Emacs to make it work more "sensibly", but it's nothing wrong if you feel all the default behaviors make sense to you. Search "Emacs beginner" most articles will list some of these. You can also use my Emacs initial file[8] as an reference.
Again, don't copy them directly into your dotfile, try to understand what these settings mean and set them accordingly per your own needs. "C-h v" is your help.
------
[1] SLIME: The Superior Lisp Interaction Mode for Emacs
[2] Projects section of projectile doc
[5] Notmuch - just an email system
[7]emacstips on notmuch offical site
---------------------
Published on 2023-11-26
The content for this site is licensed under: