[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