From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: process output has become a bit random... Date: Thu, 29 Jul 2004 22:05:19 +0900 (JST) Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <200407291305.WAA14106@etlken.m17n.org> References: <4108D78A.7090001@math.ku.dk> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1091106425 18258 80.91.224.253 (29 Jul 2004 13:07:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Jul 2004 13:07:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 29 15:06:53 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BqAcW-0000bk-00 for ; Thu, 29 Jul 2004 15:06:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BqAfi-0004C3-B2 for ged-emacs-devel@m.gmane.org; Thu, 29 Jul 2004 09:10:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BqAfU-0004Bq-61 for emacs-devel@gnu.org; Thu, 29 Jul 2004 09:09:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BqAfS-0004B9-Or for emacs-devel@gnu.org; Thu, 29 Jul 2004 09:09:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BqAfS-0004Az-Nl for emacs-devel@gnu.org; Thu, 29 Jul 2004 09:09:54 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BqAbB-0005mL-0r; Thu, 29 Jul 2004 09:05:29 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i6TD5KxK019498; Thu, 29 Jul 2004 22:05:20 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id i6TD5KU00400; Thu, 29 Jul 2004 22:05:20 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id WAA14106; Thu, 29 Jul 2004 22:05:19 +0900 (JST) Original-To: dak@gnu.org In-reply-to: (message from David Kastrup on 29 Jul 2004 14:49:33 +0200) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26099 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26099 In article , David Kastrup writes: [...] > Yes, that's it. Even though the very last line would appear to be a > preview-latex internal bug. If you take a look at the run buffer (C-c > C-l) and search for, say, "Snippet 8", you will find that some > passages around the matches are replicated. > It is probably some change in process.c or coding.c in the last month > or so. If you use gcc-3.3.4, at least it does not seem to be > gcc-3.4-related like I feared at first. The change below 2004-06-11 Kenichi Handa * coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT. is just this. Index: coding.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/coding.c,v retrieving revision 1.303 retrieving revision 1.304 diff -u -c -r1.303 -r1.304 cvs diff: conflicting specifications of output style *** coding.c 6 Jun 2004 23:59:19 -0000 1.303 --- coding.c 11 Jun 2004 05:56:44 -0000 1.304 *************** *** 6320,6325 **** --- 6320,6326 ---- produced += coding->produced; produced_char += coding->produced_char; if (result == CODING_FINISH_NORMAL + || result == CODING_FINISH_INTERRUPT || (result == CODING_FINISH_INSUFFICIENT_SRC && coding->consumed == 0)) break; Could you please try again while canceling this change? --- Ken'ichi HANDA handa@m17n.org