From: Thorsten Jolitz <tjolitz@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: narrowing to subtree in navi-mode
Date: Fri, 08 Nov 2013 10:45:13 +0100 [thread overview]
Message-ID: <877gcj8bx2.fsf@gmail.com> (raw)
In-Reply-To: CAN_Dec_ZmPotqbhgWigcnMwONHu-eHkXWcnsZgiBDU60MmTxmg@mail.gmail.com
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
prev parent reply other threads:[~2013-11-08 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 20:36 narrowing to subtree in navi-mode Matt Price
2013-11-07 21:37 ` Thorsten Jolitz
2013-11-08 2:07 ` Matt Price
2013-11-08 9:45 ` Thorsten Jolitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gcj8bx2.fsf@gmail.com \
--to=tjolitz@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.