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, 26 May 2004 09:56:54 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nd64rl2ah.fsf@lifelogs.com> References: <871xluig40.fsf@mail.jurta.org> <87u0y6jjq9.fsf@mail.jurta.org> <87n03wgt76.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 1085604258 22862 80.91.224.253 (26 May 2004 20:44:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 26 May 2004 20:44:18 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 26 22:43:55 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 1BT5Fj-0001Pp-00 for ; Wed, 26 May 2004 22:43:55 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BT5Fi-0000YU-00 for ; Wed, 26 May 2004 22:43:54 +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 1BT56z-0001QC-HC for emacs-devel@quimby.gnus.org; Wed, 26 May 2004 16:34:53 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BT4j7-0005l0-Pz for emacs-devel@gnu.org; Wed, 26 May 2004 16:10:13 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BT2DR-0007Q3-3c for emacs-devel@gnu.org; Wed, 26 May 2004 13:29:53 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BT017-00086v-Ks for emacs-devel@gnu.org; Wed, 26 May 2004 11:08:30 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BSzAH-00033O-00 for ; Wed, 26 May 2004 16:13:53 +0200 Original-Received: from asimov.bwh.harvard.edu ([134.174.9.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 May 2004 16:13:53 +0200 Original-Received: from tzz by asimov.bwh.harvard.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 May 2004 16:13:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 41 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: asimov.bwh.harvard.edu 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" User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:g0uKyGkUPlW7vG4buhIQSfcVN5Y= 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:23977 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23977 On Tue, 25 May 2004, juri@jurta.org wrote: > Richard Stallman writes: >> This fix has a drawback; it will make that buffer permanently >> incapable of being used as a series of references to places. >> >> I think we should look for a way to disable this temporarily instead. >> However, I am not sure how that would work--what would be the >> condition on which to reenable this buffer's value of >> next-error-function? > > If there is a real need to enable next-error-function in the existing > buffer visited by next-error (i.e. if it's not too rare case when the > user needs to kill a buffer and create a new, that may be inconvenient > if performed too often), then next-error-function could be enabled again > by setting it to the initial value by typing C-m or one of other error > visiting keys available in the next-error capable buffer. When these > keys are bound to one of the following functions, each function could > set the initial value of next-error-function every time it called > in the next-error capable buffer: > > compile-goto-error > diff-goto-source > occur-mode-goto-occurrence I think your proposal forces the user to do something unexpected in the flow of their work. It's not a terrible solution, if it's the only one we have, but I would prefer to do it in a different way: Maybe if there's more than one next-error capable buffers that are linked together (e.g. occur on a diff) then C-u next-error should advance through the "underlying" next-error buffer (the diff) while next-error should advance through the "overlay" next-error buffer (the occur). If the user does a grep on an occur on a diff, for instance, then C-u C-u next-error advances through the diff, C-u next-error advances through the occur, and next-error advances through the grep. Does this approach seem useful? Ted