I spent a while debugging the regex in compilation-error-regexp-alist only to find that the regex itself is fine. My current theory is that compilation-mode is just actually using a different regex instead.

The error message is: ERROR: /home/user/projects/lv/packages/client/src/log.ts[291, 11]: 'now' is declared but its value is never read.

And the regex is: ^[[:blank:]]*\\(?:\\(?:ERROR\\|\\(WARNING\\)\\):[[:blank:]]+\\)?\\((.*)[[:blank:]]+\\)?\\([^( \n)]+\\)\\[\\([[:digit:]]+\\), \\([[:digit:]]+\\)\\]: .*$

How do I see (and change) which regex compilation-mode is actually using in a given buffer?


It might be any number of the regexp that make up the compilation-error-regexp-alist.

One idea would be to place a message in compilation-parse-errors after both of the while loops: (while (re-search-forward pat end t) (message "pat: %s" pat) ... Add additional messages as needed.

A second idea would be to create a similar while/dolist loop and search through the finished output to determine applicable matches, and perhaps get a little fancy and stop at each match with a yes/no proceed so that things happen in slow-motion.

A third idea would be to use each individual regexp and open up M-x re-builder and try the different regexp on the finished output until you find a match.

A fourth idea would be to add a text-property with the applicable regexp at each location as compilation-parse-errors does its thing -- pat is the regexp used per while loop. See these with C-u C-x = and/or (text-properties-at (point)). E.g., at both locations, (while (re-search-forward pat end t) (compilation--put-prop file 'regexp pat) ... will add the regexp to the text-properties placed on the filename. In the *Help* buffer of C-u C-x = (on the filename), click on the regexp [show] option -- or, at point on the filename, evaluate (text-properties-at (point)) and look at the result in the *Messages* buffer. [If it gets truncated, you may need to set a variable to see the full value.... beyond the scope of this question/answer.]

  • Wow. Thanks for the suggestions. I will give them a go and come back to accept your answer. – Infiltrator Sep 27 '18 at 5:44
  • I personally chose to use the fourth option in my own setup. As long as there is a file (filename), the proposed solution works as indicated. If the file is nil, then another one of the highlighted regexp areas would need to be selected. The overhead is minimal and I decided to leave it with the modification for the foreseeable future just in case I ever want to inspect the regexp for whatever reason. Remember, there are two (2) locations in compilation-parse-errors where the while/loops for re-search-forward ... pat are used ... – lawlist Sep 27 '18 at 6:19

Your Answer

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

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