From: Matt Price <moptop99@gmail.com>
To: Thorsten Jolitz <tjolitz@gmail.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: narrowing to subtree in navi-mode
Date: Thu, 7 Nov 2013 21:07:05 -0500 [thread overview]
Message-ID: <CAN_Dec_ZmPotqbhgWigcnMwONHu-eHkXWcnsZgiBDU60MmTxmg@mail.gmail.com> (raw)
In-Reply-To: <87ppqb99lb.fsf@gmail.com>
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
>
>
next prev parent reply other threads:[~2013-11-08 2:07 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 [this message]
2013-11-08 9:45 ` Thorsten Jolitz
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN_Dec_ZmPotqbhgWigcnMwONHu-eHkXWcnsZgiBDU60MmTxmg@mail.gmail.com \
--to=moptop99@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tjolitz@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).