* Restricting the agenda to the current subtree
@ 2007-11-23 18:04 Rick Moynihan
2007-11-27 14:19 ` Bastien
[not found] ` <acf852aa0711271028m24c3d944wdde1481e4f7c9fa9@mail.gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Rick Moynihan @ 2007-11-23 18:04 UTC (permalink / raw)
To: emacs-orgmode
I've just discovered that you can restrict the agenda view to the
current subtree, and I think I'm going to find this very useful!
Firstly is it possible to bind this to a simple key-chord though as I'm
finding
C-a < < a
A little unwieldy.
Also, how about implementing another "follow" command, that does the
opposite of following movements in the agenda view and displaying them
in the file. i.e. When enabled it uses the org-goto interface to follow
movements within the file and display the restricted agenda view in
another window.
This could also be coupled with other queries defined in the agenda yet
would narrow their focus to the currently browsed subtree.
I'm not sure if it's a crazy idea or not but I think it might be useful.
R.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Restricting the agenda to the current subtree 2007-11-23 18:04 Restricting the agenda to the current subtree Rick Moynihan @ 2007-11-27 14:19 ` Bastien 2007-11-28 10:52 ` Rick Moynihan [not found] ` <acf852aa0711271028m24c3d944wdde1481e4f7c9fa9@mail.gmail.com> 1 sibling, 1 reply; 7+ messages in thread From: Bastien @ 2007-11-27 14:19 UTC (permalink / raw) To: emacs-orgmode Hi Rick, Rick Moynihan <rick@calicojack.co.uk> writes: > Firstly is it possible to bind this to a simple key-chord though as I'm > finding > > C-a < < a > > A little unwieldy. You can still press `C-c a 0' instead -- this keybinding is kept for backward compatibility. > Also, how about implementing another "follow" command, that does the > opposite of following movements in the agenda view and displaying them > in the file. i.e. When enabled it uses the org-goto interface to follow > movements within the file and display the restricted agenda view in > another window. I'm not sure to understand. Do you mean: while browsing an org file with org-goto, display the current entry in an agenda view when available? Maybe you could give a try to `org-toc.el': when the "info mode" is on and you are browsing the table of contents, it displays any timestamp the entry may have (which I find more "light" than building agenda views successively...) -- Bastien ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Restricting the agenda to the current subtree 2007-11-27 14:19 ` Bastien @ 2007-11-28 10:52 ` Rick Moynihan 0 siblings, 0 replies; 7+ messages in thread From: Rick Moynihan @ 2007-11-28 10:52 UTC (permalink / raw) To: Bastien; +Cc: emacs-orgmode Bastien wrote: > Hi Rick, > > Rick Moynihan <rick@calicojack.co.uk> writes: > >> Firstly is it possible to bind this to a simple key-chord though as I'm >> finding >> >> C-a < < a >> >> A little unwieldy. > > You can still press `C-c a 0' instead -- this keybinding is kept for > backward compatibility. > >> Also, how about implementing another "follow" command, that does the >> opposite of following movements in the agenda view and displaying them >> in the file. i.e. When enabled it uses the org-goto interface to follow >> movements within the file and display the restricted agenda view in >> another window. > > I'm not sure to understand. > > Do you mean: while browsing an org file with org-goto, display the > current entry in an agenda view when available? Yes, but an appropriately filtered agenda view to the current subtree. Maybe you could give a > try to `org-toc.el': when the "info mode" is on and you are browsing the > table of contents, it displays any timestamp the entry may have (which I > find more "light" than building agenda views successively...) Thanks for this, when I find the time I'll take a look at it. R. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <acf852aa0711271028m24c3d944wdde1481e4f7c9fa9@mail.gmail.com>]
* Re: Restricting the agenda to the current subtree [not found] ` <acf852aa0711271028m24c3d944wdde1481e4f7c9fa9@mail.gmail.com> @ 2007-11-28 17:41 ` Rick Moynihan [not found] ` <474D4F98.1020505@calicojack.co.uk> 1 sibling, 0 replies; 7+ messages in thread From: Rick Moynihan @ 2007-11-28 17:41 UTC (permalink / raw) To: emacs-orgmode Carsten Dominik wrote: > On 11/23/07, Rick Moynihan <rick@calicojack.co.uk> wrote: >> I've just discovered that you can restrict the agenda view to the >> current subtree, and I think I'm going to find this very useful! >> >> Firstly is it possible to bind this to a simple key-chord though as I'm >> finding >> >> C-a < < a >> >> A little unwieldy. >> >> Also, how about implementing another "follow" command, that does the >> opposite of following movements in the agenda view and displaying them >> in the file. i.e. When enabled it uses the org-goto interface to follow >> movements within the file and display the restricted agenda view in >> another window. >> >> This could also be coupled with other queries defined in the agenda yet >> would narrow their focus to the currently browsed subtree. >> >> I'm not sure if it's a crazy idea or not but I think it might be useful. > > I for one do find this idea useful. Some way to lock all agenda > commands to the current subtree or file, until this lock is removed > again. I am not sure if I'd like the agenda to automatically follow > while I am moving through a file - this would be slow since agenda > construction does need a finite amount of time. Would it necessarily need to be so slow? It seems to me that edits are pretty much prohibited during an org-goto, so could you not just build the agenda once for the org-goto session and then filter it to the subtree? Could that speed it up more, or is it the filtering itself which is slow? I appreciate this might not be the case, or it might not be possible to architect the system to support this. Either way my mentioning of follow was more to indicate the interaction style and browsable nature it encourages, rather than the instantaneous nature of it. Pressing a single key to rebuild the agenda view for the current subtree would be fantastic and probably easier for you to implement :-) > I have also been thinking about usind the sidebar engine to display > something like omnifocus' side bar hierarchy and have mouse clicks > restrict the agenda stuff to the context. But I guess this is not > needed since we have an outlining buffer anyway... Interesting... It seems that the org-goto idea and your sidebuffer idea are similar. You're right that it might not be needed, but it seems that it might be quite nice to render user-defined subtrees in the sidebar, as a kind of shortcut to current projects or outlines of concern. You're right that it might not be adding any real functionality, but I can see that it might make navigating easier/quicker for some users. One potential problem is that org seems to encourage outlines to be titles (and consequently they're quite long). If this were to be browseable in a sidebar you might want represent them with aliases or shortened names, property drawers would be an obvious way to implement this. R. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <474D4F98.1020505@calicojack.co.uk>]
* Re: Restricting the agenda to the current subtree [not found] ` <474D4F98.1020505@calicojack.co.uk> @ 2007-11-30 14:32 ` Carsten Dominik 2007-11-30 16:33 ` Rick Moynihan 0 siblings, 1 reply; 7+ messages in thread From: Carsten Dominik @ 2007-11-30 14:32 UTC (permalink / raw) To: Rick Moynihan, emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 3359 bytes --] On Nov 28, 2007 12:23 PM, Rick Moynihan <rick@calicojack.co.uk> wrote: > Carsten Dominik wrote: > > I for one do find this idea useful. Some way to lock all agenda > > commands to the current subtree or file, until this lock is removed > > again. I am not sure if I'd like the agenda to automatically follow > > while I am moving through a file - this would be slow since agenda > > construction does need a finite amount of time. > > Would it necessarily need to be so slow? It seems to me that edits are > pretty much prohibited during an org-goto, so could you not just build > the agenda once for the org-goto session and then filter it to the > subtree? Could that speed it up more, or is it the filtering itself > which is slow? I appreciate this might not be the case, or it might not > be possible to architect the system to support this. Org-mode does not keep an internal structure of the data it contains. Each time information is needed, the original plain text files are scanned. This is the good an bad of plain text files. In principle one could of course make an internal structure, index it in the appropriate ways and then create many different displays fast. But that would require a rewrite of the entire agenda code, and intensive bookkeeping to make sure updates happen when they are needed. Since Org-mode is committed to the plain text format, this is not going to happen. Either way my mentioning of follow was more to indicate the interaction > style and browsable nature it encourages, rather than the instantaneous > nature of it. Pressing a single key to rebuild the agenda view for the > current subtree would be fantastic and probably easier for you to > implement :-) > > > I have also been thinking about using the sidebar engine to display > > something like omnifocus' side bar hierarchy and have mouse clicks > > restrict the agenda stuff to the context. But I guess this is not > > needed since we have an outlining buffer anyway... > > Interesting... It seems that the org-goto idea and your sidebuffer idea > are similar. You're right that it might not be needed, but it seems > that it might be quite nice to render user-defined subtrees in the > sidebar, as a kind of shortcut to current projects or outlines of > concern. You're right that it might not be adding any real > functionality, but I can see that it might make navigating > easier/quicker for some users. One potential problem is that org seems > to encourage outlines to be titles (and consequently they're quite > long). If this were to be browseable in a sidebar you might want > represent them with aliases or shortened names, property drawers would > be an obvious way to implement this. I have tried this, and it actually works reasonably well for me. I will put sidebar support into org-mode, so that you can drill into an org-mode file (one or two levels deep, maybe) directly from the sidebar. I could also have hot keys in the sidebar that will restrict the agenda to the file or subtree the cursor points to. If combined with an immediate update of the agenda (if it is visible), this might get close to what you are looking for. Together with a command in an Org-mode buffer to restrict to the local subtree/file and immediately update the agenda. I think this is going to be *very* nice, thanks for the idea! - Carsten [-- Attachment #1.2: Type: text/html, Size: 4052 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Restricting the agenda to the current subtree 2007-11-30 14:32 ` Carsten Dominik @ 2007-11-30 16:33 ` Rick Moynihan 2007-11-30 18:38 ` Carsten Dominik 0 siblings, 1 reply; 7+ messages in thread From: Rick Moynihan @ 2007-11-30 16:33 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode Carsten Dominik wrote: > On Nov 28, 2007 12:23 PM, Rick Moynihan <rick@calicojack.co.uk> wrote: > >> Carsten Dominik wrote: >>> I for one do find this idea useful. Some way to lock all agenda >>> commands to the current subtree or file, until this lock is removed >>> again. I am not sure if I'd like the agenda to automatically follow >>> while I am moving through a file - this would be slow since agenda >>> construction does need a finite amount of time. >> Would it necessarily need to be so slow? It seems to me that edits are >> pretty much prohibited during an org-goto, so could you not just build >> the agenda once for the org-goto session and then filter it to the >> subtree? Could that speed it up more, or is it the filtering itself >> which is slow? I appreciate this might not be the case, or it might not >> be possible to architect the system to support this. > > > Org-mode does not keep an internal structure of the data it contains. > Each time information is needed, the original plain text files > are scanned. This is the good an bad of plain text files. > In principle one could of course make an internal structure, index it > in the appropriate ways and then create many different displays fast. > But that would require a rewrite of the entire agenda code, and > intensive bookkeeping to make sure updates happen when > they are needed. Since Org-mode is committed to the > plain text format, this is not going to happen. > > Either way my mentioning of follow was more to indicate the interaction >> style and browsable nature it encourages, rather than the instantaneous >> nature of it. Pressing a single key to rebuild the agenda view for the >> current subtree would be fantastic and probably easier for you to >> implement :-) >> >>> I have also been thinking about using the sidebar engine to display >>> something like omnifocus' side bar hierarchy and have mouse clicks >>> restrict the agenda stuff to the context. But I guess this is not >>> needed since we have an outlining buffer anyway... >> Interesting... It seems that the org-goto idea and your sidebuffer idea >> are similar. You're right that it might not be needed, but it seems >> that it might be quite nice to render user-defined subtrees in the >> sidebar, as a kind of shortcut to current projects or outlines of >> concern. You're right that it might not be adding any real >> functionality, but I can see that it might make navigating >> easier/quicker for some users. One potential problem is that org seems >> to encourage outlines to be titles (and consequently they're quite >> long). If this were to be browseable in a sidebar you might want >> represent them with aliases or shortened names, property drawers would >> be an obvious way to implement this. > > > I have tried this, and it actually works reasonably well for me. > I will put sidebar support into org-mode, so that you can drill > into an org-mode file (one or two levels deep, maybe) directly > from the sidebar. I could also have hot keys in the sidebar > that will restrict the agenda to the file or subtree the cursor > points to. If combined with an immediate update of the agenda > (if it is visible), this might get close to what you are looking for. > Together with a command in an Org-mode buffer to restrict to the > local subtree/file and immediately update the agenda. Cool, it sounds like it's going to be good. I can't say I've used the speedbar much but I look forward to giving it a shot with org-mode (which is the main reason I use Emacs anyway :-) ) My only concern about using the speedbar is that it'll take up more screen real estate than the equivalent idea using org-goto, as you'll have the speedbar + the fileview + the agenda on screen. This is perhaps a concern for me, as I recently got one of the tiny asus eeepc's. I wrote some opinions on it here: http://sourcesmouth.co.uk/blog/Forget-the-Linux-Desktop-it-s-the-Linux-Laptop-that-matters.html It's an awesome machine that works great as a portable note taking device (org-mode and Emacs were the first things I installed). Anyway it's working really well for me but the 7" screen means you don't want much clutter. > I think this is going to be *very* nice, thanks for the idea! No probs! Thanks again for org-mode, and being so willing to implement our ideas. R. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Restricting the agenda to the current subtree 2007-11-30 16:33 ` Rick Moynihan @ 2007-11-30 18:38 ` Carsten Dominik 0 siblings, 0 replies; 7+ messages in thread From: Carsten Dominik @ 2007-11-30 18:38 UTC (permalink / raw) To: Rick Moynihan; +Cc: emacs-orgmode On 11/30/07, Rick Moynihan <rick@calicojack.co.uk> wrote: > > Cool, it sounds like it's going to be good. I can't say I've used the > speedbar much but I look forward to giving it a shot with org-mode > (which is the main reason I use Emacs anyway :-) ) > > My only concern about using the speedbar is that it'll take up more > screen real estate than the equivalent idea using org-goto, as you'll > have the speedbar + the fileview + the agenda on screen. Speedbar will be most useful it you have a number of files you want to drill into and restrict to. If it is only a single file, you can simply do it directly from the file itself. Start from OVERVIEW and drill into the outline, and then restrict the agenda to any sybtree you like. I don't really see what advantage the org-goto interface would give (sorry, I had overlooked this particular suggestion in your initial post)... - Carsten ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-11-30 18:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-23 18:04 Restricting the agenda to the current subtree Rick Moynihan
2007-11-27 14:19 ` Bastien
2007-11-28 10:52 ` Rick Moynihan
[not found] ` <acf852aa0711271028m24c3d944wdde1481e4f7c9fa9@mail.gmail.com>
2007-11-28 17:41 ` Rick Moynihan
[not found] ` <474D4F98.1020505@calicojack.co.uk>
2007-11-30 14:32 ` Carsten Dominik
2007-11-30 16:33 ` Rick Moynihan
2007-11-30 18:38 ` Carsten Dominik
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).