On Thu, 22 Oct 1998, Asger Alstrup Nielsen wrote:
> I proposed such a generic interface for the buffer structure in January.
I proposed it two years ago, and I also have learned since then. I
remember that we had some discussion about it at the beginning of this
year. I might check the archive but maybe you have a renewed proposal
after all those that you have learned since then. ;)
> Maybe it's time to dig that out again? I designed that to hide the
> representation, and it was a pretty good solution, IMO. The main
> problem was that it didn't address the problem of rendering on the
> display, but I've learned a lot since then, and it should be possible to
> extend it to have that as well.
>From my point of view, the screen is just another client of the iterators
that browses the data structure to know what to draw and where to do it.
This is the way mathed works (see math_draw and math_cursor). I know the
code looks ugly but that was the design idea.
> This has to be reflected both in the file format, and in the internal
> representation. So there is no conflict. It's an invariant, and
> therefor there is no problem in designing the file format to be like
> this.
If that is the case, it could be accomplished with any (subset of) high
level document structure language like docbook or LaTeX. That's not the
point.
> The details of how every single construct should be is boring work that
> just has to be done. Once the overall structure is fixed (which Lgb is
> *doing* at the moment), we'll be well protected against changes in the
> internal representation, simply because the internal representation is
> implicitly given by the problem.
Sorry Asger, these are just words (IMO). What is that overall structure
you are talking about? Maybe we should move this discussion to lyx-backup
to avoid boring most people with excesive technicism.
> The problem dictates that we need to have a nested format. It's as simple
> as that.
What do you mean with nested format? Given that our output is LaTeX and
docbook, it's obvious they can hold a nested format, isn't it?
> The details about how the reader should use the information to build the
> document data structure is a different issue. Of course iterators are
> well suited for this, but this is not in conflict with the file format, as
> I see it.
Then why should it reflect the internal structure? This is not logic. I
feel you didn't read carefully my message (and of course surely I could
wrote it clearer).
To don't let things go farther to an improductive way (but go to the
interesting issue of the internal buffer structure), let me be clear in
this:
- I'm not insisting on change the file format right now. We discussed
that already.
- It's (of course) not my intention to get ride of valuable work done
in my absence.
- The internal buffer structure is very important, it should not be
fixed by hacks. Sorry to bore you, action guys, but we have to discuss
this deeply. I know you all have pretty good ideas, just let's be
more dialectic.
BTW thanks for the work on the painter inside mathed. You saved me a great
deal of work. :-)
Greets,
Alejandro
