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] |
Klaus Schilling <Klaus.Schilling@home.ivm.de> writes: > G. Harvey-s text buffer module, which is announced in the preliminary project > list, lacks stuff like markers, text properties, undo, ... > Is it possible to add those on scheme levele.g. using some object system > , taking a <tbuf> class, and deriving <tbuf-with-mark> etc. from it? Actually, I'm mostly abandoning the code that's available now to wait for goops and reimplement it generically. That being said, it should be possible to add those bits (though not necessarily with the best performance) from scheme... regexp matching is probably the best example of something that should go through scheme to get a consistant interface with the rest of guile. The only use of the code there now is for programming text mungers, where text buffers can make life easier with multiline things (though nothing to really help with common patterns, like sexps, is in there yet, either). It really doesn't have editing buffers (or, in fact, buffers consisting of anything but char's) in mind. Essentially, what should be provided is a <buffer> class, which does nothing but handle all the movement functions, insertion and deletion; from there, you could derive <text-buffer>, <text-display-buffer>, <smob-buffer> etc... Then you could have something like (pseudo closish code) (define-method buffer-insert ((<text-undo-buffer> buf)) (save-undo-state buf) (call-next-method buf)) > Or would that annihilate on site all the performance advantage that tbuffers > give over large strings when it comes to frequent > insertion/deletion? It depends on how you do it. There isn't currently a way to get at the guts of things from scheme; gap positions being the main thing you'd really need to put something more complex together, though it wouldn't be hard to make that available with the code that's there. The essential problem to making the current code more flexible (at least from c) is that it would require hobbling together a makeshift object system, which is grossness incarnate. > Also, what are the main objections to implementing buffers as port objects? They probably could be done that way, though I haven't given it much thought. -- Greg