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...
> 
> 
> >"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:
> >
> >> I've also been wondering about implementing buffers, and have a few more
> >> questions that I'd like to throw into the stream.
> >> 1. What is wrong with simply porting the existing buffer code in Emacs
> and
> >> giving it a SCM interface?
> >
> >Quite a bit ;) A lot of the code in emacs is mostly unnecesssary for
> >buffers that are, essentially, just places to put big chunks of data,
> >where you can move around easily and munge at will. Plus, there's that
> >whole mule/multibyte thing (bleah!).
> 
> Aha!  (I'm writing this email backwards, if that helps make sense of my
> comments.)  Do you mean that you are thinking of a buffer as a typeless
> byte-stream sort of thing, that is mostly written at its end and read
> starting from the beginning?

Not quite: basically, I'm thinking of it as a very convenient way to
munge a chunk of text (or bytes), which is usually much easier to do
using a buffer, rather than the typical line by line method of things
like perl or awk. To use an example, I wrote a little elisp program to
extract function&macro definitions from the qdocs I'd written. All it
had to do was find a line that contained the right tag (like
Function:), then do a forward-foo (where foo was a movement function
that would go to the end of the definition)... it didn't have to worry
about keeping track of newlines or any of that crud; it just moved
forward over what I wanted it to. Compared to using a typical text
groking language, this is a big win (the extraction function is only
10 lines long, and it's easy to insert new actions for different types;
I plan on rewritting it to use the guile buffers as soon as I have a
scheme interface written, and adding the ability to translate the
simple format of the qdocs into texinfo). 
 
> >> 2. Should Guile's buffers be designed to be more general than text
> buffers,
> >> i.e. to be buffers (ordered sequences) of arbitrary SCM objects?  (Think
> >> music, rich text, whatever... )
> >
> >It may be useful. Essentially, a buffer doesn't have a clue what's in
> >it, and it's up to the programmer to decide how to treat it, so having
> >buffers that can hold any arbitrary thing might be a bit of overkill.
> 
> I suppose I'm begging the question "when is a buffer not a buffer?"  How
> does a buffer differ from a list of objects?  Both have fast insert and
> delete operations - what else characterises a buffer?  This is probably
> obvious to you, but not yet clear to me.

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 :)

> >> 3. I assume that we want to also support overlays / intervals / "text"
> >> properties.  Correct?
> >
> >I don't think there's any real purpose. As far as I can see, those are
> >strictly for the display of the text, and since we aren't going to be
> >actually displaying the text, we don't care what it looks like.
> 
> Why do you say that we aren't going to be displaying the buffer?  It seems
> like this is something that someone will want to do very soon after a
> non-displaying buffer implementation becomes available.

Well, partly because I'm implementing buffers for my own selfish
reasons (and, I want to have a library usable from c, as well as
guile), and partly because I want the basic text/byte type buffers
finished yesterday ;). Some redesign will likely be necessary, but for
now, I really want something that can be used. Any lowlevel changes
shouldn't affect the scheme view of things, so I don't think it's too
limiting to concentrate on on a strictly text buffer, for now.

However, when using buffers for simple (or even complex) text munging
from scheme, it's wasteful to have all the trimmings, which would
never be used; a better approach is to write a display (or editor)
buffer, which uses a text buffer (or scm buffer, or note
buffer... btw, I'd really love a mod tracker in guile, so I could
finally get around to writing the garbage collector segfault song ;)
object for the contents, and implements all the display and editing
logic. It might require a little synchronization between the two (for
markers and such, you'll have to figure out how far text actually
moved at any given time), but has the benefit of leaving all the
display stuff up to someone who actually has a clue how to do it ;).

 
> I should explain a bit more where I'm coming from, which mainly concerns
> Emacs.  Two Emacs-related observations are that (i) Emacs includes a lot of
> functionality that is generally useful to other applications, e.g. buffers,
> input management, keymaps, window management; (ii) people are starting to
> write free software applications, such as gIDE, that include their own
> homegrown internal editors.  At the same time, two actual happenings: (i)
> the slow push to replace the Emacs Lisp engine with guile, and (ii) we are
> discussing the implementation of text buffers for guile.
> 
> So, maybe this is a bit too cathedral-ish, but it seems to me that the
> obviously desirable endpoint is an unbundled Emacs, where (i) different
> parts of Emacs' functionality, e.g. buffers, are implemented as guile
> modules, such that they are available both to Emacs and other applications;
> (ii) "Emacs" is actually guile + guile modules + small amount of application
> code needed to connect everything together; (iii) Emacs as a whole can be
> embedded within another application, and provides much more support for
> communication with controlling/peer external processes, perhaps through a
> generic guile IPC feature (so that the gIDE authors wouldn't need to write
> their own internal editor, they could use Emacs).
> 
> OK, reading this back it sounds laughably futuristic, but I hope that my
> point is clear.  That in an ideal GNU world, there would only be one
> implementation of text buffers.  It would be written in C/Guile, and both
> Emacs and other applications would use its services.

A lot of this is probably better achieved through corba or somesuch
(though I guess that's a little bit of heresy, given that guile is
supposed to natively translate all languages under the sun), but the
general idea is a very good one (though you could really get a lot of
people screaming bloat by imbedding emacs ;). However, I do think that
a text buffer has one job to do, and it should do it well. That it
could also be used by an editor object is just a big plus :)

-- 
Greg