This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: text buffers


"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:

> Greg Harvey <Greg.Harvey@thezone.net>  writes...

> >
> >Well, we don't have to mark a buffer of bytes. This is mostly a
> >question of how to represent the buffer (and whether to allow
> >non-uniform buffers, which sort of makes my brain hurt after the
> >adventure I had writing the logic for simple buffers ;). I can see
> >some ways to make it possible (at least for uniform objects), though
> >I'd like to have actual working text buffers before breaking them :)
> 
> 
> Fair enough.  As far as the implementation of non-uniform buffers is
> concerned, though, I'm not sure that it's only a problem of representation.
> When I was thinking about this, I couldn't work out how to move from Emacs'
> hole-based text buffers to non-uniform buffers without losing performance.

This is the real problem with non-uniform buffers. I don't think
non-uniform is ever all that useful, because it seems to always turn
up more problems than it solves, and makes everything either
inefficient or a hairy special case (some fun demonstrations are mule
and the <CR><LF> crap you get under dos). With uniform buffers, you
can still use the exact same underlying algorithms, just changing the
size of a thing it considers an element of the buffer, and the way
they're inserted (mostly for byte ordering issues).

> (Garbage collector segfault song???  I don't understand!)  

You'd have to see how many times I've dumped disk eating cores while
working on the garbage collector to really get it (ahh, now it should
work... ARGH!) ;).

> I'm not sure that
> would be a good approach to implementing a display buffer - think, assuming
> that the text buffer is not an object that can be extended by
> inheritance,

Actually, this is exactly the direction I want to take, after thinking
about the points you brought up. I've put up the really-alpha code for
the text buffers (basically, it only works as a c library; the glue
code still needs some work), but I've been thinking of just leaving
the c-library as is, and reimplementing buffers around Bernard Urban's
port of tiny clos (if I can get it to work without having to go the
whole stklos route, which I don't really need). This is much more
flexible than the implement in c route, since all of the operations
can be implemented as generic functions. Then a <text buffer> is a
buffer object which calls down to c functions (the buffer types I have
now do basically the same thing... most of the operations are written
in scheme, and they call a couple of workhorse routines written in c,
which just translate the scheme arguments to c arguments, and call the
functions to operate on the tbuf_t objects). The whole implementation
could even move directly to scheme (and after some of the joy of
trying to integrate the glue code, this is becoming very
attractive... the only thing (barely) preventing this is the ~1100
lines of c code I've already written for the buffers, but considering
the hassle it's going to be to get everything to build correctly, it'd
probably be faster to do it all from scheme... particularly to provide
support for a variety of types of buffers).

> of all the buffer-manipulation wrapper functions you'd need to copy basic
> text buffer functionality to the display buffer.  I think a better idea is
> to add hooks to the text buffer that are meaningful (and defined) in the
> text buffer's own terms but also happen to be what is needed to implement
> display.

Not necessarily. All you really need to do is create an display
object, where one element of it is a text buffer. It does it's own
insert, etc... functions, then calls down to the text buffer to do the
insertion with the actual buffer. Being built around an actual object
system would be much nicer, though. 
 
-- 
Greg