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?

Infiltrator
  • 223
  • 1
  • 4

2 Answers2

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

Att Righ
  • 725
  • 4
  • 14
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.]

lawlist
  • 18,826
  • 5
  • 37
  • 118
  • Wow. Thanks for the suggestions. I will give them a go and come back to accept your answer. – Infiltrator Sep 27 '18 at 05: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 06: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 04 '20 at 08:41