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


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?

>> 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.

>> 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.

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.

>--
>Greg

    Neil