From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: RFC: Improvements to org-remember Date: Tue, 25 Nov 2008 20:27:31 +0100 Message-ID: <1E819EC5-8CAF-4BC9-AAA6-E99784F8DE2A@uva.nl> References: <20081123232557.GC62148@yog-sothoth.mohorovi.cc> <20081125114619.GE62148@yog-sothoth.mohorovi.cc> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L53ZS-0001sq-IQ for emacs-orgmode@gnu.org; Tue, 25 Nov 2008 14:27:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L53ZQ-0001se-P0 for emacs-orgmode@gnu.org; Tue, 25 Nov 2008 14:27:37 -0500 Received: from [199.232.76.173] (port=47216 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L53ZQ-0001sb-LO for emacs-orgmode@gnu.org; Tue, 25 Nov 2008 14:27:36 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]:5400) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L53ZP-0001dp-Ox for emacs-orgmode@gnu.org; Tue, 25 Nov 2008 14:27:36 -0500 Received: by nf-out-0910.google.com with SMTP id c7so62024nfi.26 for ; Tue, 25 Nov 2008 11:27:34 -0800 (PST) In-Reply-To: <20081125114619.GE62148@yog-sothoth.mohorovi.cc> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: James TD Smith Cc: emacs-orgmode@gnu.org 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: >>> - ":" :: 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