WAROQUIERS Philippe <[email protected]> writes:
>> > I guess that the indentation of the last line typed only depends on
>> > what is before the cursor, not what is after.
>>
>> No, since it implies a full parse.
> I mean : "functionally, deciding on the indentation does not depend on
> the lines after the cursor". Of course, if indentation algorithm is
> based on a full parse result, it depends on the full unit. But with my
> very limited knowledge of indentation problem, I do not see a case
> where the indentation at the cursor position cannot be decided (always
> ? most of the time?) only by looking at what is before the cursor.
I tried that approach using SMIE, but it quickly became clear that a
full parse is needed.
It is true that the indentation algorithm only uses cached parse info
from at or before point, but generating those caches requires a full parse.
It occurred to me that if we can write a recursive descent Ada parser
that does not require backtracking, then that meets this requirement;
the parser can stop at point. I think the GPS parser is recursive
descent; I'll look into that.
>> The first parse would still be slow; would that be a tolerable
>> solution?
> Do not know.
> It depends when the parser will kick in, and how long the parsing will
> take.
Right.
To be specific, the following ada-mode functions require a parse (grep
the source for 'wisi-validate-cache'):
ada-wisi-context-clause C-c M-`
used by compiler error correction to add a 'use' clause
ada-wisi-goto-declaration-start C-c <
navigation to start of current declaration
ada-wisi-goto-declarative-region-start C-c M-`
used by compiler error correction to add a 'use type' clause
ada-wisi-in-paramlist-p ada-wisi-scan-paramlist C-c C-a
aligning parameter lists
ada-wisi-make-subprogram-body C-c C-b
alternative is skeletons, but they automatically indent
ada-wisi-which-function
for which-function-mode, changelogs
wisi-forward-statement-keyword C-c C-n
wisi-backward-statement-keyword C-c C-p
wisi-goto-statement-start
wisi-goto-statement-end C-c M-`
used by compiler error corrections
wisi-indent-statement
all indenting
font-lock also requires a parse for function return type declarations
So unless there is a 'return' keyword in the visible part of the buffer
(which would cause font-lock to trigger a parse), just opening a file
does not trigger a parse.
It's on my list to disable that part of font lock if a parse has not yet
been done.
> E.g. when navigating in sources, one can very quickly have a few files
> being loaded (e.g. when doing C-c C-d to go to spec, then body, then
> to other spec, etc).
C-c C-d does _not_ require a parse.
> Maybe a solution to performance and interactive indentation (and maybe
> have other nice things such as a much faster C-c C-r) is to interface
> to a gps "library" or "gps backend process". It might decrease the
> long term maintenance effort for Ada mode (by re-using code shared
> between gnatbench, gps and emacs adamode).
Yes, but that would be much less fun :). And it adds a different
maintenance problem; keeping up with the latest AdaCore releases, while
supporting older ones.
C-c C-r is ada-show-references; that does use a background process. By
default it uses 'gnat list'; other options are 'gnatinspect' from
gnatcoll, and 'gpr_query', which is a variant of gnatinspect that I
wrote, and handles some things that 'gnatinspect' does not.
Both gnatinspect and gpr_query are slow to start, since they read all
the .ali files and build a database. GPS puts that in the background;
currently Emacs ada-mode does not, but it could. The database is built
when the gpr project file is selected, and it is cached in some
situations, so this is not very burdensome. On the other hand, they
give much more cross reference info than gnat list. In particular, they
support other languages; C and C++ for example.
--
-- Stephe
_______________________________________________
Emacs-ada-mode mailing list
[email protected]
http://host114.hostmonster.com/mailman/listinfo/emacs-ada-mode_stephe-leake.org
