From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Patch: enhanced mark navigation commands Date: Wed, 05 Mar 2008 14:20:23 -0500 Message-ID: References: <55f7df060803042112w380b5170qe964002c6c06ab01@mail.gmail.com> <86r6ep8821.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204744853 4261 80.91.229.12 (5 Mar 2008 19:20:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Mar 2008 19:20:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 05 20:21:20 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JWzAn-00085U-50 for ged-emacs-devel@m.gmane.org; Wed, 05 Mar 2008 20:21:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JWzAF-0000fy-NH for ged-emacs-devel@m.gmane.org; Wed, 05 Mar 2008 14:20:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JWzAA-0000e3-JW for emacs-devel@gnu.org; Wed, 05 Mar 2008 14:20:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JWzA9-0000co-PE for emacs-devel@gnu.org; Wed, 05 Mar 2008 14:20:26 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JWzA9-0000ce-Hf for emacs-devel@gnu.org; Wed, 05 Mar 2008 14:20:25 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JWzA9-0003HZ-9Y for emacs-devel@gnu.org; Wed, 05 Mar 2008 14:20:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGqBzkfO+LKX/2dsb2JhbACSPZligQI X-IronPort-AV: E=Sophos;i="4.25,451,1199682000"; d="scan'208";a="15628200" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 05 Mar 2008 14:20:24 -0500 Original-Received: from pastel.home ([206.248.178.151]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id LWZ22224; Wed, 05 Mar 2008 14:20:24 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id EC09C816B; Wed, 5 Mar 2008 14:20:23 -0500 (EST) In-Reply-To: <86r6ep8821.fsf@lifelogs.com> (Ted Zlatanov's message of "Wed, 05 Mar 2008 10:11:34 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:91404 Archived-At: AR> The attached lisp allows moving around within a buffer or buffers to AR> places where recent edits or other events took place. It has been AR> part of Emacs.app for a while and users have found it useful; I'd like AR> to propose it being added to the emacs distribution itself, probably AR> as part of simple.el. AR> Specifically, the keys M-p and M-n are bound to move forwards and AR> backwards through the mark history. Also, immediately after popping a AR> global mark, e.g., with C-x C-SPC, then the global mark ring is used. The functionality looks interesting. But there are a few problems with it: - loading the file alters the behavior of Emacs. The `global-set-key' calls should be moved out of the top-level, e.g. into a minor-mode. - it seems to do some funny dances with the mark-ring and global-mark-ring (including reversing them), so I'm not sure the interaction with things like C-u C-SPC will be right. - this last point really means that maybe this should be more closely integrated into existing functionality such as C-u C-SPC. After all, C-u C-SPC (and/or C-x C-SPC) offers basically the functionality of your `ns-prev-mark' (especially together with set-mark-command-repeat-pop). So all we need is a way to provide ns-next-mark. If the main/only use of ns-next-mark is to undo an excessive use of ns-prev-mark, then maybe C-u could be used to change the direction in a series of C-SPC: C-u C-SPC C-SPC C-SPC ... oh no too far ... C-u C-SPC > Would next-error and previous-error (which are useful for any motion to > "points of interest" and have aliases defined accordingly) be > appropriate here? They already handle occur-mode, grep-mode, and > compilation-mode point of interest, and the intent is to provide a DWIM > interface. > It makes sense that if any of those three modes are not on, next-error > and previous-error should move to recent edit points. If one of those > modes is on, we can provide an override, but I expect users to be happy > with the default behavior as I describe it. What do you think? And then as soon as you run grep, diff, or compile, the feature just can't be used any more? Doesn't sound too good to me, Stefan