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: Add M-x occur to the menu-bar Date: Wed, 28 Jan 2004 10:46:37 -0500 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: <4nd694yt2a.fsf@collins.bwh.harvard.edu> References: <3F69E6FF.9050702@yahoo.com> <4n8yjto16h.fsf@collins.bwh.harvard.edu> <4nisixjibl.fsf@collins.bwh.harvard.edu> <20040127230323.GB5407@fencepost> <4n7jzc919v.fsf@collins.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075306384 29278 80.91.224.253 (28 Jan 2004 16:13:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2004 16:13:04 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jan 28 17:12:58 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 1AlsJG-0001j5-00 for ; Wed, 28 Jan 2004 17:12:58 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AlsJF-0004Rr-00 for ; Wed, 28 Jan 2004 17:12:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AlrwC-0004MS-Fr for emacs-devel@quimby.gnus.org; Wed, 28 Jan 2004 10:49:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Alrvh-0004MC-5W for emacs-devel@gnu.org; Wed, 28 Jan 2004 10:48:37 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Alrv9-0004KI-Tz for emacs-devel@gnu.org; Wed, 28 Jan 2004 10:48:35 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Alrv9-0004KE-Eu for emacs-devel@gnu.org; Wed, 28 Jan 2004 10:48:03 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Alrv8-0006j5-00 for ; Wed, 28 Jan 2004 16:48:02 +0100 Original-Received: from collins.bwh.harvard.edu ([134.174.9.80]) by news.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed Jan 28 15:48:02 2004 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Alrv7-0006iw-00 for ; Wed, 28 Jan 2004 16:48:01 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Alrv7-0006Yd-00 for ; Wed, 28 Jan 2004 16:48:01 +0100 Original-Lines: 42 Original-X-Complaints-To: usenet@sea.gmane.org Gmane-NNTP-Posting-Host: collins.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.110002 (No Gnus v0.2) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:HiG8GAkVnyw0ctGcfASZjK9DXO4= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:19527 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19527 On 28 Jan 2004, monnier@iro.umontreal.ca wrote: >> 1) next-error does not support the occur mode, which was what >> started the discussion in the firts place. I tried to fix this >> with minimum changes to the Emacs sources. > > Minimizing the amount of changes is a worthy goal but it should not > take precedence over the goals of: - consistent behavior - > maintainability What this means is that it would be better to > integrate the support for occur and the support for grep and compile > rather than add a layer on top of the support for grep and compile. > That doesn't mean it has to be 100% integration, but `next-error' > could pay attention to a variable like > `compile-error-forward-function' or something like that which > occur-mode could set buffer-locally. The idea is to keep as much of > the code together: at least the code that selects and displays the > relevant buffer should be shared, IMO. I'm OK with all this, and I can make a patch to next-error and to occur to implement these changes. >> 2) next-error is IMHO a bad name for a function that finds the next >> match in grep mode, and the next occurrence in occur mode. > > That's probably tru. If you can come up with a better name, maybe > we can change it. I don't find dwim-next to be much btter. I would just defalias, since we're patching next-error anyhow. Some names I thought of: (additive) next-error-or-occurrence (hard to spell) next-error-or-occur (but what if other modes are added?) next-error-or-spot (different altogether) next-instance next-place next-interesting next-dwim Ted