Re: RFC: Improvements to org-remember

From: Carsten Dominik <dominik@science.uva.nl>
To: James TD Smith <ahktenzero@mohorovi.cc>
Cc: emacs-orgmode@gnu.org
Subject: Re: RFC: Improvements to org-remember
Date: Wed, 3 Dec 2008 07:42:49 +0100	[thread overview]
Message-ID: <EB40EB3E-48DD-4E51-AABD-7C854D77E011@uva.nl> (raw)
In-Reply-To: <20081130023224.GH62148@yog-sothoth.mohorovi.cc>

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
>
> -- 
> |-<James TD Smith>-<email/ahktenzero@mohorovi.cc>-|
>
>
> _______________________________________________
> 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