AW: AW: emacs-29 a2d4cd06f45: Improve VHDL mode highlighting

[Cyril Arnould <cyril.arnould@outlook.com>]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

> 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<mailto:reto@gnu.org>
Gesendet: Dienstag, 9. Mai 2023 16:38
An: Cyril Arnould<mailto:cyril.arnould@outlook.com>; Eli Zaretskii<mailto:eliz@gnu.org>; Michael Albinus<mailto:michael.albinus@gmx.de>; Mattias Engdegård<mailto:mattias.engdegard@gmail.com>
Cc: emacs-devel@gnu.org<mailto: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


[-- Attachment #2: Type: text/html, Size: 6220 bytes --]