emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cyril Arnould
Subject: AW: AW: emacs-29 a2d4cd06f45: Improve VHDL mode highlighting
Date: Tue, 9 May 2023 15:48:35 +0000

> 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

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]