From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: Tips for quick jumping back and forth Date: Wed, 11 Jul 2012 16:44:10 -0700 Message-ID: <13BA66DA5FBC432785CE408796BD71AD@us.oracle.com> References: <4FFD814E.8020702@yandex.ru> <2F7782F6CA4745A3A13E350FB63DD025@us.oracle.com> <4FFDB888.6050002@yandex.ru> <21C18E931DBD4E628B30D4800DDA96A5@us.oracle.com> <4FFDEA11.3060607@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1342050265 9721 80.91.229.3 (11 Jul 2012 23:44:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2012 23:44:25 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, philipp@haselwarter.org To: "'Dmitry Gutov'" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 12 01:44:25 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Sp6a0-0001ab-HL for geh-help-gnu-emacs@m.gmane.org; Thu, 12 Jul 2012 01:44:24 +0200 Original-Received: from localhost ([::1]:42970 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp6Zz-0001d2-QM for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Jul 2012 19:44:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp6Zu-0001cw-Bo for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 19:44:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sp6Zs-0004bN-Ki for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 19:44:18 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:29806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp6Zs-0004bI-C4 for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 19:44:16 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6BNiDZe004847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 23:44:14 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6BNiD49026669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 23:44:13 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6BNiCZ7018385; Wed, 11 Jul 2012 18:44:12 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Jul 2012 16:44:12 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4FFDEA11.3060607@yandex.ru> Thread-Index: Ac1fqJ5iwM94kB16SNWOYZk0BHIwbwAAzSxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 148.87.113.117 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:85812 Archived-At: > Even if your jumps are more arbitrary than that, chances are, > even when you C-s for a piece of code, it's somehow related > to the code you were looking at before that. So jumping back > and forward between them may be a thing you want to do. And > that can be made faster than choosing the > destination with filtering both times. You would not filter both times. When you flip back and forth between two buffers using `C-x b' (or whatever) you do not ask for all buffers as possible candidates and filter the list each time. You just accept the default of the previously chosen buffer. Same thing here. For such a use case you need neither traverse a tree node-by-node nor filter it. You just go directly to the last node visited. > How to save a tree structure that would be generally useful, that's a > harder question. Apparently you are interested in only the subset of the code tree/graph made up of the nodes you have already visited. Doesn't sound like a biggee. Or do you want to also present neighbor but unvisited nodes as candidates? And possibly not just immediate neighbors but nearby neighbors? I don't hear that you have quite decided this. But I thought that your previous description involved only visited nodes as candidates. > > You want to be able to easily navigate in an order that > > reflects your code structure. But you don't want to be limited > > to that navigation order, do you? Do you want to _have_ to climb > > step by step out of a deep code hierarchy to get to a distant > > cousin node in another part of the tree? I doubt it. For that you > > would quickly abandon your tree climbing, I am sure. > > Actually, the answer to that is "maybe", depending on how distant the > cousin is, and how well I know the code. For example, if I'm > not sure I remember the cousin's exact name, I might pop to the common > ancestor and follow from there, to be sure I know where I'm going. > If I had a visual representation of the tree, that would be > even better. I guess you mean a visual representation of the bushy tree itself, in addition to a visual representation of only the nodes you have visited. Perhaps you mean the latter superimposed on the former. I assume we are still talking about navigating among visited nodes, since you made the point that for arbitrary navigation of the full code tree and not just visited nodes things like imenu and Emacs tags (and Semantic...) can be more appropriate. I agree with that point, BTW - but it is a different topic. For code navigation in general there are lots of tools available. The discussion here has (so far) been about navigating among code bits (parts of the tree) that you have already visited. > > That was one of my main points: you can order the marks > > (nodes of your tree/graph) any way you like, and you can change > > orders on the fly. > > "Any way I like" is limited by the information I have. > If I have a hierarchical tree, though, seeing the nodes in a list, > ordered and with child nodes additionally indented according to the > structure, with filtering, might be quite interesting. That is what you would have. As I said, the default order is buffer order. But be aware that if we are talking only about places already visited then your view of the tree (whether linearized or 2D) will be limited. Anything unvisited will be missing - not a candidate for navigation this way (even if you decide to visualize it somehow). You would have to get to it some other way, naturally. This is much like a folded view of the code, but with the visible/invisible determined by what you have visited or not. (Or at least the navigable - maybe you would decide to also show additional, unvisited nodes - see above.) > >>> To get to an arbitrary position - especially to get there > >>> directly, it helps for the position to have a name or to be > >>> highlighted in some way, so that you can easily (a) recognize it > >>> and (b) directly point to it (e.g. mouse, or name completion). > >> > >> That's nice, except traversing along one or two edges of the > >> tree would probably be faster (if you know which edges to follow, > >> of course). > > > > Why do you think so? > > It's just one or two key combinations away. Not at all. The only (already visited) parts of the tree that are only one or two key combinations away are those that are, well, one or two key combinations away! And they would be the same distance away if you ordered candidates by last visit, for instance. Especially if your navigation model is only from node to immediately adjacent node. > That's always faster than invoking the list, entering search > criteria, picking, etc. You seem to be using last-visited as your metric of which nodes to represent as nearby. And apparently you are interested only in, say, the Nth nearest (by visit time), to reduce your search space. Those criteria seem to _be_ your search criteria, and the same criteria can be used to control a bookmark (or whatever) choice/search just as easily. IOW, that has nothing, per se, to do with any tree structure, AFAICT. _If_ you choose to navigate the tree in the first place in some structured way, and if you mark the nodes visited as you move through them, then the navigation history will reflect the tree structure in a particular way, which you think will be helpful. (The history will reflect the tree structure in some way no matter how you navigate the tree. Of course, some ways might be more helpful than others.) > > the point is that you are not limited to one or two > > ways of navigating your tree/graph... > > I agree it can be quite useful as well. > Being able to filter the list, though, doesn't entirely solve the > problem of choice. You need to choose what to filter on, maybe also > ordering, and that requires some brainpower. You would choose it beforehand, especially if you find an approach that you like most of the time, as seems to be the case. If you like your only-the-N-last-visited-nodes search space then put that into defining your navigation set (bookmarks "navigation list" plus sort order). No special brainpower needed to explore that space afterward. IOW, however you might want to define (including to order) the set of nodes that you want to serve as navigation choices, you can do it. They can be the tree nodes nearest your current position (e.g. in terms of adjacent-node hops). Or they can be the nodes you have visited most recently. Or some combination of the two; or something else. You can (programmatically) make it quickest and easiest to get to any particular set of nodes you choose, by controlling the set and the order. And you can limit the set size to simplify choosing. > If you can only move to the neighbor nodes in a tree, this can be > performed (nearly) automatically. So make that your navigation set and limit yourself to it, if you like. > I mean that if the rule above is always true (you only move > from caller to callee or back), your movement directly reflects > elements of control flow - function call or value return, and > so helps understanding the code structure. You're more aware > of the relationships between functions. Try it, and see how useful you find it to be. If you limit yourself to navigating your code that way (`C-M-d' etc.), and if you (manually or automatically) "mark" each node you visit (or perhaps only selected nodes), then you can find out how useful your breadcrumbs structure of visited nodes is for subsequent navigating. Wrt the automatic creation of bookmarks, I should mention also that Bookmark+ has a (buffer-local or global) mode to do that, which is based on time spent at a given position with the position's buffer current: `bmkp-auto-idle-bookmark-mode'. You can define the bookmarking function that is used for this. By default it sets a temporary, autonamed bookmark at the start of the current line. But it could do anything you like, including pay attention to the code structure and code parts already visited etc. HTH.