dotfiles

dotfiles I use

Emacs todos

Housekeeping

• Switch to lexical binding
• Use #' instead of ' for fucntion

More important

• wgrep
• emacs in dired/vterm is very slow to open minibuffer when the directory is on a slow location.
• include current buffer in switch-to-buffer list
• For tramp, prevent reconnect when process has died. Can show in modeline

Less important

• For tiny-lsp-client remap to proper root for rust library files
• evil in minibuffer
• Change to emacs built-in search and search-and-replace
• Lower memory usage. Garbage collection is slow for me. Even if my config doesn’t generate more garbage than more lightweight configs, because so much memory is used, it takes time to find the garbage. My guess at least. BIG
  • One suggestion was to decrease shell term size.
• More than one help window, and don’t make them disappear so quickly
• Undo each step in search-and-replace, i.e. migrate to emacs’ query-replace
• rg options, e.g. ignore gitignore, only certain file types, fold on file, etc
• Make relative line numebrs correct in vdiff
• More colorful dired, like ll
• vim mark, but name them, cycle through with ivy
• when new buffer, ALWAYS switch to it for consistent behavior
• consider change ctrl to meta
• make vdiff auto sync at start work
• make vdiff sync as scroll always be able to scroll
• Make markdown look as good as org-mode
• add vim mark to bookmarks
• highlights in sync grep
• center buffer on compile-goto-error
• completing-read-own
  • Sometimes there are multilines in completing-read-own
• org-mode
  • SPC m s, should preserve order
  • spell in completion
  • dd inside list with line breaks delete from the line below
  • Implement centering yourself, like David Wilson did
• corfu
  • sepator like space for wildcard matching
• In find-file, nothing is shown for slow dirs, like webdav or some tramps. At least for tramp, would be good to indicate “loading”.
• eldoc flickers when typing
• delete in switch-to-buffer is sometimes buggy, e.g. when deleting 1 out of 2 matches
• In find-file when input is ~ can’t delete ~
• Slow to open icomplete for .tar.gz files
• Scroll when async output changes, things get messed up
• Sometimes annoying save prompt when checking out files etc. Maybe related to auto save timer
• transient or similar for ripgrep
• evil bug with e.g. d2k and visual lines
• search and highlight several search hits at the same time

Not important at all

• lsp diagnostics
• alt-ret for continuing list also outside org-mode
• cache modeline segments, like doom modeline

Wanted, but hard to do

• center inline images in sliced org mode (maybe possible, but requires lots of work)
• Box around the cursorline, like VSCode
• org-mode
  • Slightly bigger bullets
  • Line numbers
• Sliced images in org without inserting dummy lins, and vdiff overlays that can be partially hidden at top
  • Maybe can insert a “newline” overlay between each char in image link in org as hack/workaround?

Hard-to-reproduce bugs

• Sometimes sync grep doesn’t manage to go to result
• Corfu is laggy when typing the the LSP server is slow
• Sometimes emacs freezes, feels corfu and/or auto save timer related
• In org-mode the corfu popup is sometimes incorrectly located
• Sometimes in org-mode, scroll-up stops working. When scrolling suddenly jumps back a long distance.
  • Is related to variable-pitch-mode. Toggling it fixes the issue. Reverting the buffer doesn’t fix the issue. Copying the file, and the issue doesn’t appear in the copy. Try mixed-pitch-mode just to try somehting.

completing-read

I have split my completing-read config into ol-completing-read.el and several ol-completing-read-*.el, the latter having one per framework, so ol-completing-read-vertico.el and ol-completing-read-ivy.el. The idea is that ol-completing-read contains things generic no matter which framework I use, for example

• ol-dwim-find-file-name for finding a file name using e.g. rg --files in either project root or cwd, preferring ripgrep if available, otherwise using some fallbacks.
• ol-dwim-find-file-content for finding file content using ripgrep if available, otherwise using some fallbacks.

Then the ol-completing-read-*.el files contain configuration for making that particular framework work the way I want it, for example

• Keybindings inside the minibuffer
• Keybindings for functions e.g. imenu functionality
• Faces
• Completion styles

ol-completing-read.el requires one of the ol-completing-read-*.el files.

Why this complexity? I’ve used ivy for a long time, but wanted to try vertico and friends. Eventually I might consider writing my own framework for the reasons below:

• Understand how it works
• Simplicity - I have simple but peculiar needs
• Ultimate control - because I already tweak the frameworks quite a lot)

My vertico config is not as polished as for ivy. It was hard to get it work the way ivy worked. I might not spend time on it if I’m going to roll my own anyway.

Variants and input

Find file names

ol-dwim-find-file-name is rg --files REGEX where REGEX is the user input transformed to regex with space as wildcard. It’s synchronous which means no options can be passed to rg. For passing options, use ol-dwim-shell-command instead and pipe manually, e.g. rg --files --no-ignore -g "*.txt" | rg name. The reason ol-dwim-find-file-name is synchronous is that it’s the common case, and synchronous is slightly faster than asynchronous.

Find file content

ol-dwim-find-file-content is rg REGEX where REGEX is the user input transformed to regex with space as wildcard. The options -g "*​.ext", -g "!*.ext" and --no-ignore are relevant to use in some occasions. See below how to use them in the shell and how it translates to ol-dwim-find-file-content.

shell syntax	ol-dwim-find-file-content
rg hej	hej
rg hej.*?hello	hej hello
rg hej hello	hej hello
rg -g "*.txt" -- hello	-g "*.txt" -- hello
rg -g "!*.txt" -- hello	-g "!*.txt" -- hello
rg --no-ignore hello	--no-ignore -- hello
rg --no-ignore -- hello	--no-ignore -- hello

Upgrade preparation

To make upgrades of emacs as easy as possible, I want to rely on as few packages as possible, and those I rely on should preferably have a large community and be maintained, so that no backwards compatibility issues appear

To make upgrades of packages as easy as possible, I want to customize the config of packages as little as possible, especially advising on internal functions.

• anzu/evil-anzu -> own
  • Keep them until upgrade problems, but consider rolling my own
• evil-visualstar -> own

libvterm offline install

Inside the libvterm-mirror submodule, checkout the commit specified by CMakeLists.txt inside the emacs-libvterm submodule. Inside CMakeLists.txt change the git stuff to point to the local submodule. After that, run as usual.

Docker development environment

One idea is to make my dotfiles repo a Docker image. I like Tumbleweed for development because you have the latest packges. But, sometimes there can be driver issues at upgrade.

• Mount x11 socket
• VNC
• Mount repos dir outside docker container
• Use Emacs as “window manager”
• Mount docker socket so that can run “docker-in-docker”

“Merge Survival Knife”

Principles

This tool sets up five different views of the merge conflict according to the figure below.

         LOCAL
        /  |  \
       /   |   \
      /    |    \
     /     |     \
    /      |      \
BASE       |       MERGED
    \      |      /
     \     |     /
      \    |    /
       \   |   /
        \  |  /
         REMOTE

LOCAL is the version in the target branch, “your changes”. REMOTE is the version in the branch you’re merging in, “others’ changes”. BASE is the merge base between LOCAL and REMOTE. MERGED is the merged result.

I use the different diffs the following way:

• BASE <-> LOCAL for understanding what changes I have made since the merge base.
• BASE <-> REMOTE for understanding what changes other people have made since the merge base.
• LOCAL <-> REMOTE if LOCAL and REMOTE have made very similar changes, I use this to understand the difference between them. Useful if you have manually copy-pasted code from the branch to merge from, but also made a few changes on your own.
• REMOTE <-> MERGED for understanding what changes I will “apply” to the branch I’m merging from, if I were to merge my changes to it. For example, if I create a branch based on the main branch, I do a few changes, and main does a few changes, then this diff shows what I would apply to main if I merge to main.
• LOCAL <-> MERGED for understanding what changes remote will “apply” to my branch after I merge.

BASE <-> LOCAL shows your intention. So that diff should look very similar to REMOTE <-> MERGED if you have correctly preserved your intentions after the merge.

Similiarly, BASE <-> REMOTE shows others’ intentions, so it should look the same as LOCAL <-> MERGED.

In other words, I use

• BASE <-> LOCAL
• BASE <-> REMOTE
• LOCAL <-> REMOTE

for understanding the conflict, and

• REMOTE <-> MERGED
• LOCAL <-> MERGED

for reviewing my resolution of the conflict.

How to use it

The tool is based on vdiff.

My key	Command	Description
SPC g m	msk-mode-enable	Start solving the merge conflict the cursor is in
C-c q	msk-mode-disable	Save your resolution of the merge conflict
M-1	msk-base-local	Change diff view to BASE-LOCAL
M-2	msk-base-remote	Change diff view to BASE-REMOTE
M-3	msk-local-remote	Change diff view to LOCAL-REMOTE
M-4	msk-local-merged	Change diff view to LOCAL-MERGED
M-5	msk-remote-merged	Change diff view to REMOTE-MERGED