5

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?

2 Answers 2

2

This is a bit of a pain to debug.

In my version of compile.el you can set compilation-debug:

(setq compilation-debug 't)

Then if you call describe-text-properties the compilation-debug property then tells you which regexp is matching - along with a few other bits of information.

The following programmatically gets a regexp. (You can run it with M-x eval-expression)

(car (aref  (car (get-text-property (point) 'compilation-debug)) 1))

To get a name for this you have this rather ugly bit of elisp (again run with M-x eval-expression)

(let ((regexp (car (aref  (car (get-text-property (point) 'compilation-debug)) 1)))) (car (car (seq-filter (lambda (x) (equal (cadr x) regexp)) compilation-error-regexp-alist-alist))))

You can then reorder compilation-error-regexp-alist

1

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.]

3
  • Wow. Thanks for the suggestions. I will give them a go and come back to accept your answer. Sep 27, 2018 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, 2018 at 6:19
  • Can you tell me how to select the correct compilation regexp? pulling my hair out here. It has to be so simple I'm not seeing it.
    – RichieHH
    Dec 4, 2020 at 8:41

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.