[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release plans

From: Thien-Thi Nguyen
Subject: Re: Release plans
Date: Sun, 31 Aug 2008 11:09:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() Thomas Lord <address@hidden>
() Sat, 30 Aug 2008 16:07:51 -0700

   So, the sub-process basically contains a text editor
   in this design, albeit one without redisplay code and
   with an unusual, limited command set.

I suppose that's a fitting description.

   That need for redundant code to make this thing work helps to
   prove that, indeed, the absence of dynamic loading (including
   just shared memory regions for buffers) creates make-work to
   work around it.

I don't follow your logic, perhaps because you include
shared-memory buffers in dynamic loading (which is not what i
described), to make your point.  But that's ok; maybe we are
talking about different designs.

   For interactive typing
   that can probably keep up on a modern machine but
   for other stuff it can easily be a performance bottleneck.
   (Still, even if it is not, it's doing it "the hard way".)

Perhaps difficulty lies also in the eye of the beholder.

   That seems exaggerated.  A hook in the interact loop that
   locked a shared mem buffer briefly while asking for updates
   from an incremental parser / ide-helper doesn't seem like it
   would be all that hard to get right.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]