GNU bug report logs -
#65464
Emacs 29.1 - VHDL mode missing updates…
Previous Next
To reply to this bug, email your comments to 65464 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Wed, 23 Aug 2023 06:56:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tracy’s Gmail <justafrogg <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 23 Aug 2023 06:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Emacs 29.1 seems to have an old version of vhdl-model.el. It says that it’s 3.38.5 but it’s missing multiple updates that were in 3.38.3. It is also showing a date of 2015-03-12 which is very old.
Thanks.
Tracy
Sent from my iPhone
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Wed, 23 Aug 2023 10:48:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Tracy’s Gmail <justafrogg <at> gmail.com> writes:
> Emacs 29.1 seems to have an old version of vhdl-model.el. It says that it’s 3.38.5 but it’s missing multiple updates that were in 3.38.3. It is also showing a date of 2015-03-12 which is very old.
>
> Thanks.
> Tracy
Reto, do you have any comments here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 29 Aug 2023 13:24:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 65464 <at> debbugs.gnu.org (full text, mbox):
The vhdl-mode.el versions in the Emacs and my own distribution are not
in sync.
My latest version 3.39.2 with all older and recent updates is at
https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
Reto
On 2023-08-23 12:47, Stefan Kangas wrote:
> Tracy’s Gmail <justafrogg <at> gmail.com> writes:
>
>> Emacs 29.1 seems to have an old version of vhdl-model.el. It says that it’s 3.38.5 but it’s missing multiple updates that were in 3.38.3. It is also showing a date of 2015-03-12 which is very old.
>>
>> Thanks.
>> Tracy
> Reto, do you have any comments here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 29 Aug 2023 16:47:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Reto Zimmermann <reto <at> gnu.org> writes:
> My latest version 3.39.2 with all older and recent updates is at
>
> https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
Would you be willing to merge the changes from the Emacs master branch
into your version, and perhpaps even release a new version based on
the result? Then we could just simply copy your new version into
emacs.git.
One important thing that has changed in emacs.git version is that
lexical-binding was enabled.
Forcibly Merged 65154 65464.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 29 Aug 2023 16:49:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 29 Aug 2023 18:26:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Tracy’s Gmail <justafrogg <at> gmail.com> writes:
> I’m not proficient in Lisp so merging the code would be better suited to someone else.
Thanks, let's see what Reto says.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Wed, 30 Aug 2023 07:19:05 GMT)
Full text and
rfc822 format available.
Message #22 received at 65464 <at> debbugs.gnu.org (full text, mbox):
To all concerned,
I’m not proficient in Lisp so merging the code would be better suited to someone else.
I use vhdl-mode every day so I was able to identify issue.
Thanks!
Tracy Garner
Sent from my iPhone
On Aug 29, 2023, at 10:46 AM, Stefan Kangas <stefankangas <at> gmail.com> wrote:
Reto Zimmermann <reto <at> gnu.org> writes:
> My latest version 3.39.2 with all older and recent updates is at
>
> https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
Would you be willing to merge the changes from the Emacs master branch
into your version, and perhpaps even release a new version based on
the result? Then we could just simply copy your new version into
emacs.git.
One important thing that has changed in emacs.git version is that
lexical-binding was enabled.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Wed, 30 Aug 2023 12:25:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 65464 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-29 18:46, Stefan Kangas wrote:
> Reto Zimmermann <reto <at> gnu.org> writes:
>
>> My latest version 3.39.2 with all older and recent updates is at
>>
>> https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
>
> Would you be willing to merge the changes from the Emacs master branch
> into your version, and perhpaps even release a new version based on
> the result? Then we could just simply copy your new version into
> emacs.git.
>
> One important thing that has changed in emacs.git version is that
> lexical-binding was enabled.
Too many changes have been applied on Emacs side without my knowledge.
Some time ago I went through all of them and merged many into my code,
but some changes I could not approve of because they broke/changed
functionality and therefore didn't apply them. So, there are still
quite some differences that I'm not able to resolve myself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Wed, 30 Aug 2023 13:39:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> Cc: justafrogg <at> gmail.com, 65464 <at> debbugs.gnu.org
> Date: Wed, 30 Aug 2023 14:23:44 +0200
> From: Reto Zimmermann <reto <at> gnu.org>
>
> On 2023-08-29 18:46, Stefan Kangas wrote:
> > Reto Zimmermann <reto <at> gnu.org> writes:
> >
> >> My latest version 3.39.2 with all older and recent updates is at
> >>
> >> https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
> >
> > Would you be willing to merge the changes from the Emacs master branch
> > into your version, and perhpaps even release a new version based on
> > the result? Then we could just simply copy your new version into
> > emacs.git.
> >
> > One important thing that has changed in emacs.git version is that
> > lexical-binding was enabled.
>
> Too many changes have been applied on Emacs side without my knowledge.
> Some time ago I went through all of them and merged many into my code,
> but some changes I could not approve of because they broke/changed
> functionality and therefore didn't apply them. So, there are still
> quite some differences that I'm not able to resolve myself.
Maybe we should discuss those changes you don't approve, and see
whether we indeed must have them in Emacs, or maybe find a different
way of solving whatever problems they intended to solve, way that you
would agree with.
In general, if you keep developing and maintaining the package, I
think we should try very hard not to diverge what we have in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Thu, 31 Aug 2023 11:33:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 65464 <at> debbugs.gnu.org (full text, mbox):
On 2023-08-30 15:38, Eli Zaretskii wrote:
>> Cc: justafrogg <at> gmail.com, 65464 <at> debbugs.gnu.org
>> Date: Wed, 30 Aug 2023 14:23:44 +0200
>> From: Reto Zimmermann <reto <at> gnu.org>
>>
>> On 2023-08-29 18:46, Stefan Kangas wrote:
>>> Reto Zimmermann <reto <at> gnu.org> writes:
>>>
>>>> My latest version 3.39.2 with all older and recent updates is at
>>>>
>>>> https://iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html
>>>
>>> Would you be willing to merge the changes from the Emacs master branch
>>> into your version, and perhpaps even release a new version based on
>>> the result? Then we could just simply copy your new version into
>>> emacs.git.
>>>
>>> One important thing that has changed in emacs.git version is that
>>> lexical-binding was enabled.
>>
>> Too many changes have been applied on Emacs side without my knowledge.
>> Some time ago I went through all of them and merged many into my code,
>> but some changes I could not approve of because they broke/changed
>> functionality and therefore didn't apply them. So, there are still
>> quite some differences that I'm not able to resolve myself.
>
> Maybe we should discuss those changes you don't approve, and see
> whether we indeed must have them in Emacs, or maybe find a different
> way of solving whatever problems they intended to solve, way that you
> would agree with.
>
> In general, if you keep developing and maintaining the package, I
> think we should try very hard not to diverge what we have in Emacs.
Agree. I will be busy the next few weeks, but after that I will look
into it and start a discussion to resolve the differences.
In the meantime I have a question: when byte-compiling vhdl-mode.el with
Emacs 29.1 a 'defvar-1' ends up in vhdl-mode.elc, which causes an error
in older Emacs versions:
File mode specification error: (void-function defvar-1)
Someone reported the error for Emacs 28.2, but I can't reproduce. I can
reproduce on Emacs 15.1. Is this a known problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Thu, 31 Aug 2023 13:02:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 31 Aug 2023 13:32:12 +0200
> Cc: stefankangas <at> gmail.com, justafrogg <at> gmail.com, 65464 <at> debbugs.gnu.org
> From: Reto Zimmermann <reto <at> gnu.org>
>
> > Maybe we should discuss those changes you don't approve, and see
> > whether we indeed must have them in Emacs, or maybe find a different
> > way of solving whatever problems they intended to solve, way that you
> > would agree with.
> >
> > In general, if you keep developing and maintaining the package, I
> > think we should try very hard not to diverge what we have in Emacs.
>
> Agree. I will be busy the next few weeks, but after that I will look
> into it and start a discussion to resolve the differences.
Thanks.
> In the meantime I have a question: when byte-compiling vhdl-mode.el with
> Emacs 29.1 a 'defvar-1' ends up in vhdl-mode.elc, which causes an error
> in older Emacs versions:
>
> File mode specification error: (void-function defvar-1)
>
> Someone reported the error for Emacs 28.2, but I can't reproduce. I can
> reproduce on Emacs 15.1. Is this a known problem?
Stefan Monnier added that in commit 80ba4c17075, which was about
bug#55156. Stefan, can you answer this question? Did we make our
bytecode in Emacs 29 backward-incompatible?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Thu, 31 Aug 2023 15:00:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Stefan Monnier added that in commit 80ba4c17075, which was about
> bug#55156. Stefan, can you answer this question? Did we make our
> bytecode in Emacs 29 backward-incompatible?
See also Bug#57929.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Thu, 31 Aug 2023 18:48:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> Stefan Monnier added that in commit 80ba4c17075, which was about
> bug#55156. Stefan, can you answer this question?
Yes, he did :-)
Stefan
Removed tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 01 Sep 2023 20:23:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Sat, 02 Sep 2023 09:22:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Reto, while you're at it you may also want to take a look at vhdl-last-word:
(defun vhdl-last-word (point)
"If keyword at POINT is at eoi, then return (current-column) at that point.
Otherwise, return nil."
(save-excursion
(and (goto-char point)
(save-excursion (or (eq (progn (forward-sexp) (point))
(vhdl-point 'eoi))
(looking-at "\\s-*\\(--\\)?")))
(current-column))))
Since the calls to goto-char and looking-at never return nil, this function will always return the column of its argument. (The regexp matches the empty string so looking-at will succeed anywhere.)
And because vhdl-last-word is only used for its boolean value and never returns nil, calls to this function could effectively be replaced by t, but that was probably not the intention.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Sun, 10 Sep 2023 07:49:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 65464 <at> debbugs.gnu.org (full text, mbox):
Ping!
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Reto Zimmermann <reto <at> gnu.org>, justafrogg <at> gmail.com,
> 65464 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Thu, 31 Aug 2023 14:46:48 -0400
>
> > Stefan Monnier added that in commit 80ba4c17075, which was about
> > bug#55156. Stefan, can you answer this question?
>
> Yes, he did :-)
>
>
> Stefan
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Mon, 11 Sep 2023 02:41:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> Ping!
Not sure what's pending here. Stefan (the other) gave a good
reply, AFAICT.
Stefan
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: Reto Zimmermann <reto <at> gnu.org>, justafrogg <at> gmail.com,
>> 65464 <at> debbugs.gnu.org, stefankangas <at> gmail.com
>> Date: Thu, 31 Aug 2023 14:46:48 -0400
>>
>> > Stefan Monnier added that in commit 80ba4c17075, which was about
>> > bug#55156. Stefan, can you answer this question?
>>
>> Yes, he did :-)
>>
>>
>> Stefan
>>
>>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Mon, 11 Sep 2023 11:41:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: reto <at> gnu.org, justafrogg <at> gmail.com, 65464 <at> debbugs.gnu.org,
> stefankangas <at> gmail.com
> Date: Sun, 10 Sep 2023 22:40:38 -0400
>
> > Ping!
>
> Not sure what's pending here. Stefan (the other) gave a good
> reply, AFAICT.
AFAICT, he just pointed to another bug report.
Does this mean the answer to Reto's question is "yes, it's a known
problem for which we have no solution"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Mon, 11 Sep 2023 16:23:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> Does this mean the answer to Reto's question is "yes, it's a known problem for which we have no solution"?
That's right, assuming the question was about packages that were byte-compiled on newer Emacs versions than they are used on. Changes to Emacs are usually backward-compatible with respect to .elc files, but there is never guarantee that they are forward-compatible.
This is not just a matter of changes to the byte-code compiler and interpreter but more often about changes to macros.
In other words, if someone is unable to run vhdl-mode.elc from Emacs 29 on Emacs 28, then we're very sorry but do not consider it a defect that needs to be remedied.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Mon, 11 Sep 2023 22:19:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> In other words, if someone is unable to run vhdl-mode.elc from Emacs 29 on
> Emacs 28, then we're very sorry but do not consider it a defect that needs
> to be remedied.
Actually, I do think we should try and detect the problem (and ideally
emit a message/error and maybe even fallback to loading the
non-compiled file).
We do have the necessary info in the `.elc` file (the byte 4th byte
(0-based numbering) of a `.elc` file holds the major version number of
the Emacs on which it was compiled (with some caveat for non-released
Emacs versions, such as 30.0.NN emitting `.elc` files that say "version
29")).
We just need to make use of that info.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 12 Sep 2023 07:00:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 65464 <at> debbugs.gnu.org (full text, mbox):
12 sep. 2023 kl. 00.17 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
> Actually, I do think we should try and detect the problem (and ideally
> emit a message/error and maybe even fallback to loading the
> non-compiled file).
Very much agree. In fact I think we should do so in both directions.
And allow compiled bytecode for different versions to exist side-by-side by using different file names, which would be a step towards solving the problem once and for all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 12 Sep 2023 11:32:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 65464 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Reto Zimmermann <reto <at> gnu.org>,
> 65464 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 11 Sep 2023 18:17:18 -0400
>
> > In other words, if someone is unable to run vhdl-mode.elc from Emacs 29 on
> > Emacs 28, then we're very sorry but do not consider it a defect that needs
> > to be remedied.
>
> Actually, I do think we should try and detect the problem (and ideally
> emit a message/error and maybe even fallback to loading the
> non-compiled file).
>
> We do have the necessary info in the `.elc` file (the byte 4th byte
> (0-based numbering) of a `.elc` file holds the major version number of
> the Emacs on which it was compiled (with some caveat for non-released
> Emacs versions, such as 30.0.NN emitting `.elc` files that say "version
> 29")).
>
> We just need to make use of that info.
Make use how? In most cases the byte-code is compatible both backward
and forward, so displaying a warning would be an annoyance that 99% of
time is unjustified.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#65464
; Package
emacs
.
(Tue, 12 Sep 2023 14:09:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 65464 <at> debbugs.gnu.org (full text, mbox):
>> We just need to make use of that info.
> Make use how? In most cases the byte-code is compatible both backward
> and forward, so displaying a warning would be an annoyance that 99% of
> time is unjustified.
Actually, forward compatibility is often broken between major versions.
Stefan
This bug report was last modified 1 year and 276 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.