Daniel Hackney writes:
> When attempting to use radio lists for exporting in LaTeX, I
> found that they didn't work. I am using the example file shown
> below:
>
> ---BEGIN_EXAMPLE---
>
> #+LaTeX: % BEGIN RECEIVE ORGLST programs
> #+LaTeX: % END RECEIVE ORGLST programs
>
> #+ORGLST: SEND programs org-list-to-latex
> - Emacs text editor
> - Ubuntu Linux
> - Git version control system
> - Firefox web browser
> - Drupal content management system
> - Subversion version control system
> - Eclipse integrated development environment
>
> ---END_EXAMPLE---
>
> I eventually ran `org-list-send-list' manually on the list, and
> got the following error:
>
> funcall: Wrong type argument: number-or-marker-p, (unordered
> #("Emacs text editor" [snip...]
>
> I started debugging `org-list-send-list' and found that the error
> occurred when calling (funcall transform list). Looking back, I
> saw that `transform' was assigned (in the let*) after
> `item-beginning'. Stepping through the execution, I saw that
> `transform' was being assigned a value of `-'. It turns out when
> assigning to `item-beginning', (org-list-item-beginning) is
> called, which runs a regular expression with a capture group,
> overwriting the previously matched capture group.
>
> Luckily, the fix is simple; all that needs be done is to switch
> the assignment to `transform' with `item-beginning' so the regex
> in (org-list-item-beginning) doesn't override the match-string
> data. I tried this fix out and it worked perfectly.
Brenton Kenkel writes:
> I found an apparent minor bug with links containing quotation marks in
> LaTeX export. If the first character in the name of a link is a
> quotation mark, it is converted to a closing mark rather than an
> opening mark. For example:
>
> ,----
> | * test
> |
> | [[http://www.google.com]["hello"]]
> | [[http://www.google.com]["two" "quotes"]]
> `----
>
> This produces:
>
> ,----
> | \href{http://www.google.com}{''hello''}
> | \href{http://www.google.com}{''two'' ``quotes''}
> `----
John Wiegley writes:
> In `org-id-update-id-locations', it uses the value of
> org-id-extra-files and calls file-truename on all its members,
> assuming them to be filenames.
>
> However, my `org-id-extra-files' is the symbol
> `org-agenda-text-search-extra-files', which contains the symbol
> `agenda-archives'. I get an error because Org is calling
> file-truename on that symbol. This stops me from doing "id"
> based link lookups within archive files.
These changes provides frame / window management preferences for the
edit buffer generated using C-c ' on a source code block. Preferences
are specified by a new variable org-src-window-setup, which is based
on org-agenda-window-setup and has the same four options:
current-window, other-window, reorganize-frame, other-frame. These
behave as follows:
* current-window
The edit buffer appears in the current window.
* other-window
`switch-to-buffer-other-window' is used to switch to the edit buffer
in the same frame.
* reorganize-frame [default]
The current frame is reorganized so that it is split between the
source code edit buffer and the parent org buffer.
* other-frame
The edit buffer appears in a new frame. That frame is deleted when
exiting the edit buffer with C-c '.
In org-edit-src-save, point and mark were being restored inside the
save-window-excursion. As it happens, although mark is lost, point
nevertheless retained its position with switch-to-buffer being used to
switch between org and edit buffers, as is currently the
case. However, the failure to restore point correctly is exposed if
more complex options controlling window and frame management are
provided for the edit buffer.
Richard Moreland writes:
> (setq org-agenda-custom-commands
> '(("X" agenda "" nil ("agenda.html"))))
> ;; This seems to break org-mobile-push?
> ;;(setq org-agenda-exporter-settings
> ;; '((org-agenda-add-entry-text-maxlines 5)
> ;; (htmlize-output-type 'font)))
>
> I have the lines above in my .emacs file. When I uncomment the 3
> commented lines, org-mobile-push just hangs after OVERVIEW.
>
> I don't understand exactly what is going on, but if I hit C-g or
> C-c enough I can regain control, but the sync never finishes.
Kai Tetzlaff writes:
> i noticed that when using the org-mode clock persistence, the
> stored clock data gets deleted when i start emacs and exit again
> without turning on org-mode in between.
>
> When looking at org-clock-persistence-insinuate it looks like
> org-clock load will only run after org-mode gets started whereas
> org-clock-save will always be called when exiting emacs:
>
> (defun org-clock-persistence-insinuate ()
> "Set up hooks for clock persistence"
> (add-hook 'org-mode-hook 'org-clock-load)
> (add-hook 'kill-emacs-hook 'org-clock-save))
>
> Not running org-mode-hook (i.e. not starting org-mode) thus does
> not load clock data but org-clock-save overwrites any prviously
> saved data when exiting emacs.
>
> An easy fix for that would be to just add org-clock-load to e.g.
> emacs-startup-hook. But this will only work if the code in
> org-clock-load does not depend on any org-mode initialization
> code (or would require loading org-mode).
>
> So org-clock-save should probably check if org-clock-load has
> been running during the current emacs session (or if clock
> persistence was just enabled) and only then save clock data when
> exiting emacs. I tried to add this to the code in org-clock-save:
Now the recommendation is to use clock persistence only for the
history, and to use John's code for resolving a clock that has been
idle (either because the user stopped working or exited Emacs).
This happens regardless of types and presence of source-code blocks
in the buffer. Previously interblocks were only exported when
source-code blocks of the same "type" were present in the org-mode
buffer. This decision was placed around the assumption that
exporting small inline non-block objects only made sense in the
presence of some related block type. This assumption is
artificially limiting and is now removed from org-exp-blocks.
Carsten Dominik
Dan Davison
Bastien Guerry
John Wiegley
Eric Schulte