Gnu Emacs Ada mode 8.0.4 released

Gnu Emacs Ada mode 8.0.4 is now available in GNU ELPA.

All Ada mode executables can now be built with Alire
(; this greatly simplifies that process.

gpr-query and gpr-mode are split out into separate GNU ELPA packages.
You must install them separately (Emacs install-package doesn’t
support “recommended packages” like Debian does).

Ada mode can now be used with Eglot; this is controlled by new variables:

ada-diagnostics-backend - one of wisi, eglot, none

ada-face-backend - one of wisi, eglot, none

ada-indent-backend - one of wisi, eglot, none

ada-statement-backend - one of wisi, eglot, none

ada-xref-backend - one of gnat, gpr_query, eglot, none

The diagnostic, face, indent, and statement backends default to wisi
if the wisi parser is found in PATH, to eglot if the Ada LSP server is
found, and none otherwise. The xref backend defaults to gpr_query if
the gpr_query executable in PATH, to gnat otherwise.

ada-diagnostics-backend controls the source of compilation error
messages while editing.

ada-statement-backend controls statement motion; forward-sexp,
wisi-goto-statement-end, etc. ada-xref-backend controls
wisi-goto-spec/body and Emacs xref commands.

In addition, name completion is provided by eglot if any of the other
backends are using eglot; eglot completion is always better than wisi.

The current AdaCore language server (version 23) supports face but not
indent. The current version of eglot (1.10) does not support face. The
Language Server Protocol does not support statment motion. So for now,
eglot + ada_language_server only provides xref and completion.

The AdaCore language server ada_language_server is installed with
GNATStudio (which ada-mode will find by default), or can be built with
Alire. If you build it with Alire, either put it in PATH, or set

I have not tested ada-mode with lsp-mode. You can set ada-*-backend to
'other to expermiment with that, or tree-sitter, or some other
backend. tree-sitter will be fully supported in the next ada-mode

The required Ada code requires a manual compile step, after the normal
list-packages installation:

cd ~/.emacs.d/elpa/ada-mode-7.3beta*

If you have Alire installed, these scripts use it.


Hi Stephe,

thank you for your continuous effort to keep the Emacs ada-mode up to date and to improve it.

After upgrading the files from within Emacs and starting to build the support programs I get the following output:

❯ cd .emacs.d/elpa/ada-mode-8.0.4
❯ ./
alr is /home/re/.local/bin/alr
building ada-mode executables via Alire
warn:    New solution is incomplete.
warn:    +  emacs_wisi          4.2.0  (new)
warn:    +♼ gnat                12.2.1 (new,installed,gnat_native)
warn:    +  gnatcoll            22.0.0 (new,indirect)
warn:    +  libgpr              22.0.0 (new,indirect)
warn:    +↪ re2c                >=2.2  (new,external)
warn:    +  stephes_ada_library 3.7.2  (new)
warn:    +  wisitoken           4.1.0  (new)
warn:    +  xmlada              22.0.0 (new,indirect)
warn: Could not find a complete solution for emacs_ada_mode=8.0.3
Build will fail unless externals are made available, do you want to continue?
[Y] Yes  [N] No  (default is No) 

First there is a mismatch of ada-mode version 8.0.4 vs 8.0.3. Second, I don’t see in which way this is incomplete and what to do. Typing ‘y’ alire finally fails with

ⓘ Running pre_build actions for emacs_ada_mode=8.0.3...
/home/re/.emacs.d/elpa/ada-mode-8.0.4/emacs_ada_mode_8.0.3_ab552d7b/alire/cache/dependencies/wisitoken_4.1.0_f9cd282e/build/bin/wisitoken-bnf-generate.exe  --output_bnf ada_annex_p.wy
if [ -f ada_annex_p_*parse_table.txt ]; then mkdir -p bin; for file in ada_annex_p_*parse_table.txt; do mv $file bin; done fi
re2c --no-generation-date --debug-output --input custom -W -Werror --utf-8 -o ada_annex_p_re2c.c ada_annex_p.re2c
make: re2c: No such file or directory
make: *** [/home/re/.emacs.d/elpa/ada-mode-8.0.4/emacs_ada_mode_8.0.3_ab552d7b/alire/cache/dependencies/wisitoken_4.1.0_f9cd282e/build/wisitoken_alire_rules.make:28: ada_annex_p_re2c.c] Error 127
rm ada_annex_p.re2c
warn: A pre-build action failed, re-run with -vv -d for details
error: Compilation failed.
mv: cannot stat 'ada_annex_p_lr1_parse_table.txt': No such file or directory

So I search for a Debian Bullseye package or library called re2c but cannot find any. I only googled the source repository on Github. Am I supposed to build it from sources?


I only have Debian 11.4 here (in a VM); Synaptic shows re2c (an old version).
On Debian, Alire uses apt-get to install an external “crate” if dpkg doesn’t find it already installed.

Running under Alire on macOS, the build ends with

Build finished successfully in 1109.63 seconds.
mv: ada_annex_p_lr1_parse_table.txt: No such file or directory

because the file is already in the bin/ directory.

re2c exists in previous Debian versions (at least in Buster and Sid) but not in Bullseye.

I manually started alr get re2c which completed without errors. I then rerun ./ with the same message as above (“Could not find a complete solution… Build will fail …”). This time it succeeded.

Ada-mode is working now. I don’t know why building the tools failed in the first run and why it succeeded at the second round.

Fixed in 8.0.4.

More text because the forum has a rule about short posts. So I’ll just ramble on for a while …

Arg. This forum doesn’t have “reply in thread”! Which is why a “hint” just popped up saying “reply to several posts at once”. Sigh. Do we really have to re-invent usenet yet again?

The gitter forum does have “reply in thread”, so I prefer that if we have to use a web interface in the first place - my real preference is usenet via Emacs Gnus :).

1 Like

The ELPA package version is 8.0.4; the Alire crate is 8.0.3. The last digit indicates a ‘bug fix’ release; the bug that Simon noted was fixed in, which required a new ELPA version but not a new Alire version.

Rolf; it could be that the re2c version available on your system is too old; it would certainly help if the alr error message actually said that. What do you get from:

“apt search re2c” ?

If that fails, can you do “apt update” first, to update your package list?

Rolf: it’s not re2c; if you had an old version, alr gives an error message like:

warn: The following external dependencies are unavailable within Alire:
warn: re2c>=5.2
warn: They should be made available in the environment by the user.
warn: Generating possibly incomplete configuration because of missing dependencies

(I changed the Ada re2c version requirement locally to test this).

To search for apt on Debian, use “apt search re2c”.

Hmm; maybe apt failed to install re2c because you have an outdated Debian package database (this happens to me often on Debian testing). If so, you need to do “apt update” first.

You can try running alr with -v and/or -d to get more info on the failure. You’ll probably want to redirect output to a file; it can be very verbose.

Here is my output

❯ apt search re2c
Sorting... Done
Full Text Search... Done
re2c/stable,now 2.0.3-1 amd64 [installed]
lexer generator for C, C++ and Go

Obviously re2c exists and is installed. I’ll try to reproduce the problem and will move the discussion to the ada-mode-users mailing list.

Unfortunately, not working for me.

ⓘ Deploying re2c=3.0.0...
The system package 're2c' is about to be installed.
This action might require admin privileges and impact your system installation.
Do you want Alire to install this system package?
[Y] Yes  [N] No  [A] Always  (default is Yes) y
Seleccionando el paquete re2c previamente no seleccionado.
(Leyendo la base de datos ... 315284 ficheros o directorios instalados actualmente.)
Preparando para desempaquetar .../archives/re2c_3.0-1_amd64.deb ...
Desempaquetando re2c (3.0-1) ...
Configurando re2c (3.0-1) ...
   [archive]      libemacs_ada_mode.a
   [index]        libemacs_ada_mode.a
Build finished successfully in 747.62 seconds.

mv: cannot stat 'ada_annex_p_lr1_parse_table.txt': No such file or directory

If I find the file:

~/.emacs.d/elpa/ada-mode-8.0.4$ find . -name ada_annex_p_lr1_parse_table.txt

So maybe it doesn’t matter.

Then I run ./ without errors. But it doesn’t work when opening the first Ada file:

error in process filter: wisi-process-parse--filter: Ada parser process protocol version mismatch: elisp 7 4, process 5 3
error in process filter: Ada parser process protocol version mismatch: elisp 7 4, process 5 3
Error during redisplay: (jit-lock-function 1) signaled (error "wisi-process-parse timing out; increase ‘wisi-process-time-out’? (or bad syntax in process output)")
Error during redisplay: (jit-lock-function 501) signaled (error "parser process died")
Error during redisplay: (jit-lock-function 1001) signaled (error "parser process died")

I then noted that I have obsolete versions of wisi and ada-mode in ~/.emacs.d/elpa so I moved them away, but nothing changed.

My version of Emacs is:

GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)
of 2022-01-24, modified by Debian

There’s also releases page with ada_language_server binaries to download.

@stephe-ada-guru : I’m trying to build starting from the Git repository. The instruction in the build procedure contains:

gprbuild -p -j8 -P ada_mode_wisi_parse.gpr -aP $WISI_DIR "$@"

But this project file does not exists. In fact there is no .gpr at all in ada-mode Git sources. Any idea?

I think you’ll find there’s an which processes using gnatprep.

Hum… I may be blind but I see no file in wisi nor ada-mode Git repository on master.

I solved this problem after finding and deleting an old version of the wisi parser in /usr/bin. Now, Ada files can be opened, but if I try to load a GPR file using “Ada > Project files > Find and select project…” I get this error:

wisi-prj-make-xref: Symbol’s function definition is void: create-gpr_query-xref

If I customize the Ada Xref Backend to “gnat”, the project file loads without error, but source code navigation does not work, it always complaints:

’X’ not found in cross-reference files; recompile?

Recompiling says it is up-to-date.

After installing the gpr-query package from emacs, building and installing it by hand, it works. I had to install it by hand because it failed in this way:

~/.emacs.d/elpa/gpr-query-1.0.2$ ./
installing gpr-query executables to /home/mgr/.local/bin
alr is /home/mgr/bin/alr
cp: no se puede efectuar `stat' sobre 'emacs_gpr_query/bin/*': No existe el archivo o el directorio

Hope this could help someone experiencing the same errors.

@mgrojo : copies the executable to ~/.local/bin by default, so you need to put ~/.local/bin in PATH, before gnat. If you want it somewhere else, specify --prefix to, or just copy it.

@Orzech: Thanks, I’ll add that to the docs.

@mgrojo re gpr_query - did you run in gpr-query?

@Pascal_Obry which git repository - elpa ada-mode package or upstream org.emacs.ada-mode? In both cases, there’s a makefile.

Yes, I checked my history and can confirm it.

  463  cd ~/.emacs.d/elpa/gpr-query-1.0.2/
  464  ls
  465  ./ 
  466  ./

I repetead (without any cleaning) and the error shown seems to be the problem:

~/.emacs.d/elpa/gpr-query-1.0.2$ sh -x
+ type alr
alr is /home/mgr/bin/alr
+ echo building gpr_query via Alire; compiler:
building gpr_query via Alire; compiler:
+ alr toolchain
CRATE         VERSION       STATUS    NOTES                               
gprbuild      21.0.0-1      Available                                     
gprbuild      21.0.2        Default                                       
gprbuild      2021.0.0+0778 Available Provided by system package: gprbuild
gnat_native   10.3.0-1      Available                                     
gnat_native   11.2.2        Default                                       
gnat_native   12.2.1        Available                                     
gnat_external 10.4.0        Available Detected at /usr/bin/gnat           
+ alr get emacs_gpr_query~1.0.1
error: Cannot get a release inside another alr release, stopping.
+ cd emacs_gpr_query_config_devel.gpr emacs_gpr_query_config_release.gpr 15: cd: can't cd to emacs_gpr_query_config_devel.gpr
+ alr build --release
ⓘ Building emacs_gpr_query/emacs_gpr_query.gpr...
gnatcoll.gpr:254:07: warning: value "windows" is not used as label
gprbuild: "gpr_query" up to date
Build finished successfully in 5.50 seconds.

It cannot get the crate, cannot cd into it, but finally it is built directly in the current directory. Why downloading it, when the current directory already contains a buildable Alire environment?

My Alire version is 1.2.1, in case some behaviour has changed.