From mboxrd@z Thu Jan 1 00:00:00 1970 From: James TD Smith Subject: Re: RFC: Improvements to org-remember Date: Sun, 30 Nov 2008 02:32:24 +0000 Message-ID: <20081130023224.GH62148@yog-sothoth.mohorovi.cc> References: <20081123232557.GC62148@yog-sothoth.mohorovi.cc> <20081125114619.GE62148@yog-sothoth.mohorovi.cc> <1E819EC5-8CAF-4BC9-AAA6-E99784F8DE2A@uva.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6c6p-0008AQ-CQ for emacs-orgmode@gnu.org; Sat, 29 Nov 2008 21:32:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6c6m-00089r-O5 for emacs-orgmode@gnu.org; Sat, 29 Nov 2008 21:32:30 -0500 Received: from [199.232.76.173] (port=45478 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6c6m-00089o-IL for emacs-orgmode@gnu.org; Sat, 29 Nov 2008 21:32:28 -0500 Received: from 81-86-40-42.dsl.pipex.com ([81.86.40.42]:56015 helo=yog-sothoth.mohorovi.cc) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L6c6l-0000QQ-RS for emacs-orgmode@gnu.org; Sat, 29 Nov 2008 21:32:28 -0500 Received: from yog-sothoth.mohorovi.cc (localhost [127.0.0.1]) by yog-sothoth.mohorovi.cc (8.14.2/8.14.2) with ESMTP id mAU2WOFb005468 for ; Sun, 30 Nov 2008 02:32:25 GMT (envelope-from ahktenzero@mohorovi.cc) Received: (from ahktenzero@localhost) by yog-sothoth.mohorovi.cc (8.14.2/8.14.2/Submit) id mAU2WOjU005467 for emacs-orgmode@gnu.org; Sun, 30 Nov 2008 02:32:24 GMT (envelope-from ahktenzero@mohorovi.cc) Content-Disposition: inline In-Reply-To: <1E819EC5-8CAF-4BC9-AAA6-E99784F8DE2A@uva.nl> 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: emacs-orgmode@gnu.org Hi Carsten, On 2008-11-25 20:27:31(+0100), Carsten Dominik wrote: > On Nov 25, 2008, at 12:46 PM, James TD Smith wrote: > > On 2008-11-24 09:58:49(+0100), Carsten Dominik wrote: > >> On Nov 24, 2008, at 12:25 AM, James TD Smith wrote: > >>> I think it would make sense to move the code to get values for remember > >>> expansions out of `org-remember-apply-template' into separate functions. > >>> These could be added to an association list indexed by the expansion > >>> character. This would also make it easier to add new expansions. > >> > >> Yes. However, it is necessary to keep the sequence of handling the escapes, > >> in particular first filling in all non-interactive ones, and only then > >> doing the interactive ones. > > > > I'll probably use two lists, one of interactive escapes and one of > > non-interactive escapes. > > I believe it makes some sense to fill in the interactive parts in place, while > the partially filled template is visible. The context may help. I agree. I'm not going to change that. > >>> ** Plists for remember templates > >> > >> Ah, this will be a big relieve when it is implemented, should have been > >> like this from the start. > >> > >>> I want to change the format of remember templates to use plists. This is > >>> to allow introducing a number of optional parameters to control the new > >>> features I want to add. Org uses plists elsewhere, for example in the > >>> #+OPTIONS: configuration header, and #+PLOT: lines, so the syntax should > >>> already be familiar to org users. > >>> > >>> I also think it would make sense to to move some options which are > >>> currently set using escapes outside of the template, specifically "%!" > >>> (store template immediately) and "%&" (jump to entry after storing). > >> > >> Yes, this wil be much better. > > > > I was thinking that maybe some other expansions should be moved into the > > template, specifically those which don't insert their values where the % > > expansion is. > > > > For example instead of > > ,---- > > | ("Video" ?v "* TOWATCH %^{Title} %^g%^{Type}p%^{Length}p%^{Year}" > > | "~/Personal/Video.org" top) > > `---- > > we could have > > ,---- > > | (?v :name "Video" "* TOWATCH %^{Title}" :tags file :properties > > | ("Type" "Length" "Year") :target "~/Personal/Video.org" :prepend t) > > `---- > > > > I think the latter is much better for adding properties, particularly if you > > want to have a template with a lot of them. > > This is an interesting idea. The TODO state could also be done in this way, > maybe offering the fast selection interface for TODO states. Yes. An expansion for TODO states might be useful as well. > >> While one could have a property for explicitly selecting a type like table > >> row or plain-list item or checkbox, it would also be possible to derive > >> this from the Remember buffer content automatically. Which method is > >> better? > > > > I think using the property would be easier to implement, but automatically > > figuring out what kind of entry to insert will be needed to handle entries > > without templates. > > Will we have entries without templates? Yes, for two reasons: freeform entry with the possibility of applying a template later (see my reply to Samuel Wales' suggestions), and so remember can be used to add non-org items (possibly with other remember handlers). > > I'd like two-key access for templates anyway; I have a number of similar > > templates which are scattered over the available keys and could be grouped > > together more logically with two stage selection. > > Hmm. I am not sure if the two-key selection code from the agenda can be easily > refactored for this case, so maybe we need to duplicate this functionality, or > re-write the selector for agenda custom commands. Is `org-agenda-get-restriction-and-command' the method I should be looking at? > >> Another option I would like to see is, how many empty lines should be > >> inserted before the entry. Because sometimes it is nice to have an empty > >> line between entries, and sometimes not. Default should be no empty lines. > > > > That should be easy to add. What about entries added before the current > > contents of the target headline? The blank lines would need to go after the > > newly inserted item to maintain the proper gap between it and the headline > > below it. > > I think it is sufficient to only specify the empty lines before the heading. > An entry that is inserted as the first child must then simply be inserted > directly after the heading and possibly timestamps/properties, so that any > empty lines *before* the already present sibling remain. Please do not change > this - throughout Org, it is the empty space *before* a headline that counts. OK. > > I think using a branch in the main repo makes sense as I can push to it when > > I have things which are ready for testing, and I keep using my own repo to > > sync work between my computers without worrying about breaking things for > > anyone testing the branch. > > > > I don't currently have an account on repo.or.cz, but I'll sign up and send > > you my details. I probably ought to sign up for Worg as well. > > Good. For Worg, you need to send mail to Bastien, not through emacs-orgmode, > but directly, he will this this faster than any mails going through the list. > > One additional proposal: Would it be useful, during the development phase, to > use a different customization variable, org-remember-templates-2 or so? This > would allow people to have a "safe" version of their templates to which they > can fall back if necessary, and to do all kinds of testing in the new > variable. When things are stabilized in the end, we just rename the new > variable to the old name and be done.... I'd prefer to have org-remember-templates-2 as an adjunct to the templates in org-remember-templates, so in the testing version you would get all the templates in that plus templates in org-remember-templates-2 (with templates in org-remember-templates-2 having priority). Templates in the current format should work in the new version. James -- |---|