From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#5924: 23.1; accept-process-output switching current-buffer Date: Sun, 11 Apr 2010 12:30:48 -0400 Message-ID: References: <84mxxbknma.fsf@cs.bham.ac.uk> <19393.48894.735000.238546@gargle.gargle.HOWL> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271005158 16881 80.91.229.12 (11 Apr 2010 16:59:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 11 Apr 2010 16:59:18 +0000 (UTC) Cc: 5924@debbugs.gnu.org To: Uday S Reddy Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 11 18:59:09 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1O10V1-0006hk-TY for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Apr 2010 18:59:08 +0200 Original-Received: from localhost ([127.0.0.1]:36427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O10V1-0002Eb-HD for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Apr 2010 12:59:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O10Ul-00026D-0Z for bug-gnu-emacs@gnu.org; Sun, 11 Apr 2010 12:58:51 -0400 Original-Received: from [140.186.70.92] (port=49803 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O10Ui-00024g-R6 for bug-gnu-emacs@gnu.org; Sun, 11 Apr 2010 12:58:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O10Ug-0006NJ-NI for bug-gnu-emacs@gnu.org; Sun, 11 Apr 2010 12:58:48 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56323) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O10Ug-0006NF-LP for bug-gnu-emacs@gnu.org; Sun, 11 Apr 2010 12:58:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1O103p-0004jI-KV; Sun, 11 Apr 2010 12:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Apr 2010 16:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5924 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5924-submit@debbugs.gnu.org id=B5924.127100345818174 (code B ref 5924); Sun, 11 Apr 2010 16:31:01 +0000 Original-Received: (at 5924) by debbugs.gnu.org; 11 Apr 2010 16:30:58 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O103m-0004j5-Dz for submit@debbugs.gnu.org; Sun, 11 Apr 2010 12:30:58 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O103j-0004iz-Gr for 5924@debbugs.gnu.org; Sun, 11 Apr 2010 12:30:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+WwUtMCqWu/2dsb2JhbACbRXK2AoUMBItGgwI X-IronPort-AV: E=Sophos;i="4.52,185,1270440000"; d="scan'208";a="60626230" Original-Received: from 76-10-165-174.dsl.teksavvy.com (HELO pastel.home) ([76.10.165.174]) by ironport2-out.pppoe.ca with ESMTP; 11 Apr 2010 12:30:48 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4253E7F1B; Sun, 11 Apr 2010 12:30:48 -0400 (EDT) In-Reply-To: <19393.48894.735000.238546@gargle.gargle.HOWL> (Uday S. Reddy's message of "Sun, 11 Apr 2010 13:22:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 11 Apr 2010 12:31:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:36188 Archived-At: >> > Reading the elisp manual doesn't indicate anywhere that a call such as >> > (accept-process-output process) >> > should change the current-buffer. >> That depends on the code run during the wait. I.e. it depends on the >> code run by the process filters, sentinels, timers, ... > Yes, indeed! If there is code being run during accept-process-output > then the state can be changed by that code. But in the example that I > witnessed, there was *no code* being run. That's very odd: both the sentinel and the filter code are careful to preserve the current_buffer when there's no sentinel or no filter set. I've just installed a change in the Emacs Bzr trunk so that the current-buffer is preserved when running the Elisp code of process filters and sentinels. If you can try this code (or try the patch below) to see if it fixes your problem, it would be helpful. > In the second "way" that is being talked about, we can reasonably > expect that current-buffer might change during the execution of the > filter function. But in the first "way", where Emacs is doing all the > work of accepting the process output, I don't think it should change > the current-buffer. Indeed and it shouldn't. And with my new changes, even when running Elisp it shouldn't change current-buffer either. > I don't fully understand this, but let me say that I am just talking > about problem with the Elisp semantics, not Emacs libraries. If a > filter function changed the current-buffer, one would regard it as > buggy. But if Elisp itself changes the current-buffer...? Given that it's code run asynchronously, letting it change current-buffer is asking for trouble. > The other thing that concerns me is that the same behaviour persisted > even if I set the JUST-THIS-ONE flag to t. In that case, one would > expect that Elisp would ignore the output from all other processes. Indeed, that's what it means. > So, it should have no reason to change the current-buffer to the other > process. But it did. I am not sure if the JUST-THIS-ONE flag is > doing anything at all. I don't know of a bug in this regard, so if you have evidence that JUST-THIS-ONE doesn't prevent reading other process's output, please report it. Stefan === modified file 'src/process.c' --- src/process.c 2010-04-02 03:10:33 +0000 +++ src/process.c 2010-04-11 16:15:09 +0000 @@ -5314,6 +5314,8 @@ struct coding_system *coding = proc_decode_coding_system[channel]; int carryover = p->decoding_carryover; int readmax = 4096; + int count = SPECPDL_INDEX (); + Lisp_Object odeactivate; chars = (char *) alloca (carryover + readmax); if (carryover) @@ -5386,15 +5388,16 @@ /* Now set NBYTES how many bytes we must decode. */ nbytes += carryover; + odeactivate = Vdeactivate_mark; + /* There's no good reason to let process filters change the current + buffer, and many callers of accept-process-output, sit-for, and + friends don't expect current-buffer to be changed from under them. */ + record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); + /* Read and dispose of the process output. */ outstream = p->filter; if (!NILP (outstream)) { - /* We inhibit quit here instead of just catching it so that - hitting ^G when a filter happens to be running won't screw - it up. */ - int count = SPECPDL_INDEX (); - Lisp_Object odeactivate; Lisp_Object obuffer, okeymap; Lisp_Object text; int outer_running_asynch_code = running_asynch_code; @@ -5402,10 +5405,12 @@ /* No need to gcpro these, because all we do with them later is test them for EQness, and none of them should be a string. */ - odeactivate = Vdeactivate_mark; XSETBUFFER (obuffer, current_buffer); okeymap = current_buffer->keymap; + /* We inhibit quit here instead of just catching it so that + hitting ^G when a filter happens to be running won't screw + it up. */ specbind (Qinhibit_quit, Qt); specbind (Qlast_nonmenu_event, Qt); @@ -5474,9 +5479,6 @@ restore_search_regs (); running_asynch_code = outer_running_asynch_code; - /* Handling the process output should not deactivate the mark. */ - Vdeactivate_mark = odeactivate; - /* Restore waiting_for_user_input_p as it was when we were called, in case the filter clobbered it. */ waiting_for_user_input_p = waiting; @@ -5492,27 +5494,19 @@ cause trouble (for example it would make sit_for return). */ if (waiting_for_user_input_p == -1) record_asynch_buffer_change (); - - unbind_to (count, Qnil); - return nbytes; } /* If no filter, write into buffer if it isn't dead. */ - if (!NILP (p->buffer) && !NILP (XBUFFER (p->buffer)->name)) + else if (!NILP (p->buffer) && !NILP (XBUFFER (p->buffer)->name)) { Lisp_Object old_read_only; int old_begv, old_zv; int old_begv_byte, old_zv_byte; - Lisp_Object odeactivate; int before, before_byte; int opoint_byte; Lisp_Object text; struct buffer *b; - int count = SPECPDL_INDEX (); - odeactivate = Vdeactivate_mark; - - record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); Fset_buffer (p->buffer); opoint = PT; opoint_byte = PT_BYTE; @@ -5610,13 +5604,14 @@ if (old_begv != BEGV || old_zv != ZV) Fnarrow_to_region (make_number (old_begv), make_number (old_zv)); - /* Handling the process output should not deactivate the mark. */ - Vdeactivate_mark = odeactivate; current_buffer->read_only = old_read_only; SET_PT_BOTH (opoint, opoint_byte); - unbind_to (count, Qnil); } + /* Handling the process output should not deactivate the mark. */ + Vdeactivate_mark = odeactivate; + + unbind_to (count, Qnil); return nbytes; } @@ -6845,6 +6840,11 @@ XSETBUFFER (obuffer, current_buffer); okeymap = current_buffer->keymap; + /* There's no good reason to let sentinels change the current + buffer, and many callers of accept-process-output, sit-for, and + friends don't expect current-buffer to be changed from under them. */ + record_unwind_protect (Fset_buffer, Fcurrent_buffer ()); + sentinel = p->sentinel; if (NILP (sentinel)) return;