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] |
"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