bug#63251: AW: bug#63251: 28.2; vhdl-mode contribution

[Cyril Arnould]

Forgot to hit «Reply to all»

 

Oh, did not realize that. Yes, the (2 . 3) is important, it’s the

TYPE that determines whether the message is highlighted as an

INFO, WARNING or ERROR. From compilation-error-regexp-alist:

 

Each elt has the form (REGEXP FILE [LINE COLUMN TYPE HYPERLINK

HIGHLIGHT...]).

 

TYPE is 2 or nil for a real error or 1 for warning or 0 for info.

TYPE can also be of the form (WARNING . INFO).  In that case this

will be equivalent to 1 if the WARNING’th subexpression matched

or else equivalent to 0 if the INFO’th subexpression matched,

or else equivalent to 2 if neither of them matched.

See ‘compilation-error-face’, ‘compilation-warning-face’,

‘compilation-info-face’ and ‘compilation-skip-threshold’.

 

I’ll try to take a look into modifying the type of the

vhdl-compiler-alist.

 

 

Von: Mattias Engdegård
Gesendet: Samstag, 6. Mai 2023 11:22
An: 63251@debbugs.gnu.org
Cc: Reto Zimmermann; Eli Zaretskii; Cyril Arnould
Betreff: bug#63251: 28.2; vhdl-mode contribution

 

> Following bug#62508, I've taken a bit of a closer look at the compiler
> regexp for ModelSim. I've modified it so that it can differentiate
> between Errors, Warnings and Notes when highlighting. I also make use of
> Xilinx Vivado at work, for which I've added a new compiler entry:

Sorry, but computer says no. The modified vhdl-compiler-alist value does not match its declared type.

You can easily check this by running `M-x customize-variable vhdl-compiler-alist`; it will show the contents as a single big text field and say (mismatch).
If the value matches the type, it would have shown the value structurally.

Another check is to run `make -C test test-custom-opts`, which checks the values of all defcustom variables in Emacs.

In this case it seems to be the `(2 . 3)` values at the end of the error message sublists. Remove them and the value matches the type.
If those (2 . 3) are important, perhaps you want to change the type instead but you would have to maintain compatibility somehow. I see there is a lot of code dealing with changes to the type of that variable in vhdl-mode.el.