Re: Dynamic loading progress

[Stephen Leake]

Eli Zaretskii <address@hidden> writes:

>> Date: Sat, 14 Feb 2015 18:02:22 +0200
>> From: Eli Zaretskii <address@hidden>
>> Cc: address@hidden
>> 
>> > From: Stephen Leake <address@hidden>
>> > Date: Sat, 14 Feb 2015 09:32:54 -0600
>> > 
>> > Emacs ada-mode does indentation in two steps; first it parses the source
>> > code, and the parser actions are lisp functions that eventually call
>> > put-text-property to store information about the syntax and/or semantics
>> > on many identifiers. Then the indentation code uses those text
>> > properties to compute indentation.
>> > 
>> > I have a generalized LALR parser implemented in elisp that is fast
>> > enough for many user's Ada files, but some users have much bigger files,
>> > and it takes them 10 seconds to parse. So I need a faster
>> > implementation. So far my benchmarking says I can get close with a
>> > machine compiled parser.
>> > 
>> > So the module would contain the generalized LALR parser; the actions of
>> > the parser would still be calls to the lisp functions.
>> 
>> But this means your mode is in Lisp to begin with, and it just calls
>> functions implemented in C to work faster.  So you could leave the
>> calls to put-text-property in Lisp, and have the functions implemented
>> in the module return the information required to compute the arguments
>> to put-text-property.  Or am I missing something?
>
> And btw, what exactly do you mean by "call Lisp" in this case?  Call
> put-text-property, which is implemented in C in its entirety, doesn't
> constitute a call to Lisp in my book.

The parser actions are higher level lisp functions; they do call
put-text-property, but there is significant logic in the lisp, and I'd
rather not re-implement that in the module, to simplify maintenance.
I'll have to maintain both the elisp and module implementations, for two
reasons:

- emacs 24 doesn't support modules

- some (many?) ada-mode users won't bother to compile the module (and I
  don't plan to distribute a binary).

> Of course, that means we will want to export Fput_text_property...

Right, that might be needed at some point. Right now I'll settle for
'funcall'.

-- 
-- Stephe