From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Reto Zimmermann Newsgroups: gmane.emacs.devel Subject: Re: AW: emacs-29 a2d4cd06f45: Improve VHDL mode highlighting Date: Tue, 9 May 2023 16:37:52 +0200 Message-ID: <8c364116-0eb7-daef-536e-ae992071464d@gnu.org> References: <168326553347.14898.7329669431232347477@vcs2.savannah.gnu.org> <20230505054533.D680AC1BECD@vcs2.savannah.gnu.org> <87mt2e9c0e.fsf@gmx.de> <83h6slc438.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------bYmuxPTMUiF2H5q2k0YE9zhn" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13079"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Cc: "emacs-devel@gnu.org" To: Cyril Arnould , Eli Zaretskii , Michael Albinus , =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 09 16:38:46 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pwOUI-0003GU-DO for ged-emacs-devel@m.gmane-mx.org; Tue, 09 May 2023 16:38:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pwOTc-0004sN-1N; Tue, 09 May 2023 10:38:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwOTa-0004sF-KF for emacs-devel@gnu.org; Tue, 09 May 2023 10:38:02 -0400 Original-Received: from asave02.hostfactory.ch ([217.150.252.154]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pwOTY-000860-NT; Tue, 09 May 2023 10:38:02 -0400 Original-Received: from server09.hostfactory.ch ([185.117.170.110]) by asave02.hostfactory.ch with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pwOTS-0001KK-Kk; Tue, 09 May 2023 16:37:56 +0200 Original-Received: from [192.168.0.99] (77-56-245-67.dclient.hispeed.ch [77.56.245.67]) (Authenticated sender: reto@retoweb.net) by server09.hostfactory.ch (Postfix) with ESMTPSA id 10111601C8196; Tue, 9 May 2023 16:37:53 +0200 (CEST) Content-Language: en-US In-Reply-To: X-PPP-Message-ID: <168364307340.9741.2867053536126876280@server09.hostfactory.ch> X-PPP-Vhost: retoweb.net X-Originating-IP: 185.117.170.110 X-SpamExperts-Domain: outboundprotection.hostfactory.ch X-SpamExperts-Username: 185.117.170.110 Authentication-Results: hostfactory.ch; auth=pass smtp.auth=185.117.170.110@outboundprotection.hostfactory.ch X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9G6wUV/Z9tsxJBTR8PXMs0PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xV/VrTvp80ujJPiHe6BbBW+/J6Lx92LA/CMdMO5TA/EcDe zKDqWktITImzKaAnGpyEJwDlirT0lAJas0C6MUont+ckGZPyR0k5M/n90k2EDWGLRkvcqQzvJsy2 ADXFgAlpqJVsGl/8ZUy39C6vjHB6K5PM/zLHG1KFDmoBE60ja09kN7MM31r8n6t5T2S20aU5iSLl bw/hjZHclGt5uA05zUVyzRILyduVl6cJUh6/qWnN4OZYhX9YO36+QeblhLeDH28YGvNv6I6RuSay tok+5fI2/IW5LMClVIpD0TqF2whNiDVkJX+UoBwX40UCTfVeTORxZcD4V7zSoG4qeE0bcRqRLNeq s/aet6qZ3OUmgJZhjtcCAKH/oyUGun6WHEmmDWdbitgkRVHfNJQvgYp02xynCn9a+xb2uRiVGLQN +ko7lBvGlD3uYN84ZUa5gNfNDpZknxSBowKvJmVUgCIeKTrgWxooNcRvVzTo8bOgd/IWYr1gNIzo /NLhMj9Y7dxuRm95C9fknKYowPVSXSFWW+1QWC2ukiJpVphLB1gjiirJEgCNEGiwjjUNiuRF2B3W q/sp5F7nyLGouwMEUdm97DdbHH/8qihAF4Y/klw17tadXN8QoJkCGUT+/nq62lQ14TiNHZBO9dkj kpbpFG8w6J1fhOzjF0b4LXcjJZ5loqD3yO8WP21Qh0U+y6INlsiZM3cm/7Rav6M2nxvoqVkbbPSP RhjyQy5ONSz+cQP1hR49a7ce8o9w8 X-Report-Abuse-To: spam@asave01.hostfactory.ch Received-SPF: softfail client-ip=217.150.252.154; envelope-from=reto@gnu.org; helo=asave02.hostfactory.ch X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.421, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306007 Archived-At: This is a multi-part message in MIME format. --------------bYmuxPTMUiF2H5q2k0YE9zhn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------bYmuxPTMUiF2H5q2k0YE9zhn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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

--------------bYmuxPTMUiF2H5q2k0YE9zhn--