From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cyril Arnould Newsgroups: gmane.emacs.bugs Subject: bug#63251: AW: bug#63251: 28.2; vhdl-mode contribution Date: Sun, 7 May 2023 17:48:48 +0000 Message-ID: References: <564BC9FB-248F-4973-9D8C-C1DA7D3D60C6@gmail.com> <0E7DAFC0-0F1E-48B7-AC2F-D84D081C05C9@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_AS4PR10MB6110F3CA3230C0B8815E8BB2E3709AS4PR10MB6110EURP_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25661"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Reto Zimmermann , Eli Zaretskii , "63251@debbugs.gnu.org" <63251@debbugs.gnu.org> To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 07 19:49:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pviVV-0006To-G9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 May 2023 19:49:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pviVL-00051y-FG; Sun, 07 May 2023 13:49:03 -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 1pviVK-00051p-Pm for bug-gnu-emacs@gnu.org; Sun, 07 May 2023 13:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pviVK-0001VR-FG for bug-gnu-emacs@gnu.org; Sun, 07 May 2023 13:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pviVK-00072H-4r for bug-gnu-emacs@gnu.org; Sun, 07 May 2023 13:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Cyril Arnould Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 May 2023 17:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63251 X-GNU-PR-Package: emacs Original-Received: via spool by 63251-submit@debbugs.gnu.org id=B63251.168348173827036 (code B ref 63251); Sun, 07 May 2023 17:49:02 +0000 Original-Received: (at 63251) by debbugs.gnu.org; 7 May 2023 17:48:58 +0000 Original-Received: from localhost ([127.0.0.1]:38390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pviVF-00071z-Kv for submit@debbugs.gnu.org; Sun, 07 May 2023 13:48:58 -0400 Original-Received: from mail-he1eur04olkn2106.outbound.protection.outlook.com ([40.92.73.106]:9859 helo=EUR04-HE1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pviVD-00071i-5M for 63251@debbugs.gnu.org; Sun, 07 May 2023 13:48:56 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8kI0ZMEpb3La/u0Tp9glLTx9tEQgmAGO3cSAV+ESlkT1OZpRxv7A3rtuSD6ldbiXLaw7kTCvxGv6fyHPOtRfjEojHfqjQB1292h3r8AU1nonyS4KSs3RC+bcVvMgT436GL7gsZkCeeahJ9c6okvjdlnuvHUelYBM29PnccmHwWi4a+VMCsLd+6CMojLDpkNCHkEi21DKThOLNdk+N46D3Ph5ttuvjBtS+f7ix6+n17peu1d4Judr6GxNqUfECtsCgzXX7BBwxuaNYPC2orgt5wHK6E54vISP/OI+T5nB5COu8TiZqAASqaDQQYoLZvlZ7R65mC+3u94wWXUxW6log== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2CqGTnJqZ0YHWvdRuLb2CoDJkiuTm4sogP/eEV/Wu54=; b=X24tipPsRNS+Jlu4wxp6XJJOys96dJvXKcU32+UNVNYlbHoZ2dKuvK2/ZeMnBimUGw5MvF36BzvF9JRBBO6xVBUlSFEZjw7PjXdVNkZDZcoVPxx4HveJ0GECKaUQeOYzkaG3azIFXCc26g/y7eQ8Wg9hs8PHojwyxa7W4syAaeYUSV4+ETjtzORPiMhYZhHRqdc+GBHVDaHlRA0pZombOBbNN2cVnuNfWbjvWLL6RW/p1TpM+N0SU8ZNnwIVb9jBZtcUQyojRKX4voxPD7NbrVxmNi5ggI6j/TkqCKFh6bT21WXCBfCCuLGN13fLTb3Iww8vXhWwly1DxwtjUpWw2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2CqGTnJqZ0YHWvdRuLb2CoDJkiuTm4sogP/eEV/Wu54=; b=mUukYIkJ37BQba8aLuq0NnKbXURPsfJIJLJks2cefbuNWJxITrpuGzw3M6IshRr6yBHArc20SSc3NYybbp/ekYus3nba+YOs7rQRqAPWIBNeOBIUIIurN+N+3RFD+JBgAh5FQG167a0HXGbsJLoWau96KI8aavtsRKqYRJocLb05+r/1QhT7R70pBFXmIwb7PpDeuXWGgRylGYuxhXgh0WeBoytuf1wuSy2XQKDrKuZCk/VLC6MDzo9wohjEnGBRyZ2WRNPQ1COuYcrJGY2OKDJ3sixNbATnFxVA0IOn/QAnTZTyTXg7dAsSvahTWY4cy144jfMhqPwUYfPKlj+VKw== Original-Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:582::17) by AS8PR10MB7857.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:636::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.31; Sun, 7 May 2023 17:48:48 +0000 Original-Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::18ab:4656:4a13:e7e1]) by AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::18ab:4656:4a13:e7e1%7]) with mapi id 15.20.6363.031; Sun, 7 May 2023 17:48:48 +0000 Thread-Topic: bug#63251: 28.2; vhdl-mode contribution Thread-Index: AQHZf/xS6WFPgZRzfky0YujufV2RU69NM2m0gACVj7+AAK+qgIAAAlBPgACFcQCAAAcxaQ== In-Reply-To: Accept-Language: de-CH, en-US Content-Language: de-CH x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [fAaTcBcxYQGQ2Lm4ChQ9QGW7fLQ1is5I] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS4PR10MB6110:EE_|AS8PR10MB7857:EE_ x-ms-office365-filtering-correlation-id: d3f513f9-b760-4d4c-eb03-08db4f234fe2 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o6JOpIp3msshUoVUMYEoIJwysRGkaTxTHReDhNT33j+0sOjRZmex3ZpScjwoyKoBzdofu27FY0B1e1aDQJdH1QoA7ZFB0HGLjcSTxbKTEtG3fUP/RT3Uk6GarO+2YAPU1FPBlYwBkImjdMrZpA3clkQEFa21PbiAml3428dSez/NT5n3yePOtJgYl1lmS4LfuvM09BgW4lUysbQJ43rfdC02j7zrbSc/LdWlCCyYOlW2IDAmrLv6oaqxtMObvzdf4MyVJDInXu7Q8fo1ooKlBOKfQu2q/nyt8jST8GKO3X8009zRiwQTZtwPVPOb9BU3aiZNx8VeDhKkvL6lCkm0Hu7cSw6AhMA5kxTpy2tJDOuQ6zc40ouEQsZwfp91DHKoBzz13ep319cJ2zyduwY4kk93xZIZru0QW/uSGYCAxOMdvH/J9ILxLQHfidMGafTobClSbtJpQQ0DoVkiIfsvJ68PJ0++cOpSSl7kYUZXfJc/4G3fO4IyaTPK3tR2kOX2A/B9mCa7f0Im2lvbtgySI0GsJWw6+DtualWHwHBOIpJytuQ43I59TJS2Hr43gfbw x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: UftqzOq0U3sCbO0Ivx5cOnSKdym4SAcqYzB8T/uwTjs6xawFju3fsTYhmYr1qJng+fe27Hyykiv9P4wE/696a1G9XgnJwq8zXfoqwJ3Eh0fL84nJ5aVS9n661jS/eQIxprhQZP8zQpZSDYBy99vEhc8n+9LrghVNiP9PEjOwHxo8oqm3R4y/29N9XUotTPIWTGPXLLBBcvgLtOoLIJvoPpIaa+haTF+bEJPjKZizv83jkMgzW/pornM9yuMZZlQ01/Mv5JaVPm1FwhplEtjMk8EljbJilFpzpMopVv6jafUgxwLHYJpqa8kzcmwzcydnRgowjWKWvyAuyZpy4BsMOmzUqn4ywbGNtBXycm0Bs8FRQJgGV+cMAfuIr1wemp1bEupLhTz127PHXWgNsS5bUOuEgENJtL/HFXXl1b93AR47BN9M8RPEzoK60TGZPpcNYR97xRUuuswRfeDP6aAScMyHOVH6XsGb2DH2ReXOM4o7otaSJqx7qXDcX0PaC1scrTj5mAH7SBuIG/RRm+AzpXcbYcjYCqDNa5wxEva7rnLRVYIvQChytOSclEFWGhp4uBpfFjmDIg2Sn4kQsxIQi5YGd8XEM1+aWbXLNxpYlnoSPaEfVBl/NVFH5xgW3CR+p5mp5/jtGYP7x1e2+ML4H3kVYI/hVBDa1QqJ7qcCpZJbZSy9BydZaAtqBgdDP2mI5xw9/1Ba+h/W4cY1+3/mWASMHWIbdnjh9vbFM7hBWO/JNHRGP4YAoKEy3I 3/YdTat62osryyTNORgxEVydlTy9gncCLvJh44T/tSvjSxTqtc2g6jOU4sQscze1Vdf1rVbYZUrR4wboB6l4P8vc+Iaztr8fvg X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: d3f513f9-b760-4d4c-eb03-08db4f234fe2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2023 17:48:48.5368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR10MB7857 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261268 Archived-At: --_000_AS4PR10MB6110F3CA3230C0B8815E8BB2E3709AS4PR10MB6110EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Why would they be set to a dotted list? Can you give an example? Oh, sorry, I meant dotted pair, not list. So the (2 . 3) from the ModelSim compiler entry, for example. > I tried > > (cons :tag "Warning and Info" > (natnum :tag "Warning subexp index") > (natnum :tag "Info subexp index ")) > > instead of the (sexp ...) and it seems to work alright. I agree, the above code seems to be the better option. I would change the =ABWarning and Info=BB text though, seen as the compilation command can differentiate between Warnings, Infos AND Errors using the expression. Maybe =ABType detection=BB? Or =ABType detection via regexp=BB? > What I meant was that the code > > (let ((tmp-alist vhdl-compiler-alist)) > (while tmp-alist > (setcdr (nthcdr 3 (nth 11 (car tmp-alist))) > '(2 . nil)) > (setq tmp-alist (cdr tmp-alist)))) > > modifies the existing list structure instead of creating a new one based = on the old. This can lead to surprises if parts of the structure being muta= ted is shared with structure elsewhere. Now this code probably does work, b= ut it's a bit brittle, and it takes some work for the reader to understand = that it's OK. Contrast it to something like (untested!) > > (setq vhdl-compiler-alist > (mapcar (lambda (entry) > ;; Add a `2' to the end of the list that is element #11= . > (append (take 11 entry) > (append (nth 11 entry) (list 2)) > (nthcdr 12 entry))) > vhdl-compiler-alist)) > > where there is no mutation of the list structure, nor any sharing of a pr= ogram constant whose accidental mutation might have very confusing conseque= nces. (`take` is new in Emacs 29 but you can work around it by using `butla= st` instead if the code needs to work with older Emacs versions.) I have to admit this is going over my head a bit, but thanks for explaining. I'll let it up to the maintainers to decide upon the backwards compatibility code, I'm fine either way. Couldn't test your changes though as I'm still on Emacs 28.2. Von: Mattias Engdeg=E5rd Gesendet: Sonntag, 7. Mai 2023 18:22 An: Cyril Arnould Cc: 63251@debbugs.gnu.org; Reto Zimmermann; Eli Zaretskii Betreff: Re: bug#63251: 28.2; vhdl-mode contribution 7 maj 2023 kl. 17.40 skrev Cyril Arnould : > I had tried (cons =85) instead of (sexp =85), but that just resulted in > the customization menu breaking again if one of the compilers was set > to a dotted list. Why would they be set to a dotted list? Can you give an example? I tried (cons :tag "Warning and Info" (natnum :tag "Warning subexp index") (natnum :tag "Info subexp index ")) instead of the (sexp ...) and it seems to work alright. > > Think of what happens if later code performs an in-place change of that= nil you added. > > I am by no means an expert when it comes to elisp, I don=92t know what > kind of problems this could cause. What I meant was that the code (let ((tmp-alist vhdl-compiler-alist)) (while tmp-alist (setcdr (nthcdr 3 (nth 11 (car tmp-alist))) '(2 . nil)) (setq tmp-alist (cdr tmp-alist)))) modifies the existing list structure instead of creating a new one based on= the old. This can lead to surprises if parts of the structure being mutate= d is shared with structure elsewhere. Now this code probably does work, but= it's a bit brittle, and it takes some work for the reader to understand th= at it's OK. Contrast it to something like (untested!) (setq vhdl-compiler-alist (mapcar (lambda (entry) ;; Add a `2' to the end of the list that is element #11. (append (take 11 entry) (append (nth 11 entry) (list 2)) (nthcdr 12 entry))) vhdl-compiler-alist)) where there is no mutation of the list structure, nor any sharing of a prog= ram constant whose accidental mutation might have very confusing consequenc= es. (`take` is new in Emacs 29 but you can work around it by using `butlast= ` instead if the code needs to work with older Emacs versions.) --_000_AS4PR10MB6110F3CA3230C0B8815E8BB2E3709AS4PR10MB6110EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Why would they be set to a dotted list? Can you= give an example?

Oh, sorry, I meant dotted pair, not list. So the (2 = . 3) from the

ModelSim compiler entry, for example.

 

> I tried

> 

>        =             &nb= sp;          (cons :tag "= Warning and Info"

>        =             &nb= sp;            =     (natnum :tag "Warning subexp index")

>        =             &nb= sp;            =     (natnum :tag "Info subexp index   ")= )

> 

> instead of the (sexp ...) and it seems to work = alright.

 

I agree, the above code seems to be the better optio= n. I would

change the =ABWarning and Info=BB text though, seen = as the

compilation command can differentiate between Warnin= gs, Infos AND

Errors using the expression. Maybe =ABType detection= =BB? Or =ABType

detection via regexp=BB?

 

> What I meant was that the code

> 

>   (let ((tmp-alist vhdl-compiler-alis= t))

>     (while tmp-alist

>       (setcdr (nt= hcdr 3 (nth 11 (car tmp-alist)))

>        =        '(2 . nil))

>       (setq tmp-a= list (cdr tmp-alist))))

> 

> modifies the existing list structure instead of= creating a new one based on the old. This can lead to surprises if parts o= f the structure being mutated is shared with structure elsewhere. Now this = code probably does work, but it's a bit brittle, and it takes some work for the reader to understand that it's OK.= Contrast it to something like (untested!)

> 

>   (setq vhdl-compiler-alist

>        = (mapcar (lambda (entry)

>        =            ;; Add a `2' t= o the end of the list that is element #11.

>        =            (append (take = 11 entry)

>        =             &nb= sp;      (append (nth 11 entry) (list 2))

>        =             &nb= sp;      (nthcdr 12 entry)))

>        =          vhdl-compiler-alist))=

> 

> where there is no mutation of the list structur= e, nor any sharing of a program constant whose accidental mutation might ha= ve very confusing consequences. (`take` is new in Emacs 29 but you can work= around it by using `butlast` instead if the code needs to work with older Emacs versions.)

 

I have to admit this is going over my head a bit, bu= t thanks for

explaining. I'll let it up to the maintainers to dec= ide upon the

backwards compatibility code, I'm fine either way. C= ouldn't test

your changes though as I'm still on Emacs 28.2.=

 

 

Von: Mattias Engdeg=E5rd
Gesendet: Sonntag, 7. Mai 2023 18:22
An: Cyril Arnould Cc: 63251@debbugs.gnu.org; Reto Zimmermann; Eli Zaretskii
Betreff: Re: bug#63251: 28.2; vhdl-mode contribution

 

7 maj 2023 kl. 17.40 = skrev Cyril Arnould <cyril.arnould@outlook.com>:

> I had tried (cons =85) instead of (sexp =85), but that just resulted i= n
> the customization menu breaking again if one of the compilers was set<= br> > to a dotted list.

Why would they be set to a dotted list? Can you give an example?
I tried

            &nb= sp;            =      (cons :tag "Warning and Info"
            &nb= sp;            =            (natnum :tag &= quot;Warning subexp index")
            &nb= sp;            =            (natnum :tag &= quot;Info subexp index   "))

instead of the (sexp ...) and it seems to work alright.

> > Think of what happens if later code performs an in-place change o= f that nil you added.
> 
> I am by no means an expert when it comes to elisp, I don=92t know what=
> kind of problems this could cause.

What I meant was that the code

  (let ((tmp-alist vhdl-compiler-alist))
    (while tmp-alist
      (setcdr (nthcdr 3 (nth 11 (car tmp-alist)))<= br>             &nb= sp; '(2 . nil))
      (setq tmp-alist (cdr tmp-alist))))

modifies the existing list structure instead of creating a new one based on= the old. This can lead to surprises if parts of the structure being mutate= d is shared with structure elsewhere. Now this code probably does work, but= it's a bit brittle, and it takes some work for the reader to understand that it's OK. Contrast it to someth= ing like (untested!)

  (setq vhdl-compiler-alist
        (mapcar (lambda (entry)
            &nb= sp;     ;; Add a `2' to the end of the list that is ele= ment #11.
            &nb= sp;     (append (take 11 entry)
            &nb= sp;            = (append (nth 11 entry) (list 2))
            &nb= sp;            = (nthcdr 12 entry)))
            &nb= sp;   vhdl-compiler-alist))

where there is no mutation of the list structure, nor any sharing of a prog= ram constant whose accidental mutation might have very confusing consequenc= es. (`take` is new in Emacs 29 but you can work around it by using `butlast= ` instead if the code needs to work with older Emacs versions.)

 

--_000_AS4PR10MB6110F3CA3230C0B8815E8BB2E3709AS4PR10MB6110EURP_--