From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard M Stallman Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#2350: 23.0.90; compilation-mode inserts output in the wrong location Date: Wed, 18 Feb 2009 18:05:31 -0500 Message-ID: References: Reply-To: rms@gnu.org, 2350@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1234999462 1762 80.91.229.12 (18 Feb 2009 23:24:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2009 23:24:22 +0000 (UTC) Cc: 2350@emacsbugs.donarmstrong.com, emacs-pretest-bug@gnu.org, erich@cozi.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 19 00:25:37 2009 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.50) id 1LZvnM-0000Yf-Gl for geb-bug-gnu-emacs@m.gmane.org; Thu, 19 Feb 2009 00:25:36 +0100 Original-Received: from localhost ([127.0.0.1]:59950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZvm2-0000qd-Bx for geb-bug-gnu-emacs@m.gmane.org; Wed, 18 Feb 2009 18:24:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZvlW-0000eQ-IW for bug-gnu-emacs@gnu.org; Wed, 18 Feb 2009 18:23:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZvlU-0000cn-VH for bug-gnu-emacs@gnu.org; Wed, 18 Feb 2009 18:23:41 -0500 Original-Received: from [199.232.76.173] (port=39411 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZvlU-0000cY-JI for bug-gnu-emacs@gnu.org; Wed, 18 Feb 2009 18:23:40 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57482) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LZvlT-0002KN-En for bug-gnu-emacs@gnu.org; Wed, 18 Feb 2009 18:23:39 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n1INNZoF028522; Wed, 18 Feb 2009 15:23:36 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n1INF8Tj026205; Wed, 18 Feb 2009 15:15:08 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Richard M Stallman Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 18 Feb 2009 23:15:08 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 2350 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 2350-submit@emacsbugs.donarmstrong.com id=B2350.123499846824207 (code B ref 2350); Wed, 18 Feb 2009 23:15:08 +0000 Original-Received: (at 2350) by emacsbugs.donarmstrong.com; 18 Feb 2009 23:07:48 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-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 Original-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 In-reply-to: (message from Stefan Monnier on Wed, 18 Feb 2009 09:25:59 -0500) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Wed, 18 Feb 2009 18:23:41 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list 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:25428 gmane.emacs.pretest.bugs:23936 Archived-At: 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