GNU bug report logs -
#39553
28.0.50; ada mode was removed
Previous Next
Reported by: Tom Tromey <tom <at> tromey.com>
Date: Mon, 10 Feb 2020 20:31:01 UTC
Severity: normal
Tags: wontfix
Merged with 50510
Found in versions 27.1, 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39553 in the body.
You can then email your comments to 39553 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Mon, 10 Feb 2020 20:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tom Tromey <tom <at> tromey.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 10 Feb 2020 20:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I built Emacs from source and noticed that ada-mode was removed.
I dislike this decision. I work in Ada with some regularity.
The commit log says:
Delete built-in ada-mode; Gnu ELPA is a good replacement
... however, I think that's insufficient justification. package.el is
designed in such a way that a package could live *both* in emacs proper
and have separate updates on ELPA. I'd prefer this "batteries included"
approach here.
Note that this change neglected to update auto-mode-alist.
So, visiting an Ada source file now causes an error.
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.11, cairo version 1.16.0)
of 2020-02-07 built on murgatroyd
Repository revision: 30abcda54e1b0e15fc10b3db1c2b9f89ca521bfa
Repository branch: master
Windowing system distributor 'Fedora Project', version 11.0.12006000
System Description: Fedora 30 (Workstation Edition)
Recent messages:
Saving /home/tromey/.newsrc.eld...
Saving file /home/tromey/.newsrc.eld...
Wrote /home/tromey/.newsrc.eld
Saving /home/tromey/.newsrc.eld...done
Making completion list...
File mode specification error: (void-function ada-mode) [2 times]
Type "q" in help window to restore its previous buffer, C-M-v to scroll help.
s is undefined
Quit
Mark saved where search started
Configured using:
'configure --prefix=/home/tromey/Emacs/install --with-libjit
--with-x-toolkit=gtk3
PKG_CONFIG_PATH=/home/tromey/Emacs/install/lib64/pkgconfig/'
Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
XDBE XIM MODULES THREADS PDUMPER GMP
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
ggtags-navigation-mode: t
erc-list-mode: t
erc-menu-mode: t
erc-autojoin-mode: t
erc-ring-mode: t
erc-pcomplete-mode: t
erc-netsplit-mode: t
erc-spelling-mode: t
erc-truncate-mode: t
shell-dirtrack-mode: t
which-function-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-notify-mode: t
erc-notifications-mode: t
erc-match-mode: t
erc-services-mode: t
erc-networks-mode: t
erc-hl-nicks-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
savehist-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow emacsbug cl-print webjump novice rfc2368 find-file gud autoconf
autoconf-mode idutils pulse pcase goto-addr ggtags etags fileloop xref
project log-view pcvs-util tabify man html2text find-dired ffap grep
compile python tramp-sh yaml-mode term/xterm xterm dabbrev supercite
regi bbdb-message mailalias mail-hist copyright vc-mtn vc-hg vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs org-element avl-tree generator
ol-eww ol-rmail ol-mhe ol-irc ol-info ol-gnus nnir ol-docview doc-view
image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint
org-pcomplete org-list org-faces org-entities noutline outline
org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat org-macs org-loaddefs add-log bug-reference vc-git cc-mode
cc-fonts cc-guess cc-menus cc-cmds jka-compr erc-list erc-menu erc-join
erc-ring erc-pcomplete erc-netsplit erc-spelling erc-truncate
smerge-mode diff diff-mode easy-mmode flow-fill mm-archive gnus-html
url-queue help-fns radix-tree url-cache mm-url cl-extra sort smiley
gnus-cite mail-extr gnus-bcklg misearch multi-isearch gnus-async qp
gnus-ml disp-table gnus-topic nndraft nnmh nnfolder utf-7 bbdb-gnus
bbdb-mua bbdb-com crm gnutls network-stream nsm gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view
mml-smime smime dig nntp gnus-cache gnus-sum url url-proxy url-privacy
url-expand url-methods url-history mailcap shr url-cookie url-domsuf svg
dom gnus-group gnus-undo smtpmail sendmail gnus-start gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
rmc puny rfc822 mml mml-sec epa derived epg epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums text-property-search mail-utils mm-util mail-prsvr flyspell
ispell diminish appt diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp
which-func imenu autorevert filenotify desktop frameset cus-start
cus-load git-link url-util erc-track erc-notify
erc-desktop-notifications erc-match erc-services erc-networks
notifications dbus xml erc-hl-nicks color erc-button erc-fill erc-stamp
wid-edit erc-goodies erc erc-backend erc-compat format-spec thingatpt pp
erc-loaddefs dired-aux dired-x dired dired-loaddefs warnings advice
vc-dir ewoc vc vc-dispatcher flycheck find-func help-mode rx dash
cc-styles cc-align cc-engine cc-vars cc-defs bbdb bbdb-site timezone
ange-ftp comint ansi-color ring server savehist finder-inf info package
easymenu browse-url url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 1253099 400357)
(symbols 48 46427 1)
(strings 32 428203 32364)
(string-bytes 1 10037565)
(vectors 16 145593)
(vector-slots 8 2855195 239264)
(floats 8 476 963)
(intervals 56 121804 53778)
(buffers 1000 207))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Mon, 17 Feb 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Stephen, you made the commit in question. Could you please take a look at
Bug#39553 <https://debbugs.gnu.org/39553>? Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Sun, 23 Aug 2020 13:16:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Stephen, you made the commit in question. Could you please take a look at
> Bug#39553 <https://debbugs.gnu.org/39553>? Thanks.
6 months later. Ping!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Mon, 07 Sep 2020 20:45:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Without speaking to the policy decision of removing ada-mode, I don't seem to have the same problem as you do in regards to auto-mode-alist. When I open an Ada source file it opens in fundamental mode with no error. Looking through the value of auto-mode-alist as well I don't see anything related to Ada, which is probably the expected behaviour. I've never dealt with Ada files before, so maybe there is a configuration problem on your end?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Mon, 07 Sep 2020 20:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 39553 <at> debbugs.gnu.org (full text, mbox):
"Nicholas Savage" <nick <at> nicksavage.ca> writes:
> Without speaking to the policy decision of removing ada-mode, I don't
> seem to have the same problem as you do in regards to
> auto-mode-alist. When I open an Ada source file it opens in
> fundamental mode with no error. Looking through the value of
> auto-mode-alist as well I don't see anything related to Ada, which is
> probably the expected behaviour. I've never dealt with Ada files
> before, so maybe there is a configuration problem on your end?
I think this was fixed recently:
commit b44a5d849e2d29bf91abe9015105cc71da458b1f
Author: Stephen Leake <stephen_leake <at> stephe-leake.org>
AuthorDate: Fri Aug 7 04:43:18 2020 -0700
* lisp/files.el (auto-mode-alist): delete ada-mode; now in GNU ELPA only
As for the policy of moving modes to ELPA -- I think we shouldn't do
that until we have the "include ELPA in the Emacs distribution" thing
that's been discussed for quite a while (but hasn't been implemented
yet).
As for ada-mode in particular, it's too late to move it back now, so I
don't think there's anything further to be done in this bug report, so
I'm closing it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Sep 2020 20:58:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
39553 <at> debbugs.gnu.org and Tom Tromey <tom <at> tromey.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Sep 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 02:31:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 39553 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 07 Sep 2020 22:56:42 +0200
> Cc: 39553 <at> debbugs.gnu.org
>
> As for the policy of moving modes to ELPA -- I think we shouldn't do
> that until we have the "include ELPA in the Emacs distribution" thing
> that's been discussed for quite a while (but hasn't been implemented
> yet).
I tend to agree.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 07:37:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> As for the policy of moving modes to ELPA -- I think we shouldn't do
> that until we have the "include ELPA in the Emacs distribution" thing
> that's been discussed for quite a while (but hasn't been implemented
> yet).
Is it hard to do? We just need to add a step to copy the relevant files
in make-tarball.txt and we're done, no? Or do we need it to be
completely automatic?
> As for ada-mode in particular, it's too late to move it back now, so I
> don't think there's anything further to be done in this bug report, so
> I'm closing it.
Can't we just move it back in 27.2?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 08:05:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 39553 <at> debbugs.gnu.org (full text, mbox):
On Sep 08 2020, Stefan Kangas wrote:
> Is it hard to do? We just need to add a step to copy the relevant files
> in make-tarball.txt and we're done, no? Or do we need it to be
> completely automatic?
You probably also need to regenerate loaddefs.el.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 10:31:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
>> As for the policy of moving modes to ELPA -- I think we shouldn't do
>> that until we have the "include ELPA in the Emacs distribution" thing
>> that's been discussed for quite a while (but hasn't been implemented
>> yet).
>
> Is it hard to do? We just need to add a step to copy the relevant files
> in make-tarball.txt and we're done, no? Or do we need it to be
> completely automatic?
I think the idea is that one should still be able to download newer
versions of the packages from ELPA, even if (older) versions are
included in the distribution? But I haven't followed the discussions
much...
>> As for ada-mode in particular, it's too late to move it back now, so I
>> don't think there's anything further to be done in this bug report, so
>> I'm closing it.
>
> Can't we just move it back in 27.2?
We could, but I think that'd be even more annoying, really.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 12:11:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Is it hard to do? We just need to add a step to copy the relevant files
>> in make-tarball.txt and we're done, no? Or do we need it to be
>> completely automatic?
>
> I think the idea is that one should still be able to download newer
> versions of the packages from ELPA, even if (older) versions are
> included in the distribution? But I haven't followed the discussions
> much...
Shouldn't that Just Work (TM)?
To be more specific, typing `M-x list-packages U' should mark such
packages for upgrade automatically? Anything else sounds like a bug to
me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 14:26:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 39553 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 8 Sep 2020 00:36:24 -0700
> Cc: 39553 <at> debbugs.gnu.org
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > As for the policy of moving modes to ELPA -- I think we shouldn't do
> > that until we have the "include ELPA in the Emacs distribution" thing
> > that's been discussed for quite a while (but hasn't been implemented
> > yet).
>
> Is it hard to do? We just need to add a step to copy the relevant files
> in make-tarball.txt and we're done, no?
That part is simple, but then it won't support updating the package
from ELPA. So doing this "the simple way" flies in the face of the
very reason for which packages are moved to ELPA: to allow users
update them without waiting for the next Emacs release.
The challenge is to "include ELPA" in a way that will allow updating
the included packages.
> > As for ada-mode in particular, it's too late to move it back now, so I
> > don't think there's anything further to be done in this bug report, so
> > I'm closing it.
>
> Can't we just move it back in 27.2?
If that's what people want, sure, I think we can. But we should first
review the reasons for which we moved ada-mode to ELPA: perhaps some
of those reasons are still valid, and we will be re-creating the same
problems again.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 14:27:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> Is it hard to do? We just need to add a step to copy the relevant files
>>> in make-tarball.txt and we're done, no? Or do we need it to be
>>> completely automatic?
>>
>> I think the idea is that one should still be able to download newer
>> versions of the packages from ELPA, even if (older) versions are
>> included in the distribution? But I haven't followed the discussions
>> much...
>
> Shouldn't that Just Work (TM)?
>
> To be more specific, typing `M-x list-packages U' should mark such
> packages for upgrade automatically? Anything else sounds like a bug to
> me.
Seems like this actually doesn't work.
I press `M-x list-packages' using an Emacs with svg.el version 1.0.
Version 1.1 is available from GNU ELPA. But it doesn't propose to
update it.
I'm not sure where that leaves us...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 14:57:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 39553 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 8 Sep 2020 14:26:49 +0000
> Cc: 39553 <at> debbugs.gnu.org, Nicholas Savage <nick <at> nicksavage.ca>
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
> >> I think the idea is that one should still be able to download newer
> >> versions of the packages from ELPA, even if (older) versions are
> >> included in the distribution? But I haven't followed the discussions
> >> much...
> >
> > Shouldn't that Just Work (TM)?
> >
> > To be more specific, typing `M-x list-packages U' should mark such
> > packages for upgrade automatically? Anything else sounds like a bug to
> > me.
>
> Seems like this actually doesn't work.
>
> I press `M-x list-packages' using an Emacs with svg.el version 1.0.
> Version 1.1 is available from GNU ELPA. But it doesn't propose to
> update it.
>
> I'm not sure where that leaves us...
It leaves us with a job that someone should do, so that we could
bundle ELPA packages with Emacs releases.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 15:10:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I'm not sure where that leaves us...
>
> It leaves us with a job that someone should do, so that we could
> bundle ELPA packages with Emacs releases.
Right. Sorry to not be more clear, but what I mean more specifically is
that I don't understand what needs doing here.
I suppose `M-x list-packages U' should consider also built-in packages.
Anything else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 15:33:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 39553 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 8 Sep 2020 15:09:35 +0000
> Cc: larsi <at> gnus.org, 39553 <at> debbugs.gnu.org, nick <at> nicksavage.ca
>
> Right. Sorry to not be more clear, but what I mean more specifically is
> that I don't understand what needs doing here.
>
> I suppose `M-x list-packages U' should consider also built-in packages.
>
> Anything else?
Doesn't package.el maintain some information about packages being
installed? If so, how and where do you maintain that information for
packages that come from the tarball?
IOW, packages installed by package.el go to a special directory and
are handled specially by the startup code, something that is not true
for a built-in package. This needs rectifying in some way. I don't
know enough about package.el to give more specific and detailed
advice, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Doesn't package.el maintain some information about packages being
> installed?
AFAIK, it just uses whatever is in your `package-directory-list'.
> If so, how and where do you maintain that information for packages
> that come from the tarball?
Good question, I'd need to look into the details.
> IOW, packages installed by package.el go to a special directory and
> are handled specially by the startup code, something that is not true
> for a built-in package. This needs rectifying in some way. I don't
> know enough about package.el to give more specific and detailed
> advice, sorry.
I thought this was okay, since this is initialized in the early init
file? But I might be overlooking something.
Maybe we should ask on emacs-devel what the hurdles are, because there
seems to be some possibly subtle problems here that I don't fully
understand. It would be good to get this to work, if possible...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Tue, 08 Sep 2020 17:59:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Maybe we should ask on emacs-devel what the hurdles are, because there
> seems to be some possibly subtle problems here that I don't fully
> understand. It would be good to get this to work, if possible...
Yes, please.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 07 Oct 2020 11:24:05 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Fri, 13 Nov 2020 21:40:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Fri, 13 Nov 2020 21:43:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 39553 <at> debbugs.gnu.org (full text, mbox):
[Forwarding this from Tom Tromey, as his original email to
39553 <at> debbugs.gnu.org bounced due to the fact that Bug#39553 was
archived at the time. I have unarchived the bug.]
-------- Forwarded Message --------
Subject: Re: bug#39553: 28.0.50; ada mode was removed
Date: Fri, 13 Nov 2020 11:34:30 -0700
From: Tom Tromey <tom <at> tromey.com>
To: Stefan Kangas <stefan <at> marxist.se>
CC: Paul Eggert <eggert <at> cs.ucla.edu>, Stephen Leake
<stephen_leake <at> stephe-leake.org>, 39553 <at> debbugs.gnu.org, Tom Tromey
<tom <at> tromey.com>
>> Stephen, you made the commit in question. Could you please take a look at
>> Bug#39553 <https://debbugs.gnu.org/39553>? Thanks.
Stefan> 6 months later. Ping!
I'd like to point out that the replacement does not actually work.
I installed it and it asks me to run a build script:
File mode specification error: (error ada_mode_wisi_lr1_parse not found
on ‘exec-path’; run ’build.sh’ in the ELPA package.)
This seems like a step backward compared to the old mode, but ok.
However:
murgatroyd. pwd
/home/tromey/.emacs.d/elpa/ada-mode-7.1.4
murgatroyd. sh build.sh directories.gpr:27:04: no value defined
for "hardware_platform"
directories.gpr:27:41: undefined external reference "HARDWARE_PLATFORM"
gprclean: "ada_mode_wisi_parse.gpr" processing failed
directories.gpr:27:04: no value defined for "hardware_platform"
directories.gpr:27:41: undefined external reference "HARDWARE_PLATFORM"
gprbuild: "ada_mode_wisi_parse.gpr" processing failed
That is, compilation fails.
I think I'll try to make my own package from the old sources.
I'd like to ask, though, that the old package just be restored.
I don't see any benefit to the current setup, only negatives.
thanks,
Tom
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#39553
; Package
emacs
.
(Sat, 14 Nov 2020 11:28:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 39553 <at> debbugs.gnu.org (full text, mbox):
Tom Tromey <tom <at> tromey.com> writes:
>>> Stephen, you made the commit in question. Could you please take a look at
>>> Bug#39553 <https://debbugs.gnu.org/39553>? Thanks.
>
> Stefan> 6 months later. Ping!
I'm sorry, but I never got the first emails about this bug. There seems
to be an issue with sending email from the bug server to my mail server.
It's possible a spam filter ate them.
> I'd like to point out that the replacement does not actually work.
>
> I installed it and it asks me to run a build script:
>
> File mode specification error: (error ada_mode_wisi_lr1_parse not
> found on ‘exec-path’; run ’build.sh’ in the ELPA package.)
> This seems like a step backward compared to the old mode, but ok.
Since you are using ada-mode, the assumption is you are used to
compiling Ada code, so this should not be a burden.
> However:
>
> murgatroyd. pwd
> /home/tromey/.emacs.d/elpa/ada-mode-7.1.4
> murgatroyd. sh build.sh
> directories.gpr:27:04: no value defined for "hardware_platform"
> directories.gpr:27:41: undefined external reference "HARDWARE_PLATFORM"
> gprclean: "ada_mode_wisi_parse.gpr" processing failed
> directories.gpr:27:04: no value defined for "hardware_platform"
> directories.gpr:27:41: undefined external reference "HARDWARE_PLATFORM"
> gprbuild: "ada_mode_wisi_parse.gpr" processing failed
>
> That is, compilation fails.
This indicates a problem with your Ada compiler installation.
'directories.gpr' is not from ada-mode.
If you use the Community release of GNAT from
https://www.adacore.com/community, build.sh runs cleanly.
> I think I'll try to make my own package from the old sources.
They are all available at
https://download.savannah.nongnu.org/releases/ada-mode/, back to
ada-mode 5.1.9 in 2016.
> I'd like to ask, though, that the old package just be restored.
> I don't see any benefit to the current setup, only negatives.
Once you get the code compiled, there are many benefits to the latest
version; support for Ada 2012 (and 2020 in the next release), more
consistent indentation, integration with package.el.
I deleted the old ada-mode to force people to try the new one,
and also to avoid maintenance requests on the old code. I have no
objection to making the old code available in lisp/obsolete, so it is
clear it is no longer supported.
--
-- Stephe
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Dec 2020 12:24:05 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 10 Sep 2021 15:05:02 GMT)
Full text and
rfc822 format available.
Forcibly Merged 39553 50510.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 10 Sep 2021 15:05:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 09 Oct 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.