Re: [Orgmode] RFC: Improvements to org-remember
Hi James, two more feature requests for the new remember templates: - An :id switch which triggers automatic creation of an ID property You can create one by calling org-id-get-create in the entry, on the headline or below it. - A :link switch (or similarly named). When remember is called from an Org-file with this switch, it should create a link to the remember entry and store that link like org-store-link does. Thanks - Carsten ___ 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 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. An
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 sen
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 >
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. -- |---| ___ 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, 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
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: - ":" :: 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 deriv
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: > >- ":" :: 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 pos
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
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
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
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 2008-Nov-24, at 04:25, [EMAIL PROTECTED] wrote: From: James TD Smith <[EMAIL PROTECTED]> Date: 24 November 2008 01:25:57 EET To: emacs-orgmode@gnu.org Subject: [Orgmode] RFC: Improvements to org-remember * New features ** Adding non-headline items That's a fantastic idea! ** Updating completion statistics ** 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 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? 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.___ 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, 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 -- |---| ___ 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 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: - ":" :: 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 - :: 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 number of limi
Re: [Orgmode] RFC: Improvements to org-remember
James TD Smith <[EMAIL PROTECTED]> writes: > ** 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. As your the first one to really use unit tests, I suggest you use the framework you like the most or you trust the most, what ever. In the worst case, those tests have to be rewritten but this could happen anyway. As I read through the 'How you can help' thread [1], I found no basis for a decision. The only example code on Worg uses ert [2]. Could be a hint, since one of the active elisp people here used it at least once to write the example code (Eric?). Looks like simply choosing one and see how far it goes might be the way to go here. Regards, Sebastian Footnotes: --- [1] http://lists.gnu.org/archive/html/emacs-orgmode/2008-10/msg00451.html and previous/next messages. [2] Worg.git/org-tests/ert-publish-test.el -- 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
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
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
[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: - ":" :: 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 - :: 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 I use checkli