From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: next-error-last-buffer Date: Wed, 12 May 2004 09:50:34 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4n7jvhg3f9.fsf@lifelogs.com> References: <871xluig40.fsf@mail.jurta.org> <873c6983t9.fsf@mail.jurta.org> <8765b3vm0r.fsf@mail.jurta.org> <4nn04fgeli.fsf@lifelogs.com> <87hdumto1j.fsf@mail.jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084374961 23759 80.91.224.253 (12 May 2004 15:16:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 15:16:01 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 12 17:15:50 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 1BNvSY-0002Jh-00 for ; Wed, 12 May 2004 17:15:50 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNvSY-0000ov-00 for ; Wed, 12 May 2004 17:15:50 +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 1BNuwP-0000JT-Pj for emacs-devel@quimby.gnus.org; Wed, 12 May 2004 10:42:37 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNutl-0008AV-Rs for emacs-devel@gnu.org; Wed, 12 May 2004 10:39:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNutC-00082r-L8 for emacs-devel@gnu.org; Wed, 12 May 2004 10:39:50 -0400 Original-Received: from [134.174.9.44] (helo=mail.bwh.harvard.edu) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BNuNe-0001jM-MC for emacs-devel@gnu.org; Wed, 12 May 2004 10:06:42 -0400 Original-Received: (qmail 8434 invoked from network); 12 May 2004 14:01:15 -0000 Original-Received: from asimov.bwh.harvard.edu (HELO asimov) ([134.174.9.63]) (envelope-sender ) by mail.bwh.harvard.edu (qmail-ldap-1.03) with SMTP for ; 12 May 2004 14:01:14 -0000 Original-To: Juri Linkov X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" In-Reply-To: <87hdumto1j.fsf@mail.jurta.org> (Juri Linkov's message of "Wed, 12 May 2004 02:46:48 +0300") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) 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:23251 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23251 On Wed, 12 May 2004, juri@jurta.org wrote: > The current implementation of next-error framework is general enough > to allow implementing different approaches easily (for example, I > was able to implement the desired behavior with only one small > change in the `next-error' function), but it is still not extensible > enough. > > Based on my recent experience, I want to make some suggestions > how to make it more extensible: > > 1. Add an option to allow the user to select among predefined > behaviors. Though, this will not help the user if he will not > find a desired option in the predefined set. What predefined behaviors should we allow? - use the last visited buffer - prefer {compile,grep,occur} buffers - use the visible buffers - user-defined function The behavior preferences should be in a list, so the user can say "use my function, then use the visible buffers first, then try a compile buffer, then use the last visited buffer" for instance. I really think most users will be happy with a default of "last visited buffer" but we should let the users decide by making it easy to configure. > 2. Add a new user variable `next-error-find-buffer-function' and try > to call it (i.e. to call it if it's fbound and return its value, but > if it returns `nil', try other rules) in `next-error-find-buffer' at > the top precedence level before all other rules. This will allow > the user to override the standard rules for finding the next-error > capable buffer with his own rule. I think this should be just another behavior, not an overriding preference. It could go in the middle of the search rules, for instance. > 3. Add a hook to `next-error' after the `funcall > next-error-function' to allow the user to perform actions (such as > setting buffer-local variables) in the buffer found by > `next-error-function'. I'm OK with that. > I thought again about why the current behavior is too confusing > and I think I found the reason: the most confusing is the fact that > the compilation buffer is visible in the window adjacent to the > source file window where the point is located, but typing C-x ` > uses the last but not visible compilation buffer. You are not a typical user. I, for instance, have NEVER run more than one compilation at a time. I may have to in the future, sure, but I doubt it's typical user behavior. > So w.r.t. `next-error-find-buffer' I propose to modify it to use the > following priority order: > > 1(new). Try to call a user-defined > `next-error-find-buffer-function'. 2. If the current buffer is a > next-error capable buffer, return it. 3(new). If a next-error > capable buffer is in one of the windows of the current frame, return > it. 4. If next-error-last-buffer is set to a live buffer, use that. > 5. Otherwise, look for a next-error capable buffer 6. Signal an > error if there are none. I think the current buffer should override any other rules. The other rules' order should be user-configurable. Ted