From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: narrowing to subtree in navi-mode Date: Fri, 08 Nov 2013 10:45:13 +0100 Message-ID: <877gcj8bx2.fsf@gmail.com> References: <87ppqb99lb.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeidA-0003rU-TM for emacs-orgmode@gnu.org; Fri, 08 Nov 2013 04:45:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Veid4-0005je-Vj for emacs-orgmode@gnu.org; Fri, 08 Nov 2013 04:45:32 -0500 Received: from plane.gmane.org ([80.91.229.3]:35568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Veid4-0005ja-Nr for emacs-orgmode@gnu.org; Fri, 08 Nov 2013 04:45:26 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Veid2-0001dq-R3 for emacs-orgmode@gnu.org; Fri, 08 Nov 2013 10:45:24 +0100 Received: from e178191066.adsl.alicedsl.de ([85.178.191.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Nov 2013 10:45:24 +0100 Received: from tjolitz by e178191066.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Nov 2013 10:45:24 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Matt Price writes: > On Thu, Nov 7, 2013 at 4:37 PM, Thorsten Jolitz wrote: >> Matt Price writes: [...] >>> I would like to keep the full tree visible in the navi-mode buffer >>> while narrowing the original org buffer. I wonder if this is >>> possible? In particular, I wonder if I am confronting an underlying >>> limitation in occur-mode, on which navi-mode is based. >> >> Actually navi-mode does nothing special wrt to narrowing, and a quick >> search in occur-mode (replace.el) gave no match for 'narrow' or >> 'restriction' or so. I think this is just basic Emacs behaviour for most >> functions to only act on the visible parts of the buffer. >> >> I would try to (partly) achieve your goal with visibility cycling: with >> point in the *Navi* buffer, use to globally cycle the >> associated Org-buffer into the states OVERVIEW or CONTENTS, then move >> point in the *Navi* buffer to the headline your are interested in and use >> to locally cycle this headline to state SHOW ALL. >> >> Not a perfect solution, but yields a folded Org file with only one >> headline unfolded, while all navi searches still act on the whole file. > > Let me try to explain better the effect I'm trying for. The idea > behind org-writers-room is to achieve a mostly distraction-free > environment for writing, but which preserves some elements of the > context into which the piece you are currently writing actually fits. > To this end, I was hoping to have: > > (a) a GUIDE window which shows the whole structure of the file > (really, the buffer) on which you are working. You should be able to > collapse this out to arbitrary levels. But I think it's important > that the whole outline be visibleat any given moment. Obviously > navi-mode is great for this. This description reminds me very much of http://www.gnu.org/software/emacs/manual/html_node/speedbar/ which I did not really use in practise, but which seems to offer a kind of "explorer" for Emacs and might just do what you want. > (b) a MAIN window which shows *only the part of the file you are > currently working on*. This could be a chapter (of your dissertation > or of a novel), a section, or even a paragraph. I want to restrict > the visibility of other sections because having the other text in the > window will detract from the main point of this mode, which is to help > the writer focus. > > (c) a META window which shows some set of properties that is relevant > to the particular work. I think this should always include a > synopsis, and other properties will be specific to the genre or > individual work. It might be nice to include tags here also but that > is a more ambitious goal. Ok, now I understand you goals better. Again, this reminds me very much of ECB, so you try to build a kind of IDE for writers instead of programmers. > I'm thinking the way to do this would be to avoid narrowing the main > org buffer at all. Instead, I should write a function based on > navi-goto-occurence-other-window (or a defadvice for that function? > I'm not sure which is cleaner) to which I would bind both RET and "o". Somehow I never 'advise' functions, so I can't really comment on that, but this sounds like a good idea > The new function would travel to the desired occurence in the main > org buffer (which would be opened in window "MAIN" rather than in a > new window), then quickly create an indirect buffer narrowed to the > subtree and switch-to-buffer in the same MAIN window. again this sounds like a reasonable approach > It all seems rather elaborate but it would solve my problem I htink. > If you see any problems with this strategy, or a less ugly way to do > the same thing, I would of course appreciate the guidance. you might want to look at ECB, speedbar and alikes if they don't offer out-of-the-box what you want. navi-mode is for very flexible and very efficient buffer navigation and exploration as well as for a kind of buffer-remote-control. It might be very well suited for you needs, but there are quite a lot of alternatives too. -- cheers, Thorsten