Re: [Orgmode] RFC: Improvements to org-remember

[James TD Smith]

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

-- 
|-<James TD Smith>-<email/address@hidden>-|