emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] narrowing to subtree in navi-mode


From: Matt Price
Subject: Re: [O] narrowing to subtree in navi-mode
Date: Thu, 7 Nov 2013 21:07:05 -0500

On Thu, Nov 7, 2013 at 4:37 PM, Thorsten Jolitz <address@hidden> wrote:
> Matt Price <address@hidden> writes:
>
> Hi Matt,
>
>> I am trying to rewrite my org-writers-mode to use a navi-mode buffer
>> as a guide for the org-mode buffer
>>
>> In navi-mode, it is possible to narrow the original ("twin)) buffer
>> using the quick ommand "r".  However, doing so also narrows the
>> navi-mode buffer, so that only the current heading is visible.
>
> But this is a big advantage in IMO. E.g. when using navi-mode to explore
> org.el, a giant file with lots of headlines and many functions and vars
> in each subtree, its very useful to quickly restrict search to the
> subtree at point and then use e.g. f and v for viewing functions and
> variables in that subtree. Otherwise you would see a narrowed original
> buffer in one window, but hundreds of functions (most of them not in the
> narrowed subtree) when you type f in the *Navi* buffer.

Yes, it works great in code, I agree.  See below...

>
>> 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 <BACKTAB> 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
> <TAB> 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.

(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.

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".
 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.

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.

Thanks!

Matt

>
> --
> cheers,
> Thorsten
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]