Adam Spiers writes:
> I really like the way `M-x org-agenda C' takes you straight to the
> *Customize Option: Org Agenda Custom Commands* buffer. Similarly, it
> would be nice if `M-x org-remember C' took you straight to the
> *Customize Option: Org Remember Templates* buffer.
This does now work, but only if the user has no template defined for
the access letter `C'.
>
> Although in both cases it would be even nicer if the keystroke for
> this was customisable, as no doubt some people already have `M-x
> org-remember C' set up to do something else.
It is not customizable, like for the agenda....
Adam Spiers writes:
> The code for handling %^{PROP}p in org-remember templates seems to
> have a bug:
>
> ((equal char "p")
> (edebug)
> (let*
> ((prop (org-substring-no-properties prompt))
> (pall (concat prop "_ALL"))
> (allowed
> (with-current-buffer
> (get-buffer (file-name-nondirectory file))
>
> Here get-buffer can return nil, in which case `org-remember' fails
> with the error:
>
> Wrong type argument: stringp, nil
>
> It seems to be assuming that the non-directory part of the filename
> corresponds to the buffer name, but this is not guaranteed. Perhaps I
> noticed it because I am using uniquify.el ?
priority
So far the headline had to match the one specified in the template
exactly, except for tags. Now a TODO keyword and a priority can be
added, and the headline will still be found.
Reported by Samuel Wales and Bernt Hansen.
This default to t, so the default behavior of org-mode doesn't
change. But the user might want to keep at least one blank line
at the end of the remembered subtree, this option lets her do it.
Scot Beker writes:
> I have org-remember working successfully (I can't believe that it took
> me so long to experiment with it. It has made a huge difference in my
> work).
>
> But if, after calling the extension with C-c r, I type a "wrong" tag
> selector (e.g. I mistype a right one), I get
> (1) the error message 'no template' (good)
> (2) a remember buffer without a bullet point, with the point at the
> very top of the file (sure, what do I expect?)
> (3) but, having realized my mistake, I can't get out of it gracefully.
> I can't abort (C-c C-k), and can't (C-c C-c).
> I get the error message "Args out of range 0, 1"
>
> Any idea whether I've set something up wrong or if org just has no
> mercy on those who can't manage to type one of the selected values?
> Otherwise, org-remember works well.
This situation is now avoided by forcing the selection of a valid
template.
Carsten Dominik writes:
> On Apr 26, 2009, at 12:08 AM, Samuel Wales wrote:
>
> > I noticed the following regarding
> > org-remember-backup-directory:
> >
> > 1) auto-saving does not save contents
> > - solution: put (auto-save-mode 1) before or after (not
> > sure which) the call to org-set-local in the
> > following lines in org-remember:
> >
> > # (expand-file-name
> > # (format-time-string "remember-%Y-%m-%d-%H-%M-%S")
> > # org-remember-backup-directory))
> > # (save-buffer)
> > # (org-set-local 'auto-save-visited-file-name t))
> > # (when (save-excursion
>
> Done.
>
>
> > 2) save-buffer is called before there are any contents
> > - this causes files without useful content to stick
> > around in the dir if the buffer is killed or
> > something.
> > - solution: don't save the buffer; let auto-saving do
> > that work. will this work?
>
> Usually, the template expansion will have filled in stuff like
> links and initial contents, so I would prefer to keep the
> save-buffer here and let the user deal with the extra files.
>
> > 3) if you have auto-save-file-name-transforms set,
> > auto-saving is done according to that variable instead
> > of saving in place.
> >
> > I am now turning that variable off, locally in the remember buffer.
> > Does that fix the problem?
>
> - Carsten
>
> > - solution: is this an emacs bug? i am not sure. the
> > auto-saving should be done in place, saving in
> > org-remember-backup-directory and not saving in the
> > place where the transforms variable tells it to save.
> > perhaps each user can kludge transforms or perhaps
> > emacs needs fixing? i have reached debugging ability
> > limit.
If the heading field in the remember template entry is either `top' or
`bottom', it is now OK to file to a file that is not in org mode, and
the content of the remember buffer is inserted without forcing an
Org-style header.
Remember and refile processing does not require a task. This change
removes the unneeded default task.
This supports a workflow where new remember tasks and notes go into a
mostly empty file which just has #+FILETAGS: at the top and nothing
else.
This workflow has a minimal number of remember templates
- one for new tasks and (filed in tasks.org)
- one for new notes (filed in notes.org)
- one for phone calls (filed in phone.org)
New tasks are added as top-level tasks to the end of these files and
the #+FILETAGS: REFILE header causes each task to be easy to find.
All tasks in these files are refiled to a more appropriate org file at
a later time.
The annotation and initial contents for a remember template are
normally taken from the variables `annotation' and `initial', which
are bound by remember. We now also check the property list for such
values, so that the link generating routine can force the right values
in there.
When setting the variable `org-remember-back-directory', each
remember buffer created will now get its own unique file name in that
directory. So if you, by accident, overwrite a remember buffer or
remove it before storing it, there will be a backup.
Org has a number of places where the value read by completing-read may
contains spaces. For these occasions, the space character needs to be
a normal character.
The recent support for ido.el invalidated these special cases because
ido has its own way of dealing with spaces.
This commit now makes sure that ido is off for the critical cases
where completion must allow spaces.
Carsten Dominik
Bastien Guerry
Bernt Hansen