Re: [Ada-mode-users] Gnu Emacs Ada mode 6.0.1 released.

[Stephen Leake]

Simon Wright <address@hidden> writes:

> On 9 Dec 2018, at 16:55, Stephen Leake <address@hidden> wrote:
>>
>> Gnu Emacs Ada mode 6.0.1 is now available in GNU ELPA. This is a minor
>> packaging bug release; the file ada_lr1_parse_table.txt, which is 41MB
>> uncompressed, is now compressed (to 2.9MB), so it takes much less time
>> to download in 'list-packages'. In addition, copyright on all the Ada
>> code is now Free Software Foundation.
>>
>> If you are using this new ada-mode, please try the 'process' parser,
>> which provides syntax error correction.
>
>> When you've tried the process parser, let me know, in this forum.
>
> Looking good so far!
>
> I ran build.sh using FSF GCC 8.1.0, and copied the executables + the
> parse table to a directory that's always on my PATH, as discussed.
>
> For some of the executables, the .exe suffix is present, for some
> (gpr_query, ada_mode_gps_indent) not.

Ah. That's because ada_mode_wisi_parse.gpr has this:

   package Builder is
      --  We use ".exe" extension even on non-Windows, to simplify the 
makefiles.
      for Executable_Suffix use ".exe";
   end Builder;

while gpr_query.gpr, ada_mode_gps_indent.gpr do not. The makefile has
some hardcoded .exe, and some $(EXE_EXT). Sigh.

I'll fix it to use EXE_EXT more consistently.

> The customisation Ada Gps Indent Exec is set to
> ada_mode_gps_indent.exe, which isn't present on this macOS system (or
> on Linux systems).

Arg. The .exe is optionally added by locate-file, so it should not be
in the var.

> The red exclamation points in the left margin for syntax errors is
> good.

:).

There are also marks in the right margin, showing the relative location
in the entire buffer; they are not always updated correctly, and I'm not
sure they are useful.

> 2 points:
>
> When inserting a comment, the marker appears after the leading '-' &
> doesn't go away as the rest of the comment is typed (until DEL or
> RET).

Ah. There's a bug in the elisp code that triggers a reparse; after the
second '-', you are editing a comment, so it thinks no reparse is needed
:(.

> The marker appears for S : String(1..Length);. C-c C-f points to the
> 'L'. Marker disappears if a space is inserted after the '1'.

Hmm. The lexer thinks "1.." is a valid numeric literal, so then ".." is
missing.

(you can see what the lexer is doing by running:

~/.emacs.d/elpa/ada-mode-6.0.1/run_ada_lalr_parse.exe <file> Face --verbosity 4 
0 0

Note that the file is lexed twice; first just to find out how many lines
there are, which Emacs does for us normally.)

That's because the regexp for NUMERIC_LITERAL has this:

([0-9][0-9a-fA-F._-]*)

which allows trailing decimal points (and minus signs! - for floating
point exponents). This is correct (at least for this test case):

([0-9])|([0-9][0-9a-fA-F._-]*[0-9])

Note that this allows a lot of things that are not Ada numeric literals.
But it's faster than a strictly conforming regexp.

Hmm. It only needs E, not a-fA-F, since based literals are handled in
the next part of the regexp.

> I tried this on a large file (used to be a long pause after each
> character typed): HUGE improvement!

Excellent.

--
-- Stephe