WAROQUIERS Philippe <[email protected]> writes: > About the performance: > The gnat parser is very fast : 0.05 seconds to parse the big file > referenced in my initial posting (in syntax mode only). > Not too much idea how to measure the gps parser speed, but it looks > not noticeable (so probably below 0.1 second).
Thanks for checking. It would help if you send me the big file, so I can do some profiling etc. I can sign a non-disclosure agreement if necessary. I'm not working for a company any more, if that was an issue. > So, I guess the performance problem might be solved by rewriting the > parser (or the performance bottleneck) in C (if needed to integrate it > in emacs) The only reason for using C would be political. Since GNAT can generate Ada headers from C headers, there's no problem using Ada to interface to the Emacs C library. Hmm, unless the C headers are so complicated the GNAT generator breaks. On the other hand, Emacs does not yet have a Foreign Function Interface, which is needed to load an object library at runtime. I don't want to put Ada mode back into Emacs core, so it must be a loadable library. There is some effort on that currently. > (probably re-using the gps parser is not do-able unless it is > isolated in a separate process 'gnatparse', like 'gnatfind' ?) The parser can't be in a separate process; the primary result of parsing is setting a slew of text properties in the current buffer, in the parser actions. Hmm. I suppose it would be possible to compute a list of text properties in a separate process, and return that to the Emacs process to be applied. In that case, I'd prefer to use the OpenToken parser, because that would also work for other source languages (gpr at least, maybe others in the future). > How is gnatbench (the eclipse based ide) doing the indentation ? Good question; I should go look. > About indentation while typing code: > I understand that a possible workaround is to change the editing > behaviour to use skeletons. It is however doubtful that all (or many?) > 'lambda' users will find that attractive. At least at Eurocontrol, there > was (including me) close to zero enthusiasm for that workaround. Ok, thanks for the feedback. > So, again as mentioned by Stephen, introducing (some) error recovery > in the parser might solve that. Again, maybe the solution used by gps > might be inspiring ? Yes, I have no idea how GPS solves this problem. > Note that for interactive edition, we do not need a very > intelligent/complete error recovery: IMO, what is needed is correct > indentation of the line you are have just typed, based on the > assumption that all preceding lines are syntactically correct (up to > the cursor). That's easy to say, but not easy to do. The indentation rules rely on semantic information, which is only available after a complete parse. > 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. However, it may be possible to not throw away _all_ of the parser output on the first edit. I'm experimenting with that for speed reasons (more below), but so far I've not tried to use that for indenting while editing. Another possibility is to have a more intelligent set of rules that work in the absence of a full parse; currently there is only one trivial rule used in that case (which apparently people hate :). > (note that the above 2 blocking problems mean that nice > features of the new ada-mode are not looked at: users are all > almost directly abandoning the new ada-mode once the performance > and no indentation while typing problems are encountered). Ok. There was a major speedup in 5.1.5 (now available in ELPA), but gnatcoll-projects.adb is still noticeably slow (1.8 seconds for a full parse). I'm experimenting with caching the parser state. If I can preserve the parser state before and after each edit, then only the edited code is actually parsed, which will solve the "indent after edit" speed problem (which is _not_ the "indent while edit" problem, unfortunately). The first parse would still be slow; would that be a tolerable solution? I won't spend too much time on this, if it proves complicated. Better to work on an FFI for Emacs, and then the Ada mode parser in Ada. Or on a parser in a separate process, as a first step. > Philippe (still having some hope to use emacs in the future :) Is Ada mode 4.1 not a good workaround? It's not for me, because I'm using Ada 2012 features whenever I can. -- -- Stephe _______________________________________________ Emacs-ada-mode mailing list [email protected] http://host114.hostmonster.com/mailman/listinfo/emacs-ada-mode_stephe-leake.org
