narrowing to subtree in navi-mode

narrowing to subtree in navi-mode

[Matt Price]

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.

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.

 Thanks for your help!
Matt

Re: narrowing to subtree in navi-mode

[Thorsten Jolitz]

Matt Price <moptop99@gmail.com> 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.

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

-- 
cheers,
Thorsten

Re: narrowing to subtree in navi-mode

[Matt Price]

On Thu, Nov 7, 2013 at 4:37 PM, Thorsten Jolitz <tjolitz@gmail.com> wrote:
> Matt Price <moptop99@gmail.com> 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
>
>

Re: narrowing to subtree in navi-mode

[Thorsten Jolitz]

Matt Price <moptop99@gmail.com> writes:

> On Thu, Nov 7, 2013 at 4:37 PM, Thorsten Jolitz <tjolitz@gmail.com> wrote:
>> Matt Price <moptop99@gmail.com> 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 <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.

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