Re: [AUCTeX-devel] Re: [AUCTeX] Re: Toolbar-x development

[David Kastrup]

"Miguel V. S. Frasson" <address@hidden> writes:

>> On Fri, Jul 28 2006, Miguel V. S. Frasson wrote:
>>
>> > For a long while I have not talked too much here about what is going
>> > on with the toolbar tools.
>> >
>> > In my free time, I have been developing toolbar-x to improve
>> > performance.  After some ponderation, I realized that there were
>> > some wrong decisions in the implementation.  The code, although
>> > it works (far from optimally), is not easily understandable
>> > (difficulting maintainability).

This is quite important.  Next is how well it is documented.  After
all, toolbar-x is supposedly useful for more than just AUCTeX.  And of
course, important is how easy it is to understand how to use its
interfaces.

>> > About what is new:
>> >
>> > * Performance was my main concern, specially if there were many
>> > many buttons.  The symbols toolbar eventually could have hundreds
>> > of symbols (seldomly used most of them).  Before, all the tree of
>> > buttons was parsed, even if buttons never happened to be
>> > inserted. Now parsing is gradual and only on demand.  Only what
>> > is to be displayed is parsed. Before, a refresh forced buttons to
>> > be recomputed, even if this computation yield to objects that are
>> > `equal' (lisp function).  Now, everything that can be computed
>> > only once is computed just once and stored for faster redisplay.

One thing to note: when weighing performance over clearness of code,
the latter should always win except when there is a delivery deadline
after which no more development happens.  Unreadable code can no
longer be improved, it can only be replaced.

There is a saying "premature optimization is the root of all evil"
among programmers.

>> > * The algorithm is clearer.  I think that most guys here could
>> > understand it reading the comments and code.  Before some people
>> > complained that the code was too confusing, and it really
>> > was. The engines are completely separated due to improved
>> > clearness. Before we have the situation `function x calls
>> > function y and function y calls function x', mixing
>> > everything. This does not happen anymore.

Sounds like an improvement.

>> > * There is a single and important sintax change: the argument
>> > `meaning-alist' becomes `meaning-alists' which is a list of
>> > alists or variable bound to alists. This avoids the necessity of
>> > concatenation of alists (takes "long" and can introduce
>> > inconsistence, since both can have properties for the same
>> > symbol) like done before. I think that this change is for the
>> > best.

Why would concatening alists take long as compared to lookup?  It is
probably cleaner, as it does not necessitate copying (and thus memory
usage), but the speed is not likely to be problematic.

>> > * David asked me for the omega icon with a sumo fighter head, (I
>> > understood that it should be the TeX lion's head).  It is almost
>> > looking good. Eventually I will deliver it.

It will probably make more people play around with Omega than anything
else at this point of time.

I can't think of good visuals for source specials and interactive mode
right now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum