* narrowing to subtree in navi-mode
@ 2013-11-07 20:36 Matt Price
2013-11-07 21:37 ` Thorsten Jolitz
0 siblings, 1 reply; 4+ messages in thread
From: Matt Price @ 2013-11-07 20:36 UTC (permalink / raw)
To: Org Mode, Thorsten Jolitz
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: narrowing to subtree in navi-mode
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
0 siblings, 1 reply; 4+ messages in thread
From: Thorsten Jolitz @ 2013-11-07 21:37 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: narrowing to subtree in navi-mode
2013-11-07 21:37 ` Thorsten Jolitz
@ 2013-11-08 2:07 ` Matt Price
2013-11-08 9:45 ` Thorsten Jolitz
0 siblings, 1 reply; 4+ messages in thread
From: Matt Price @ 2013-11-08 2:07 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: Org Mode
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
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: narrowing to subtree in navi-mode
2013-11-08 2:07 ` Matt Price
@ 2013-11-08 9:45 ` Thorsten Jolitz
0 siblings, 0 replies; 4+ messages in thread
From: Thorsten Jolitz @ 2013-11-08 9:45 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-11-08 9:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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).