Ah, I see. A practical requirement for plain text streams is overridden by a
theoretical need of composing editors?
Feh.
On Wed, Mar 28, 2001 at 05:55:48PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > On Wed, Mar 28, 2001 at 06:20:52PM -0500, Greg Hudson wrote:
> > > > Euh... I still need Change #7 (from STACK) to enable sending files
> > > > up to the server.
> > >
> > > I don't understand. What do copy nodes have to do with enabling
> > > sending files up to the server?
> >
> > Sorry. #6
>
> Have you read the problem noted in that item? Here's the relevant bit
> from STACK:
>
> Editor composition becomes more difficult if we use streams. A
> window is a discrete chunk of data that can be used by several
> consumers, but streams are different: if consumer A reads some
> data off a stream, then when consumer B reads, she'll get
> different results. You'd have to design your streams in a funky
> way to make this not be a problem.
>
> In some circumstances, this isn't an issue. After all, usually
> a set of composed editors is a bunch of lightweight editors,
> that don't do much, surrounding a core editor that does the real
> work. For example, an editor that prints out filenames wrapped
> with an editor that actually updates those files. In such
> cases, the lightweight editor simply never reads data off the
> stream, so the core editor is not deprived of anything.
>
> But other editors (say, a commit guard?) might want to actually
> examine file data. That could have bad consequences if we
> switch from windows to streams.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:26 2006