emacs-orgmode
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carsten Dominik
Subject: Re: [Orgmode] RFC: Improvements to org-remember
Date: Tue, 25 Nov 2008 20:27:31 +0100 
Hi James,

On Nov 25, 2008, at 12:46 PM, James TD Smith wrote:


Hi Carsten,

On 2008-11-24 09:58:49(+0100), Carsten Dominik wrote:


Hi James, I do like all this.  A few comments:

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.





** 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.
For backwards compatibility, the current template format would still be supported, but the additional options would not be available. Defaults for the extra parameters would be set so if they are not present the templates 
would work as they do currently.

The current options would be represented as below:
- :template :: the template itself
- :name :: the name of the template
- :target :: The :target parameter takes the place of the current
                  file and headline target specification. The parameter
                  specifies only the default target; all the other options will
                  remain available via numeric prefixes to C-c C-c. The
                  available options are:
 - "<filename>:<heading>" :: a file target. If the heading is
                                   omitted, a top-level heading will be created.
That should be a double colon, for symmetry with org-archive- location, 
and to avoid problems with Windows paths.


Yes, it was supposed to be a double colon.


* New features
** Adding non-headline items
For some time I have wanted to be able to use remember to add checklist entries and table rows as well as org headlines. To configure this, a :type parameter will be added to the template, which can be either headline (the 
default), list, checklist or table.

- Table rows.


This is an awesome idea, as are plain list items and checkboxes.
For plain list items, I guess the right thing would be to select the first plain list under the headline, there might be several. Also, the first table 
under a headline, in case there are more.
The plain list items would be added as direct children of the target headline. I'm not sure having a plain list item under a headline as a target makes sense, 

I agree, let's not go there.
but it could be implemented by changing the :target specification to allow specifying a path, so "test.org::Target::list item" would add the new entry as a child of the first list item. This would also remove the requirement for 
remember targets to have headlines which are unique in the file.
For tables it would have to be the first table under the headline, as I don't think there is a way of identifying a particular table in an org entry. Maybe we 
could use #+CAPTION, when it's been added?


Let's just go for the first table.  I think when one
makes a table the target of a remember process, it deserves
to be the only on under a heading.
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?
An extension to this would be to include a truncated copy of the table in the remember buffer, with just the headers (and possibly formulae) from the target table, so the user could add multiple lines in the remember buffer 
and then add them to the table.


I guess you mean here to retrive that truncated copy from the target
location?


Yes.


- Checklist entries

 I use checklists a lot for breaking down tasks. Being able to add
checklist entries using remember, with the clocked task as a target, would make it possible to do this without having to switch away from the 
 buffer I was working in.

- Plain list entries.
It also be useful to be able to add plain list items. This would be like 
 a more featureful version of `org-add-note', with the full range of
 remember expansions available.


I would like to add here

 - Non-org items, to simply be appended to a file.
   I believe Russel Adams had a request about this, on how to use
   remember to add entries to a ledger file, for which using a
template would be nice. The problem is that Org currently requires 
   the target file to be in Org-mode - for good reasons, because all
   kinds of Org stuff will be executed when the new entry is added.
   We should allow for the results of a remember template to be added
   to a non-Org file.
- With these new options, will we need to have optional two-key access to templates, or is single key enough? Maybe only at a later stage if it is 
   felt that this is really necessary.
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.
While we're on the subject, I'm not sure the way org-select-remember- template currently handles keys which don't correspond to a template is right; I think it would make more sense to keep asking the user for a template until they select a 
valid one, or choose a 'no template' option.


I am OK with changing this, it was mere laziness on
my side that it does not work like this right now.


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.


* Development plan

It will take me quite a while to implement all this so I plan on
doing it in
stages. After the preliminary work is done, each new feature will be
implemented in a separate git branch which can be merged into the
master
branch when it's finished and properly tested. I'll post an update
to the list
when each feature is ready for testing.


Yes, this sounds good.  The one thing we need to keep in mind is
that a significant number of people by now really depend on the
templates working, so we cannot break org-remember at any stage for
the normal user. So my proposal would be to create a new branch in our main repository, a branch James will be the only one to push to, using 
patches and ideas from the rest of us.  If this branch is frequently
rebased to the main Org-mode master, testers could easily and without
loss of other new features switch between the Org master and the
remember branch.

Does that sound good, or would you prefer to use your own repo
for this, James?  I believe the number of testers will be larger
if you use our main repo.  If you give me your user name on
repo.or.cz, I will give you push access.
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....


- Carsten
reply via email to
[Prev in Thread] Current Thread [Next in Thread]