From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Moringen Newsgroups: gmane.emacs.devel Subject: Re: eshell and after-change-functions Date: Wed, 21 Jul 2010 19:31:46 +0200 Message-ID: <8935_1279733507_ZZh043qfJa0Ve.00_1279733506.2433.14.camel@steed.robot-madness> References: <27611_1279665215_ZZh045m5ysdni.00_1279665214.3039.14.camel@steed.robot-madness> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7BIT X-Trace: dough.gmane.org 1279733620 26359 80.91.229.12 (21 Jul 2010 17:33:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Jul 2010 17:33:40 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 21 19:33:38 2010 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.69) (envelope-from ) id 1ObdAn-00051D-MV for ged-emacs-devel@m.gmane.org; Wed, 21 Jul 2010 19:33:38 +0200 Original-Received: from localhost ([127.0.0.1]:58001 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ObdAn-0002UZ-6u for ged-emacs-devel@m.gmane.org; Wed, 21 Jul 2010 13:33:37 -0400 Original-Received: from [140.186.70.92] (port=45067 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Obd97-0001Wy-Nn for emacs-devel@gnu.org; Wed, 21 Jul 2010 13:31:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Obd93-0000ui-Uc for emacs-devel@gnu.org; Wed, 21 Jul 2010 13:31:50 -0400 Original-Received: from mux1-unibi-smtp.hrz.uni-bielefeld.de ([129.70.204.65]:33978) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Obd93-0000uY-Pk; Wed, 21 Jul 2010 13:31:49 -0400 Original-Received: from pmxchannel-daemon.mux1-unibi-smtp.hrz.uni-bielefeld.de by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0L5X00K004OZA400@mux1-unibi-smtp.hrz.uni-bielefeld.de>; Wed, 21 Jul 2010 19:31:48 +0200 (CEST) Original-Received: from [129.70.165.66] ([129.70.165.66]) by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPPSA id <0L5X00AYQ4OZ4BC0@mux1-unibi-smtp.hrz.uni-bielefeld.de>; Wed, 21 Jul 2010 19:31:47 +0200 (CEST) In-reply-to: X-Mailer: Evolution 2.30.2 X-EnvFrom: jan.moringen@uni-bielefeld.de X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.7.21.172415, pmx8 X-Connecting-IP: 129.70.165.66 X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:127626 Archived-At: Hi Stefan. > > The feature in question is sharing interactive buffers like comint, > > slime and, well, eshell with other users. The problem is that Rudel > > relies on `after-change-functions' to monitor buffer changes and > > propagate them to peers, but eshell let-binds this variable to nil in > > `eshell-send-input' and `eshell-output-filter'. This prevents buffer > > changes performed in these functions from being propagated and > > de-synchronizes the session. I cannot find a specific reason for > > disabling all after-change functions in the ehsell code and was > > wondering if somebody knows why this is necessary. If it is not > > necessary, could this maybe be changed? > > Have you tried to remove the offending let-binding and see what effect > it has on Eshell's behavior? Removing the let-binding solves the problem for Rudel. A brief test did not reveal any problems with eshell either, but a more experienced developer should be the judge of that. > The commit logs don't give any help about the reason for these bindings, > and looking at the code I can't figure it out myself either, so unless > John remembers why they were added, we'll be forced to just "try and > pray". Thanks. This would be very hard or even impossible to work around by sensible means. Jan