I am working on a major mode derived from special-mode, which populates its buffers with formatted lists of items retrieved from a web API. Reverting such a buffer involves refetching and reformatting said list of items. I would appreciate advice on whether to tailor this custom function to revert-buffer-function or to make it standalone.

Initial thoughts

For revert-buffer-function:

  • Better integration/consistency with rest of Emacs
    • revert-buffer is already bound to g in parent special-mode-map
    • running {before,after}-revert-hook in revert-buffer-function makes sense and affords more customisability

For standalone revert command:

  • Allow custom interactive arguments
    • For example, how many items to fetch
    • revert-buffer-function arguments make little to no sense in a non-file-visiting context and cannot be reused for an alternative purpose
      • Prefix argument to revert-buffer cannot easily be retrieved from revert-buffer-function - this probably begs a new SE question
  • Docstring becomes clearer, more specific and more readily accessible, i.e. the user does not have to read about revert-buffer, inspect revert-buffer-function or ignore the file-visiting-specific arguments

Practical examples

  • eww.el provides a standalone eww-reload command with custom interactive arguments, but also comments FIXME: revert-buffer-function instead!
  • Most non-file-visiting modes I have come across both within and without the Emacs tree are more or less evenly split between rolling out a custom command and using revert-buffer-function with ignored argument(s)


The fact that the prefix argument to revert-buffer-function is file-visiting-specific, together with last-prefix-arg not being usefully bound to the prefix argument to revert-buffer, suggest revert-buffer-function is not really intended for non-file-visiting purposes and so it is unnecessary to seek too deep a level of integration with this mechanism. Is this a sound conlusion? Is there a better use of revert-buffer-function or similar mechanisms than the way described herein? Would extending the flexibility of revert-buffer constitute a useful feature request?

  • 1. You seem to have laid out the advantages and disadvantages. What else are you looking for, as an answer? 2. revert-buffer-function*is* intended also for non-file-visiting purposes. There are plenty of modes that use it as such.
    – Drew
    Sep 18 '17 at 18:27
  • @Drew 1. I am looking for a second opinion from a more experienced package maintainer like yourself on which approach holds most merit and whether there are any workarounds to the drawbacks I have mentioned, though I gather that, as usual, it boils down to "do as you see fit." 2. Indeed, I mention coming across many such cases, but it seems to have been designed primarily with file-visiting in mind.
    – Basil
    Sep 18 '17 at 18:36
  • @Drew 1. (continued) Anyone inclined to answer may also be able to confirm or correct any of my interpretations.
    – Basil
    Sep 18 '17 at 19:44
  • 1
    When you use revert-buffer-function, you have a chance to enable also auto-revert-mode for your buffers. Sep 19 '17 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.