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/[EMAIL PROTECTED]>-|
_______________________________________________
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
_______________________________________________
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