From erich@cozi.com Mon Feb 16 16:20:39 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Feb 2009 00:20:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1H0KWs3005362 for ; Mon, 16 Feb 2009 16:20:33 -0800 Received: from mx10.gnu.org ([199.232.76.166]:37119) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LZDfP-0007ZA-6u for emacs-pretest-bug@gnu.org; Mon, 16 Feb 2009 19:18:27 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LZDhN-0008Kx-KO for emacs-pretest-bug@gnu.org; Mon, 16 Feb 2009 19:20:31 -0500 Received: from mail.cozi.com ([64.94.137.135]:44929) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZDhN-0008KX-6V for emacs-pretest-bug@gnu.org; Mon, 16 Feb 2009 19:20:29 -0500 Received: from ubuntu-erich.corp.cozi.com ([10.98.76.131]) by mail.cozi.com (StrongMail Enterprise 4.0.1.1(4.0.1.38126)); Mon, 16 Feb 2009 15:34:13 -0800 X-VirtualServerGroup: Default X-Destination-ID: emacs-pretest-bug@gnu.org X-MailingID: 00000::00000::00000::00000::::7031 X-SMHeaderMap: mid="X-MailingID" X-SMFBL: ZW1hY3MtcHJldGVzdC1idWdAZ251Lm9yZw== X-Mailer: StrongMail Enterprise 4.0.1.1(4.0.1.38126) DomainKey-Signature: a=rsa-sha1; c=nofws; s=sm; d=cozi.com; q=dns; b=5KK370at9IbjQwKzeSxvTiTkv7+h+2TnPiIspiTW5b7vegs/UJmqar9l+fM5J6t7J2wQ/4EQFrvtsH0WAnf6/NT+fOteHS0VRYTlwom42XsmFJMrEbAw5Hx/R6uM9/P/N9kWIFll5/nXqMMyMLNvZJLiATy6+dwU++m+t2PTuaE= DKIM-Signature: a=rsa-sha1; c=simple; d=cozi.com; s=sm; i=@cozi.com; h=Received:From:To:Subject:Date:Message-ID: User-Agent:MIME-Version:Content-Type; b=di8rYZMalkybjPMdGuCZDjrXZ ltlMEs/4W2c4O/zAPzVz5Ux+r1b4JBOcq4j5FndOCeY0j1erYk/8AIazM4j2ziFq Rb2hfm+7Mm8+BG4HmIdBlN6B1xZiZBVPAUcKwH8Zw8YxdF917qv/AnxgqysV5rH2 iTUfQgfjzuuoqMzsXQ= Received: from erich by ubuntu-erich.corp.cozi.com with local (Exim 4.69) (envelope-from ) id 1LZDhJ-000101-7u for emacs-pretest-bug@gnu.org; Mon, 16 Feb 2009 16:20:25 -0800 From: Eric Hanchrow To: emacs-pretest-bug@gnu.org Subject: 23.0.90; compilation-mode inserts output in the wrong location Date: Mon, 16 Feb 2009 16:20:25 -0800 Message-ID: <86ab8l3ody.fsf@ubuntu-erich.corp.cozi.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I started a long-running "compilation" that simply emmitted the time every two seconds: M-x compile RET C-a C-k while sleep 2; do date; done RET I then narrowed the *compilation* buffer to the first few lines: C-@ C-u C-n C-u C-n C-x n n I then sat and watched as the current date got inserted at the end of my narrowed region. I'd expected it to be inserted instead at the end of the buffer, even though that happened to be invisible. This is arguably not a bug, but the behavior I'd expected is indeed useful: sometimes when a compilation is running, I want to study just part of the output, and it's convenient to narrow to just the part I want. With the current behavior, though, in order to avoid getting the *compilation* buffer's lines all mixed up, I must copy the interesting region to another buffer. In GNU Emacs 23.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2009-02-04 on ubuntu-erich Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Compilation Minor modes in effect: erc-ring-mode: t erc-pcomplete-mode: t erc-netsplit-mode: t erc-button-mode: t erc-fill-mode: t erc-stamp-mode: t erc-autojoin-mode: t erc-track-mode: t erc-match-mode: t erc-services-mode: t erc-networks-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-readonly-mode: t desktop-save-mode: t display-time-mode: t global-auto-revert-mode: t diff-auto-refine-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-e RET ESC p C-b C-b C-b C-b C-b \ n C-f C-f \ n C-e RET C-u C-p C-@ ESC C-n ESC w C-x o C-n ESC m ESC C-o C-y , C-p C-a C-k C-x C-o C-x C-s C-p ESC m ESC . C-n C-n C-n ESC C-f ESC f ESC . C-x o ESC > q ( ) . RET C-x k RET ESC x m a k e RET y e s RET C-x o C-u C-@ C-x 0 ESC > C-x [ ESC > C-h v C-x [ C-g C-h v C-x [ C-g C-g C-h c C-x [ C-x [ C-x ] C-u C-x $ C-x [ C-x $ C-x [ C-x ] C-n ESC 0 C-l C-x ] C-p C-x n p ESC < C-x 2 C-x o C-v C-u C-x $ C-x 0 C-s n o t SPC t C-n C-a C-p C-x $ C-u C-x $ C-n C-n C-n C-n C-n C-n C-n C-n C-s k i C-w C-r C-r C-r C-s C-s C-s C-s C-s C-s C-s C-s C-s C-a C-u C-@ C-x n p ESC < C-v C-x n w C-x n p C-x n w C-c C-k ESC > C-c C-k ESC x w o m a n RET y e s RET q ESC x c o m p i l e RET C-a C-k w h i l e SPC s l e e p SPC 2 ; SPC d o SPC e c h o SPC ESC DEL d a t e ; SPC d o n e RET C-@ C-u C-n C-u C-n C-p C-x n n C-x n w ESC > C-g C-c C-k ESC x r e p o r t - TAB m e TAB DEL DEL e m TAB RET Recent messages: Mark saved where search started Mark set [2 times] Compilation interrupt uncompressing yes.1.gz...done WoMan formatting buffer...done in 0 seconds (No files need saving) Mark activated Quit Compilation interrupt Making completion list... From monnier@IRO.UMontreal.CA Tue Feb 17 08:43:03 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 17 Feb 2009 16:43:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1HGh0MB022988 for ; Tue, 17 Feb 2009 08:43:01 -0800 Received: from mx10.gnu.org ([199.232.76.166]:51003) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LZT09-0006GR-ON for emacs-pretest-bug@gnu.org; Tue, 17 Feb 2009 11:40:53 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LZT28-0002Mk-1S for emacs-pretest-bug@gnu.org; Tue, 17 Feb 2009 11:42:58 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:43927) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZT27-0002MP-NZ for emacs-pretest-bug@gnu.org; Tue, 17 Feb 2009 11:42:55 -0500 Received: from alfajor.home (vpn-132-204-232-203.acd.umontreal.ca [132.204.232.203]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n1HGgf1i007249; Tue, 17 Feb 2009 11:42:42 -0500 Received: by alfajor.home (Postfix, from userid 20848) id C3327A225A; Tue, 17 Feb 2009 11:42:41 -0500 (EST) From: Stefan Monnier To: Eric Hanchrow Cc: 2350@debbugs.gnu.org, emacs-pretest-bug@gnu.org Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Message-ID: References: <86ab8l3ody.fsf@ubuntu-erich.corp.cozi.com> Date: Tue, 17 Feb 2009 11:42:41 -0500 In-Reply-To: <86ab8l3ody.fsf@ubuntu-erich.corp.cozi.com> (Eric Hanchrow's message of "Mon, 16 Feb 2009 16:20:25 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3212=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-CrossAssassin-Score: 2 > This is arguably not a bug, but the behavior I'd expected is indeed > useful: sometimes when a compilation is running, I want to study just > part of the output, and it's convenient to narrow to just the part I > want. With the current behavior, though, in order to avoid getting the > *compilation* buffer's lines all mixed up, I must copy the interesting > region to another buffer. This is a fundamental problem in `narrow': its meaning is ambiguous. Sometimes it is used to pretend that the buffer is really smaller than it is, and other times it's used just to "focus" on a subpart. The implementation (i.e. most of the C and Elisp code) tend to take the first point of view, but sometimes users intend the other. Maybe a good way to provide what the user wants is to introduce a notion of window-local narrowing, or a visual-narrowing. Stefan From rms@gnu.org Wed Feb 18 04:12:05 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 18 Feb 2009 12:12:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1ICBuot008358; Wed, 18 Feb 2009 04:11:57 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LZlFM-0000lT-Dg; Wed, 18 Feb 2009 07:09:48 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Stefan Monnier , 2350@debbugs.gnu.org CC: erich@cozi.com, 2350@debbugs.gnu.org, emacs-pretest-bug@gnu.org In-reply-to: (message from Stefan Monnier on Tue, 17 Feb 2009 11:42:41 -0500) Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Reply-to: rms@gnu.org References: Message-Id: Date: Wed, 18 Feb 2009 07:09:48 -0500 This is a fundamental problem in `narrow': its meaning is ambiguous. Sometimes it is used to pretend that the buffer is really smaller than it is, and other times it's used just to "focus" on a subpart. The implementation (i.e. most of the C and Elisp code) tend to take the first point of view, but sometimes users intend the other. While that is true, as a general statement, it is clear what we should do to fix this problem: Compilation mode should widen temporarily and insert at the end of the whole buffer. Rather than using save-restriction, it should preserve point-max as a count from the beginning (the value of (point-max) itself). From monnier@iro.umontreal.ca Wed Feb 18 06:26:05 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 18 Feb 2009 14:26:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1IEQ284018522 for ; Wed, 18 Feb 2009 06:26:04 -0800 Received: from mail.gnu.org ([199.232.76.166]:35333 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LZnL9-0002xM-Nl for emacs-pretest-bug@gnu.org; Wed, 18 Feb 2009 09:23:55 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LZnNB-0000kQ-0U for emacs-pretest-bug@gnu.org; Wed, 18 Feb 2009 09:26:02 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:25133) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZnNA-0000kC-GX; Wed, 18 Feb 2009 09:26:00 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAAupm0lMCpTK/2dsb2JhbACBbtJShBMGgzw X-IronPort-AV: E=Sophos;i="4.38,229,1233550800"; d="scan'208";a="34028554" Received: from 76-10-148-202.dsl.teksavvy.com (HELO pastel.home) ([76.10.148.202]) by ironport2-out.teksavvy.com with ESMTP; 18 Feb 2009 09:25:59 -0500 Received: by pastel.home (Postfix, from userid 20848) id 7E7E08442; Wed, 18 Feb 2009 09:25:59 -0500 (EST) From: Stefan Monnier To: rms@gnu.org Cc: 2350@debbugs.gnu.org, erich@cozi.com, emacs-pretest-bug@gnu.org Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Message-ID: References: Date: Wed, 18 Feb 2009 09:25:59 -0500 In-Reply-To: (Richard M. Stallman's message of "Wed, 18 Feb 2009 07:09:48 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > This is a fundamental problem in `narrow': its meaning is ambiguous. > Sometimes it is used to pretend that the buffer is really smaller than > it is, and other times it's used just to "focus" on a subpart. > The implementation (i.e. most of the C and Elisp code) tend to take the > first point of view, but sometimes users intend the other. > While that is true, as a general statement, it is clear what we should > do to fix this problem: Compilation mode should widen temporarily and > insert at the end of the whole buffer. But what isn't clear is whether it's always the right thing to do: it's clear in this particular use of narrow, but there might be other uses of narrow in conjunction with compilation buffers where it would be the wrong thing to do. Stefan From rms@gnu.org Wed Feb 18 15:07:48 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 18 Feb 2009 23:07:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1IN7dwp024193; Wed, 18 Feb 2009 15:07:41 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LZvTv-0005tO-TA; Wed, 18 Feb 2009 18:05:31 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Stefan Monnier CC: 2350@debbugs.gnu.org, erich@cozi.com, emacs-pretest-bug@gnu.org In-reply-to: (message from Stefan Monnier on Wed, 18 Feb 2009 09:25:59 -0500) Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Reply-to: rms@gnu.org References: Message-Id: Date: Wed, 18 Feb 2009 18:05:31 -0500 But what isn't clear is whether it's always the right thing to do: it's clear in this particular use of narrow, but there might be other uses of narrow in conjunction with compilation buffers where it would be the wrong thing to do. While I cannot prove a priori that is impossible, I doubt it will happen. Where as this case -- user narrowing to exclude some of the buffer from view -- is clearly going to happen (and not just in this one case). So let's make it do the right thing for this kind of narrowing. If it isn't perfect, it is at least better. Unless and until we come across a real case From rms@gnu.org Wed Feb 18 15:07:49 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 18 Feb 2009 23:07:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1IN7efl024196; Wed, 18 Feb 2009 15:07:41 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LZvTw-0005tW-TE; Wed, 18 Feb 2009 18:05:32 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Stefan Monnier CC: 2350@debbugs.gnu.org, erich@cozi.com, emacs-pretest-bug@gnu.org In-reply-to: (message from Stefan Monnier on Wed, 18 Feb 2009 09:25:59 -0500) Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Reply-to: rms@gnu.org References: Message-Id: Date: Wed, 18 Feb 2009 18:05:32 -0500 But what isn't clear is whether it's always the right thing to do: it's clear in this particular use of narrow, but there might be other uses of narrow in conjunction with compilation buffers where it would be the wrong thing to do. I looked at the code, and I think it is clear what to do: make sure that narrowing does not prevent insertion at the specified insertion point. Does this change make it work? *** compile.el.~1.486.~ 2009-02-17 13:06:13.000000000 -0500 --- compile.el 2009-02-18 12:23:10.000000000 -0500 *************** *** 1733,1741 **** (with-current-buffer (process-buffer proc) (let ((inhibit-read-only t) ;; `save-excursion' doesn't use the right insertion-type for us. ! (pos (copy-marker (point) t))) (unwind-protect (progn (goto-char (process-mark proc)) ;; We used to use `insert-before-markers', so that windows with ;; point at `process-mark' scroll along with the output, but we --- 1733,1747 ---- (with-current-buffer (process-buffer proc) (let ((inhibit-read-only t) ;; `save-excursion' doesn't use the right insertion-type for us. ! (pos (copy-marker (point) t)) ! (min (point-min-marker)) ! (max (point-max-marker))) (unwind-protect (progn + ;; If we are inserting at the end of the visible region, + ;; keep the inserted text visible. + (set-marker-insertion-type max t) + (widen) (goto-char (process-mark proc)) ;; We used to use `insert-before-markers', so that windows with ;; point at `process-mark' scroll along with the output, but we *************** *** 1745,1751 **** (comint-carriage-motion (process-mark proc) (point))) (set-marker (process-mark proc) (point)) (run-hooks 'compilation-filter-hook)) ! (goto-char pos)))))) ;;; test if a buffer is a compilation buffer, assuming we're in the buffer (defsubst compilation-buffer-internal-p () --- 1751,1760 ---- (comint-carriage-motion (process-mark proc) (point))) (set-marker (process-mark proc) (point)) (run-hooks 'compilation-filter-hook)) ! (goto-char pos) ! (narrow-to-region min max) ! (set-marker min nil) ! (set-marker max nil)))))) ;;; test if a buffer is a compilation buffer, assuming we're in the buffer (defsubst compilation-buffer-internal-p () Unless and until we come across a real case From monnier@iro.umontreal.ca Wed Feb 18 15:52:23 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 18 Feb 2009 23:52:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=HAS_BUG_NUMBER,XIRONPORT autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1INqKvB004813 for ; Wed, 18 Feb 2009 15:52:22 -0800 Received: from mx10.gnu.org ([199.232.76.166]:60014) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LZwBA-0007T2-AR for emacs-pretest-bug@gnu.org; Wed, 18 Feb 2009 18:50:12 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LZwDC-0005LD-CQ for emacs-pretest-bug@gnu.org; Wed, 18 Feb 2009 18:52:19 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:59429) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZwDC-0005L9-4A; Wed, 18 Feb 2009 18:52:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAHctnElMCpTK/2dsb2JhbACBbtJ+hBMGgzw X-IronPort-AV: E=Sophos;i="4.38,231,1233550800"; d="scan'208";a="34060773" Received: from 76-10-148-202.dsl.teksavvy.com (HELO pastel.home) ([76.10.148.202]) by ironport2-out.teksavvy.com with ESMTP; 18 Feb 2009 18:52:17 -0500 Received: by pastel.home (Postfix, from userid 20848) id 556D98442; Wed, 18 Feb 2009 18:52:17 -0500 (EST) From: Stefan Monnier To: rms@gnu.org Cc: 2350@debbugs.gnu.org, erich@cozi.com, emacs-pretest-bug@gnu.org Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Message-ID: References: Date: Wed, 18 Feb 2009 18:52:17 -0500 In-Reply-To: (Richard M. Stallman's message of "Wed, 18 Feb 2009 18:05:31 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > So let's make it do the right thing for this kind of narrowing. > If it isn't perfect, it is at least better. I think this will discourage implementation of a good solution to this problem. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 11 17:31:13 2011 Received: (at control) by debbugs.gnu.org; 11 Sep 2011 21:31:13 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2rcO-0004Zt-Ml for submit@debbugs.gnu.org; Sun, 11 Sep 2011 17:31:13 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2rcN-0004Zn-RW for control@debbugs.gnu.org; Sun, 11 Sep 2011 17:31:12 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R2rY8-0001BC-Jk for control@debbugs.gnu.org; Sun, 11 Sep 2011 23:26:48 +0200 Date: Sun, 11 Sep 2011 23:23:47 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #2350 X-MailScanner-ID: 1R2rY8-0001BC-Jk X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316381208.71235@EpUAgzc491QmYMXgMSK2DA X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) tags 2350 patch From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 21 14:54:47 2016 Received: (at 2350) by debbugs.gnu.org; 21 Jan 2016 19:54:47 +0000 Received: from localhost ([127.0.0.1]:56697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMLJf-0005xA-Dz for submit@debbugs.gnu.org; Thu, 21 Jan 2016 14:54:47 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:34908) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMLJd-0005wj-IL for 2350@debbugs.gnu.org; Thu, 21 Jan 2016 14:54:45 -0500 Received: by mail-wm0-f53.google.com with SMTP id r129so186402809wmr.0 for <2350@debbugs.gnu.org>; Thu, 21 Jan 2016 11:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=OrGerkMGnXg0kPcpHib3HhJxbDzFx0vso151Rblj+CU=; b=Zq38KN5SnTgS9+Za191Da6pgXdrsdYPe2OgEKEdLF8HDGvkmlw8+6JgEZJPTYByMAr /0IdwLkel4OCOdgCFKAzeReJoGsGRsQ+Jl1Rb52am0yrRIRJeD2uGHv1fXVglX0ebr9L r+zeeJZh7HglxLNOkdIj3USA3PtCoH502KjkQPDfDleynAxpSqEGE+hmENj6nyA9yXEN 5c3GPFsFIMH2BfLuyn2NnrxhDa3ktGfAWQwSr0CMdSVxoKiwg+L0AFm0qAxZ1Zs4TebW LEspQiuuKSYmJFHSYnS//KYjWZ9Sops+NoCYYcH5u8r3asK3nLjlhFLB+D4v56i+hdvY +Qhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=OrGerkMGnXg0kPcpHib3HhJxbDzFx0vso151Rblj+CU=; b=d0IXOnsqg6ZeKjXlMtjUCUR1+qA7cElW9fErV8JUzemUSI0U6iR9X5AWTUJVdRbYfJ E+u8Lq6yQ4lKCaMRbs+REYbu74Z42fAt0/hP72jlolncI9/Znmo64o4Y47N5ZcBsSm9p QxdR+xVlB64ds/k2g7WFimyOxsKOZb54ZgjLsxsklY2IHxHTWJobTY6xDj6ukwcWLU2D IsruE35O3h8bA1Ll0tSNCE/yOLmSEVQvogPLh4QkKUK70FURVxGniwzBMDu5I26/JGUx B/CPoObeNyFte6w5r4td4oNzFyDs5hVkGn1JWV/AofRliE8XGpNBznh7wd+ZUGrc3TNn qkHA== X-Gm-Message-State: ALoCoQk8Heczt2hd9TlEGlGHvki2SAmYA43O2bqjl6KBP/Ht3ryCk2lk4JprBCA7f+MHm4xKao00vp8BcTaXx2ELPpJ1NwquxQ== X-Received: by 10.194.175.104 with SMTP id bz8mr41829474wjc.8.1453406079891; Thu, 21 Jan 2016 11:54:39 -0800 (PST) Received: from galloway.idiocy.org (d.0.d.3.7.a.e.3.0.f.2.b.f.2.5.7.9.2.1.8.8.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:3f8:8129:752f:b2f0:3ea7:3d0d]) by smtp.gmail.com with ESMTPSA id i63sm4296585wmf.24.2016.01.21.11.54.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2016 11:54:39 -0800 (PST) From: Alan Third To: Richard M Stallman Subject: Re: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location References: Date: Thu, 21 Jan 2016 19:54:35 +0000 In-Reply-To: (Richard M. Stallman's message of "Wed, 18 Feb 2009 18:05:32 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 2350 Cc: 2350@debbugs.gnu.org, erich@cozi.com, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Richard M Stallman writes: > But what isn't clear is whether it's always the right thing to do: it's > clear in this particular use of narrow, but there might be other uses of > narrow in conjunction with compilation buffers where it would be the > wrong thing to do. > > I looked at the code, and I think it is clear what to do: make sure > that narrowing does not prevent insertion at the specified insertion point. > > Does this change make it work? I can't replicate this behaviour in Emacs 25 and the patch provided in this email was applied in 2009: commit 0b508a27360a82763d4d7256b4cd526f9d3514aa Author: Richard M. Stallman Date: Mon May 18 16:30:59 2009 +0000 * progmodes/compile.el (compilation-filter): If inserting at end of accessible part of buffer, keep end of output visible. I believe we can close this bug report. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 29 16:13:26 2016 Received: (at control) by debbugs.gnu.org; 29 Jan 2016 21:13:26 +0000 Received: from localhost ([127.0.0.1]:40833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPGMA-0002Yy-5p for submit@debbugs.gnu.org; Fri, 29 Jan 2016 16:13:26 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:33514) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPGM8-0002Yl-Eb for control@debbugs.gnu.org; Fri, 29 Jan 2016 16:13:24 -0500 Received: by mail-wm0-f49.google.com with SMTP id l66so83292561wml.0 for ; Fri, 29 Jan 2016 13:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:date:message-id:to:from:subject; bh=e5FjdzCz6CsiY8usjetQFgN7cpt1TpbGN3/GolCCXek=; b=YnWELysxx3q4XFgnqR6UdAo2Lb9Fvm3lwBgY9Xf2p5/sB/Neh3NgYIeZgbQo+k643q 5LdR9ZKcf7x7m4h2/9/TWzi6JnwbbsERq9zyUcCS869F6F/8uPe54RJ+rdPxudB+e9Oz 2bFe5P5Z9qqz7tvpVP0iG2VWomcsogORZmwTKHJtJiAj1x1o1rP5ceg5r5TV5XX8agf7 K8UNqY/ALIyn4E9CzgnfvUd0KUAyB6WMu83POu5ZXUrB29ub4UYmOSSndjWJzGwDTuKi 5lvwglAvLbO1u9/iFrxD39U3p1giQuTnVZUmczLUwO0FJE+ykKCypSwBpL9LLkjJa54M aIcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:message-id:to:from:subject; bh=e5FjdzCz6CsiY8usjetQFgN7cpt1TpbGN3/GolCCXek=; b=gTiCf3E3Ul6Bc2JfEFk+6pEkWagiLYuBFB67+d+D0FDoWXOZXh/yowR40r+T6g1n74 eU1dH5jvJ0afRFTIPyZOOOoziQFfszyfMCHBdP08awALJzsAS7xcCjUlMSIGGeOM2CF5 +BKfx+YHs1LFPA8tqs+62ixO/EjmakbwB09io9VE1mDVR6e7gscAw9kMjIg+uW+OXNUc lFxOrxulyGTpJji0nXkykMPDJmqspOzAitqaoHuESAXGIxPnfBWMmhlh5vx265zs+yRR LE0kfxEBAOtNnbDQtLeozmQwqIHGNoucOobKXKZfb7ZlG8elp1FqAFncJsRTX3P2aWfs tnEA== X-Gm-Message-State: AG10YOTEJfKuARHpZRm5plwc5ucmLYyxq+aqtBXL7tirgwTUdSwAKkernlAGLSP6bHRd0w== X-Received: by 10.28.87.21 with SMTP id l21mr10633299wmb.8.1454101998744; Fri, 29 Jan 2016 13:13:18 -0800 (PST) Received: from galloway.idiocy.org (4.3.6.0.e.6.e.9.d.a.b.c.f.e.1.2.9.2.1.8.8.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:3f8:8129:21ef:cbad:9e6e:634]) by smtp.gmail.com with ESMTPSA id js8sm17280412wjc.37.2016.01.29.13.13.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jan 2016 13:13:18 -0800 (PST) Date: Fri, 29 Jan 2016 21:13:16 +0000 Message-Id: To: control@debbugs.gnu.org From: Alan Third Subject: control message for bug #2350 X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) close 2350 25.1 From unknown Mon Jun 23 11:25:06 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 27 Feb 2016 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator