emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.


From: Karl Fogel
Subject: [O] [PROPOSAL] Use prefix arg to control scope of org-narrow-to-subtree.
Date: Wed, 24 Apr 2019 14:05:10 -0500

Hi.  This is a feature proposal -- if the consensus is that it would be 
welcomed, I'm happy to code it.  I just didn't want to take the time to write 
it if there's no chance for it to be accepted upstream (since I don't want to 
be maintaining my own personal branch of Org Mode).

It would be useful if `org-narrow-to-subtree' could optionally narrow to the 
next subtree(s) up, rather than only to the subtree point is currently in.  For 
example, assume this text:

   * This is the first level
   Some text here.
   ** This is the second level
   Some other text here.
   *** This is the third level
   By now we all know this song.
   It is such a pretty song.
   **** This is the fourth level
   But do we have to sing it all day long?
   This car trip is getting incong
   ***** This is the fifth level
   ruously unrhymed.

Further assume that point is on the "c" of "car trip".  

In the current Org Mode, if you type `C-x n s', it will narrow to the 
fourth-level subtree (with the fifth level included in the narrowed buffer, of 
course).

Since `org-narrow-to-subtree' takes no arguments at all right now, it's 
conveniently ripe for improvement :-).

My proposal is for each raw prefix arg (each `C-u' prefix) to expand the 
narrowing level outward/upward by one.  So in the above situation:

  - `C-u C-x n s' would narrow to the third-level subtree

  - `C-u C-u C-x n s' would narrow to the second-level subtree

And so on.

If you offer too many `C-u's, such that the narrowing would be wider than the 
current surrounding first-level subtree, then there are two possible ways we 
could handle it:

1) Extra `C-u's are ignored -- just narrow to surrounding 1st-level subtree.

2) Throw an error.

I prefer (1), because it would be the more useful behavior, even though (2) 
would be easier to implement (since `org-back-to-heading' already throws the 
error).  However, I'd welcome others' feedback on that question, or on any 
other aspect of this proposal.

Best regards,
-Karl



reply via email to

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