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: Thorsten Jolitz
Subject: Re: [O] narrowing to subtree in navi-mode
Date: Fri, 08 Nov 2013 10:45:13 +0100
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux)

Matt Price <address@hidden> writes:

> On Thu, Nov 7, 2013 at 4:37 PM, Thorsten Jolitz <address@hidden> wrote:
>> Matt Price <address@hidden> 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




reply via email to

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