From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Sun, 31 Aug 2008 11:09:00 +0200 Message-ID: <877i9xpn4j.fsf@ambire.localdomain> References: <87ljytkwpk.fsf@rattlesnake.com> <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@emf.net> <87ej4atczj.fsf@gmail.com> <48B78A75.8080103@emf.net> <803akoyrqy.fsf@tiny.isode.net> <48B7F59B.5060705@gmail.com> <48B84CA8.7080908@emf.net> <87zlmvd1xl.fsf@ambire.localdomain> <87myiub7tm.fsf@ambire.localdomain> <48B9D2C7.4070103@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1220173949 1652 80.91.229.12 (31 Aug 2008 09:12:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 09:12:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 11:13:23 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZizq-0008QZ-Fr for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 11:13:22 +0200 Original-Received: from localhost ([127.0.0.1]:47643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZiyr-00066X-Hu for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 05:12:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZiym-00066S-HI for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:12:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZiyk-000669-NX for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:12:16 -0400 Original-Received: from [199.232.76.173] (port=44512 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZiyk-000666-KE for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:12:14 -0400 Original-Received: from [151.61.142.27] (port=49783 helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZiyk-00029M-1s for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:12:14 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1KZivd-0001ug-0F; Sun, 31 Aug 2008 11:09:01 +0200 In-Reply-To: <48B9D2C7.4070103@emf.net> (Thomas Lord's message of "Sat, 30 Aug 2008 16:07:51 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103303 Archived-At: () Thomas Lord () 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. OK. thi