I have a sporadic error when running query-replace:

Args out of range: #<buffer lib.rs>, 0, 1

There are similar questions:

These point towards the problem being that something is overriding the match-data during the find-and-replace operation, but it's difficult to identify exactly what.

Is it possible to log to a buffer or enter the debugger any time that the match-data is modified? Is there another technique to identify what is clobbering the match-data, before I resort to line-by-line printf style debugging? Bisecting my init file would tell me what package I'm using is misbehaving, but not where the misbehavior occurs.

I've seen Tracking down a write to a variable, but that doesn't appear to apply to match-data, which is a function, not a variable. I've also seen How do I debug when match-data is not getting set?, which appears to be the opposite problem from mine.

1 Answer 1


Kudos for checking similar questions and their answers.

One thing you can do, to start with, is to set debug-on-error to t, to at least get a backtrace so you know which function raised the error, what function called it, etc. But that will only get you so far, probably.

There is no magic way I'm aware of to track down which code clobbers match data that you are hoping doesn't get clobbered.

  1. Copy the overall code involved, so you have something you can modify without touching the original.

  2. Insert calls to message at a few places (in your copy of the code), printing whatever info you're interested in (e.g. the match data).

  3. Use the printed messages (in buffer *Messages*) to narrow down where the problem is, inserting more calls to message as needed (and perhaps removing calls no longer needed).

  4. (Optional) After you've narrowed down the culprit to a function of interest, you might want to use debug-on-entry for that function, instead of continuing to insert message calls inside it. Use d to step through the debugger (or c to skip through a step without diving down into its code). Use e to evaluate a sexp at any time (e.g. (match-data ...)).

You can alternatively just start with #4, debugging from the beginning, if you at least have some idea of a high-level function where things go wrong.

Before using the debugger, load the source file that defines the function you want to step through. You can see better what's going on when you use the source code instead of byte-compiled code (.elc).

  • Thanks. After adding some messages, I saw that the error Unable to load color "color-236" was appearing intermixed with my messages. This was coming from a customization I had done for lsp-mode, but I don't recall why I picked an invalid color. On a hunch, I removed that customization and I haven't been able to reproduce the problem since. It is an intermittent problem, so I might have to refer to these instructions a few more times, but fingers are crossed!
    – Shepmaster
    Commented Mar 17, 2019 at 23:52
  • Every time I use Edebug, the match data gets clobbered with every evaluation. This makes anything to do with match data impossible to debug. I wouldn’t even know where to start figuring out where that problem is. Any ideas? Commented May 11, 2019 at 4:32
  • 1
    …for the benefit of those reading this: After a Herculean effort, I did finally figure out what was clobbering the match-data. The culprit was guide-key, a package I completely forget I had installed. It’s not actively maintained, but I filed a bug anyway. github.com/kai2nenobu/guide-key/issues/48 Commented May 11, 2019 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.