Weekly Tips, Tricks, &c. Thread

This is a thread for smaller, miscellaneous items that might not warrant a full post on their own. [See this search for previous "Weekly Tips, Tricks, &c." Threads.](https://www.reddit.com/r/emacs/search?q=Weekly+tips&restrict_sr=on&sort=new&t=all) Don't feel constrained in regards to what you post, just keep your post vaguely, generally on the topic of emacs.

Below are functions and `add-advice` that I've added for my org-mode interactions. If point is at a UUID, I will check if there's an org node with that ID and if so open it; otherwise fallback to existing behavior. (defun jf/follow-thing-at-point (fn &rest args) "Lookup org-id for `thing-at-point'. If it exists, open it. Otherwise apply FN with ARGS." (let* ((node-id (format "%s" (thing-at-point 'symbol))) (node (jf/org-id-find-id-file node-id))) (if node (find-file node) (apply fn args)))) (defun jf/org-id-find-id-file (id) "Query the id database for the file in which ID is located. Unlike `org-id-find-id-file' this does not fallback to the current file." (unless org-id-locations (org-id-locations-load)) (or (and org-id-locations (hash-table-p org-id-locations) (gethash id org-id-locations)) nil)) (advice-add #'org-open-at-point :around #'jf/follow-thing-at-point '((name . "wrapper"))) (advice-add #'markdown-follow-thing-at-point :around #'jf/follow-thing-at-point '((name . "wrapper"))) (advice-add #'xref-find-definitions :around #'jf/follow-thing-at-point '((name . "wrapper"))) (advice-add #'org-open-at-point-global :around #'jf/follow-thing-at-point '((name . "wrapper")))

When I start emacs I create a `*text*` buffer in `text-mode` as a sort of scratch pad for very simple text editing. I find `fundamental-mode` too limited. (save-excursion (switch-to-buffer (get-buffer-create "*text*")) (text-mode)) I'm open to suggestions for other relevant modes that might be even better. I want to preserve this buffer, but I often kill it accidentally. Oh and while I'm at it, I'm also fed-up of accidentally killing the `*scratch*` buffer too. (defun b/immortal-buffers () "Prevent some buffers from being accidentally killed." (interactive) (pcase (buffer-name) ("*scratch*" (bury-buffer)) ("*text*" (bury-buffer)) (_ t))) (add-hook 'kill-buffer-query-functions #'b/immortal-buffers)

Sometimes you want to be able to paste/yank something n amount of times, but there's no easy way to do this by default. So I wrote the following. (defun init-multi-yank (amount) "Yank the first item in the kill ring an AMOUNT of times. Passing a negative number will prompt you for what to yank from the `kill-ring.'" (interactive "p") (if (cl-minusp amount) (let ((index (1+ (cl-position (completing-read "Choose what to yank: " kill-ring) kill-ring :test #'equal)))) (dotimes (_ (abs amount)) (let ((kill-ring-yank-pointer nil)) (yank index)))) (dotimes (_ amount) (yank)))) (global-set-key (kbd "C-M-y") #'init-multi-yank)

Treemacs now supports moving files via mouse drag, if that's your thing.

Today I discovered that passing -1 to `just-one-space` makes it remove newlines which is pretty cool because the majority of my use cases were - go to end of line - delete newline - `just-one-space`

Out of curiosity, what is your use case for having both text and scratch buffers?

If you just want to join a single line, is that not what `join-line` with prefix arg does?

I use `paredit` so the \*scratch\* buffer is not at all convenient for plain text. For example `M-q` is normally `fill-paragraph` (text) but it gets bound to `paredit-reindent-defun` (lisp like languages). I have dedicated keybindings to quickly switch to them that I've grown so used to it's an unconscious reaction now.

Not really, `(just-one-space -1)` deletes all newlines between previous char and next char and adds a space. `(join-line)` with prefix arg joins the next line with the current one ~~right after the point~~ with a space too. What's cool about `join-line` is that you don't need to have your cursor at the end of the line in order to join 2 lines. EDIT: I was wrong about how join-line joins the lines, it also adds a space between both lines This is pretty much the best of both words for me: (defun join-line-one-space () "A mix between join-line and only-one-space" (interactive) (save-excursion (move-end-of-line nil) (just-one-space -1)))

Interesting, thanks!

If you were to make these file buffers, with a file in a temporary directory perhaps, the contents would preserved even if you killed the buffer. Just an option.

I just go `<f3> C-y C-5 <f4>` to yank five times.

This is how I switch between light and dark themes. I haven't encountered a situation yet where I want more than one theme enabled. (defun only-theme (new-theme) (dolist (theme custom-enabled-themes) (disable-theme theme)) (load-theme new-theme)) (defun dark-mode () (interactive) (only-theme 'alect-black)) (defun light-mode () (interactive) (only-theme 'alect-light-alt))

Damn, I can't believe I didn't think of macros for this; that's really obvious in hindsight.

Let me suggest creating a hook, say `switch-theme-hook`, and run that in `only-theme` as well ? This is what `modus-themes` do and I hook like, color-changing nick functions for IRC into that hook. It's pretty useful :)

winner-mode

Is that a mode?

C-c left/right is bound to winner-{undo/redo} default, which nicely rhymes with C-x left/right for going back and forth between the buffers u visited within a window. it's great to have winner-mode built-in! for a long time I was annoyed by the help windows popping up and not getting focused, so I can conveniently scroll in them and get rid of them AND their newly opened window with q. there's is some built-in customization setting which makes them focused on open, but either way, winner-undo is a great, uniform way of getting rid of popups, regardless of whether they got focus or not.

No, [it works out of the box](https://raw.githubusercontent.com/Alexander-Miller/treemacs/master/screenshots/mouse-drag.gif).

So … newbie here, but a fast learner. I’m up and running after a weekend transition from LogSeq to org-roam and org-mode (with beorg on the phone) for learning, reading, task/project management. Question … I may be missing this, but at a high altitude level, what is the difference between M-x, C-c, and C-x? When creating my own bindings, is there a “preference” about when I should choose C-c or C-x, for example?

check this reddit post out: https://www.reddit.com/r/emacs/comments/a5j3lc/emacs_key_binding_conventions_and_why_you_should/ "In summary, the general rules are: C-x reserved for Emacs native essential keybindings: buffer, window, frame, file, directory, etc... C-c reserved for user and major mode: C-c letter reserved for user. <F5>-<F9> reserved for user. C-c C-letter reserved for major mode. Don't rebind C-g, C-h and ESC."

Thank you! Very helpful!

You know that you can set the mode for the scratch buffer right? Try setting `initial-major-mode` to `text-mode` and then you don't need to have a separate *text* buffer.

Sure but I'm used to tinkering with elisp in the `*scratch*` buffer :). I think there's more to it than that though. If I'm writing python, ruby or haskell code... I want a repl to test out and help develop that code. I think of emacs (quite literally) as an elisp program with a massive and extendable built-in API, so it makes sense to have an elisp repl for testing and developing my own extensions. Frankly I'd be lost without it. I suppose I could use `ielm` but then there would still need to be 2 dedicated buffers.

Fair enough. I guess I’d want a dedicated project scratch buffer in that case but it sounds like you’ve got a workflow that works for you so that’s really all that matters!