> So I would suggest to release your changes under 3.38.5. Will do. > I'm not sure why backwards compatibility code is needed here. I hadn't considered that. If we define Error to be 2 in the type, the compatibility code *is* needed not to break the customization menu with previously saved customizations. If we define it as nil though, saved customizations appear normal in the menu. So I will update the patch with Error to be nil exclusively and forego the backwards compatibility code. Thanks! Von: Reto Zimmermann Gesendet: Dienstag, 9. Mai 2023 16:38 An: Cyril Arnould; Eli Zaretskii; Michael Albinus; Mattias Engdegård Cc: emacs-devel@gnu.org Betreff: Re: AW: emacs-29 a2d4cd06f45: Improve VHDL mode highlighting On 2023-05-09 13:51, Cyril Arnould wrote: > Cyril, are you done discussing this, or do I need to wait some more? I was actually hoping to get Reto's and/or your input on two points, the first one being: > Since this introduces changes in the vhdl-compiler type, I guess > it would be appropriate to increment the vhdl-version number? I've seen that on Reto's website, the latest vhdl-version number is 3.38.4, while in the emacs repository it's at 3.38.1. I'm not sure if this is intentional or if it simply hasn't been tracked in emacs. If development is not intended to diverge, we could skip ahead to 3.38.5 or 3.39.1. Development has already diverged. I have in the meantime fixed numerous indentation bugs and added support for VHDL'18, among other changes. I know this is not ideal, but I was not able to approve of all the changes that have been made on Emacs side some time ago, without sufficient testing. I'm in the process of integrating most of these changes in my code though. I will also release 3.39.1 myself soon. So I would suggest to release your changes under 3.38.5. The second point is that we now have two solutions for backwards compatibility code. There's my original solution which is a slight modification of already established backwards compatibility code. Alternatively, there's the solution elaborated with Mattias which should be safer but is less tested. If using a more "experimental" solution is no problem then we can go ahead with the new approach. I'm not sure why backwards compatibility code is needed here. The only change here is that an additional element (cons) is added to a sub-list, which however can be nil when no warning/info syntax is present. On my side it works without compatibility code. Reto