From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.help Subject: Re: Tips for quick jumping back and forth Date: Thu, 12 Jul 2012 01:03:13 +0400 Message-ID: <4FFDEA11.3060607@yandex.ru> References: <4FFD814E.8020702@yandex.ru> <2F7782F6CA4745A3A13E350FB63DD025@us.oracle.com> <4FFDB888.6050002@yandex.ru> <21C18E931DBD4E628B30D4800DDA96A5@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1342040623 2125 80.91.229.3 (11 Jul 2012 21:03:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2012 21:03:43 +0000 (UTC) Cc: help-gnu-emacs@gnu.org, philipp@haselwarter.org To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jul 11 23:03:41 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 1Sp44R-0004MC-0m for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Jul 2012 23:03:39 +0200 Original-Received: from localhost ([::1]:52728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp44Q-0001iU-6p for geh-help-gnu-emacs@m.gmane.org; Wed, 11 Jul 2012 17:03:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp44G-0001iM-Qy for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 17:03:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sp44E-00074z-Q4 for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 17:03:28 -0400 Original-Received: from forward8.mail.yandex.net ([77.88.61.38]:55165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sp44E-0006z7-83 for help-gnu-emacs@gnu.org; Wed, 11 Jul 2012 17:03:26 -0400 Original-Received: from smtp9.mail.yandex.net (smtp9.mail.yandex.net [77.88.61.35]) by forward8.mail.yandex.net (Yandex) with ESMTP id E1505F60402; Thu, 12 Jul 2012 01:03:12 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1342040593; bh=12GLDJDRLM7hiyraq7+i77eqIECyF1g8tOT9Ks39Y7I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pItoCS7rXEn8yHxvQFDXtPkczS6J9ydKjakkT5zprtzGA+mBz9t4s4OY24H0fl3UN H/a1/InIZxt6xnqC/CkzIhxN+heSEYyYzGg3N0iWz+p+cQdN3PmdAi4T6sSK2DA2Dg /JYKgG3vAN1w7GOJ5ChMEB+d15xvBV6Jet61pjaM= Original-Received: from smtp9.mail.yandex.net (localhost [127.0.0.1]) by smtp9.mail.yandex.net (Yandex) with ESMTP id B0648152072F; Thu, 12 Jul 2012 01:03:12 +0400 (MSK) Original-Received: from 98-87.nwlink.spb.ru (98-87.nwlink.spb.ru [178.252.98.87]) by smtp9.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 3C484bL8-3C4upNN8; Thu, 12 Jul 2012 01:03:12 +0400 X-Yandex-Rcpt-Suid: drew.adams@oracle.com X-Yandex-Rcpt-Suid: philipp@haselwarter.org X-Yandex-Rcpt-Suid: help-gnu-emacs@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1342040592; bh=12GLDJDRLM7hiyraq7+i77eqIECyF1g8tOT9Ks39Y7I=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZPyz4ztaYGY76ct35ol9jtOSpP1hGsKjZoV2xxo/nJTh+iD1H5A2c3PE33Quoo3x4 ScyPOgb6juSkYxlnmn880HMLVkzjX8NdlGD298+P4PbQD0JGqwOLZbW05bjh/TAYUs /MfHvaeM10eKEeSiUrTjFK5o+0ryTOtt0pF7qSS8= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <21C18E931DBD4E628B30D4800DDA96A5@us.oracle.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 77.88.61.38 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:85811 Archived-At: On 11.07.2012 22:33, Drew Adams wrote: >> That's correct, except many useful functions, such as `imenu', >> `find-function', and `isearch-mode', automatically push mark before >> performing navigation. So the mark rings become a centralized >> source of information on "where I was before I did that thing". > > Sure, but as you say afterward this builtin, automatic where-I-was marking can > have its own drawbacks, including the global ring vs local rings limitation The limitation is not necessary, I think. So, I'm puzzled by the built-in behavior, and I point it out. > which you point out. Hence your attempt to (manually? programmatically?) mark > where-I-was. Programmatically, through before-advice. I don't have a tree (yet?), though, just two stacks. >> If you're just editing text, maybe. But I'd wager that most >> of the time people are using Emacs to read and edit program code. > > Yes, so? You still want to be able to navigate among code positions in any > order. I think `imenu' and `find-tag' facility serve that purpose better, since you may want to jump to any class or function, not just some of them you have bookmarked. > In particular, _you_ say you want to be able to navigate among them in a > particular order that you establish to represent the code calling hierarchy. > That's one of many possible structures (position relations), and even a single > tree/graph allows for many different traversals. That graph description was one of many possible interpretations, but I wanted to illustrate that when a structure has meaning, it can become easier to use. 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. > Which is my point. The structure of a set of positions (ring, tree, whatever) > should not limit how you access individual positions or groups of positions. I agree that sometimes it shouldn't, but you can always additionally implement regexp search or other filtering, like you did with bookmarks. How to save a tree structure that would be generally useful, that's a harder question. >> The jumps may be contained to one file, or may be spread >> across several files - if I have to keep in mind which kind >> the last jump was when I want to return, that's a speed bump >> (hence my dislike for global vs >> local mark rings, etags.el does this better). > > That's just an argument that the global and local rings do not cut the mustard > for you. Sounds good to me. I agree. They are what they are, and no more. Yes, I just wanted to elaborate on the reason why. > I hear you and go beyond what you're saying: the structure of the positions you > set should not limit your navigation of its elements in any way. > > It's fine to have some help that favors certain predefined navigations/relations > over others. But that's different from having the marker set's structure impose > predefined order(s). > > 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. On the other hand, if we don't have a structure saved, or if we just have the two mark rings, we can't even do the "pop back" action confidently. > I agree that if you have a graphical (e.g. 2D) representation of that > order/structure, then you can see it as a whole and directly access positions or > access them using tree/graph traversal. Think code folding, for instance. > > Barring a 2D representation, you can use a linear ordering of the tree/graph - a > particular traversal. And that you can do using either of the features I > mentioned. (Again, think code folding: your code is both a tree/graph and a > linear representation.) And you can flip among multiple such traversals. > > 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. >>> 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. That's always faster than invoking the list, entering search criteria, picking, etc. > Here's the picture: You've got a list of your tree nodes, in an order that you > find useful. You can immediatly hide/show particular nodes (by name or another > property), on the fly. You can easily see all nodes that match some condition > (related to their names, creation dates, last access time, or anything else). > And you can immediately get to any of them you like after such filtering. And > you can trip among groups of them in various orders. > > The power is in the filtering. Once you can see your destination, hey, just go > there. Navigation as, first and foremost, filtering. The same thing you would > do in (e.g. functional) programming to access parts of a tree. You would map, > filter, whatever, to massage the tree into one that puts what you want at your > fingertips. You would not necessarily mechanically set out on a depth- or > breadth- or best-first Silk Road traversal of all nodes from here to there. > > I say "necessarily" because the point is that you are not limited to one or two > ways of navigating your tree/graph. But nothing prevents you from getting there > the hard way, a neighbor node at a time. 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. If you can only move to the neighbor nodes in a tree, this can be performed (nearly) automatically. >> With direct access, you also lose the relationship context - >> like "the code I'm looking at now [calls|is called by] the code I was >> looking at a second ago". > > Why would you lose it? If you can create it then it is there and it remains. > It is part of the information recorded for your "marks". 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.