From: James TD Smith <ahktenzero@mohorovi.cc>
To: emacs-orgmode@gnu.org
Subject: Re: RFC: Improvements to org-remember
Date: Sun, 30 Nov 2008 02:32:24 +0000 [thread overview]
Message-ID: <20081130023224.GH62148@yog-sothoth.mohorovi.cc> (raw)
In-Reply-To: <1E819EC5-8CAF-4BC9-AAA6-E99784F8DE2A@uva.nl>
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/ahktenzero@mohorovi.cc>-|
next prev parent reply other threads:[~2008-11-30 2:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-23 23:25 RFC: Improvements to org-remember James TD Smith
2008-11-24 0:23 ` Samuel Wales
2008-11-24 10:02 ` James TD Smith
2008-11-24 19:29 ` Samuel Wales
2008-11-24 21:11 ` Carsten Dominik
2008-11-24 21:41 ` Samuel Wales
2008-11-30 1:03 ` James TD Smith
2008-12-03 20:36 ` Samuel Wales
2008-11-24 3:05 ` Sebastian Rose
2008-11-24 3:09 ` Sebastian Rose
2008-11-24 8:58 ` Carsten Dominik
2008-11-24 16:57 ` Russell Adams
2008-11-25 11:46 ` James TD Smith
2008-11-25 19:27 ` Carsten Dominik
2008-11-30 2:32 ` James TD Smith [this message]
2008-12-03 6:42 ` Carsten Dominik
2008-12-12 14:48 ` Carsten Dominik
2008-11-24 9:50 ` Ben Alexander
2008-11-30 2:00 ` James TD Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081130023224.GH62148@yog-sothoth.mohorovi.cc \
--to=ahktenzero@mohorovi.cc \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).