This is in response to issue 12 in my dotfiles.git.I am posting it here since (i) some of the information is useful ingeneral and (ii) it is easier for me to find it here.The specifics of my Emacs configuration: https://protesilaos.com/emacs/doteamcs https://github.com/protesilaos/dotfiles/tree/master/emacsConfiguration modules and Elisp packages What is the motivation to divide between what seems to be like e.g.prot-lisp consisting of what seems to be just functions (library)and prot-emacs-modules which seems to be just package configuration(like what you’d fine in the body of a use-package declaration)?I keep prot-emacs-modules and prot-lisp separate because they havea different role. The latter consists of what effectively are EmacsLisp “packages”. I write them in the same style as actual packagesthat I maintain (check https://protesilaos.com/emacs).The modules are the specifics of my configuration. They have the exactpreferences I rely on in my current session. A package may defineoptions. The module picks one among them.This is exactly what we all do when we configure a package from GNUELPA, for example: the package defines options and in our init.el weset it up as we see fit.Strictly speaking, this distinction is not necessary for a personalEmacs configuration. All the code is mine. I could easily hardcodevalues, not provide abstractions, and not bother with clear points ofentry. Doing so would work well for my use-case, which is the maingoal of all this code, anyway. But that would be a counterproductivehabit; “counterproductive” because I want the code I write to be easyfor others to copy and adapt. It also conditions me to be morethoughtful with my programs and more organised with my writings.There are some exceptions where a function is defined in the modules.This is either because the function really is about my configurationor it is part of some experiment I am doing.Trying out my custom modeline Also, is there anything you’d suggest to make it easier to try oute.g. your modeline from the config and and tweak from it into myown? Copying the contents of those two files and trying to evaluateit is not enough as it depends on other functions. I guess the onlyway is to take your whole config and play with it in a separateemacs –init-directory and dig around for relevant parts, right?It is probably better for you long-term to follow the video I didabout writing a custom modeline and tweaking its colours: https://protesilaos.com/codelog/2023-07-29-emacs-custom-modeline-tutorial/ https://protesilaos.com/codelog/2024-01-13-customize-emacs-mode-line/By understanding those concepts, you will be prepared to copy only theparts you need from prot-modeline.el and tweak them accordingly.That granted, here is how you can get my code into your setup (andanything from prot-lisp/ for that matter). The use-package forprot-modeline is the equivalent of what I have in my modules rightnow.(use-package prot-common :vc ( :url "https://github.com/protesilaos/dotfiles" :lisp-dir "emacs/.emacs.d/prot-lisp" :main-file "prot-common.el" :rev :newest))(use-package prot-modeline :vc ( :url "https://github.com/protesilaos/dotfiles" :lisp-dir "emacs/.emacs.d/prot-lisp" :main-file "prot-modeline.el" :rev :newest) :config (setq mode-line-compact nil) ; Emacs 28 (setq mode-line-right-align-edge 'right-margin) ; Emacs 30 (setq prot-modeline-show-frame-name (alist-get 'undecorated initial-frame-alist)) (setq-default mode-line-format '("%e" prot-modeline-kbd-macro prot-modeline-narrow prot-modeline-buffer-status prot-modeline-window-dedicated-status prot-modeline-input-method " " prot-modeline-buffer-identification " " prot-modeline-major-mode prot-modeline-process " " prot-modeline-frame-name " " prot-modeline-vc-branch " " prot-modeline-eglot " " prot-modeline-flymake " " mode-line-format-right-align ; Emacs 30 prot-modeline-which-function-indicator prot-modeline-notmuch-indicator " " prot-modeline-misc-info)))About not using use-package It seems you don’t use use-package (I see (require ... in themodules) anymore? Curious why.I consider this “sand in the gears”. It forces those who read myconfiguration to slow down and be careful about what they are copying.If they just paste my Elisp into their setup, they will get an error.Slowing down gives them the chance to read the code and think aboutwhat they are working towards.Yes, this sounds like I am doing them a disservice. But I think theywill benefit from this practice long-term. Copying willy-nilly is howyou never learn.Concretely about the use of require, in the modules I use my ownmacros. Every require should be wrapped in a prot-emacs-configure.Not all my modules rely on require though. I have some packages thatare loaded when a certain condition is met, typically via a hook.In prot-lisp/ the use of require is standard: this is how packagesare supposed to do it.By the way, writing my own configuration macros has helped meunderstand things at a deeper level. It also gives me maximum controlover my setup. But the real reason is the sand in the gears that Ialluded to.Autoloads and deferred loading Is there any reason to autoload features? I’ve come across someguides on using Emacs and it seems people tend to prefer to autoloadeverything as much as possible but I feel like it only makes senseto autoload only features you might not use during a session. Thetime to load on startup when you front load instead of autoloadseems less important than the time it takes to load when youactually use a feature during a session. Especially if running Emacsas a server or using a single long-running instance.With use-package you get deferred loading when you use keywords suchas :bind and :hook. Internally, this depends on the autoloadmechanism that Emacs has. Autoloads are hints that inform Emacs aboutthe existence of some function or variable in a certain file. Whenthat symbol is called for the first time before its file is loaded,Emacs goes to the corresponding file, evaluates everything, and thenruns the original code. For example:(autoload 'prot-test-hello "prot-test")If we call prot-test-hello, Emacs evaluates prot-test.el, and runsprot-test-hello. This works only if the file is in the load-path.Users generally do not need to understand the technicalities. Wheninstalling a package, Emacs generates an index of all the autoloadsautomatically. If you are curious, go to the elpa/ subdirectory ofyour Emacs directory, find a package, and read the autolaods file(e.g. denote-autoloads.el).Strictly speaking, deferred loading is not necessary. If you are goingrun Emacs for several hours non-stop, then the ~60 seconds it takes toload an average configuration do not matter. Even ten minutes are notbe important in such a scenario: you can brew a coffee in the meantime.Deferred loading is still beneficial though: It makes you think about the relationship between the various partsof your configuration. Having an Emacs that loads fast and workswell means that you have understood how you are piecing thingstogether. Deferred loading makes it easier to experiment with yourconfiguration and to restart Emacs when necessary. Imagine wantingto try things out, restart Emacs, and wait for several minutes eachtime… That breaks your flow.Autoloads help you discover new features. For example, when you pressM-x in a generic Emacs you are presented with thousands of options.Most of those are not loaded yet. Emacs just knows the symbols andwill load their files when you make the selection. A package developercan leverage this feature to provide functionality that may be usefulonly under certain circumstances. That is a helpful way for the userto notice the before and after states. It also gives the user maximumcontrol of what to load and when, which improves confidence in one’sEmacs configuration.GUI or terminal Do you ever run Emacs on the terminal or GUI only and do you alwayshave a single long-running instance or do you sometimes use multipleinstances?I always use the GUI. It can combine different font families and fontsizes and it can also display images—how else am I supposed to checkmy selfies? The terminal is fine in its own right and is especiallyuseful for remote connections. But I do not have that use-case.My terminal emulator is xterm, by the way. It works well, though Ido not rely on it. Everything that could be done in a terminal ishandled by Emacs. I also am on Debian stable, so trying the newestprograms is neither a straightforward option nor a priority: I have astable setup and focus on getting work done.I use a single instance of Emacs. In my configuration I also haveserver-start. This gives me the option to evaluate Emacs Lisp codeeven when Emacs is not focused, such as when I switch the theme of myentire desktop environment or window manager.I do not run Emacs for long hours. When I am done with whatever I amworking on, I switch off the computer. The typical workflow is for 2-3hours maximum. Then I will do some outdoor activity.Choice of keybindings and Evil Any thoughts on using Evil?It is fine and I am indifferent to it. What makes Emacs so nice isthat you can evaluate Emacs Lisp live and work with the new state. Thechoice of keybindings is a personal choice. There is no better orworse.People will, of course, argue about which paradigm is more efficient.This is the kind of knowledge that seldom translates into real-worldproductivity. The bottleneck is how fast and how well you can think.Then what matters are the qualities of your output. Moving text aroundquickly does not make you productive per se or, indeed, a decentwriter/programmer.This is a matter of comfort though, which can indirectly influenceyour productivity simply by improving your mood and willingness towrite. I put colours and fonts in that same category. If it makes youfeel better, then use it.That granted, to configure evil-mode properly you need to have asolid understanding of Emacs and be willing to control every part ofyour setup. Otherwise you will run into cases where something does notwork as expected and you will not know how exactly to change it. It seems like you’re willing to embrace Emacs defaults–is thereanything you’ve still maintained Emacs to be more Vim-like, e.g.modal and arguably more ergnomic/mnemonic?The general scheme of Emacs default keybindings is good enough for me.Though I change plenty of keybindings to do what I want. Actually, Iplan to rebind basics such as C-n, but I have not found the time todo it thoroughly. There are many default keybindings that I do notlike.I do not think Vim is ergonomic by default. Impulsively reaching outto the Escape key is not helpful, especially if you are twisting thewrist in the process. Typing Shift with the relatively weak smallfingers is not beneficial either. Yes, you can circumvent those, but Iam referring to the out-of-the-box experience, because if you arethinking about making changes then you might as well do the same forthe Emacs-style keys.Emacs keys are not ergonomic either. Ergonomics is a matter of theentire office setup, from the keyboard, to the desk, the placement ofthe monitor, the typing style. I have an article on the matter:https://protesilaos.com/codelog/2026-05-04-emacs-keyboard-ergonomics/.My custom keyboard has hjkl mapped to the arrow keys on a so-called“layer” that I can activate with my thumbs. The yuio keys abovecorrespond to Home, PageDn, PageUp, End, respectively. Thoseare the bigger motion counterparts of the cardinal directions. Extendthis to Ctrl and one of those keys to perform a different motion,like C- to go to the beginning of the buffer, C- tomove forward by a word. This works everywhere, by the way.I actually have plenty of articles on the topic of keyboards, if youare so inclined: https://protesilaos.com/keeb.Persisting Emacs sessions I may have missed this, but how do you approach persistent session(if at all)?I do not. This is not necessary in my workflow. I have bookmarks forthe buffers/files I visit frequently. Then I have Git projects that Ialways keep in a clean state with a history that is meaningful. When Ineed to work on something, I switch to the bookmark/project and startfrom where I left it. I like that if I return a project I’ve worked on a few weeks ago,restoring these aspects is a good way to suggest where I last leftoff instead of starting from scratch (little things like windowlayout or set of open buffers is suggestive of progress of theproject).This is a matter of how one’s brain works. Mine is more abstract, sohaving things in a specific spatial arrangement does not add muchvalue. Configuring Emacs to take care of all relevant cases is thusnot appealing to me. I will commit my changes and leave everything ina condition that makes the next step obvious. I am happy to writeTODO and FIXME comments in my code and/or have a relevant task inmy Org agenda. This is a matter of logical sequencing. It is easierfor me to reason about it.I used to load the built-in desktop.el. Then I realised that loadinghundreds of buffers for something that I might not need iscounter-productive. Furthermore, storing a specific state for apotential future occasion requires that I remember to load the rightfile, manage all such files, and so on, which is cognitivelyburdensome and ultimately no more efficient than working with Git. 🔷 Consider making a donation.