From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Moynihan Subject: Re: Restricting the agenda to the current subtree Date: Fri, 30 Nov 2007 16:33:32 +0000 Message-ID: <47503B5C.4070107@calicojack.co.uk> References: <47471647.8000308@calicojack.co.uk> <474D4F98.1020505@calicojack.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iy8oP-00085h-81 for emacs-orgmode@gnu.org; Fri, 30 Nov 2007 11:33:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iy8oO-000854-Ml for emacs-orgmode@gnu.org; Fri, 30 Nov 2007 11:33:56 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iy8oO-00084z-HY for emacs-orgmode@gnu.org; Fri, 30 Nov 2007 11:33:56 -0500 Received: from storm.bpweb.net ([83.223.106.8]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Iy8oO-0007ps-A4 for emacs-orgmode@gnu.org; Fri, 30 Nov 2007 11:33:56 -0500 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org Carsten Dominik wrote: > On Nov 28, 2007 12:23 PM, Rick Moynihan 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.