[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ECB for LaTeX?

From: Klaus Berndl
Subject: Re: ECB for LaTeX?
Date: 11 Jun 2003 10:03:49 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

On 10 Jun 2003, Stefan Monnier wrote:

> > Concerning displaying stuff like LaTeX etc (all file-types supported by
> > imenu and etags but not by semantic) you are ECB steals the
> > speedbar implementation because it works great and is well tested.
>  Ah, so it doesn't reinvent the wheel, I misunderstood.  Good.

Puhhh :-)

> > ECB could use either the speedbar code itself (but this brings
> > another dependence to speedbar internals i dislike) or re-implement the
> > few parts of the speedbar-code needed for this.
>  Why not cooperate with Eric to make those internals less internal ?

Yes, good idea... let us see what Eric means... for myself i would second this.

> > I have decided to go the latter approach because then ECB is independent
> > from speedbar internals and if these are changed....
>  yes... ?  if these are changed...what ?  You mean you'd rather not benefit
>  from the enhancements brought by those changes ?  I don't understand.

The other side... ECB can only display tokens in its method-buffer if the
tokens are semantic-token, i.h. they must offer the semantic-API to get the
informations to display. speedbar on the other side has well working and well
tested code to use imenu and etags to parse files. But then speedbar displays
these imenu and etags tokens in it's own proprietary display engine.

Conclusion: ECB uses the speedbar code for generating imenu- and etags tokens
but then ECB has to transform these tokens itself into the semantic-format.

Now if Eric changes the internal format of the tokens speedbar gets with imenu
and etags and if ECB uses this internal code then probably the
ECB-transformation-engine (transforming to semantic-format) will be broken.

Is this more understandable?

But maybe Eric could extract the imenu and etags code from speedbar, put on
top a well defined API and make it therefore less internal...then ECB can
completely be based on this code.


>          Stefan

Klaus Berndl                    mailto: address@hidden
sd&m AG               
software design & management    
Thomas-Dehler-Str. 27, 81737 M√ľnchen, Germany
Tel +49 89 63812-392, Fax -220

reply via email to

[Prev in Thread] Current Thread [Next in Thread]