Re: [Orgmode] RFC: Improvements to org-remember
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
Re: [Orgmode] RFC: Improvements to org-remember
Hi James, Parts snipped. James TD Smith [EMAIL PROTECTED] wrote: On 2008-11-24 14:41:00(-0700), Samuel Wales wrote: + respect pop-up-windows Could you explain this in more detail? That variable controls whether the window gets split. Some people prefer buffer-creating commands to act like c-x 4 b while others prefer that the whole window be used. Those who use somewhat large fonts need the latter because splitting the window makes small windows. It does not seem to be possible to change org-remember's behavior with same-window-buffer-names or -regexps. That's about all I know about it. A dedicated variable would be OK. + if org-remember does not recognize the type, abort completely Personally I'd prefer it to keep asking for a valid template if you enter a character that doesn't correspond I like your proposal even better. Ideally ^G and perhaps esc esc esc will get you back to where you were before. + org-remember-templates takes a character can it take a function key? It would be possible to add this. Do you specifically want to use the F-keys, or have you just run out of keys for templates? I'm planning on adding two-stage selection for remember templates, which will make it possible to have many more templates. If possible, it would be nice if it were like emacs key bindings. Function keys can be surprisingly useful. + emacs-w3m tight integration with org-mode - might be interesting to use an org-mode file to store bookmarks. this would require changing the way bookmarks are added, to store them in a way similar to org-remember. I like the idea of using org-mode to store bookmarks. I use org-mode to keep track of things I want to read online, using a remember template '(Web reading ?w * TOREAD %^L\n%U %k\n%? ~/Personal/Web.org Web sites to read) which I use to add items to my reading list. I also have the following in my .emacs: which fills in the descriptions for links with the title from the retrieved web page. IMO it would be good to have this stuff integrated as org code, and, if the user sets, to replace the relevant keys (such as v) in w3m. Sounds like all the code is there. There are useful possibilities here. Remember could then use ido to choose where in the bookmark tree, ideally creating a parent headline if it does not exist. Or just go to a default location to be refiled later. Or offer places where you have bookmarked stuff before. The best part is that you can have all of your bookmarks in your org outline hierarchy where they belong. If they are tagged as bookmarks, then they show up in an agenda command as a nice sparse tree of bookmarks. Then you can call w3m, or whatever else, from there. No need to keep a separate bookmark file. This would be easier to use than the dedicated w3m bookmark mechanism. And it would work for files and directories also. You can bookmark some code that you are working on, if you want. Remember seems like the right place to do most of this. - Perhaps antenna can also be integrated with org-mode. Extension #1 to the bookmark idea. Antenna is a way of keeping up with site changes. In w3m, it is a separate command from bookmarks, but there is no reason that both antenna and bookmarks could not use the same mechanism. In org, this would be powerful. For example, a bookmark could have properties, and among those properties would be the site's last-modified timestamp or your last-checked timestamp. Then without visiting the pages you can run a command to see which pages have changed. Where remember comes in is that remember helps you store those bookmarks. You might want to limit the scope of your code, but I thought I'd propose it anyway in case there is interest. The bookmark idea is much more important than antenna. + org merge org-annotate-file with remember code to allow annotating anything Have you looked at org-registry.el in contrib? The `org-registry-show' function will list any org files which have links to the current buffer. Extension #2 to the bookmark idea. My idea is to always have annotations available for emacs-w3m, dired, files, like org-annotate-file, just with more modes. You can see in the mode line that whatever buffer you are in has an annotation, and you can make an annotation. You can also go to the annotation. The annotations are stored in an org file anywhere in the hierarchy. Thus, if you want, annotations on a doctor's web site can be stored in the entry for that doctor that is in your org file. If you visit that web site from any source, even Google, the mode line says that it is annotated. Then you can pull up that entry with a command. Likewise with files or dired or whatever. For example, you can comment org.el or /etc/passwd without having to modify them. Remember code seems a plausible place to arrange for choosing a location and putting a note into it. Annotations are like bookmarks with text that also go the other
Re: [Orgmode] RFC: Improvements to org-remember
Hi Samuel, I wasn't expecting this many ideas, thanks. There are some great suggestions here, though I think some of them are outside the scope of what I am planning on doing. On 2008-11-24 14:41:00(-0700), Samuel Wales wrote: + respect pop-up-windows Could you explain this in more detail? + if the target file for org-remember is already known use the control variables from that file that way you can have your todo sequence available I'm definately adding this. Perhaps there should also be a parameter to set the todo keywords to use for templates which don't have a known target. + if org-remember does not recognize the type, abort completely Personally I'd prefer it to keep asking for a valid template if you enter a character that doesn't correspond to any of the templates as most of the time I do that I've hit the wrong key. You do know you can abort at the template selection stage with C-g? + org-remember-templates takes a character can it take a function key? It would be possible to add this. Do you specifically want to use the F-keys, or have you just run out of keys for templates? I'm planning on adding two-stage selection for remember templates, which will make it possible to have many more templates. + org-remember should be reentrant able to call itself from inside itself if you have a note you want to add that is not related to the one you are adding. This is a limitation of remember itself, not the org remember handler. It would be useful to be able to have multiple remember sessions running at once. + emacs-w3m tight integration with org-mode - might be interesting to use an org-mode file to store bookmarks. this would require changing the way bookmarks are added, to store them in a way similar to org-remember. I like the idea of using org-mode to store bookmarks. I use org-mode to keep track of things I want to read online, using a remember template '(Web reading ?w * TOREAD %^L\n%U %k\n%? ~/Personal/Web.org Web sites to read) which I use to add items to my reading list. I also have the following in my .emacs: ,[ link description function ] | (defun ahkt-link-description (link desc) | Link description generator for orgmode | (cond ((string-match https?: link) | (with-temp-buffer | (w3m-retrieve link) | (w3m-region (point-min) (point-max)) | (if (string= text/html (w3m-content-type link)) | (replace-regexp-in-string [ \t]+ | (replace-regexp-in-string | \\(\n\\| \\) | (w3m-current-title)) | ((string-match file:\\([^:]+\\)::\\(.+\\) link) | (let ((search (match-string-no-properties 2 link)) | (filename | (car (last | (split-string (match-string-no-properties 1 link) /) | (format %s: %s filename search))) | ((string-match file:\\([^:]+\\) link) |(car (last (split-string (match-string-no-properties 1 link) / | (t (or desc link | | (setq org-make-link-description-function 'ahkt-link-description) ` which fills in the descriptions for links with the title from the retrieved web page. - Perhaps antenna can also be integrated with org-mode. + org merge org-annotate-file with remember code to allow annotating anything also have a hook for opening files and w3m pages etc. that will print in the minibuffer this file/page/directory is annotated. press ... to see the annotation. Have you looked at org-registry.el in contrib? The `org-registry-show' function will list any org files which have links to the current buffer. + brainstorm: support asking for the template after the note was entered. this might complicate things too much. this is a tricky one to design, but the philosophy is that the time between having an idea and entering it should be minimal. choosing the template type is a cognitive burden before you enter the idea. so dedicate a remember shortcut to the concept of let me enter this now. c-c c-c, it asks you details like is this a todo item? and which file does it go to? you would have a remember template that allows for other remember templates to be chosen after you enter the note. ideally, it works like this: 1. call org-remember like that 2. enter note 3. c-c c-c 4. choose whether it's a note, journal, or shopping item 5. if it's note or journal, choose whether it's todo 6. if it's note or journal, choose tags (RET for none) 7. show completed buffer 8. y to accept; n to edit Personally I don't find selecting a template before making an entry a problem, but I can see what ypu're getting at. I think I can implement something which will do what you want. Suppose you have a set of templates as below: (Note ?n * %^s %i%? %^g Notes.org top) (Journal ?j *
Re: [Orgmode] RFC: Improvements to org-remember
Hi Ben, On 2008-11-24 11:50:53(+0200), Ben Alexander wrote: On 2008-Nov-24, at 04:25, [EMAIL PROTECTED] wrote: ** Automatic sorting Right now, I have a :SORT: property in my property drawer which looks like: :SORT: C-c S-6 p This is just a reminder to me for the key chord I need to play to get the sort I want. It's conveniently located near the headline and not too hard to open and read when I need to resort manually. It seems to me that having an hook like 'org-remember-after-filing would allow people to choose what kinds of updating they wanted done after a remember template was used. Mixing this with different types of templates may take some care: you don't want to run all the hooks inside a save-excursion if the point to to allow the hook to move point to a special place, but then all hooks would have to be written with that in mind. Perhaps the hooks should be run inside a (let ) with some official bindings for markers for the following: - org-remember-marker-to-beginning-of-new-text - org-remember-marker-to-end-of-new-text - org-remember-marker-to-parent-headline (perhaps most useful for non-headline remember templates) - org-remember-template-type This is basically how I was thinking of implementing the sort after filing (and the other post-commit update functions). But automatic sorting seems useful in many other contexts (like after scheduling or rescheduling an item, or changing priority, or editing the headline text) so perhaps some wishes/ideas from the list would be appropriate. Could org-mode take ownership of the :SORT: property for headlines, and have a org-sort-file-using-property (or a org-sort- headline-using-property) which could be added to hook lists where-ever the user wanted? I think it would be rather difficult to get automatic sorting working for editing the headline text. Org doesn't have hook lists for priority or scheduling changes either. I do like the idea of defining a default sort for a tree. We would need a :SORT_KEY: property as well, for sorting by property or table column, and a #+SORT: facility for file level sorting. The property could be used to determine a default sort for org-sort, with a new option added to select the default (maybe C-c ^ RET). Or is this too specific? Would it be nice to have plain lists (or checkboxed lists) have some kind of sort property too? Where could a user store this data so it could be easy to see but also easy to ignore. I'm not sure it's necessary to be able to do this in plain lists. If a plain list item has enough activity under it to need sorting on a regular basis its probably worth promoting it to a headline. -- |-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
Re: [Orgmode] RFC: Improvements to org-remember
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,
Re: [Orgmode] RFC: Improvements to org-remember
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.
** 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.
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,
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?
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.
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
Re: [Orgmode] RFC: Improvements to org-remember
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
Re: [Orgmode] RFC: Improvements to org-remember
Hi James, I do like all this. A few comments: On Nov 24, 2008, at 12:25 AM, James TD Smith wrote: I have a number of improvements to org-remember I am planning to implement. I have briefly discussed some of them with Carsten, and I thought I should post a detailed description here for discussion as I'm sure you will have ideas, suggestions and criticisms of the proposed changes. * Preliminary work ** Refactoring Carsten suggested that the remember handler could do with some refactoring before adding any new features, as it has gotten quite complicated in places. The longest functions are `org-remember-apply-template' and `org-remember-handler', so these are probably the best place to start. 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 o keep the sequence of handling the escapes, in particular first filling in all non-interactive ones, and only then doing the interactive ones. ** Unit tests If we can decide on a unit testing framework, this would be an ideal opportunity to add some test coverage, as I'll need to do extensive testing to ensure I don't break anything with the refactoring or the new features. I have some experience with unit testing using JUnit. ** 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. 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. - clock :: currently clocked task - current :: add under the the org headline where the point is. - interactive :: select a location interactively using the appropriate interface - function :: call function to get the target. The function can return either a marker, or a file/headline string. - :test :: a function, or list of major modes. The template is only available if the function returns true, or the current buffer is in one of the appropriate modes - :immediate :: replaces the %! escape; if t, the template is stored as soon as all escapes are replaced. - :jumpto :: replaces the % escape; if t, org jumps to the target location when the note is stored. * 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. 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? Currently if you want to use org to record periodic measurements (for example see the thread about using org to manage fitness training), you have to use properties and column view, which has a
Re: [Orgmode] RFC: Improvements to org-remember
Hi Samuel, On 2008-11-23 17:23:15(-0700), Samuel Wales wrote: All of this looks great. I especially like code integrity, plist syntax, and :prefix. Do you want more ideas for remember? Yes. Any suggestions for new features or ways the behaviour of the remember handler could be improved are most welcome. 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
Re: [Orgmode] RFC: Improvements to org-remember
On Mon, Nov 24, 2008 at 09:58:49AM +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: ... ** 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. Table rows would rock! 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. This style of adding to non-org files essentially makes remember a template generated data entry front end for arbitrary text. This would make the ledger file easy. My idea was to use remember to quickly enter time/expenses/mileage into my ledger. Thanks for your efforts! -- Russell Adams[EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ___ 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
Re: [Orgmode] RFC: Improvements to org-remember
On Mon, Nov 24, 2008 at 03:02, James TD Smith [EMAIL PROTECTED] wrote: Yes. Any suggestions for new features or ways the behaviour of the remember handler could be improved are most welcome. In addition to the stuff already mentioned: * TODO remember ideas *** respect pop-up-windows *** if the target file for org-remember is already known use the control variables from that file that way you can have your todo sequence available *** if org-remember does not recognize the type, abort completely *** org-remember should be reentrant able to call itself from inside itself if you have a note you want to add that is not related to the one you are adding. *** org-remember-templates takes a character can it take a function key? *** emacs-w3m tight integration with org-mode - might be interesting to use an org-mode file to store bookmarks. this would require changing the way bookmarks are added, to store them in a way similar to org-remember. - perhaps antenna can also be integrated with org-mode. [2008-09-20 Sat 18:26] *** org merge org-annotate-file with remember code to allow annotating anything also have a hook for opening files and w3m pages etc. that will print in the minibuffer this file/page/directory is annotated. press ... to see the annotation. [2008-10-27 Mon 22:02] [[http://orgmode.org/manual/Extensions-in-the-contrib-directory.html][Extensions in the contrib directory - The Org Manual]] *** brainstorm: support asking for the template after the note was entered. this might complicate things too much. this is a tricky one to design, but the philosophy is that the time between having an idea and entering it should be minimal. choosing the template type is a cognitive burden before you enter the idea. so dedicate a remember shortcut to the concept of let me enter this now. c-c c-c, it asks you details like is this a todo item? and which file does it go to? you would have a remember template that allows for other remember templates to be chosen after you enter the note. ideally, it works like this: 1. call org-remember like that 2. enter note 3. c-c c-c 4. choose whether it's a note, journal, or shopping item 5. if it's note or journal, choose whether it's todo 6. if it's note or journal, choose tags (RET for none) 7. show completed buffer 8. y to accept; n to edit nested plists? P.S. :prepend -- org-refile also needs this, separately from adding notes in reverse order. ___ 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
Re: [Orgmode] RFC: Improvements to org-remember
Hi Samuel, this is hard to read. Try, with the cursor on the first line: C-c @to select the subtree C-c C-e ato export to ASCII The result is more readable as an Email text. HTH - Carsten On Nov 24, 2008, at 8:29 PM, Samuel Wales wrote: On Mon, Nov 24, 2008 at 03:02, James TD Smith [EMAIL PROTECTED] wrote: Yes. Any suggestions for new features or ways the behaviour of the remember handler could be improved are most welcome. In addition to the stuff already mentioned: * TODO remember ideas *** respect pop-up-windows *** if the target file for org-remember is already known use the control variables from that file that way you can have your todo sequence available *** if org-remember does not recognize the type, abort completely *** org-remember should be reentrant able to call itself from inside itself if you have a note you want to add that is not related to the one you are adding. *** org-remember-templates takes a character can it take a function key? *** emacs-w3m tight integration with org-mode - might be interesting to use an org-mode file to store bookmarks. this would require changing the way bookmarks are added, to store them in a way similar to org-remember. - perhaps antenna can also be integrated with org-mode. [2008-09-20 Sat 18:26] *** org merge org-annotate-file with remember code to allow annotating anything also have a hook for opening files and w3m pages etc. that will print in the minibuffer this file/page/directory is annotated. press ... to see the annotation. [2008-10-27 Mon 22:02] [[http://orgmode.org/manual/Extensions-in-the-contrib-directory.html] [Extensions in the contrib directory - The Org Manual]] *** brainstorm: support asking for the template after the note was entered. this might complicate things too much. this is a tricky one to design, but the philosophy is that the time between having an idea and entering it should be minimal. choosing the template type is a cognitive burden before you enter the idea. so dedicate a remember shortcut to the concept of let me enter this now. c-c c-c, it asks you details like is this a todo item? and which file does it go to? you would have a remember template that allows for other remember templates to be chosen after you enter the note. ideally, it works like this: 1. call org-remember like that 2. enter note 3. c-c c-c 4. choose whether it's a note, journal, or shopping item 5. if it's note or journal, choose whether it's todo 6. if it's note or journal, choose tags (RET for none) 7. show completed buffer 8. y to accept; n to edit nested plists? P.S. :prepend -- org-refile also needs this, separately from adding notes in reverse order. ___ 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
Re: [Orgmode] RFC: Improvements to org-remember
I was trying to contribute while reducing typing to a minimum to reduce pain, and ended up making it hard for you to read. Apologies. == remember ideas i've gathered over the past few months = Author: tom [EMAIL PROTECTED] Date: 2008-11-24 14:38:05 MST Table of Contents = + respect pop-up-windows + if the target file for org-remember is already known use the control variables from that file that way you can have your todo sequence available + if org-remember does not recognize the type, abort completely + org-remember should be reentrant able to call itself from inside itself if you have a note you want to add that is not related to the one you are adding. + org-remember-templates takes a character can it take a function key? + emacs-w3m tight integration with org-mode - might be interesting to use an org-mode file to store bookmarks. this would require changing the way bookmarks are added, to store them in a way similar to org-remember. - perhaps antenna can also be integrated with org-mode. [2008-09-20 Sat 18:26] + org merge org-annotate-file with remember code to allow annotating anything also have a hook for opening files and w3m pages etc. that will print in the minibuffer this file/page/directory is annotated. press ... to see the annotation. [2008-10-27 Mon 22:02] [Extensions in the contrib directory - The Org Manual] + brainstorm: support asking for the template after the note was entered. this might complicate things too much. this is a tricky one to design, but the philosophy is that the time between having an idea and entering it should be minimal. choosing the template type is a cognitive burden before you enter the idea. so dedicate a remember shortcut to the concept of let me enter this now. c-c c-c, it asks you details like is this a todo item? and which file does it go to? you would have a remember template that allows for other remember templates to be chosen after you enter the note. ideally, it works like this: 1. call org-remember like that 2. enter note 3. c-c c-c 4. choose whether it's a note, journal, or shopping item 5. if it's note or journal, choose whether it's todo 6. if it's note or journal, choose tags (RET for none) 7. show completed buffer 8. y to accept; n to edit nested plists? -- Myalgic encephalomyelitis denialists are knowingly causing further suffering and death by opposing biomedical research on this fast-spreading serious disease. Do you care about the world? http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm ___ 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
[Orgmode] RFC: Improvements to org-remember
I have a number of improvements to org-remember I am planning to implement. I
have briefly discussed some of them with Carsten, and I thought I should post a
detailed description here for discussion as I'm sure you will have ideas,
suggestions and criticisms of the proposed changes.
* Preliminary work
** Refactoring
Carsten suggested that the remember handler could do with some refactoring
before adding any new features, as it has gotten quite complicated in places.
The longest functions are `org-remember-apply-template' and
`org-remember-handler', so these are probably the best place to start.
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.
** Unit tests
If we can decide on a unit testing framework, this would be an ideal
opportunity to add some test coverage, as I'll need to do extensive testing
to ensure I don't break anything with the refactoring or the new features. I
have some experience with unit testing using JUnit.
** Plists for remember templates
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).
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.
- clock :: currently clocked task
- current :: add under the the org headline where the point is.
- interactive :: select a location interactively using the appropriate
interface
- function :: call function to get the target. The function can return
either a marker, or a file/headline string.
- :test :: a function, or list of major modes. The template is only
available if the function returns true, or the current
buffer is in one of the appropriate modes
- :immediate :: replaces the %! escape; if t, the template is stored as soon
as all escapes are replaced.
- :jumpto :: replaces the % escape; if t, org jumps to the target location
when the note is stored.
* 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.
Currently if you want to use org to record periodic measurements (for
example see the thread about using org to manage fitness training), you
have to use properties and column view, which has a number of limitations
(speed, calculations). Being able to add table rows via remember would make
it much easier to do this.
The simplest implementation would use a template containing the appropriate
number of table columns, for example something like
| %U | %^{Value 1} | %^{Value 2} |
This would be added to the table at the appropriate position (depending on
the :prepend value for the template, and then formatted properly using
`org-table-align'.
The handler would also need to ensure that table formulae get updated
(increment row ranges etc) and that values are recalculated (if automatic
recalculation is enabled) after the line is added.
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.
- Checklist entries
Re: [Orgmode] RFC: Improvements to org-remember
All of this looks great. I especially like code integrity, plist syntax, and :prefix. Do you want more ideas for remember? ___ 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
Re: [Orgmode] RFC: Improvements to org-remember
James TD Smith [EMAIL PROTECTED] writes: * New features ** Adding non-headline items - Table rows. - Checklist entries - Plain list entries. ** Per-template insertion order ** Automatic sorting Yes :-) +1 Best, -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de ___ 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
