Any setting I can use to get back the old behavior where killing a buffer I get to the next buffer for the files I have given on the command line?

I have been using Emacs like this for years

  1. Open many files in emacs buffers: emacs $(find . -name "Makefile")
  2. Start recording macro: C-x (
  3. Do a small safe change to one of the files
  4. Kill buffer: C-x k <ret>
  5. Stop recording: C-x )
  6. Try it out once or twice: C-x e
  7. Run the macro on all the files: C-u C-u C-u C-x e
  8. Exit Emacs: C-x C-c
  9. Redo from 1 until all have the intended changes

I work in Release Engineering and use to call this "working more horizontally vs dev work", changing things like updating copyright headers in many files. Emacs and macros has helped me a lot and is in general more flexible vs using sed/awk/perl one-liners!

Problem is, with more recent Emacs versions the first time I do step 5 Emacs will go to the *scratch* buffer. Fine, I do C-x k <ret> and then hit C-x e again. Only to end up in the *Messages* buffer.

After this Emacs seems to go to buffers for the files I gave on the command line and end with *Buffer List* where I exit Emacs.

This might sound like a small thing, but I do this many times a day and constantly be thrown into *scratch* and *Messages* instead of the intended file buffers is annoying. Especially since I want to hit a few C-u and when entering those buffers my macro will fail and everything stop.

  • Why does your macro fail in those buffers?
    – NickD
    Apr 28 at 16:03
  • It sounds like you're saying tat C-x ) switches to another buffer (e.g. *scratch*). Does this happen if you start Emacs using emacs -Q (with your $find etc.)? If not, bisect your init file to find the culprit. Otherwise, does this also happen when you define other simple keyboard macros? If not, investigate why (the difference). If so, consider reporting an Emacs bug: M-x report-emacs-bug.
    – Drew
    Apr 28 at 16:47
  • @Drew: no, the last thing that the macro does (in step 4) is it kills the current buffer.
    – NickD
    Apr 28 at 22:28
  • The macro will close the buffer. And when I repeat it then process all the files given on the command line. I see now I forgot to include the "Save buffer" step before closing the buffer. Let's say the macro created search for something like "foo:<newline><tab>bar", removes those lines, saves, and exit the buffer. If I then repeat the macro using C-u C-u C-u C-x e, then it will beep and abort the repeated macro invocation when hits the scratch buffer as there is no match in that buffer.
    – kboortz
    May 2 at 19:25

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.