Hsiu-Khuern Tang writes:
> Hi Carsten,
>
> You recently changed org-edit-src-code to use a separate buffer
> instead of an indirect buffer. One side effect of this is that I
> can no longer edit several code examples at the same time:
> opening the second buffer will silently discard any changes made
> in the first. I would prefer this behavior: when opening the
> second edit source buffer, write any changes in the first buffer
> to the originating Org buffer (but don't save it, of course).
>
> Another approach is to use different buffer names.
The better approach is clearly to allow several buffers, now
implemented with this commit.
Harri Kiiskinen writes:
> There is an elusive bug in the ICal export functions. To
> demonstrate it, open this file, allow for the use of the local
> variable, and run 'org-export-icalendar-this-file'. What I get is
> the message "Wrong type argument: stringp, nil"
>
> -----------------------------
> #+FILETAGS: test
> * TODO header
>
> # Local Variables:
> # org-use-tag-inheritance: "^[t]"
> # End:
> -----------------------------
>
> Now, the funny thing is, that if you change the filetag from
> "test" to "est", close the file, and open it again, the file will
> be exported fine! It seems, that if the filetag does match the
> regular expression in org-use-tag-inheritance, then the result is
> error.
This bug was due to a missing save-match-data around a call to
org-get-tags-at. However, when studying this bug it turned out
that explicitly checking for the archive tag is not needed,
because we already have a call to `org-agenda-skip' in the same
loop.
Peter Frings writes:
> Good day, org-ers
>
> I have seen a *small* problem in the Agenda's log mode.
>
> Org-mode version 6.26d
> GNU Emacs 22.3.1 (i386-apple-darwin9.5.0, Carbon Version 1.6.0) of 2008-11-01
>
>
> I have this in time-sheets.org:
>
>
> * Project AI
> ** Enhancement PT <2009-04-30 Thu 10:00-11:00 +1w>
> CLOCK: [2009-05-14 Thu 09:55]--[2009-05-14 Thu 10:45] => 0:50
>
>
> But, the Agenda shows this:
>
> Day-agenda (W20):
> Thursday 14 May 2009
> 9:00...... ----------------
> planning: 9:12- 9:55 Clocked: (0:43) BUSY Notifications
> time-sheet: 10:00-11:00 Clocked: (0:50) Enhancement PT
> time-sheet: 10:00-11:00 Enhancement PT
> 10:00...... ----------------
> 11:00...... ----------------
>
He is right. Progress lines should never take their
time from the headline, always only from the triggering line.
Benjamin Andresen writes:
> I was curious as to why a value such log-mode wasn't customizable
> to be run on start-up as follow-mode and clock-report-mode are.
>
> If Carsten thinks this is a good idea, I've attached a patch that
> may shave of 5 seconds of him adding it. It applies cleanly to
> current git HEAD.
This commit applies Beanjamin's patch
There is now a new export function, `org-export-as-org', which
basically creates a copy of the Org file with things like archived
trees, commented trees, and trees deselected by export tags,
stripped.
This commit adds:
{{{date(FORMAT)}}} current date/time, formatted with
`format-time-string'
{{{modification-time(FORMAT)}}} date/time of last modification of
file, formatted with `format-time-string'
{{{input-file}}} the file name of the source Org file.
entries.
Guy Wiener writes:
> Hello everyone,
>
> I use orgmode to write down TODO tasks with dependencies (using
> org-enforce-todo-dependencies). I want to export the tasks to an
> iCalendar file, but *without* the blocked tasks (i.e, tasks that have
> unfinished dependencies). The agenda view hides these tasks if you set
> org-agenda-dim-blocked-tasks. It there a way to configure the
> iCalendar export to ignore these tasks too, like in the agenda view?
This commit implements this, when the value of
`org-icalendar-include-todo' is the symbol `unblocked'.
The commit implements a general mechanism for providing special
(e.g. completion) support for specific link types when entering links
with `C-c C-l'. After calling `C-c C-l', you may now press RET after
inserting a link prefix, and Org will look for a function
`org-PREFIX-complete-link'. Such functions may be defined for any
link types, including link abbreviations. Currently, Org has
`org-file-complete-link' for file name completion, and
`org-bbdb-complete-link' for completion of record names from BBDB.
Peter Westlake writes:
> On Fri, 8 May 2009 06:24:54 +0200, "Carsten Dominik"
> <carsten.dominik@gmail.com> said:
>
> I anyone could make an example that allos me to reproduce this
> problem, then I might be able to fix it.
>
> It's trivial:
>
> * top
> ** sub 1
> Set org-cycle-include-plain-lists.
> Type TAB on this line, and the whole of top gets folded.
>
> ** sub 2
> This entry is not needed to reproduce the bug. It just
> makes it more visible.
There was indeed a bug, I think it is fixed now.
Shaun Johanson writes:
> Consider the following Org file:
>
> * Test
>
> See [[(foo)][FOOBIE]]
>
> #+BEGIN_EXAMPLE
> <foo>: blah blah (ref:foo)
> #+END_EXAMPLE
>
> Question 1)
> In Org mode the link displays as FOOBIE, in the exported HTML it
> displays as (foo). Is there any way to cause the link to use the
> description (FOOBIE) in HTML? If not would this be a useful option
> to add?
This was a bug, fixed now.
Editing source code examples and pictures is not done in a truly
separate buffer, not in an indirect buffer. Indirect buffers had
caused problems with fontification, for example.
Jason Riedy writes:
> I'm trying to change org-export-latex-image-default-option
> to "width=.7\\linewidth" in a file local variable. It's set
> correctly as a buffer local variable, and it's having no
> effect on the export. My guess is that the buffer-local
> property is stopping it as soon as org-export-as-latex runs
> set-buffer.
>
> I can smuggle the value in by adding an entry to org-export-plist-vars
> referring to org-export-latex-image-default-option and pulling the value
> from the plist, but that feels incorrect.
It is actually the correct way to do this, and I have
implemented this change.
Samuel Wales writes:
> I frequently export to ascii without wanting a file to be created,
> especially not in a useful directory, as the files are temporary.
>
> Is there a way to export ascii to just a buffer?
There is now, `C-c C-e A'.
This commit also implements commands
- org-export-as-ascii-to-buffer
- org-replace-region-by-ascii
- org-export-region-as-ascii
which are similar to what is available for HTML and LaTeX.
`C-c C-e A' used to be the key for publishing all projects.
This functionality has now been moved to `C-c C-e E'.
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.
Matt Lundin writes:
> When I select a region and invoke
> org-replace-region-by-latex, the region is removed, but no
> latex output is put in its place. In other words, the region
> is simply deleted.
>
> Strangely, if I select multiple headlines, they are
> converted to latex. But if I select only text underneath a
> headline, it is not replaced.
This is hopefully fixed now.
Alex Mizrahi writes:
> I'm trying to use column view to work with effort estimates, but it
> does not seem to work in XEmacs. When I press C-c C-x C-c columns
> show up in agenda view (I'm not sure if 100% correcly, but
> more-or-less so), but when I try editing anything, column view goes
> away and error appears:
>
> Wrong number of arguments: #<subr local-variable-p>, 1
Chris Gray had the idea to have arbitrary blocks turned in LaTeX
environments and HTML divs. These three new hooks allow
implementation has an add-on rather than a patch.
Thomas Morgan writes:
> I just tried exporting an Org file with LaTeX fragments to HTML
> on a computer that doesn't have dvipng. There were error messages
> in *Messages* ("Failed to create png file..."), but this wasn't
> obvious to me at first glance because those messages were replaced
> in the echo area by "Exporting... done" before I could see them.
>
> So I was wondering, is there a good way to make the user aware of
> those errors? Maybe by printing "Exporting... done (with errors)"?
There is now a better error message when either the latex or the
dvipng program does not exist.
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.
Carsten Dominik