Feeling gratitude towards this community. Just wrote my first #emacslisp advice ever.

(advice-add #'package-function-has-no-hook :before #'my-little-hook-function)

A small thing, but it removes friction from my org-static-blog (recommended!) workflow.

These little steps forward are what make this hobby so much fun. And—you'll just have to believe me—the confidence to bork around like this comes from being part of this community.

[EDIT: broken link removed; see thread]

#emacs #mastodon #fediverse

@jameshowell FYI if you wrote "my-little-hook-function", you could also be interested in `define-advice', which combines a defun and a advice-add into a single form. Here are two example from my init.el:

(define-advice eval-last-sexp (:before (&rest _) eval-last-sexp-pulse)
(save-excursion
(forward-sexp -1)
(let ((start (point)))
(forward-sexp 1)
(pulse-momentary-highlight-region start (point)))))

@jameshowell Also, what function from package.el did you want to modify? Your sourcehut link points to a 404 page.

@pkal Sorry! Let's try it this way. NEW BLOG POST: "My first advice! (in Emacs Lisp)"

https://jamesendreshowell.com/2026-04-04-my-first-advice-in-emacs-lisp.html

#emacs #emacslisp

My first advice! (in Emacs Lisp)

@jameshowell You ask in the blog post why Emacs Lisp doesn't have a function to return the contents of a file as a string. It kind of makes sense to me, let's see if I can explain it.

Emacs has two data structures to store text in: strings and buffers. You may think of buffers as just for showing to the user in a window to edit, but buffers also have an extensive collection of functions to work on them programatically (obviously, since every thing the user can do to edit a buffer just calls some command). I feel like Emacs in general pushes you towards using strings only for small amounts of temporary text and buffers for longer text or longer-lived pieces of text. From that point of view it makes perfect sense to me that Emacs has a function to insert the content of a file into a buffer, but not one to return it as a string: a file is likely to long and to stick around a while for you to work on it, it belongs most likely in a buffer rather than a string. The existence of `insert-file-contents` and the non-existence of a corresponding string-returning function is meant to nudge towards buffers for file processing.

@pkal

@oantolin No, I get it, in fact slinging HTML lines around in buffers and concatenating them together in buffers makes more sense—in the Emacs context. But you can see how someone (like perhaps the author of org-static-blog, and certainly naive me) would cling to string-oriented habits.

Thank you for the thoughtful, patient, illuminating answer to my snarky rhetorical question!

@pkal

@jameshowell Well, having given that answer, I should say that lots of people have probably had to write that function to get the contents of a file as a string, it probably should be included with Emacs. 😅 @pkal

@oantolin The "s" package has a function to do that, and the consequence is that people keep on reading an entire function in as a string and then doing GC-heavy list processing on the function, where using a buffer would have been more idiomatic.

I am not sure if I submitted a patch for this once, but a compromise of having a `slurp` macro could be interesting, since it would read in the file once at macroexpansion time, without making it a general replacement for buffers.

@jameshowell

@pkal @oantolin @jameshowell Creating new buffers also inctroduces overheads. So, it is not always obvious whether using buffers to manipulate text is better than using strings.
@yantar92 @oantolin @jameshowell True, but the instances I am thinkig about are those where you already have a buffer and call `buffer-string` on it.
@pkal @oantolin @jameshowell I actually attempted using with-work-buffer as a replacement for string manipulation in ox.el. I did not observe measurable improvements. That's not to say that using buffers is not useful, but IMHO one needs to do benchmarks on case-by-case basis.
@yantar92 That's interesting! Exporting is exactly the kind of task I would have assumed buffers were better for, since the output is built up by concatenating a lot of small strings. I mean, it's the kind of thing that I would have used a StringBuilder for in Java (or StringBuffer?, I can't remember Java) rather than using strings. @pkal @jameshowell
@oantolin @pkal @jameshowell To be clear, my experiment was more limited in scope that you may think. Because Org export is built around passing strings around, I only used buffers to concatenate the final results. Strings were still created.
@yantar92 I see. The thing to compare it against would be a pure "buffer passing style", where instead of returning strings, functions insert strings into the current buffer. @pkal @jameshowell