Re: How to add pseudo vector types

[Stephen Leake]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> 39 milliseconds for re-indent is just slow enough to be noticeable; I still
>> have algorithms to convert to be as incremental as possible.
>
> [snip]
>
>> In a very small file:
>>
>> initial   0.000632 seconds
>> re-indent 0.000942 seconds
>>
>> Easily fast enough to keep up with the user.
>
> Doing work every time the user changes the file is not always a good
> thing. 

It very much depends on the user's preferences. Note that in standard
Emacs usage, font-lock runs after every character is typed.

With the current ada-mode release, which uses partial parse instead of
incremental parse, the parse process cannot keep up with user typing. So
I run with jit-lock-defer-time set to 1.5 seconds. However, many people
want the fontification to be much more responsive. With wisi
incremental parse, ada-mode can now do that.

Since I got incremental parse working in wisi, I've set
jit-lock-defer-time to the default nil; I like it, and will not go back.
I mostly tolerated the delay before because I knew how hard it would be
to fix :).

> Nowadays the user doesn't just expect automatic indentation, he wants
> code formatting too, which means splitting, fusing and inserting
> lines, plus moving chunks of code left and right. Doing that every
> time a character is added or deleted can be visually confusing due to
> chunks of text changing positions as you type, so the systems I know
> are triggered by certain events (like the insertion of characters that
> mark the end of statements). 

Yes; different parser-based operations are triggered by different
events. That is true for wisi now; font-lock is triggered by the
standard Emacs mechanisms (ie, after every character is typed, the
window is scrolled, etc), indent is triggered by the standard Emacs
mechanisms (indent-region-function, indent-line-function; ie RET and
TAB), navigate (computing single-file cross-reference) is triggered by
forward-sexp or some similar "wisi-goto-*" function, reformatting is
triggered by "align" (in parallel with the standard Emacs align
mechanism) or a direct wisi-reformat-* function (there are some in a
context menu for Ada). All of these operations update the parse tree
only if the buffer has changed; if not, they use the existing tree.

The user can always customize things - wisi provides the framework.

> Then they analyze the code and, if it is well formed, apply the
> reformatting. Something similar could be said about fontification and
> other tasks.

Wisi does indentation even in the presence of syntax errors (ie, not
"well formed"). This helps when writing code; when entering an "if"
statement, you don't have to start with a complete template; you just
type the code. It does sometimes cause confusing results; fixing the
syntax always resolves that.

> So I'll insist on not obsessing too much about performance. Implement
> something simple, see if it is usable. If not, invest effort on
> optimizations until it is good enough.

Yes; premature optimization is the enemy of good enough. And good
benchmarks/metrics should be the guide of any optimization; allowing
font-lock to run after every character is typed is one such metric.
Indentation in the presence of syntax errors is another; that was the
primary complaint about ada-mode before I implemented error correction,
and is still a common complaint; incremental parse will improve that.
These two metrics were the trigger that started me implementing
incremental parse.

-- 
-- Stephe