From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: next-error-last-buffer Date: Tue, 11 May 2004 08:23:30 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <871xluig40.fsf@mail.jurta.org> <873c6983t9.fsf@mail.jurta.org> <87wu3kqguz.fsf-monnier+emacs@gnu.org> <874qqnvm0n.fsf@mail.jurta.org> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1084281831 7130 80.91.224.253 (11 May 2004 13:23:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 May 2004 13:23:51 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 11 15:23:24 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNXEB-0004ZP-00 for ; Tue, 11 May 2004 15:23:23 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNXEB-0004Tn-00 for ; Tue, 11 May 2004 15:23:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNWXS-0002r0-0l for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 08:39:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNWIq-0001Cy-Fe for emacs-devel@gnu.org; Tue, 11 May 2004 08:24:08 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNWIH-00014m-72 for emacs-devel@gnu.org; Tue, 11 May 2004 08:24:05 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNWIG-000141-7P for emacs-devel@gnu.org; Tue, 11 May 2004 08:23:32 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BNWIE-0008SB-K0; Tue, 11 May 2004 08:23:30 -0400 Original-To: Juri Linkov In-reply-to: <874qqnvm0n.fsf@mail.jurta.org> (message from Juri Linkov on Tue, 11 May 2004 02:45:12 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23138 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23138 > Indeed. In order to get the right behavior in all cases, we'd need > to read the user's mind. So the current approach at least has the > advantage of being simple for the user to understand (and thus predict), > while working correctly for the most common cases. The current approach is simple, but unusable in real situations. I expect the same would be true if we make the change that you propose. I pointed out, when we first started to unify Occur with next-error, that finding the right way to treat these issues would be the hardest part of the job. On such issues it is quite common to find that all the straightforward options are clearly wrong in some cases. > If you switch to another source buffer that was last reached > through C-x ` from a compilation error, then C-x ` will get the > next compilation error, rather than the next occurrence. > At least, it sounds like your change would have that result. Exactly. This is the most expected behavior, because the user associates the buffer visited through C-x ` with the compilation buffer from which it was visited You're assuming one scenario, but there are others just as plausible. For instance, the user still working on looking through all the occurrences in the Occur buffer, and looks at this other buffer because one of its functions was called from the code at one of those occurrences. It seems nobody really tried yet to use two or more different compile/grep/occur processes at the same time. Otherwise, it would be apparent that this behavior is the most useful. It could not hurt for more people to try these cases, and try playing with different behaviors, so that we can find out what is really best.