From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: RFC: Improvements to org-remember Date: Wed, 3 Dec 2008 07:42:49 +0100 Message-ID: References: <20081123232557.GC62148@yog-sothoth.mohorovi.cc> <20081125114619.GE62148@yog-sothoth.mohorovi.cc> <1E819EC5-8CAF-4BC9-AAA6-E99784F8DE2A@uva.nl> <20081130023224.GH62148@yog-sothoth.mohorovi.cc> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7my7-0001T7-2H for emacs-orgmode@gnu.org; Wed, 03 Dec 2008 03:20:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7my5-0001Su-OI for emacs-orgmode@gnu.org; Wed, 03 Dec 2008 03:20:22 -0500 Received: from [199.232.76.173] (port=43862 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7my5-0001Sr-GJ for emacs-orgmode@gnu.org; Wed, 03 Dec 2008 03:20:21 -0500 Received: from fg-out-1718.google.com ([72.14.220.153]:54768) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L7my5-0007op-21 for emacs-orgmode@gnu.org; Wed, 03 Dec 2008 03:20:21 -0500 Received: by fg-out-1718.google.com with SMTP id l26so2599879fgb.30 for ; Wed, 03 Dec 2008 00:20:20 -0800 (PST) In-Reply-To: <20081130023224.GH62148@yog-sothoth.mohorovi.cc> 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: James TD Smith Cc: emacs-orgmode@gnu.org On Nov 30, 2008, at 3:32 AM, James TD Smith wrote: > 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? Yes, this is where two-key commands would have to be implemented. > > >>>> 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. OK, sure, this is even better. - Carsten > > > James > > -- > |---| > > > _______________________________________________ > 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