Re: Error with org-agenda with 9.5.3
Thank you. Happy that I found a real error and didn't just waste everyone's time. Also happy to report that I updated org to 9.5.4 and all is well. Best, R On 3 Jun 2022, at 9:08, Ihor Radchenko wrote: > Ihor Radchenko writes: > >>> I am running Emacs 25 (Aquamacs). So, maybe this code requires Emacs 26? >>> If so, it would be nice if org-mode 9.5.3 was tagged as incompatible >>> with Emacs 25? (It would also be nice if package mode supported >>> roll-back, but that's OT here!) >> >> Thanks for reporting! This has been fixed on our bugfix branch, but not >> yet on ELPA. > > You can now update to Org 9.5.4. > > Best, > Ihor
Error with org-agenda with 9.5.3
I just updated org-mode using package.el and got release 9.5.3 Now I get an error in `org-at-timestamp-p` (OATP), which is invoked when calling `org-agenda`. I checked the repository and the problem is in commit 1f617727f1, which added to this function the following code block: ``` - (let* ((regexp (if extended - (if (eq extended 'agenda) - org-element--timestamp-regexp - org-ts-regexp3) - org-ts-regexp2)) + (let* ((regexp + (if extended + (if (eq extended 'agenda) + (rx (or (regexp org-ts-regexp3) + (regexp org-element--timestamp-regexp))) + org-ts-regexp3) +org-ts-regexp2)) ``` The issue arises where OATP uses `rx` to process a regex stored in `org-ts-regexp3`: ``` (rx (or (regexp org-ts-regexp3) ; here (regexp org-element--timestamp-regexp))) ``` This fails because `rx-check` checks the sub-expression `(regexp org-ts-regexp3)` to make sure that `org-ts-regexp3` is a string, but `org-ts-regexp3` is not evaluated, and the *symbol* `org-ts-regexp3` is not a string (it's a symbol), even though it's *value* is a string. I'm not sure whether this is a bug in org-mode proper (I would have thought this would be caught before release) or perhaps org-mode expects some version of `rx.el` that I do not have. Unfortunately, I don't see a version number in `rx.el`, only a copyright date. I am running Emacs 25 (Aquamacs). So, maybe this code requires Emacs 26? If so, it would be nice if org-mode 9.5.3 was tagged as incompatible with Emacs 25? (It would also be nice if package mode supported roll-back, but that's OT here!)
Re: [PATCH v3] Fix FAQ entry about mailto links.
On 14 Feb 2022, at 7:22, Max Nikulin wrote: On 11/02/2022 00:42, Robert Goldman wrote: There are a couple of minor issues in the patch you sent (including a couple of grammatical errors), so attached is a revision. Great. Thank you, Robert, it exact reason why I asked for a review. I am sending the updated patch and a diff to your edits to highlight my latest changes. Hello, Max -- Some responses below, then I think merging would be fine. I am losing my ability and energy to process these patch files, honestly. From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" Date: Thu, 10 Feb 2022 11:20:36 -0600 Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links." This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a. Would you like to have you original version in git history? For me it is not a problem to make my patch updating yours one without reverting the original commit (create another branch, cherry-pick commits, resolve conflict to the latest state). Otherwise you can avoid unnecessary commits in your local repository by either applying my patch to a new branch or using "git rebase -i master" to drop unnecessary commits. I don't need to be credited; it would be fine to just merge in whatever way is convenient. +If you prefer an external application that is /not/ the one configured +in your desktop environment, What is bothering me a bit is the entry title "Org-mode is not opening mailto links in my *default* mail client". The updated variant mostly discusses changing of defaults. The whole thing addresses how to open mailto links in the default mail client. It's not our fault that figuring out how org-mode dispatches these links and then what goes on inside browse-url is so complicated! +**side comment:** the above paragraph is hard to understand. Would it be +possible to add pointers to the discussion of these issues? I do not follow Emacs development. The source is git commit history and commit messages rarely have links to discussion or references to bug tracker. To be honest, I'm not sure what value this whole comment section has. Given that, I'm ok with whatever you want to do: leave it as it, try to fix it, or just remove it altogether. I actually think that removing it might be best. It's confusing, and will eventually become out-of-date, and who will update it? I'll leave it to you to choose. Best, R
Re: [PATCH] Fix FAQ entry about mailto links.
On 7 Feb 2022, at 10:59, Max Nikulin wrote:
Robert,
Thank you for pointing out that `org-link-mailto-program' should not
be recommended in FAQ any more.
I prepared an alternative patch that recommends to customize Emacs
variables at first. I hope, an example is safer now, however I can not
test it on MacOS. Could you, please, review the patch, since I may
miss something important from your point of view?
On 07/01/2022 18:03, Max Nikulin wrote:
On 07/01/2022 01:34, Robert Goldman wrote:
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
I am unsure if MailMate is acceptable since it is a proprietary
application. Org is a part of *GNU* Emacs, so it may be better to
mention some free mail user agent.
+#+begin_src elisp
+("mailto" :follow
^
It seems, `org-link-set-parameters' is missed.
I am sorry, I missed that you suggested to customize the
`org-link-parameters' variable, so function call is not necessary
here.
There are a couple of minor issues in the patch you sent (including a
couple of grammatical errors), so attached is a revision.
I'm afraid there are now multiple patch files.
Please note that I have requested clarification at several places in the
comment block.
Best,
R
From b8158af7a839a751e6976cd95d18a5d5f199024a Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman"
Date: Thu, 6 Jan 2022 12:27:59 -0600
Subject: [PATCH 1/4] Fix FAQ entry about mailto links.
The old entry referred to the variable =org-link-mailto-program= which
was removed from org-mode almost eight years ago! See org-mode commit
b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
---
org-faq.org | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index 4b34560c..cac8063e 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
#+index: Link!Mailto
You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+changing the entry for =mailto:= links in =org-link-parameters=:
-=M-x customize-variable org-link-mailto-program=
+=M-x customize-variable org-link-parameters=
The default function called is =browse-url=, which opens a mail
composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
+=browse-url= depends on the setting of the variable =mail-user-agent=.
Thus, if you want to ensure that mailto links use Gnus to open a
message buffer, you could add the following to your =.emacs=:
@@ -1941,6 +1941,18 @@ message buffer, you could add the following to your
=.emacs=:
(setq mail-user-agent 'gnus-user-agent)
#+end_src
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
+
+#+begin_src elisp
+("mailto" :follow
+ (lambda
+(path)
+(shell-command
+ (format "open -a MailMate 'mailto:%s'" path
+#+end_src
+
** Can I use CamelCase links?
:PROPERTIES:
:CUSTOM_ID: CamelCase-links
--
2.31.1
From e7f0f2c51950b3c0f181191c5210ea26cafc03f4 Mon Sep 17 00:00:00 2001
From: "Robert P. Goldman"
Date: Thu, 10 Feb 2022 11:20:36 -0600
Subject: [PATCH 2/4] Revert "Fix FAQ entry about mailto links."
This reverts commit b8158af7a839a751e6976cd95d18a5d5f199024a.
---
org-faq.org | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index cac8063e..4b34560c 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
#+index: Link!Mailto
You can customize the function org-mode uses to open mailto links by
-changing the entry for =mailto:= links in =org-link-parameters=:
+setting the variable =org-link-mailto-program=:
-=M-x customize-variable org-link-parameters=
+=M-x customize-variable org-link-mailto-program=
The default function called is =browse-url=, which opens a mail
composition buffer within Emacs. The type of buffer opened by
-=browse-url= depends on the setting of the variable =mail-user-agent=.
+browse-url depends on the setting of the variable =mail-user-agent=.
Thus, if you want to ensure that mailto links use Gnus to open a
message buffer, you could add the following to your =.emacs=:
@@ -1941,18 +1941,6 @@ message buffer, you could add the following to your
=.emacs=:
(setq mail-user-agent 'gnus-user-agent)
#+end_src
-You can also change the function used to a different one. For
-example, the following function (on MacOS) opens =mailto:= links in
-the =MailMate= program:
-
-#+begin_src elisp
-("mailto" :follow
- (lambda
-(path)
-(shell-command
- (format "open -a MailMate 'mailto:%s&
[PATCH] Fix FAQ entry about mailto links.
The old entry referred to the variable =org-link-mailto-program= which
was removed from org-mode almost eight years ago! See org-mode commit
b9f2e17f07faf01109fc6f7f1eb5a34e0f97eafb
---
org-faq.org | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/org-faq.org b/org-faq.org
index 4b34560c..cac8063e 100644
--- a/org-faq.org
+++ b/org-faq.org
@@ -1927,13 +1927,13 @@ For example:
#+index: Link!Mailto
You can customize the function org-mode uses to open mailto links by
-setting the variable =org-link-mailto-program=:
+changing the entry for =mailto:= links in =org-link-parameters=:
-=M-x customize-variable org-link-mailto-program=
+=M-x customize-variable org-link-parameters=
The default function called is =browse-url=, which opens a mail
composition buffer within Emacs. The type of buffer opened by
-browse-url depends on the setting of the variable =mail-user-agent=.
+=browse-url= depends on the setting of the variable =mail-user-agent=.
Thus, if you want to ensure that mailto links use Gnus to open a
message buffer, you could add the following to your =.emacs=:
@@ -1941,6 +1941,18 @@ message buffer, you could add the following to
your =.emacs=:
(setq mail-user-agent 'gnus-user-agent)
#+end_src
+You can also change the function used to a different one. For
+example, the following function (on MacOS) opens =mailto:= links in
+the =MailMate= program:
+
+#+begin_src elisp
+("mailto" :follow
+ (lambda
+(path)
+(shell-command
+ (format "open -a MailMate 'mailto:%s'" path
+#+end_src
+
** Can I use CamelCase links?
:PROPERTIES:
:CUSTOM_ID: CamelCase-links
--
2.31.1
[O] Two questions about org-export-insert-default-template in new org-exporter
1. The original org-insert-export-options-template always inserted the template at the top of the file. The new one inserts at point. Since the options need to be at the top of the file, would there be any objection to making the new template inserter behave the same way? 2. Users can directly issue this command using M-x org-export-insert-default-template, since it's tagged as (interactive). Since this is possible, wouldn't it make sense to have the function query for the BACKEND argument when invoked interactively? Best, r
[O] Minor bug in org export to latex
I find that a mathmode environment, bounded by $..$, that breaks across line boundaries, is not typeset correctly. I am attaching a minimal example org-file. Best, r #+TITLE: Latex Export bug on line boundaries #+AUTHOR: Robert P. Goldman #+DATE: <2013-05-31 Fri> #+EMAIL: rpgold...@sift.info #+OPTIONS: ':nil *:t -:t ::t <:t H:3 \n:nil ^:t arch:headline author:t c:nil #+OPTIONS: creator:comment d:(not LOGBOOK) date:t e:t email:nil f:t inline:t #+OPTIONS: num:t p:nil pri:nil stat:t tags:t tasks:t tex:t timestamp:t toc:t #+OPTIONS: todo:t |:t #+CREATOR: Emacs 24.3.50.3 (Org mode 8.0.3) #+DESCRIPTION: #+EXCLUDE_TAGS: noexport #+KEYWORDS: #+LANGUAGE: en #+SELECT_TAGS: export * Here is a good example $(1 - \nu)$ * Here is a bad example When I type a lot of text in front of the mathmode so that the mathmode breaks across a line boundary, I find that it is not typeset properly as here: $(1 - \nu)$
Re: [O] {New exporter] What happened to the export template
A very late follow-up: I note that the Worg instructions for HTML export still cite org-insert-export-options-template: http://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html
[O] Question about org-agenda-goto-today (bug?)
I am finding that when I use this command (bound to "." in the org agenda), I often do NOT go to today. Looking at the code, it seems like org-mode may be guessing today based on text markup: (let ((tdpos (text-property-any (point-min) (point-max) 'org-today t))) We jump to this position, instead of checking the clock, if we can find it. If it helps, I often leave emacs running for days at a time, which I suspect could be confusing it about what today is. E.g., this just happened to me when I tried to update my org-agenda after having been away from it overnight. Perhaps it would be an improvement to look at what we find at TDPOS and check to verify that it corresponds somehow to org-today?
Re: [O] Fix for bug in org-capture
Bastien wrote:
> Hi Robert,
>
> Robert Goldman writes:
>
>> I tried to make two submenus to my org-capture templates: a prefix key
>> "t" (for TODO) and a prefix key "T" (for today's TODO).
>>
>> When I tried to use them, the "T" key did not appear and was not accepted.
>>
>> Looking more deeply, it appears that it was filtered out by a mistakenly
>> case-folding (or at least potentially case-folding) search in org-capture.
>
> I cannot reproduce this.
>
> I have these two captures templates:
>
> (setq org-capture-templates
> '(
> ("Ir" "Information read" entry (file+headline "~/org/garden.org"
> "Infos")
>"* TODO %?%a :Read:\n :PROPERTIES:\n :CAPTURED: %U\n :END:\n\n%i"
> :prepend t)
>
> ("IR" "Information read (!)" entry (file+headline "~/org/garden.org"
> "Infos")
>"* TODO %?%a :Read:\n :PROPERTIES:\n :CAPTURED: %U\n :END:\n\n%i"
> :prepend t :immediate-finish t)
>))
>
> They are both recognized well.
This isn't actually the same as my bug (which I didn't explain
adequately). A closer equivalent to mine would have been to have both
"i" and "I", not both "r" and "R".
Here's the bit of my config:
(defvar rpg-org-remember-todo-template
"* TODO %^{todo title}\n %?")
(setq org-capture-templates
`(
("t" "Templates for TODO items.")
("tw" "Work Todo" entry (file+headline "~/org/todo.org" "Tasks")
,rpg-org-remember-todo-template)
("tp" "Personal Todo" entry (file+headline "~/personal/org/todo.org"
"Tasks") ,rpg-org-remember-todo-template)
("T" "Templates for today TODO items.")
("Tw" "Today work todo" entry (file+headline "~/org/todo.org"
"Tasks")
"* TODO %^{todo title}\n SCHEDULED: %t\n %?")
("Tp" "Today personal todo" entry (file+headline
"~/personal/org/todo.org" "Tasks")
"* TODO %^{todo title}\n SCHEDULED: %t\n %?"))
You will see above that it's the prefix keys, not the suffix keys that
causes the problem.
Also, note that if I delete the lines defining the prefix keys:
("t" "Templates for TODO items.")
("T" "Templates for today TODO items.")
the problem goes away. You don't seem to have such definitions in your
code.
>
> Maybe you can try with this minimal example and tell if you can
> still reproduce the problem? Also let us know what version of Org
> you are using.
I can replicate this with head pulled within the past hour.
>
>> I am attaching a diff which has the two line fix for this bug.
>
> I'll apply it if we can reproduce and narrow down the problem.
BTW, I would actually argue that my fix is right, even if you could not
replicate down the problem. This use of the string matching function
incorrectly allows global state to bleed into the functioning of the
calling function. If you *know* (as here) that case-fold-search should
be nil (because the org manual dictates that these keys are case
sensitive), then you should never allow a surrounding binding of
case-fold-search to bleed into the function.
The use of dynamic binding complicates replication, because global state
(binding of case-fold-search) dictates whether this function as written
behaves correctly or not.
Hope that clarifies,
cheers,
r
[O] Fix for bug in org-capture
I tried to make two submenus to my org-capture templates: a prefix key "t" (for TODO) and a prefix key "T" (for today's TODO). When I tried to use them, the "T" key did not appear and was not accepted. Looking more deeply, it appears that it was filtered out by a mistakenly case-folding (or at least potentially case-folding) search in org-capture. I am attaching a diff which has the two line fix for this bug. diff --git a/lisp/org-capture.el b/lisp/org-capture.el index d8e62a1..861d640 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1431,7 +1431,8 @@ only the bare key is returned." (insert prefix "[" dkey "]" "..." " " ddesc "..." "\n") ;; Skip keys which are below this prefix (setq re (concat "\\`" (regexp-quote dkey))) - (while (and tbl (string-match re (caar tbl))) (pop tbl))) + (let ((case-fold-search nil)) + (while (and tbl (string-match re (caar tbl))) (pop tbl ((= 2 (length (car tbl))) ;; Not yet a usable description, skip it )
Re: [O] phone links...
Michael Strey wrote: > Robert, > > On Mo, Apr 08, 2013 at 09:44:12 -0500, Robert Goldman wrote: >> Michael Strey wrote: >>> Currently org-phone.el as well as my org-dial.el are incompatible with >>> org-contacts. The only idea behind my proposal was to make the contributors >>> of both packages aware of each other. >> Can you explain what makes org-phone incompatible with org-contacts? >> Maybe my naming of some function? > > The problem is on the side of org-contacts. Org-contacts does not > support links in its properties. Thus, currently the only solution to > use the advantages of org-contacts and org-phone is to give the > information twice, like in the following example. > > #+BEGIN_SRC org > * Strey, Michael > :PROPERTIES: > :EMAIL:mst...@strey.biz f...@bar.com > :PHONE:+493514129535 +491263213 > :END: > > [[mailto:mst...@strey.biz]] > [[mailto:f...@bar.com]] > [[phone:+49 (0)351 41295-35]] > [[phone:+49 126 3213]] > #+END_SRC > > This shortcoming effects not only the phone links but email links as > well. > > Regards I think in that case it might be best to have a function in org-contacts that "knows" that PHONE contains phone numbers, and that can parse them out, and shoot them off to org-phone. Vague thought: Make C-c C-c aware of PHONE properties so that it can perform this magic. Again, I am not an org-contacts user, so this may be a stupid question, but how does org-contacts "know" when it has a contact? I am looking at the sample record you present above, and it looks just like an org-mode header to me. There is no marker, as far as I can tell, that would tell org-mode that it is a contact record, instead of some other arbitrary thing. This seems odd to me. Why isn't it something like #+BEGIN_SRC org * CONTACT Strey, Michael :PROPERTIES: :EMAIL:mst...@strey.biz f...@bar.com :PHONE:+493514129535 +491263213 :END: #+END_SRC by analogy to the way TODO flags a task? At any rate, any function that could parse a :PHONE: property could easily (funcall org-phone-function ). Cheers, r
Re: [O] phone links...
Michael Strey wrote: > Currently org-phone.el as well as my org-dial.el are incompatible with > org-contacts. The only idea behind my proposal was to make the contributors > of both packages aware of each other. Can you explain what makes org-phone incompatible with org-contacts? Maybe my naming of some function? If so, I will make sure to remove any incompatiblities on my side. BTW, I would be happy to push org-phone.el into contrib/lisp... I *think* I may have commit privileges as a hang-over from once committing patches to the old generic exporter. cheers, r
Re: [O] phone links...
Michael Strey wrote: > Robert, > > On Do, Apr 04, 2013 at 09:38:48 -0500, Robert P. Goldman wrote: > > [...] > >> I will be happy to include this into contrib (and do the relevant >> assignment) at any time when people think that it is sufficiently ready >> to go. I have been testing it in contrib/ in a testing branch in my git >> repo. > > What about integrating these few functions into org-contacts? I am very reluctant to do this. I don't use org-contacts at all, but I *do* like to have phone numbers in my TODO items. I don't believe a person should have to use org contacts in order to permit themselves to use phone links. I think we can get an appropriate combination by having org-phone be free-standing, and simply let the org-contacts user adopt them if s/he likes. Related question: if the org-contact entries are *known* to be phone numbers (keyed by the field), why not automagically treat those values as phone numbers, instead of requiring them to be phone links (which add cruft to the files)? And similarly for EMAIL. I.e., why not simply have: #+BEGIN_SRC org * Surname, Name :PROPERTIES: :EMAIL:f...@bar.com :PHONE:+49 351 4129535; +49 176 6626196 :END: #+END_SRC ? But as a non-org-contacts user, my opinion is obviously not so important here...
Re: [O] phone links...
On 4/3/13 Apr 3 -9:52 AM, Michael Strey wrote: > This gives me the opportunitie to publish my own attempt to implement > telephone functionality into org. I'm using Linphone > (http://www.linphone.org/) instead of Skype. Thanks! I am folding the linphone code in to make org-phone more generic. Question: why the removal of "(0)"? For international calls? Why "(0)" only, instead of any 0 prefix? Also, do you ever want to remove it anywhere but as a prefix? If so, maybe DELETE is the wrong function call. Current draft: ;;;--- ;;; org-phone.el ;;; Add support for "phone:" links to phone numbers. ;;; Optional support for calling them with skype ;;;--- ;;; Copyright (C) 2013 Free Software Foundation, Inc. ;; Author: Robert P. Goldman ;; Homepage: http://orgmode.org ;; Version: 0.02 ;; This file is not yet part of GNU Emacs. (require 'org) (org-add-link-type "phone" 'org-phone-open) ;; not sure whether we need/want this yet... ;;(add-hook 'org-store-link-functions 'org-phone-store-link) (defcustom org-phone-function 'org-phone-call "The Emacs function to be used to call a phone number. By default, a simple function that uses shell-command to apply org-phone-call-command (qv.) to the phone number." :group 'org-link :type 'symbol) (defcustom org-phone-call-command "skype-call" "The executable command to be used to call a phone number. This should be a script that starts the call and returns: it should not block." :group 'org-link :type 'string) (defun org-phone-open (phone-number) "Phone the number PHONE-NUMBER. PHONE-NUMBER should be a string for a PSTN phone number." (funcall org-phone-function phone-number)) (defun org-phone-call (phone-number) (shell-command (format "%s %s" org-phone-call-command phone-number))) (defun trim-phone-number (phone-number) "Remove whitespaces from a telephone number" (mapconcat 'identity (delete "(0)" (split-string phone-number "[ /-]")) "")) ;; (defun org-phone-store-link () ;; "Store a link to a phone number." ;; ;; This is a man page, we do make this link ;; (let* ((page (org-man-get-page-name)) ;; (link (concat "man:" page)) ;; (description (format "Manpage for %s" page))) ;; (org-store-link-props ;;:type "man" ;;:link link ;;:description description (provide 'org-phone)
Re: [O] phone links...
On 3/29/13 Mar 29 -6:23 PM, Robert Goldman wrote: > Since I keep my todo tasks in my org files, and some of them involve > phone calls, I made a rudimentary handler for "phone:" links that I > would like to contribute. It features a link declaration (in > org-phone.el) and an ancillary script (currently only working on Mac OS > X, but should be translatable to other platforms) that can be used to > place skype calls to the phone numbers. > > One thing it does not do is support interactive entry of phone numbers. Looks like the Right Thing here is to add a definition for an org-phone-complete-link function. I didn't read the manual carefully enough I'll see if I can whip something up, perhaps something that would use a contacts database. cheers, r
[O] phone links...
Since I keep my todo tasks in my org files, and some of them involve
phone calls, I made a rudimentary handler for "phone:" links that I
would like to contribute. It features a link declaration (in
org-phone.el) and an ancillary script (currently only working on Mac OS
X, but should be translatable to other platforms) that can be used to
place skype calls to the phone numbers.
One thing it does not do is support interactive entry of phone numbers.
The two files are below, in hopes of getting suggestions for improvement
so that someday this could find itself into contrib/.
Cheers,
r
org-phone.el
;;;---
;;; org-phone.el
;;; Add support for "phone:" links to phone numbers.
;;; Optional support for calling them with skype
;;;---
;;; Copyright (C) 2013 Free Software Foundation, Inc.
;; Author: Robert P. Goldman
;; Homepage: http://orgmode.org
;; Version: 0.01
;; This file is not yet part of GNU Emacs.
(require 'org)
(org-add-link-type "phone" 'org-phone-open)
;; not sure whether we need/want this yet...
;;(add-hook 'org-store-link-functions 'org-phone-store-link)
(defcustom org-phone-function 'skype-call
"The Emacs function to be used to call a phone number."
:group 'org-link
:type 'symbol)
(defcustom org-skype-command "skype-call"
"The executable command to be used to call a phone number.
This should be a script that starts the call and returns: it
should not block."
:group 'org-link
:type 'string)
(defun org-phone-open (phone-number)
"Phone the number PHONE-NUMBER.
PHONE-NUMBER should be a string for a PSTN phone number."
(funcall org-phone-function phone-number))
(defun skype-call (phone-number)
(shell-command (format "%s %s"
org-skype-command
phone-number)))
;; (defun org-phone-store-link ()
;; "Store a link to a phone number."
;; ;; This is a man page, we do make this link
;; (let* ((page (org-man-get-page-name))
;; (link (concat "man:" page))
;; (description (format "Manpage for %s" page)))
;; (org-store-link-props
;;:type "man"
;;:link link
;;:description description
(provide 'org-phone)
skype-call
#!/bin/sh
command="CALL $1"
osascript -e 'tell application "Skype"' \
-e "send command \"${command}\" script name \"skype-call\"" \
-e 'end tell'
Re: [O] A mail client that is org-mode compatible
On 1/3/13 Jan 3 -4:17 AM, Daniel Clemente wrote: > El Wed, 02 Jan 2013 13:07:20 -0600 Robert Goldman va escriure: >> >> Thunderbird, which I have been using, doesn't support links to messages. >> OTOH, it has the best IMAP client I have found, so I keep coming back >> to it. >> >> Gnus: I regret to say that despite having tried it at least three >> times, I have never managed to wrap my head around the gnus doctrine >> that mail is just news, so I cannot use it. >> > > Wanderlust speaks IMAP natively and works in a similar way to Thunderbird. > It does not store e-mails locally, although it uses some caché. > Probably others too. > Thank you so much. I recall trying to install Wanderlust in the past and getting tripped up by the need to install SEMI, APEL and FLIM, which didn't successfully build for me (Aquamacs). Wanderlust still seems pretty difficult to set up: The INSTALL instructions for Wanderlust (on github) have not been updated in 2 years. They give instructions for up-to-date Emacs versions like 20.4 and they are unclear about whether to use FLIM or CLIME, or where to get the latter. Also, currently, the FAQ at the Wanderlust homepage points to dead FTP URLs for SEMI, APEL, and FLIM packages. If you don't grok el-get, or have prepackaged (e.g., Debian) versions of Wanderlust, this beast seems like a huge chore to install. Sigh.
Re: [O] A mail client that is org-mode compatible
I have a closely related question: I use multiple devices, so I need to have an IMAP server that really is an IMAP server, instead of something the just serves up messages to be downloaded. I have multiple folders, and I read messages from different clients. I haven't been able to figure out an org-mode compatible mail reader that doesn't seem to want me to pull down all the messages to a local server. [I'm ok if it doesn't read nntp.] Thunderbird, which I have been using, doesn't support links to messages. OTOH, it has the best IMAP client I have found, so I keep coming back to it. Gnus: I regret to say that despite having tried it at least three times, I have never managed to wrap my head around the gnus doctrine that mail is just news, so I cannot use it. VM: I used to use VM, but at least when I was using it, it demanded local storage, and did not include a full-fledged IMAP client. any other suggestions? Maybe this could go onto worg
Re: [O] Org agenda and recent files list....
On 8/10/12 Aug 10 -2:21 AM, Bastien wrote: > Robert Goldman writes: > >> ;;;--- >> ;;; Agenda files shouldn't get entries in the recentf-list >> ;;;--- > > Knowing about `recentf-exclude' will certainly help many users, > not only for excluding Org files. > > Thanks, > For what it's worth, a more fine-grained alternative would be to get inside org-get-agenda-file-buffer and inhibit the recentf caching while calling find-file inside there. That would allow you to have an agenda file appear in the recent files list IF it was opened through a manual use of find-file, but NOT if it was opened as a side effect of loading an agenda. This more fine-grained approach was a little more work than I wanted to do, and didn't necessarily provide me a lot more value, so I didn't bother with it. But someone else might find it worth coding up. Chacun à son org configuration! Cheers, r
[O] Org agenda and recent files list....
I was finding that the use of org-agenda made my recent files list less than useful, by filling up the list with files that I rarely opened "by hand" with find-file. The following snippet, added to my org-config file, seems to have fixed things. ;;;--- ;;; Agenda files shouldn't get entries in the recentf-list ;;;--- (defun org-is-agenda-file (filename) (find (file-truename filename) org-agenda-files :key 'file-truename :test 'equal)) (require 'recentf) (pushnew 'org-is-agenda-file recentf-exclude) I mention this on the off-chance it's useful to someone else... cheers, r
Re: [O] centering blocks cause latex export to crash
On 12/23/11 Dec 23 -12:41 PM, Nick Dokos wrote: > Bastien wrote: > >> Hi Robert, >> >> Robert Goldman writes: >> >>> The attached org-mode file causes latex export to crash with an error of >>> "unbalanced begin/end center blocks with " >> >> This should work as expected now - please pull and confirm. >> > > I tried it with Robert's skeleton input file: AFAICT, it works as > expected. I hope it works with Robert's real file too. > > Thanks for fixing it! > > Nick Yes, this works with my original source file, too! Thanks and Happy Holidays! Robert
Re: [O] centering blocks cause latex export to crash
On 12/14/11 Dec 14 -3:13 PM, Nick Dokos wrote: > Robert Goldman wrote: > >> I am using the latest org from git. >> >> The attached org-mode file causes latex export to crash with an error of >> "unbalanced begin/end center blocks with " >> >> This did work, as recently as a month ago, so something relatively >> recent has broken it. >> >> best, >> r > > Indeed, but note that the latex exporter has always been a little flaky > with stuff before the first headline. As a workaround, if you add a > headline before the block, it works. > > Nick Thanks. But the workaround is not ideal here --- the centering block is supposed to say "Not Cleared for Public Release" for reasons of conditions on my research grant, and that really is not supposed to be in a heading. I have another work-around, but I think the general principle is that forbidding text before the first header is not an ideal constraint. If there's a way to have a header that doesn't produce output (a la noexport), but that doesn't suppress its children, that might be a handy way to accomplish this. I don't know if that's possible (that would also be handy for outlines where you want the outline structure to "fade away" and just leave you with the text that the outline inspired). Best, r
Re: [O] centering blocks cause latex export to crash
On 12/14/11 Dec 14 -3:06 PM, Robert Goldman wrote: > I am using the latest org from git. > > The attached org-mode file causes latex export to crash with an error of > "unbalanced begin/end center blocks with " > > This did work, as recently as a month ago, so something relatively > recent has broken it. I got in the debugger, and the problem is that the regular expression for the end of the centering block, computed as inner-re in org-export-blocks-preprocess fails to match my #+end_center inner-re is: (inner-re (format "[\r\n][ \t]*#\\+\\(begin\\|end\\)_%s" (regexp-quote (downcase (match-string 2) I don't understand why this is happening: I haven't been able to tell if the regular expression is incorrectly written, so it fails to find the ending of the center block, or if somehow the logic in the while loop (which counts begins and ends to make sure they match) is counting wrong. Cheers, r
[O] centering blocks cause latex export to crash
I am using the latest org from git. The attached org-mode file causes latex export to crash with an error of "unbalanced begin/end center blocks with " This did work, as recently as a month ago, so something relatively recent has broken it. best, r #+TITLE: center-export-bug.org #+AUTHOR:Robert P. Goldman #+EMAIL: rpgold...@sift.info #+DATE: 2011-12-14 Wed #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc #+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: #+TAGS: noexport #+begin_center Not Cleared for Public Release #+end_center * Problem with centering block. My document fails to export successfully to latex with the above =center= block in it.
Re: [O] OPatches for org-generic-export
On 10/24/11 Oct 24 -9:44 AM, Wes Hardaker wrote: >> On Fri, 21 Oct 2011 19:23:04 +0200, Bastien said: > >>> Glad to see someone tinkering with it! yay! > > B> Could you test Robert's patches against latest Org and report > B> any problem? As the author of the generic exporter, you might > B> spot problems more easily... > > I think they looked fine without intense study, and I trust him to fix > bugs that come his way :-) > > Anyway, I really like the idea of an exporter test regression suite. > Now we just need to make that happen! The only challenge I see is the matcher. That is, I can create a test document, based on Jambunathan's, but I don't know the best way to write the tests. I suppose some form of regular expression is The Right Thing. There must be a better solution, though --- I figure someone must have a good way to match text files against expectations. I just don't know what that way is. cheers, r
Re: [O] OPatches for org-generic-export
On 10/21/11 Oct 21 -12:06 PM, Wes Hardaker wrote: >> On Fri, 21 Oct 2011 11:13:24 -0500, "Robert P. Goldman" >> said: > > RPG> Attached is a set of patches to the org-generic-exporter. They fix > RPG> a change in the org-preprocess process that means that all uses of > RPG> the org-generic export facility will crash. They also add > RPG> rudimentary support for trac wiki and tikiwiki export. Finally, I > RPG> have removed the HTML exporter from the org-generic export. I > RPG> don't see any reason to struggle to support this, since it is done > RPG> better by the core parts of org-mode. > > Glad to see someone tinkering with it! yay! > > FYI, the reason the HTML was in there was for proof of concept more than > anything else. It was a learning example for those wishing to write > their own exports, as HTML is known by lots of people and demonstrated > what you could do with it. [especially if you wanted hand-crafted html] Hm. Well, we could certainly just skip that patch, and apply only the others to org-mode, if we want to keep it. The problem with doing that is that when I am fixing things (e.g., I am working to make links work with various wiki export formats), I don't have the energy to maintain the HTML backend. So it's likely to bit-rot, which would make it turn into a /bad/ exemplar. What do you think? I think also we should try to assemble a single org document with all kinds of markup that are expected to work, and use that to make tests. An export facility is actually easy to regression test I just haven't gotten around to it. Do you know if there is such a document for one of the other exporters that I could piggyback on? Best, r
Re: [O] Bug? in latex export of cross-references in footnotes
On 9/26/11 Sep 26 -2:26 PM, Robert Goldman wrote:
> Here is a simple footnote in a test file:
>
> Footnotes:
> [1] The footnote contains a cross-reference to [[Heading]].
>
> When I export this using org-export-as-pdf, the cross-reference to
> Heading doesn't get exported properly. In particular, what I see in the
> emitted latex file is:
>
> Inside the text there is a footnote.\protect\footnote{The footnote
> contains a cross-reference to \hyperref[Heading]{Heading}. }
>
> But the only latex \label associated with \section{Heading} is
> \label{sec-1}.
>
> I am attaching the sample org file and latex output.
>
> Thanks for any suggestions!
>
> Robert
I tweaked the example a little (see attachment), and this is a bona fide
bug. A corresponding link in the body text (I have modified the link to
use the "restricted to headers" syntax, just in case that was the
problem), works properly. It's only in the footnote that it's broken.
* Heading
* Another heading
* Some text
Inside the text there is a footnote.[1]
* Some more text
Here's text with a link in the body: [[*Heading]].
Footnotes:
[1] The footnote contains a cross-reference to [[*Heading]].
footnote-crossref.tex
Description: TeX document
[O] Bug? in latex export of cross-references in footnotes
Here is a simple footnote in a test file:
Footnotes:
[1] The footnote contains a cross-reference to [[Heading]].
When I export this using org-export-as-pdf, the cross-reference to
Heading doesn't get exported properly. In particular, what I see in the
emitted latex file is:
Inside the text there is a footnote.\protect\footnote{The footnote
contains a cross-reference to \hyperref[Heading]{Heading}. }
But the only latex \label associated with \section{Heading} is
\label{sec-1}.
I am attaching the sample org file and latex output.
Thanks for any suggestions!
Robert
* Heading
* Another heading
* Some text
Inside the text there is a footnote.[1]
Footnotes:
[1] The footnote contains a cross-reference to [[Heading]].
footnote-crossref.tex
Description: TeX document
Re: [O] Question about org-mode compilation
On 9/11/11 Sep 11 -12:52 AM, David Maus wrote: > At Sat, 10 Sep 2011 12:08:45 -0500, > Robert Goldman wrote: >> >> Today I was trying to push to mobile org after an update from git, and >> got an invalid function error on org-eval-in-environment. >> >> This macro is defined in org-macs.el and is used in org-agenda.el. >> >> I note that the makefile has org-agenda depending on org.el, but /not/ >> on org-macs.el. >> >> Is that an error? >> >> Adding that dependency, then making clean and making all fixes things. >> But I may not have properly cleaned before my last build, so I'm not sure. > > Hi Robert, > > I checked and don't think the missing dependency in Makefile was cause > of the problem. When org-agenda.el is compiled it requires org.el > which in turn requires org-macs.el -- thus the macro definition is > loaded. Otherwise the compiler would stop. > > An invalid function error with a macro is according to my experience > an indicator of mixing up of old and new files. Thus, the make clean > was the action that fixed the issue. > > I byte compiled Org and ran a batch-agenda (which uses > org-eval-in-environment) with no error. Thanks, I noticed that org.el dependency, but I wasn't sure how transitive these dependencies were. I will try to remember to always make clean! best, R
[O] Question about org-mode compilation
Today I was trying to push to mobile org after an update from git, and got an invalid function error on org-eval-in-environment. This macro is defined in org-macs.el and is used in org-agenda.el. I note that the makefile has org-agenda depending on org.el, but /not/ on org-macs.el. Is that an error? Adding that dependency, then making clean and making all fixes things. But I may not have properly cleaned before my last build, so I'm not sure. Thanks! r
Re: [O] Google Tasks integration
On 9/3/11 Sep 3 -12:44 PM, Sven Bretfeld wrote: > Hi Brad > > I don't know anything about your question proper, but ... > > Brad Collette writes: > >> I've also been using mobileorg to get my stuff on my iphone. However, I'm >> less >> satisfied with that. Having to both push and pull from both ends to keep >> things >> in sync is a pain and I often forget. > > This is absolutely automatized on my system. I don't have to do anything > except keep the computer running. As an Android user I don't know if > MobileOrg on iPhone can sync automatically, the Android app can. I have > configured it to sync every 30 min. on my phone and pad. My computer > runs a cronjob every 20 minutes that pulls and pushes. Here is the > script that does the job: > > #!/bin/bash > > emacs --batch --load ~/.emacs --eval "(gtd)" --eval "(org-mobile-pull)" > --eval "(org-save-all-org-buffers)" --eval "(org-mobile-push)" > > If you are on Linux or Mac the script should work as a cronjob. I don't > know about Windows. > Could you amplify a little on how this works? I believe that org-mobile-push is a side-effecting operation (among other things it adds ID properties). So how can you run this cron job all the time? Doesn't it interact badly with running your own interactive emacs job? thanks, r
Re: [O] HTML5 presentations
On 6/16/11 Jun 16 -3:36 PM, Jambunathan K wrote: > Eric Schulte writes: > >> Robert Goldman writes: >> >>> On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote: >>>> Vinh Nguyen writes: >>>> >>> >>> I have tried the version here: >>> https://github.com/twada/org-html5presentation.el >>> >>> and it does not seem to be ready for prime-time. Org-babel features >>> don't work, and there seems to be not a clear integration with the >>> org-export-preprocessor. See my two issues, one (not satisfactorily) >>> closed, one open. >>> >>> Possibly this should be folded into contrib, so that people could >>> cooperate on it more easily than when it lives off in a separate git >>> repo, but it shouldn't be enabled for the unwary until it's been >>> thoroughly exercised. >>> >>> Is there a "tries to use all features" org presentation somewhere that >>> would serve as a good acid test for an export facility? It would be >>> very handy to have that. >>> >> >> This export target seems to re-implement much of the org HTML export >> mechanics which is most likely the reason for the incomplete coverage of >> Org's large functionality. >> >> Perhaps it would be possible to change this so that it works more like >> org-s5, that is, so that it firsts exports using the existing html >> export functionality, and then simply manipulates the resulting html. >> > > I haven't looked at or tried either org-s5 or the html5 presentations. > > I would like to note that much of the refactoring of the html exporter > is already done and is ready for prime time. I would very much like to > see that my code be used for such experimentations. > > I will only note that the only way Free Software can thrive is by > adopting an "embrace and extend" approach. Can you explain more about how we should proceed? Are you recommending: Your refactoring should be merged into the main branch BEFORE attempting to re-engineer org-html5presentation? Or is there something else? Also, does your re-engineering help with the problem that I cited above? I.e., the fact that org-export-current-backend is used BOTH to load the export code AND to indicate to the preprocessor how to preprocess. The problem here is that we can't make two different backends share the same preprocessing. Actually, more generally, I think the problem is that the export-preprocessor, since it doesn't have anything like methods or higher-order functions, forces us to build into each preprocessing function a big conditional based on the value of org-export-current-backend, which is cumbersome. Best, r
Re: [O] HTML5 presentations
On 6/16/11 Jun 16 -2:29 PM, Eric Schulte wrote: > Robert Goldman writes: > >> On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote: >>> Vinh Nguyen writes: >>> >>>> After the recent org-mode to S5 discussion, I stumbled onto >>>> [these](https://gist.github.com/509761) code. It offers a way to >>>> export org files to HTML5 presentations. I think it looks quite nice. >>>> I see it being better than S5 in that no "ui" folder is required. >>>> What do you all think? Is it worthy of being incorporated into >>>> org-mode? >>> >>> Just tried it, and it's pretty cool! Easy to use and nicely looking. >>> >>> Bye, >>> Tassilo >>> >>> >>> >> >> I have tried the version here: >> https://github.com/twada/org-html5presentation.el >> >> and it does not seem to be ready for prime-time. Org-babel features >> don't work, and there seems to be not a clear integration with the >> org-export-preprocessor. See my two issues, one (not satisfactorily) >> closed, one open. >> >> Possibly this should be folded into contrib, so that people could >> cooperate on it more easily than when it lives off in a separate git >> repo, but it shouldn't be enabled for the unwary until it's been >> thoroughly exercised. >> >> Is there a "tries to use all features" org presentation somewhere that >> would serve as a good acid test for an export facility? It would be >> very handy to have that. >> > > This export target seems to re-implement much of the org HTML export > mechanics which is most likely the reason for the incomplete coverage of > Org's large functionality. > > Perhaps it would be possible to change this so that it works more like > org-s5, that is, so that it firsts exports using the existing html > export functionality, and then simply manipulates the resulting html. Alternatively, would it be possible to have this behave mostly like conventional HTML export (i.e., have the org-export-current-backend be 'html), and then simply have the code that does the emitting override particular bits of the normal org-html behavior? The problem with this approach is that a side-effect of setting the org-export-current-backend to 'foo is to (require 'org-foo). This means it's difficult to make something like org-export-as-html5presentation be parasitic on org-export-as-html... I confess to not understanding how beamer and conventional latex export interact; possibly that would provide valuable precedent for this. best, r
Re: [O] HTML5 presentations
On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote: > Vinh Nguyen writes: > >> After the recent org-mode to S5 discussion, I stumbled onto >> [these](https://gist.github.com/509761) code. It offers a way to >> export org files to HTML5 presentations. I think it looks quite nice. >> I see it being better than S5 in that no "ui" folder is required. >> What do you all think? Is it worthy of being incorporated into >> org-mode? > > Just tried it, and it's pretty cool! Easy to use and nicely looking. > > Bye, > Tassilo > > > I have tried the version here: https://github.com/twada/org-html5presentation.el and it does not seem to be ready for prime-time. Org-babel features don't work, and there seems to be not a clear integration with the org-export-preprocessor. See my two issues, one (not satisfactorily) closed, one open. Possibly this should be folded into contrib, so that people could cooperate on it more easily than when it lives off in a separate git repo, but it shouldn't be enabled for the unwary until it's been thoroughly exercised. Is there a "tries to use all features" org presentation somewhere that would serve as a good acid test for an export facility? It would be very handy to have that.
[O] Problem with latex export of anchors
The latex exporter mistakenly leaves the text of anchors in the exported text. I have reported this before --- see http://thread.gmane.org/gmane.emacs.orgmode/41414 I am attaching an org-mode file that shows a minimal test case, and the corresponding exported latex My earlier posting proposed a fix, but that doesn't seem to have gone anywhere. best, r * Header * Another header <> * The last header anchor-export-bug.tex Description: TeX document
[O] Bug in latex description list export
I stumbled across a /very/ weird bug in latex export. The bug arises when there is 1. A footnote in a description list 2. The word "description" appears in the footnote and 3. The word "description" is flush to the left margin. See the attached .org file * Header + item 1 :: definition,[fn:1] + item 2 :: another definition this time one that runs on and on off the right margin and onto the next line + item 3 :: A third item to replicate my original bug * Footnotes [fn:1] Here's a footnote that breaks the description list. The problem arises when the word description appears in the left margin.
Re: [O] Org babel does not work properly with included files
I would say we can close this bug report as INVALID. AFAICT, the actual problem was happening simply because of the incorrect treatment of missing links during export, which is now fixed. When that got fixed, my issue went away. best, r
Re: [O] mobileorg android refuses to syn with mydisk.se
On 5/10/11 May 10 -12:34 PM, Matthew Jones wrote: > Hi Robert... I'm the developer for MobileOrg on Android, we have a known > issue with self-signed certificates. What version of MobileOrg are you > using? If you visit the site in the Android browser do you get a > certificate notification also? Yes, I do, but I get the opportunity to continue through the certificate notification. this is android 2.2 Best, r
[O] mobileorg android refuses to syn with mydisk.se
Using mydisk.se, when I try to sync I get an SSL error --- not trusted server certificate. Interestingly, neither FF nor Google Chrome on my laptop have any issue with this server. And my iPod Touch's copy of Mobile Org is happy with mydisk.se, too. Unfortunately, MobileOrg does not offer any option to inspect the cert and decide to accept it. Is anyone else having this problem? Is it fixable? thanks, r
Re: [O] Bug in latex export tutorial on worg ?
On 5/10/11 May 10 -12:25 AM, Thomas S. Dye wrote:
> Robert Goldman writes:
>
>> On 5/9/11 May 9 -11:22 PM, Nick Dokos wrote:
>>> Robert Goldman wrote:
>>>
>>>> On 5/9/11 May 9 -9:54 PM, Nick Dokos wrote:
>>>>> Robert Goldman wrote:
>>>>>
>>>>>> There is the following code block there:
>>>>>>
>>>>>> #+begin_src emacs-lisp :results silent
>>>>>> (add-to-list 'org-export-latex-classes
>>>>>> '("per-file-class"
>>>>>> "\\documentclass{scrartcl}
>>>>>> [NO-DEFAULT-PACKAGES]
>>>>>> [EXTRA]"
>>>>>> ("\\section{%s}" . "\\section*{%s}")
>>>>>> ("\\subsection{%s}" . "\\subsection*{%s}")
>>>>>> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
>>>>>> ("\\paragraph{%s}" . "\\paragraph*{%s}")
>>>>>> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>>>>>> #+end_src
>>>>>>
>>>>>> Is this still correct? Or should this be :exports none instead of
>>>>>> :results silent?
>>>>>>
>>>>>
>>>>> ``:results silent'' works for me and keeps the result from appearing in
>>>>> the org buffer. I don't think :exports can do that - it can only affect
>>>>> what's exported.
>>>>>
>>>>> Nick
>>>>
>>>> I must be doing something wrong then --- I had the :results silent and
>>>> found the source block in verbatim in my latex export file Changing
>>>> to :exports none made that go away for me. Maybe that was a
>>>> coincidence. I will have to investigate further, I guess.
>>>>
>>>
>>> No, you are not doing anything wrong: the default :exports value is
>>> "code", so the code ends up in your export. ``:exports none'' keeps it
>>> (and any results) from being exported.
>>>
>>> OTOH, try evaluating (C-c C-c) the code block, with and without
>>> ``:results silent''. There is a behavior difference and *that* difference
>>> is not affected by how you set :exports.
>>>
>>> Nick
>>
>> Ah. I get it now. But then surely the above IS a bug -- presumably
>> it's not usual for a person to wish their latex export configuration to
>> appear, in verbatim block, in their org-generated latex document!
>>
>> Best,
>> Robert
>>
>>
>>
>
> Aloha Robert,
>
> I've added :exports none to the example, which came from a document
> about how to export LaTeX documents from Org-mode. Thanks for pointing
> out that it could be used in a way that yields unexpected results.
>
> In my usual setup I put this kind of configuration in a heading of its
> own that is protected by a :noexport: tag. This works for me because I
> often have notes about why things are in there and what I think they
> might be doing.
Great! Thanks. Your tutorial has been very helpful to me. I needed to
figure out how to set up a special-purpose format for my document and in
a moment I had just the solution I needed.
I suppose one could do...
(unless (find "per-file-class" org-export-latex-classes :key 'car
:test 'equal)
(add-to-list 'org-export-latex-classes
'("per-file-class"
"\\documentclass{scrartcl}
[NO-DEFAULT-PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"
since the add-to-list is a globally side-effecting action; it doesn't
need to be repeated on each export, right? [I thought at first pushnew
could do the job, but now I don't think so.]
Best,
R
Re: [O] Bug in latex export tutorial on worg ?
On 5/9/11 May 9 -11:22 PM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> On 5/9/11 May 9 -9:54 PM, Nick Dokos wrote:
>>> Robert Goldman wrote:
>>>
>>>> There is the following code block there:
>>>>
>>>> #+begin_src emacs-lisp :results silent
>>>> (add-to-list 'org-export-latex-classes
>>>> '("per-file-class"
>>>> "\\documentclass{scrartcl}
>>>> [NO-DEFAULT-PACKAGES]
>>>> [EXTRA]"
>>>> ("\\section{%s}" . "\\section*{%s}")
>>>> ("\\subsection{%s}" . "\\subsection*{%s}")
>>>> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
>>>> ("\\paragraph{%s}" . "\\paragraph*{%s}")
>>>> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>>>> #+end_src
>>>>
>>>> Is this still correct? Or should this be :exports none instead of
>>>> :results silent?
>>>>
>>>
>>> ``:results silent'' works for me and keeps the result from appearing in
>>> the org buffer. I don't think :exports can do that - it can only affect
>>> what's exported.
>>>
>>> Nick
>>
>> I must be doing something wrong then --- I had the :results silent and
>> found the source block in verbatim in my latex export file Changing
>> to :exports none made that go away for me. Maybe that was a
>> coincidence. I will have to investigate further, I guess.
>>
>
> No, you are not doing anything wrong: the default :exports value is
> "code", so the code ends up in your export. ``:exports none'' keeps it
> (and any results) from being exported.
>
> OTOH, try evaluating (C-c C-c) the code block, with and without
> ``:results silent''. There is a behavior difference and *that* difference
> is not affected by how you set :exports.
>
> Nick
Ah. I get it now. But then surely the above IS a bug -- presumably
it's not usual for a person to wish their latex export configuration to
appear, in verbatim block, in their org-generated latex document!
Best,
Robert
Re: [O] Bug in latex export tutorial on worg ?
On 5/9/11 May 9 -9:54 PM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> There is the following code block there:
>>
>> #+begin_src emacs-lisp :results silent
>> (add-to-list 'org-export-latex-classes
>> '("per-file-class"
>> "\\documentclass{scrartcl}
>> [NO-DEFAULT-PACKAGES]
>> [EXTRA]"
>> ("\\section{%s}" . "\\section*{%s}")
>> ("\\subsection{%s}" . "\\subsection*{%s}")
>> ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
>> ("\\paragraph{%s}" . "\\paragraph*{%s}")
>> ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
>> #+end_src
>>
>> Is this still correct? Or should this be :exports none instead of
>> :results silent?
>>
>
> ``:results silent'' works for me and keeps the result from appearing in
> the org buffer. I don't think :exports can do that - it can only affect
> what's exported.
>
> Nick
I must be doing something wrong then --- I had the :results silent and
found the source block in verbatim in my latex export file Changing
to :exports none made that go away for me. Maybe that was a
coincidence. I will have to investigate further, I guess.
best,
r
[O] Bug in latex export tutorial on worg ?
There is the following code block there:
#+begin_src emacs-lisp :results silent
(add-to-list 'org-export-latex-classes
'("per-file-class"
"\\documentclass{scrartcl}
[NO-DEFAULT-PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src
Is this still correct? Or should this be :exports none instead of
:results silent?
Cheers,
r
Re: [O] Bug in :minlevel for INCLUDE
On 5/5/11 May 5 -6:03 PM, Nick Dokos wrote: > Robert Goldman wrote: > >> AFAICT there is an off-by-one-error here. I.e., if I tell it that the >> :minlevel is 2, then my included level one headers get level 3, and if I >> tell it that the :minlevel is 1, then they get level 2. >> > > I think that's the desired behavior. That allows text before the first > headline in the included file (level 0) to properly take its place in the > result tree. > >> So it seems like :minlevel is actually being interpreted as a level >> *increment*, rather than a minimum... >> > > I don't really understand your comment: level N in the included file > becomes level :minlevel+N in the result (N = 0, 1, 2, ...). What were you > expecting? I was expecting the standard English usage (always dangerous in a technical context!). The minimum of 1,2,3 is 1. But here the thing we are calling "minimum" for 1,2,3 would be zero. Suggestion: the term :levelinc[rement] would be more indicative of the meaning. I think if you read your explanation, you will see that the thing referred to as a minimum is really an increment... It may be too late to make that change without disruption, so the alternative would be to modify the manual to make the meaning clearer. Best, r
[O] footnotes header not handled properly by INCLUDE files?
I just included a file that had a footnotes header, and the footnotes header appeared in the main text as a separate region, rather than correctly being interpreted as footnotes. I guess I'm not /terribly/ surprised this fails, but it does suggest the need for some link rewriting on import, or the footnotes are going to collide, aren't they?
[O] Bug in :minlevel for INCLUDE
AFAICT there is an off-by-one-error here. I.e., if I tell it that the :minlevel is 2, then my included level one headers get level 3, and if I tell it that the :minlevel is 1, then they get level 2. So it seems like :minlevel is actually being interpreted as a level *increment*, rather than a minimum... Best, r
Re: [O] Org babel does not work properly with included files
On 5/5/11 May 5 -4:27 PM, Eric Schulte wrote: >>> >>> I'm not sure that the current behavior is a bug. Is it reasonable to >>> place code block parameters into an included file? These parameters >>> would not be successfully found during interactive evaluation, and could >>> only plausibly be used during export as you anticipated. >> >> Aren't the code block parameters supposed to appear /with/ the code >> block? So here's the use case: >> >> I have a file chapter.org. This contains a full draft of a chapter of >> my manual. I finish it and circulate it for comments, then get it ready >> for inclusion. >> >> Now I have manual.org and I want to include the main body of chapter.org >> (typically there's some front matter I leave off). >> >> When I put the #include in manual.org, the source code snippets in >> chapter.org, which used to work, no longer do. >> >> This doesn't seem like /such/ a crazy use case that it shouldn't work, >> does it? >> > > Oh, my apologies, apparently in scanning this email thread I > mis-understood your use case. > > I've just tried to re-create the situation you've described above > (including a file which contains code blocks). I was unable to > reproduce your problem locally (the results of exporting both to html > and tex are included). Could you modify the attached example > sufficiently to demonstrate the problem you're experiencing? I will work on it --- I have a somewhat complicated perl script that is pulling stuff out for me and exporting results as source. Getting it to work in a small example is tricky! > >> >> [btw, I am not entirely sure I know what "header parameters" are --- > > see http://orgmode.org/manual/Header-arguments.html That's what I thought --- I was just confused because the comment in the code flips from using the term "argument" to "parameter," and I considered the possibility that there were two different mechanisms. Thanks, r
Re: [O] Org babel does not work properly with included files
On 5/5/11 May 5 -11:56 AM, Eric Schulte wrote: > Robert Goldman writes: > >> Looking over this some more, I see that the challenge is to: >> >> 1. read the file parameters (whatever they are) from the original file >> (hence opening the file from the link) and >> >> 2. read the header parameters from the export buffer, since the header >> may not actually be contained in the original file. >> > > The above is a good summary. Babel ensures that code blocks will be > evaluated in the original buffer, so that they can e.g., reference a > code block outside of the exported subtree when only exporting a > subtree. > >> >> This seems like a substantial reorganization from the original, which >> attempts to do both tasks in the original file (and fails for included >> files). >> > > I'm not sure that the current behavior is a bug. Is it reasonable to > place code block parameters into an included file? These parameters > would not be successfully found during interactive evaluation, and could > only plausibly be used during export as you anticipated. Aren't the code block parameters supposed to appear /with/ the code block? So here's the use case: I have a file chapter.org. This contains a full draft of a chapter of my manual. I finish it and circulate it for comments, then get it ready for inclusion. Now I have manual.org and I want to include the main body of chapter.org (typically there's some front matter I leave off). When I put the #include in manual.org, the source code snippets in chapter.org, which used to work, no longer do. This doesn't seem like /such/ a crazy use case that it shouldn't work, does it? [btw, I am not entirely sure I know what "header parameters" are --- are these the parameters that come from the #+begin_src line? If so, shouldn't they definitely be read from the #+begin_src line? They can't very well be read from manual.org, which doesn't contain the #+begin_src line.] Sorry if I wasn't clear in my original message. Best, r
Re: [O] Request for suggestions including source code
On 5/4/11 May 4 -6:10 PM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> On 5/4/11 May 4 -4:44 PM, Nick Dokos wrote:
>> So what I need now is some way to fix the verbatim environments that are
>> produced by org-mode to use a smaller font. I.e., instead of trying to
>> fix the source code to match char-width, fix the char-width to match the
>> source code. Any idea how to do that?
>>
>
> Here is one possibility: create a verbfont.sty file like this:
>
> --8<---cut here---start->8---
> \makeatletter
> \def\verbatim@font{\normalfont\scriptsize\ttfamily}
> \makeatother
> --8<---cut here---end--->8---
>
> and add this to your org file:
>
> --8<---cut here---start->8---
> #+LATEX_HEADER: \usepackage{verbfont}
> --8<---cut here---end--->8---
>
> Instead of \scriptsize, you can use any of the ones defined in
> size1X.clo (for some X). If you use \tiny, you should package a
> magnifier with the book...
Thank you! That was just /exactly/ what I needed. The listings
approach seems neat for other cases, but mine is a simpler solution and
this nails it.
Best,
R
Re: [O] [Accepted] Make the latex export preprocessor rewrite #+INDEX to \index.
On 5/4/11 May 4 -5:36 PM, Carsten Dominik wrote:
>
> On 4.5.2011, at 17:08, Robert Goldman wrote:
>
>> On 5/4/11 May 4 -2:59 AM, Carsten Dominik wrote:
>>> Patch 767 (http://patchwork.newartisans.com/patch/767/) is now "Accepted".
>>>
>>> Maintainer comment: Pushed with modifications. Some optimization, and the
>>> original patch would have stopped at the first #+index line that was
>>> missing the entry... Please verify that it still works
>>>
>>> This relates to the following submission:
>>>
>>> http://mid.gmane.org/%3C1303991243-30731-2-git-send-email-rpgoldman%40sift.info%3E
>>
>> I think there's a minor problem with the patch. AFAICT, it binds the
>> local variable 'entry' but does not read it (instead it uses the match
>> text directly).
>
> That is right, that is unnecessary. I removed that, thanks.
>
>> As an aside, it might be desirable to handle the empty index case that
>> you identified. E.g.,
>>
>> (if (> (match-end 1) (match-beginning 1))
>>...rewrite the index entry...
>>;; else
>>emit a warning
>>rewrite the index entry as the empty string
>> )
>
> You mean, instead of ignoring it, there should be an error message
> or warning?
>
> - Carsten
I was suggesting a warning. I don't /believe/ (I'm not in a position to
check right now) that the previous code ignored it --- I think it was
going to write an empty index --- \index{} --- and I'm not sure whether
that would be happy with Latex, or would generate a hard-to-debug error
downstream after processing the generated latex.
I also don't know if it's easy to report the particular line in the org
file that's bad. I suspect not, because of the preprocessing, but I
could be wrong.
best,
R
Re: [O] Request for suggestions including source code
On 5/4/11 May 4 -5:23 PM, Thomas S. Dye wrote:
>
> On May 4, 2011, at 11:59 AM, Robert Goldman wrote:
>
>> On 5/4/11 May 4 -4:13 PM, Thomas S. Dye wrote:
>>> Aloha Robert,
>>>
>>> Have a look at the listings and minted packages. You can specify font
>>> size on a per-document or per-language basis. I believe listings has an
>>> option to wrap long lines (don't remember this for minted, though).
>>>
>>> The instructions here might be helpful:
>>>
>>> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12_2
>>
>> Hm. I'm still grappling with this. I am including many of these
>> examples by using a source snippet (in sh) that goes out and pulls the
>> example out of a source code file.
>>
>> Even after adding
>>
>> #+LaTeX_HEADER \usepackage{listings}
>>
>> and
>>
>> #+src: setup-listings
>>
>
> Sorry for the confusion. In the example, the line
>
> #+source: setup-listings
>
> names the source code block that follows. I don't think it will do
> anything by itself in your document.
>
> That code block named setup-listings contains an example of a listings
> setup that maps Org-mode's output for Emacs Lisp code blocks to
> something listings recognizes. It can be executed in Org-mode, using
> Babel, to setup the listings export. After this is done, then the
> example should export correctly.
>
> I'm not sure what is going wrong on your end. Perhaps
> org-export-latex-custom-lang-environments needs to be configured for the
> language you're using?
Is there any chance that this won't work because I have a source snippet
in one language (sh) that returns as results a source snippet in a
/different/ language (a lisp-like domain-specific language)? I don't
off-hand see how I can come up with a single label for the source block
that takes this into account
This may be a weird enough case that I should be aiming at a solution
that is much simpler: e.g., just figuring out how to change all of my
verbatim environments to use a smaller font or changing the export
behavior so that /all/ verbatim blocks turn into listings blocks.
Best,
r
Re: [O] Request for suggestions including source code
On 5/4/11 May 4 -4:44 PM, Nick Dokos wrote:
> Tom provides the practical answers, I go for the frivolous ones :-) : the
> following
> latex program will give you the text width of the page:
>
> --8<---cut here---start->8---
> \documentclass{article}
>
> \begin{document}
> \the\textwidth
> \end{document}
>
> %%% Local Variables:
> %%% mode: latex
> %%% TeX-master: t
> %%% End:
> --8<---cut here---end--->8---
>
> I get 345.0pt (but you can use geometry.sty to change it).
>
> Let's say we want to use cmtt10 (at its design size of 10pt, i.e. not scaled
> up
> or down). The character sizes of this font can be obtained from the TFM file.
> An
> easy way to get them in human-readable form is to use tftopl:
>
> tftopl /usr/share/texmf-texlive/fonts/tfm/public/cm/cmtt10.tfm | grep CHARWD
>
> will give you the character widths as fractions of the design size. Since this
> is a fixed-width font, all widths are the same:
>
>(CHARWD R 0.524996)
>
> So the width of each character in points is:
>
>0.524996 * design size = 5.24996pt
>
> and you can accommodate
>
>floor(345.0 / 5.24996) = 65
>
> characters per line.
>
> So there you have it: a frivolous exercise, almost completely OT for the
> list and an almost useless answer[fn:1].
This actually was pretty helpful. The problem is, of course, that I
can't rewrite all of my source code to be in 65-width lines, nor can I
convince my colleagues to do so.
So what I need now is some way to fix the verbatim environments that are
produced by org-mode to use a smaller font. I.e., instead of trying to
fix the source code to match char-width, fix the char-width to match the
source code. Any idea how to do that?
thanks,
r
Re: [O] Request for suggestions including source code
On 5/4/11 May 4 -4:13 PM, Thomas S. Dye wrote:
> Aloha Robert,
>
> Have a look at the listings and minted packages. You can specify font
> size on a per-document or per-language basis. I believe listings has an
> option to wrap long lines (don't remember this for minted, though).
>
> The instructions here might be helpful:
>
> http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12_2
Hm. I'm still grappling with this. I am including many of these
examples by using a source snippet (in sh) that goes out and pulls the
example out of a source code file.
Even after adding
#+LaTeX_HEADER \usepackage{listings}
and
#+src: setup-listings
to the top of my file, and setting
org-export-latex-listings to 'listings
the :results of the source blocks, which look like, e.g., the following:
#+begin_src sh :exports results :results output
sourceSample.perl single code/ontology/top.prxo 'Class Pattern'
#+end_src
come out wrapped in
\begin{verbatim}
...
\end{verbatim}
Maybe I'm not doing enough. I'm a bit confused by the listings example
in the tutorial because it has the configuration examples be in their
own source block, and adds all of the options for specially typesetting
particular programming languages. It's not altogether clear to me which
bits of that are critical to getting the listings stuff to work at all,
and which are only specially tailoring its function.
Is it necessary to specify what programming language is used in order to
typeset using listings? I am using a domain specific language for which
there is no obvious listings setting and, anyway, what I am trying to
typeset is the /results/ of the source blocks, which are in a different
programming language from the /source/ of the source blocks.
I suspect I am just looking for a simpler solution, e.g., one which
would make org-mode give me the source blocks in
{\small
\begin{verbatim}
...
\end{verbatim}
}
instead of
\begin{verbatim}
...
\end{verbatim}
or something like that.
best,
r
[O] Request for suggestions including source code
I have a document that has big chunks of included source code. Unfortunately, when this is typeset in LaTeX, it typically blows past the right margin. I find it quite difficult to determine how many characters I get in a monospace line in LaTeX, and it seems like LaTeX won't give me enough to fit in plausible blocks of source code. Does anyone have a solution to this? Any way to tell org-mode to shrink the fontsize when exporting code examples to LaTeX? More condensed font to use for typewriter when exporting to LaTeX? Other tricks of the trade? Seems like many would have encountered this problem. Many thanks, r
Re: [O] [Accepted] Make the latex export preprocessor rewrite #+INDEX to \index.
On 5/4/11 May 4 -2:59 AM, Carsten Dominik wrote: > Patch 767 (http://patchwork.newartisans.com/patch/767/) is now "Accepted". > > Maintainer comment: Pushed with modifications. Some optimization, and the > original patch would have stopped at the first #+index line that was missing > the entry... Please verify that it still works > > This relates to the following submission: > > http://mid.gmane.org/%3C1303991243-30731-2-git-send-email-rpgoldman%40sift.info%3E I think there's a minor problem with the patch. AFAICT, it binds the local variable 'entry' but does not read it (instead it uses the match text directly). As an aside, it might be desirable to handle the empty index case that you identified. E.g., (if (> (match-end 1) (match-beginning 1)) ...rewrite the index entry... ;; else emit a warning rewrite the index entry as the empty string ) Hope that helps, Robert
Re: [O] [PATCH] Revised my #+index preprocessor to fontify index entries.
On 5/4/11 May 4 -3:03 AM, Carsten Dominik wrote:
> Hi Robert,
>
> I am rejecting this part of the patch for now. More thinking is needed here,
> also about special characters etc. No sure yet what the right course will be,
> but this is much too limited.
Carsten,
I don't fully understand the latex exporter, but I believe that
somewhere in it, LaTeX contexts are protected from translation.
Question: would it be possible to somehow mark the argument to \index{}
as being NOT protected? If we could do that, I suspect the rest of the
processing would run its course.
I am working on a manual so correct indexing of monospaced entries is
critical to me! ;-)
Best,
r
>
> - Carsten
>
>
> On May 1, 2011, at 6:01 PM, rpgold...@sift.info wrote:
>
>> From: Robert P. Goldman
>>
>> ---
>> The previous patch wasn't quite right because, e.g., it would index
>> #+INDEX: =Class=
>> as
>> \\index{=Class=}
>> instead of
>> \\index{\texttt{Class}}
>> This patch attempts to fix that.
>>
>> Question: would you prefer to have this reformulated as some kind of
>> unified patch
>> with the earlier one?
>>
>> lisp/org-latex.el | 12 +---
>> 1 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/lisp/org-latex.el b/lisp/org-latex.el
>> index 731d6e6..b8f7019 100644
>> --- a/lisp/org-latex.el
>> +++ b/lisp/org-latex.el
>> @@ -1,4 +1,4 @@
>> -;;; org-latex.el --- LaTeX exporter for org-mode
>> +;; org-latex.el --- LaTeX exporter for org-mode
>> ;;
>> ;; Copyright (C) 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
>> ;;
>> @@ -2331,9 +2331,15 @@ The conversion is made depending of STRING-BEFORE and
>> STRING-AFTER."
>>(let ((case-fold-search t))
>> (re-search-forward "^[ \t]*#\\+index:[ \t]*\\(.*?\\)[ \t]*$" nil t))
>>(> (match-end 1) (match-beginning 1)))
>> +;; (message "Found a #+INDEX match...")
>> (let ((entry (match-string 1)))
>> -;; (message "Found a #+INDEX match...")
>> - (replace-match (format "\\index{%s}" entry) t t)))
>> + (replace-match (format "\\index{%s}" entry) t t)
>> + ;; now process font directives in the index entry
>> + (re-search-forward "^[ \t]*index{\\([^}]\\)}" nil t)
>> + ;; (message (format "Trying to fontify string %s" (match-string 1)))
>> + (save-restriction
>> +(narrow-to-region (match-beginning 1) (match-end 1))
>> +(org-export-latex-fontify
>>
>> ;; Convert center
>> (goto-char (point-min))
>> --
>> 1.7.3.5
>>
>>
>
> - Carsten
>
>
>
Re: [O] Org babel does not work properly with included files
Looking over this some more, I see that the challenge is to: 1. read the file parameters (whatever they are) from the original file (hence opening the file from the link) and 2. read the header parameters from the export buffer, since the header may not actually be contained in the original file. This seems like a substantial reorganization from the original, which attempts to do both tasks in the original file (and fails for included files). best, r
[O] Org babel does not work properly with included files
Here's the problem: when org-babel goes to look for parameters when executing
a source block, it looks for them in the parent source file, and not in the
parent source file with the included materials. Here is the function that goes
awry:
(defmacro org-babel-exp-in-export-file (lang &rest body)
(declare (indent 1))
`(let* ((lang-headers (intern (concat "org-babel-default-header-args:"
,lang)))
(heading (nth 4 (ignore-errors (org-heading-components
(link (when org-current-export-file
(org-make-link-string
(if heading
(concat org-current-export-file "::" heading)
org-current-export-file
(export-buffer (current-buffer)) results)
(when link
;; resolve parameters in the original file so that
;; headline and file-wide parameters are included, attempt
;; to go to the same heading in the original file
(set-buffer (get-file-buffer org-current-export-file))
(save-restriction
(condition-case nil
** (org-open-link-from-string link)
(error (when heading
(goto-char (point-min))
(re-search-forward (regexp-quote heading) nil t
(setq results ,@body))
(set-buffer export-buffer)
results)))
The line that blows up, AFAICT is the one marked with an asterisk. It goes to
look in the file *without* incorporated materials, instead of the file *with*
incorporated materials.
I believe that what needs to happen is that the link must be searched for in the
export-buffer, rather than in org-current-export-file.
Unfortunately, I don't understand the code well enough to figure out how to make
this modification. I believe that the first trick is to NOT concatenate
org-current-export-file onto the link string. The second would be to change
org-open-link-from-string to something that looks for the link match in the
current buffer.
To see the bug, it should be sufficient to install the attached to .org files
into a temporary directory and then try to export foo.org to latex. You may
need to tweak your configuration so that evaluation is enabled for sh scripts
(require 'ob-sh)
The error messages one gets are deeply cryptic. To debug this I modified
org-link-search as follows. I added a DEBUG call when the link is unfound.
This is, of course, not generally good practice, but you will want this debug
call in place when you test the export per my instructions above. You will get
a debug window with a backtrace that should make things relatively clear. Here
is the modified org-link-search --- you can just evaluate the definition before
testing the export. To see what I've changed, just search for debug...
Cheers,
r
(defun org-link-search (s &optional type avoid-pos)
"Search for a link search option.
If S is surrounded by forward slashes, it is interpreted as a
regular expression. In org-mode files, this will create an `org-occur'
sparse tree. In ordinary files, `occur' will be used to list matches.
If the current buffer is in `dired-mode', grep will be used to search
in all files. If AVOID-POS is given, ignore matches near that position."
(let ((case-fold-search t)
(s0 (mapconcat 'identity (org-split-string s "[ \t\r\n]+") " "))
(markers (concat "\\(?:" (mapconcat (lambda (x) (regexp-quote (car x)))
(append '(("") (" ") ("\t") ("\n"))
org-emphasis-alist)
"\\|") "\\)"))
(pos (point))
(pre nil) (post nil)
words re0 re1 re2 re3 re4_ re4 re5 re2a re2a_ reall)
(cond
;; First check if there are any special search functions
((run-hook-with-args-until-success 'org-execute-file-search-functions s))
;; Now try the builtin stuff
((and (equal (string-to-char s0) ?#)
(> (length s0) 1)
(save-excursion
(goto-char (point-min))
(and
(re-search-forward
(concat "^[ \t]*:CUSTOM_ID:[ \t]+" (regexp-quote (substring s0
1)) "[ \t]*$") nil t)
(setq type 'dedicated
pos (match-beginning 0
;; There is an exact target for this
(goto-char pos)
(org-back-to-heading t)))
((save-excursion
(goto-char (point-min))
(and
(re-search-forward
(concat "<<" (regexp-quote s0) ">>") nil t)
(setq type 'dedicated
pos (match-beginning 0
;; There is an exact target for this
(goto-char pos))
((and (string-match "^(\\(.*\\))$" s0)
(save-excursion
(goto-char (point-min))
(and
(re-search-forward
(concat "[^[]" (regexp-quote
(format org-coderef-label-format
Re: [O] Images in included files
I'm having exactly this same problem. I have a file, suggestions.org, in directory ~/x/y/z/top/child/ that contains many images. These are included by means of links such as [[./foo.pdf]] Now, I have a parent file in top/, manual.org, and I want to #+include "child/suggestions.org" Unfortunately, this breaks all the figure links in suggestions.org, because "." is interpreted as top/ and not top/child/. Even more unfortunately, this is a shared document, and a number of people are going to check it out from a source code repository (subversion in this case). This means that I cannot specify the images as ~/x/y/z/top/child/foo.pdf because I cannot force my co-authors to check out the top/ to ~/x/y/z. Indeed, I cannot even force my co-authors to have directories x/ x/y or x/y/z... So what is needed, I believe is some way of indicating that these relative links should be resolved at *include* time, rather than later. I am pretty sure that this is the same problem John Tait alludes to, with some more details. Best, Robert
Re: [O] Bug in latex export of <>
On 4/29/11 Apr 29 -4:07 PM, Robert Goldman wrote:
> I have this header in my org-mode file:
>
> Documentation <>
>
> it gets translated into the following, which formats poorly:
>
> \item Documentation \label{documentationPseudoProp}documentationPseudoProp\\
>
> Any idea why this would happen? Seems like a bona fide bug, but perhaps
> I'm just doing something wrong.
This block of org-latex seems to have the problem in it:
(while (re-search-forward
(concat "<<>>?\\((INVISIBLE)\\)?") nil t)
(org-if-unprotected-at (+ (match-beginning 0) 2)
(replace-match
(concat
(org-export-latex-protect-string
(format "\\label{%s}" (save-match-data (org-solidify-link-text
(match-string 1)
* (if (match-string 2) "" (match-string 1)))
t t)))
I suspect that the "INVISIBLE" up there indicates some way I am supposed
to flag this as a non-printing link, but there's no documentation
(AFAICT) about this. Anyone know what that's supposed to do?
The manual suggests putting these targets in comments, but that only
works for HTML export --- if you do that in LaTeX export, the \label{}
command gets commented out! Finding a solution that works equally well
in HTML and LaTeX export would be a good thing, I think.
Commenting out the starred s-expression in the block above would
probably fix my problem, but I have no way of telling what collateral
damage there might be. Can anyone clarify?
If someone can fill me in, I will supply a patch to either the manual or
the code, whichever is appropriate
thanks!
r
[O] Collaboration and settings --- was Re: bug in latex export tutorial?
On 4/30/11 Apr 30 -5:14 PM, Eric S Fraga wrote:
> Robert Goldman writes:
>
>> On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
>
> [...]
>
>>> amsmath conflicts with wasysym (redefines \iint), so you have to
>>> redefine your headers to omit wasysym or include amsmath *first*: for
>>> some reason, if you \usepackage{amsmath} *before* you
>>> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
>>> assumes that \iint is not defined beforehand, whereas wasysym does not
>>> make that assumption.
>>
>> The not-very-tasty solution I came up with was to put the following into
>> the local variables list at the foot of my file:
>>
>> # org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
>> "fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
>> ("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
>> "textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
>> "latexsym" t) ("" "amssymb" t)
>> ("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
>> "hyperref" nil) "\\tolerance=1000")
>>
>> I put this in the file, rather than in my configuration, because it is
>> specific to the formatting of this file, and because I share this
>> document with others, who need to be able to export from it w/o having
>> to reconfigure their org-mode installations.
>>
>> I figure that someone can probably suggest a solution that is nicer than
>> that!
>>
>> Best,
>> r
>
> From earlier this year on the mailing list, below is a solution
> which works if you more often than not want amsmath; i.e. it's not a
> solution for the use case you specify in which you want to share a
> single file etc. However, it's worth repeating this solution for other
> use cases.
Is there any documentation any where about how people use Org-mode in
collaborative authoring? I find myself not on solid ground
understanding how to ensure that my colleagues have the same
configuration. For now, I resort to entries in the local variables
list, but this may not be the best solution
One could hijack the directory locals, but that seems like The Wrong
Thing --- we should leave that to the individual user for his/her
preferences. Possibly set up something that would be layered, so that
there are dir-locals that optionally load user-specific settings /after/
the dir-locals (i.e., a second layer of dir-locals)?
Is anyone else trying to do stuff like this?
best,
r
[O] Bug in latex export of <>
I have this header in my org-mode file:
Documentation <>
it gets translated into the following, which formats poorly:
\item Documentation \label{documentationPseudoProp}documentationPseudoProp\\
Any idea why this would happen? Seems like a bona fide bug, but perhaps
I'm just doing something wrong.
best,
r
[O] Bug Re: [PATCH] Make the latex export preprocessor rewrite #+INDEX to \index.
Drat. This patch isn't quite right; it mis-handles typeface
specifications. E.g.
#+index: =Class=
generates an index entry for =Class= instead of an entry for "Class" set
in monospace font.
Maybe someone who understands the intricacies of exporting can figure
out a fix. The problem is likely to be the fact that my \index{=Class=}
is protected from the font rewriting.
Any suggestions?
Best,
r
Re: [O] bug in latex export tutorial?
On 4/29/11 Apr 29 -1:21 PM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote:
>>> Aloha Robert,
>>>
>>> Yep. It should be "One of these, amssymb, requires amsmath, which
>>> conflicts with several LaTeX fonts."
>>
>> I don't /believe/ amssymb requires amsmath. I have been working on a
>> document where I wanted to use some of the stuff in amsmath (e.g.,
>> \text, align environment). That document did /not/ parse, even though
>> amssymb *is* in the preamble of the exported file. I looked, and the
>> preamble has amssymb, but not amsmath.
>>
>> It would be *great* if someone could provide tutorial information that
>> would tell us:
>>
>> 1. How do we configure a file so that it *can* use amsmath?
>
> amsmath conflicts with wasysym (redefines \iint), so you have to
> redefine your headers to omit wasysym or include amsmath *first*: for
> some reason, if you \usepackage{amsmath} *before* you
> \usepackage{wasysym}, the error does not arise -- presumably, amsmath
> assumes that \iint is not defined beforehand, whereas wasysym does not
> make that assumption.
The not-very-tasty solution I came up with was to put the following into
the local variables list at the foot of my file:
# org-export-latex-default-packages-alist: (("AUTO" "inputenc" t) ("T1"
"fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t) ("" "longtable" nil)
("" "float" nil) ("" "wrapfig" nil) ("" "soul" t) ("" "t1enc" t) (""
"textcomp" t) ("" "marvosym" t) ("" "amsmath" t) ("" "wasysym" t) (""
"latexsym" t) ("" "amssymb" t)
("colorlinks=true,pdfstartview=FitV,linkcolor=blue,citecolor=blue,urlcolor=blue"
"hyperref" nil) "\\tolerance=1000")
I put this in the file, rather than in my configuration, because it is
specific to the formatting of this file, and because I share this
document with others, who need to be able to export from it w/o having
to reconfigure their org-mode installations.
I figure that someone can probably suggest a solution that is nicer than
that!
Best,
r
Re: [O] bug in latex export tutorial?
On 4/29/11 Apr 29 -11:44 AM, Thomas S. Dye wrote: > Aloha Robert, > > Yep. It should be "One of these, amssymb, requires amsmath, which > conflicts with several LaTeX fonts." I don't /believe/ amssymb requires amsmath. I have been working on a document where I wanted to use some of the stuff in amsmath (e.g., \text, align environment). That document did /not/ parse, even though amssymb *is* in the preamble of the exported file. I looked, and the preamble has amssymb, but not amsmath. It would be *great* if someone could provide tutorial information that would tell us: 1. How do we configure a file so that it *can* use amsmath? 2. What happens to the parallel HTML export if we use amsmath constructs in an org file? thanks! r > > Thanks for pointing this out. > > All the best, > Tom > > On Apr 29, 2011, at 6:26 AM, Robert Goldman wrote: > >> The document http://orgmode.org/worg/org-tutorials/org-latex-export.html >> claims >> >> "The Org-mode LaTeX exporter uses several packages to support special >> characters used by org-entities. One of these, amsmath, conflicts with >> several LaTeX fonts. If you want finer control over which packages are >> loaded, then it makes sense to define an export class like this in >> .emacs:" >> >> But I just checked the results of exporting one of my org files, and it >> does /not/ use amsmath. >> >> Is this a bug in the tutorial? >> >> >
[O] bug in latex export tutorial?
The document http://orgmode.org/worg/org-tutorials/org-latex-export.html claims "The Org-mode LaTeX exporter uses several packages to support special characters used by org-entities. One of these, amsmath, conflicts with several LaTeX fonts. If you want finer control over which packages are loaded, then it makes sense to define an export class like this in .emacs:" But I just checked the results of exporting one of my org files, and it does /not/ use amsmath. Is this a bug in the tutorial?
Re: [O] Patch --- adding an easy template for #+index
On 4/28/11 Apr 28 -2:11 PM, Bernt Hansen wrote: > rpgold...@sift.info writes: > >> The next message will contain a patch that provides a new easy template for >> adding index entries, per Nick Dokos's suggestion. > > Hi Robert, > > Just a FYI: you can include the above information right in your patch > after the --- and before the diffstat like this: I have been using git send-email, and the only option I understand is the --compose one, which generates these predecessor emails. Are you sending an email with a different client and then attaching the patch files? Or something else? > > --8<---cut here---start->8--- > ... > just made the Muse equivalent of #+index be #+index. I don't know > org-mtags enough to know if this is appropriate. > --- > The next message will contain a patch that provides a new easy template > for adding index entries, per Nick Dokos's suggestion. > > Any text you put in here after the '---' and before the diffstat is > discarded by the git tools that apply the patch. This is a great place > to add extra comments and details that do not belong in the commit > message itself. > > lisp/org.el |9 ++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/lisp/org.el b/lisp/org.el > ... > --8<---cut here---end--->8--- > > Regards, > Bernt
Re: [O] [PATCH] Make the latex export preprocessor rewrite #+INDEX to \index.
My mistake -- I made the template wrong; it wasn't a case-fold issue, after all. I have a patch that will do this now. Will post it soon. Cheers, r
Re: [O] [PATCH] Make the latex export preprocessor rewrite #+INDEX to \index.
On 4/28/11 Apr 28 -7:33 AM, Nick Dokos wrote: > rpgold...@sift.info wrote: > >> From: Robert P. Goldman >> >> --- >> lisp/org-latex.el | 13 + >> 1 files changed, 13 insertions(+), 0 deletions(-) >> ... > > Very nice! Did a small test and it works as advertised. > > Suggestion: maybe add an "I" easy template for it? This can be done > per-user of course, so it is not strictly necessary and easy templates > are experimental anyway, but it might be a good idea to reserve the "I" > for this. Actually, it might be better to reserve "i" for this and > shift the include to "I", since there will only be a few includes but > potentially hundreds of index entries in a file. I'm not sure that this is feasible. I tried doing this and as far as I can tell the template matching is not case-sensitive. I could wrap the string-match there in a (let ((case-fold-search nil)) ...) but I'd like some advice from a core maintainer before doing this (I'll check in on IRC, too). I've got a patch ready if that's the right way to go. cheers, r
Re: [O] Making an index in latex export --- surprisingly difficult
On 4/28/11 Apr 28 -4:28 AM, Eric S Fraga wrote:
> Robert Goldman writes:
>
> [...]
>
>> I looked at that thread and unfortunately it petered out (partly because
>> it went off into a different direction to solve an easier problem with
>> conflicting style files).
>>
>> The last message from Eric Fraga states:
>>
>>> Oh well, there goes that theory. The web link you gave yesterday
>>> would seem to indicate that the problem is present if you invoke the
>>> bibtex command from another directory and this does not appear to be
>>> the case here. Very strange.
>>
>> It's not actually invoking the bibtex command from another directory,
>> AFAICT, but invoking the bibtex command on an argument that is an
>> /absolute/ pathname. This is now forbidden for makeindex and bibtex (I
>> don't know if it's permitted for pdflatex or not, but I suspect it is,
>> since the pdflatex part of the export process is working --- pdflatex
>> may not honor openout_any=p).
>
> If the file is indeed in the /current/ directory, then a simple fix may
> be to use %b for the file argument to makeindex? I have no problems
> with bibtex using
>
> ,
> | org-latex-to-pdf-process is a variable defined in `org-latex.el'.
> | Its value is ("pdflatex %f" "bibtex %b" "pdflatex %f" "pdflatex %f")
> `
>
> Note the use of %b instead of %o or %f. I've never used makeindex so
> cannot be sure this would work.
>
No, actually this does not work, since the expansion of %b is still an
absolute pathname, rather than a relative pathname. The only difference
is that the file extension is removed. Here's a snippet from my
*trace-output* buffer when I trace the shell-command function:
command="makeindex -o
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.idx"
The entry from my org-latex-to-pdf-process is:
"makeindex -o %b.ind %b.idx"
So using the basename is orthogonal to the underlying problem, which is
that absolute pathnames are always used.
When I restore the openout_any = p setting, I see:
rpg% makeindex -o
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.idx
makeindex: Not writing to
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind
(openout_any = p).
Can't create output index file
/Users/rpg/obtw/obtw-trunk/memos/plan-representation/manual.ind.
Note that this isn't something one needs any org-mode testing to verify
--- you can just figure out what %b will expand to, and test
interactively with the shell using makeindex or bibtex, if you have a
recent texlive, with the paranoid settings.
The only "solution" I know (aside from disabling the texmf.cnf security
setting) would be to have org ensure that its CWD is the document
directory when running these programs and use relative pathnames. I
don't know that this solution is compatible with correct use of
EXPORT_FILE_NAME, however
This seems like a very crippling security setting -- it would break many
plausible uses of the tex suite when they are run under program control
(I could easily imagine scenarios with make that would result in the use
of absolute pathnames, too); I'm surprised it was made.
Best,
r
Re: [O] Making an index in latex export --- surprisingly difficult
On 4/26/11 Apr 26 -6:14 PM, Nick Dokos wrote: > Robert Goldman wrote: > >>>> 2. put in \index commands (I don't /believe/ #+INDEX works, but I could >>>> be wrong) >> >> Am I right about #+INDEX not being translated in the latex back end (it >> seems not to work, but it's hard to verify a negative)? >> > > Seems to be a publishing thingie only. ...snip... Working on a patch to org-latex that will translate #+INDEX: So far it's a little more difficult than I'd hoped. If we have that, then adding something to automagically invoke the right latex fu to accumulate and print the index should be relatively trivial. Even adding a new export method should be ok (modulo fixing the general bibtex + makeindex privs issue). R
Re: [O] Making an index in latex export --- surprisingly difficult
On 4/26/11 Apr 26 -4:52 PM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> I was trying to make an index in latex export and found that it was very
>> difficult to make it work. I wonder if this could be simplified.
>> Here's what I had to do:
>>
>> 2. put in \index commands (I don't /believe/ #+INDEX works, but I could
>> be wrong)
Am I right about #+INDEX not being translated in the latex back end (it
seems not to work, but it's hard to verify a negative)?
If so, would this be hard to fix? If it wouldn't, seems like that would
be A Good Thing.
>> 4. Modify the org-latex-to-pdf-process to
>>
>> ("pdflatex -interaction nonstopmode -output-directory %o %f" "makeindex
>> -o %b.ind %b.idx" "pdflatex -interaction nonstopmode -output-directory
>> %o %f" "pdflatex -interaction nonstopmode -output-directory %o %f")
>>
>> [This was /somewhat/ of a big deal. Suggest we add support for indexing
>> as a built-in option, like bibtex...]
>>
>
> Maybe you can try the texi2dvi option (I think it runs makeindex), but
> texi2dvi did have a bug that has caused problems here in the past:
> that's the reason it's not the default setting for
> org-latex-to-pdf-process. If you run into the bug but still want to try
> texi2dvi anyway, see
>
> http://lists.gnu.org/archive/html/bug-texinfo/2010-03/msg00032.html
>
> for the fix Karl Berry applied to the development sources.
Once one has makeindex hacked in there (oh, and you've broken the
security!), it works fine, thanks.
>
>> 5. The REAL big deal: edit my texmf.cf file to break the security
>> protection of openout_any=p. By default, makeindex will refuse to open
>> an absolute pathname. But org-mode will only pass absolute pathnames to
>> makeindex (AFAICT). Question: it seems like bibtex should suffer from
>> this same restriction. Has anyone had that problem with it?
>>
>
> I haven't had the problem, primarily because I haven't used bibtex
> through org yet :-) But bibtex should exhibit the same problem: the
> bibtex change predated the makeindex one. Maybe bibtex is only called
> with a relative path (if that's the case, then the same method should
> cure makeindex as well). BTW, ".." is not allowed in the relative path:
> you can only use subdirectories of the current directory.
>
> Nick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: [O] Making an index in latex export --- surprisingly difficult
On 4/26/11 Apr 26 -4:26 PM, Suvayu Ali wrote: > On Tue, 26 Apr 2011 16:09:22 -0500 > Robert Goldman wrote: > >> The REAL big deal: edit my texmf.cf file to break the security >> protection of openout_any=p. By default, makeindex will refuse to >> open an absolute pathname. But org-mode will only pass absolute >> pathnames to makeindex (AFAICT). Question: it seems like bibtex >> should suffer from this same restriction. Has anyone had that >> problem with it? > > I did and no clean solution has been found yet. > http://thread.gmane.org/gmane.emacs.orgmode/38247/focus=38562 > > HTH > I looked at that thread and unfortunately it petered out (partly because it went off into a different direction to solve an easier problem with conflicting style files). The last message from Eric Fraga states: > Oh well, there goes that theory. The web link you gave yesterday would seem > to indicate that the problem is present if you invoke the bibtex command from > another directory and this does not appear to be the case here. Very strange. It's not actually invoking the bibtex command from another directory, AFAICT, but invoking the bibtex command on an argument that is an /absolute/ pathname. This is now forbidden for makeindex and bibtex (I don't know if it's permitted for pdflatex or not, but I suspect it is, since the pdflatex part of the export process is working --- pdflatex may not honor openout_any=p). I don't see why, per the discussion in the texlive distribution notes, it should matter that you change the TEXMF pathname environment variable, since makeindex isn't doing any metafonting! I also don't see any obvious way for programs like org-mode to adapt to this except possibly by explicitly changing their working directory to be the working directory of the org files and then using relative pathnames instead of absolute ones. And I would like to say right now that I don't have the FOGGIEST idea what that would mean on Windows, which seems to think about working directories somewhat differently! Best, r
[O] Making an index in latex export --- surprisingly difficult
I was trying to make an index in latex export and found that it was very
difficult to make it work. I wonder if this could be simplified.
Here's what I had to do:
1. put \makeindex and \usepackage{makeidx} in latex export header [no
big deal]
2. put in \index commands (I don't /believe/ #+INDEX works, but I could
be wrong)
3. Put a \printindex in the end. [again, no big deal]
4. Modify the org-latex-to-pdf-process to
("pdflatex -interaction nonstopmode -output-directory %o %f" "makeindex
-o %b.ind %b.idx" "pdflatex -interaction nonstopmode -output-directory
%o %f" "pdflatex -interaction nonstopmode -output-directory %o %f")
[This was /somewhat/ of a big deal. Suggest we add support for indexing
as a built-in option, like bibtex...]
5. The REAL big deal: edit my texmf.cf file to break the security
protection of openout_any=p. By default, makeindex will refuse to open
an absolute pathname. But org-mode will only pass absolute pathnames to
makeindex (AFAICT). Question: it seems like bibtex should suffer from
this same restriction. Has anyone had that problem with it?
Cheers,
r
Re: [O] Patch for org-babel manual node
On 4/21/11 Apr 21 -3:56 PM, Eric Schulte wrote: > Patch appears to be missing, could you resend? Hope this will go through better LMK if you don't get it. > > Thanks -- Eric > > "Robert P. Goldman" writes: > >> There was a bug in an example of argument passing in the org-babel >> part of the manual. Fixed in the following patch. >> >> > >From 31bd57dc0a904ca0b42f46dd1c10fc772c678343 Mon Sep 17 00:00:00 2001 From: Robert P. Goldman Date: Thu, 21 Apr 2011 12:09:57 -0500 Subject: [PATCH] Fixed shell script example in "Emacs Lisp evaluation of variables." The variable names in the header arguments and in the sh code didn't line up. Made them agree. --- doc/org.texi |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index 17922d4..e68ed18 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -12072,8 +12072,8 @@ org-mode file, while there is no such guarantee for evaluation of the code block body. @example -#+begin_src sh :var file-name=(buffer-file-name) :exports both - wc -w $file +#+begin_src sh :var filename=(buffer-file-name) :exports both + wc -w $filename #+end_src @end example -- 1.7.3.5
Re: [O] include an .org file and lower the level of all its headers
This is a feature that I was just looking for, and I'm pretty excited about it. However, I find that providing this new facility leads me to look for another one: relativizing links. It seems like when I include another file, the links in that other file get messed up. In particular, I have figures in the sub-file, and AFAICT it looks like the sub-files file links aren't working correctly. Or maybe that's not what's really wrong: the symptoms I am seeing are missing pdfs + a blizzard of warnings that look like this: No match - create this as a new heading? (y or n) I suspect that this message is intended to be seen at a time when its meaning will be more obvious to the user. Any suggestions? thanks, r
Re: [O] Illiterate programming question
On 3/30/11 Mar 30 -4:33 PM, Nick Dokos wrote: > Robert Goldman wrote: > >> I would like to do the opposite of literate programming (hence the >> subject line!): >> >> I would like to pull into my org file snippets from a code file. I know >> that org-mode will let me import /entire/ source code files. Is there >> some way to say "Import the region of this file between these two >> delimiters?" >> >> If not, do you think it would be hard to add this feature? I already >> have the snappy name, after all! >> > > I don't really understand: can't you cut and paste? Yes, but if I cut and paste the text of the code that I am describing may change out from under my text. If I import the code, it stays in sync (at least when the document is exported). Honestly, I was tempted to do the literate programming thing with babel, but was concerned that it might not work well as a multiple-author thing (I would be writing the document, but someone else might be modifying the code and might find org-babel confusing). > > And what do you mean that "org-mode will let me import /entire/ source code > files"? Is this a facility other than insert-file? Or are you talking about > the #+INCLUDE mechanism? Yes, I was talking about #+INCLUDE. I was really wondering if there mightn't be something like #+INCLUDE ~/myfile.lisp :from "(defun sample-function" :to "; end sample-function" [sorry --- that's word-wrapped to further obscurity.] cheers, r
[O] Illiterate programming question
I would like to do the opposite of literate programming (hence the subject line!): I would like to pull into my org file snippets from a code file. I know that org-mode will let me import /entire/ source code files. Is there some way to say "Import the region of this file between these two delimiters?" If not, do you think it would be hard to add this feature? I already have the snappy name, after all! Best, r
Re: [O] Having problem with latex export of image file
On 3/17/11 Mar 17 -4:35 AM, Bastien wrote: > Hi Nick, > > Nick Dokos writes: > >> I didn't look very hard, but I didn't find documentation on these. > > If Robert or you can provide a documentation patch for this, it would > be nice. It's not (only) laziness from me: since you stumbled on the > issue, I guess you can better explain what is at stake. > > Thanks! > I'm ordinarily willing to chime in with a manual patch, but this seems odd enough that I wonder if there isn't a bug that needs fixing. In particular, it seems very weird to me that the latex exporter would treat un-directoried pathnames as files to be exported as links rather than inline images *even if there is a #+CAPTION present*. Is it worth re-examining this, instead of documenting it? cheers, r
Re: [O] Having problem with latex export of image file
X-TagToolbar-Keys: D20110315084847273
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 3/15/11 Mar 15 -12:04 AM, Nick Dokos wrote:
> Robert Goldman wrote:
>
>> I have the following in my org file:
>>
>> #+CAPTION: Sample (partial) plan graph.
>> #+LABEL: fig:sampleGraph
>> #+ATTR_LaTeX: width=.9\textwidth
>> [[plan-with-tc-start.pdf]]
>>
>> which I believe should give me a figure. However, when I run this
>> through the latex export I get the following instead:
>>
>> \hyperref[plan-with-tc-start.pdf]{plan-with-tc-start.pdf}
>>
>> I pushed "pdf" onto image-file-name-extensions but that doesn't seem to
>> make any difference.
>>
>> I figure there's something simple I'm doing wrong, but I can't figure
>> out what that is.
>>
>> Thanks for any advice!
>>
>
> Try
>
> [[./plan-with-tc-start.pdf]]
Thanks. That did fix it. Question: what's the rule about file names
here? Is it that there must be a non-empty directory part? Or
something else?
A second question: is there any way to set image file extensions /on a
per-file basis/? It seems to me, for example, to be quite likely that
in some files PDF should be treated as images (since I use pdflatex, pdf
seems like the best choice for images), whereas in others maybe not...
But it seems like image-file-name-extensions is not something that is
expected to be buffer-local
best,
r
[O] Having problem with latex export of image file
I have the following in my org file:
#+CAPTION: Sample (partial) plan graph.
#+LABEL: fig:sampleGraph
#+ATTR_LaTeX: width=.9\textwidth
[[plan-with-tc-start.pdf]]
which I believe should give me a figure. However, when I run this
through the latex export I get the following instead:
\hyperref[plan-with-tc-start.pdf]{plan-with-tc-start.pdf}
I pushed "pdf" onto image-file-name-extensions but that doesn't seem to
make any difference.
I figure there's something simple I'm doing wrong, but I can't figure
out what that is.
Thanks for any advice!
best,
r
[Orgmode] Re: convert orgmode to docx --- using odt export
Question: is this only usable in a stand-alone emacs, or can we load the exporter into our normal orgmode configuration? I suspect from reading that a merge will be difficult that we must use this outside our standard environment, but just wanted to be sure Thanks, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] OrgCamp in Minneapolis/St. Paul
There's a lisp users group here in the Twin Cities (Twin Cities Lispers --- tclispers.org). I think that would be a good venue to have an OrgCamp, if there is sufficient interest. Feel free to contact me off line if this sounds interesting. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: EmacsForMacOSX - copy & paste in orgmode
On 8/18/10 Aug 18 -5:01 AM, Erwin Panen wrote: > Hi Juan, > > I hope you don't mind me mailing you directly. I copied orgmode list in cc. > > Do you have a way to copy / paste between say Firefox and Emacs / orgmode? > > It doesn't seem to work, and I've found some posts googling, but no > apparent solution. It seems Acquamacs will do it, so I'd assume it's a > matter of configuring .emacs? I find the easiest way to do this in emacs is NOT to make the command key into meta. That way I still have the Cmd-C, Cmd-X and Cmd-V keys that work the same inside and outside Aquamacs. If I do this, I can simply use Cmd-C in, e.g., firefox, then go to aquamacs and do Cmd-V, just like any other pair of mac applications. I find having clear access to BOTH the emacs and mac cut buffers much less confusing than trying to make them stick together. (I don't like smooshing the X and emacs cut buffers together on linux, either). This is very much a minority opinion, but you could try it, and see if it works for you. If you want to try it, you can use the Aquamacs menu Options > Option, Command, Meta keys > Option is meta If you make heavy use of accents in your emacs, this is a losing choice, though. I don't, because any serious text I compose will be in latex, anyway. Cheers, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Quick note about subtree copy and paste
On 1/11/11 Jan 11 -8:03 AM, Giovanni Ridolfi wrote: > Robert Goldman writes: > >> I just did a copy and paste and noticed that when I did so the copied >> properties included the ID which, after being copied, meant that the >> unique identifier became a non-unique identifier. > Well, you shouldn't ! ;-) > > If you have to copy/paste a subtree, please... *clone* it. > > manual: Structure editing: > > `C-c C-x c' (`org-clone-subtree-with-time-shift') > > (then the :ID: is changed) > > Giovanni I get the point, but the current presentation is unnecessarily confusing. I was just /copying/ --- there was no time shifting involved, so when I look at them menu and see "copy" and "clone with time shift," it is "copy" that's what I naturally do. Actually, as I look at the manual I see: `C-c C-x c' (`org-clone-subtree-with-time-shift') Clone a subtree by making a number of sibling copies of it. You will be prompted for the number of copies to make, and you can also specify if any timestamps in the entry should be shifted. This can be useful, for example, to create a number of tasks related to a series of lectures to prepare. For more details, see the docstring of the command `org-clone-subtree-with-time-shift'. There's nothing there to even remotely suggest to me that this is going to Do The Right Thing about properties. It's all about dates and time-shifting. It may /happen/ to do the right thing with properties, but it sure doesn't /say/ that it will. The ID property is mentioned only in the interactive docstring, and pretty deeply down. I'd like to make a somewhat radical suggestion: If cloning is the primary option, and more safe than copy --- i.e., if copy is "this is the primitive operation that you should only do if you know what you are doing, because it might corrupt data," then I would argue that it's CLONE that should be bound to C-c C-x M-y --- the standard emacs keybinding I'm going to go to first --- and COPY should be demoted to the less-familiar alternative. This assumes that the answer to "Is there any case where I should do copy and /not/ prefer clone?" is "no." But I'm not sure that's the case. They clone doesn't do the same thing to the cut buffer as copy, does it? e.g., I don't use clone to make a copy of a subtree from file A into file B. Even more radical suggestion: So maybe the right answer is not to ask us to use clone all the time, but that COPY and PASTE should be fixed to Do The Right Thing with the ID property. Best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Quick note about subtree copy and paste
I just did a copy and paste and noticed that when I did so the copied properties included the ID which, after being copied, meant that the unique identifier became a non-unique identifier. Is it work tweaking the org-paste-special command to rip out ID properties? cheers, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Request for suggestions: multiple revision control systems/repositories + org
On 12/20/10 Dec 20 -1:03 AM, Rémi Vanicat wrote: > "Robert P. Goldman" writes: > >> That is what I had done originally, but I thought mobile org required that >> all the org files be in the same directory. Was I wrong about that? >> > > I've org files in several directories, and in `org-agenda-files’, and > with a relatively recent org-mode files org-mobile just work. It is > `org-mobile-push’ and `org-mobile-pull’ that put a copy of all this in > `org-mobile-directory’. > Thanks. I did what I should have before and read org-mobile-push, and it seems clear that the org-directory variable just /allows/ me to have relative path names. It doesn't /require/ me to have all the org files located in that directory, as long as I use absolute file names. This will make things much easier to deal with between org-mode and vc-mode. Thanks, everyone. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Request for suggestions: multiple revision control systems/repositories + org
I am looking for hints. I have a number of org files, typically one for each major project plus two or three for my personal life. These must often live in different revision control systems: my work projects, in particular, have different repositories; I have a main set of org files for work in ~/org/, tracked by my employers' svn; occasionally, I do something outside, like work on a paper with someone outside my company in a dedicated git repo; and I'd like to stuff my personal materials off in a git repo of my own. I have been pulling all of these together into my ~/org directory, using symbolic links, for the benefit of mobile org. That is, my ~/org directory has my main work org files, plus links to a bunch of others. That works well for syncing with mobile org. Unfortunately, it's a mess for Emacs's version control mode. VC mode sees the .svn directory in that place, and can handle the local files, but gets horribly confused by the sym-linked files. Anyone have a similar need to gather together a mess of org files, and have a cleaner solution? Extra credit if you have a way of creating the same set of symlinks on more than one machine! ;-) Thanks to all, Robert ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] bug in docstring for org-emphasis-regexp-components (org.el)
The docstring says: "...This is a list with 6 entries pre Chars allowed as prematch. Beginning of line will be allowed too. post Chars allowed as postmatch. End of line will be allowed too. border The chars *forbidden* as border characters. body-regexp A regexp like "." to match a body character. Don't use non-shy groups here, and don't allow newline here. newline The maximum number of newlines allowed in an emphasis exp. ..." That looks like 5 entries to me. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Having problems with faces in org agenda
On 9/30/10 Sep 30 -2:34 PM, Robert Goldman wrote:
> My org agendas for day and week are showing DONE items with the "DONE"
> in red, and not dulled out. This makes the agenda less useful than it
> might be for at-a-glance planning.
>
> This (bright red "DONE"s) does not happen when I am looking at an org
> file, where the TODO keyword is red and the DONE keyword is green.
I know it's bad form for me to follow-up to my own post, but I have
another piece of information.
I have two ways of getting at the day's agenda. The ordinary org-agenda
command, "a", and then I can choose a day or week.
I wanted to make shortcuts to just directly choose the day's or week's
agenda. So I added these:
("D" "Today's tasks"
((agenda))
((org-agenda-ndays 1)))
("W" "This week's tasks"
((agenda))
((org-agenda-ndays 7)))
to org-agenda-custom-commands.
These are the commands that are causing me pain. If I use normal
org-agenda and choose either day or week, the org faces are fine.
If I use the D or W special commands I have defined above, I get the
wrong faces, with DONE shown in red.
So is there something in the above configuration that's wrong, and that
causes the faces to go awry?
thanks,
r
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Meetup/conference
Since we're talking about meet-ups, I'd like to say it would be great to see an informal org-mode meet-up attached to other conferences one might attend. Not as an alternative to the Hawaii proposal, but as an "also." cheers, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] quotes inside code markup: bug?
I'm finding that, when I export as Latex or html, quoted strings don't get translated properly. I.e., a bit of text like ="foo"= will be translated literally, instead of turning into a code marked-up string. I am attaching a simple document of this type, and the results of export to latex. Export to HTML seems to give the same behavior. This seems like something that would happen to many people, so I wonder if it's a bug or if I'm failing to understand something. * Here's a headline with a quote in monospace ** A ="string"= in code sample-quote-bug.tex Description: TeX document ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Minor docstring bug: org-footnote-goto-previous-reference
The docstring for the command "org-footnote-goto-previous-reference" is Find the next previous of the footnote with label LABEL. ...which I can't actually parse. "Find the (immediately) previous reference to the footnote with label LABEL." Is that better? Cheers, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Bug (?) in org-capture
On 10/15/10 Oct 15 -1:48 AM, Carsten Dominik wrote: > Hi Robert, > > I cannot reproduce this error. If I set my default notes file to > "~/org//notes.org" > things seem to work just fine. I will see if I can figure out why this happened for me. I may not be able to do so, though --- it occurred when I had a half-configured org-capture, and now I have org-capture really working. It's not always easy to go back to the buggy state! Thank you very much for org-capture, BTW --- I really like the ability to dispatch on key combinations, in particular, since I find that the more I use org-capture, the more opportunities I see to get more value out of it. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Bug (?) in org-capture
On 10/14/10 Oct 14 -9:40 AM, Robert Goldman wrote: > I was trying to experiment for the first time using org-capture together > with w3m today, and I get an error. > > I invoke org-capture, and was pleased to find that it built me a buffer > just fine, and made an org link for the URL of the w3m buffer. So far, > so good. > > Unfortunately, when I try to save the buffer, either with C-c C-c or C-c > C-w, I get an error. > > The error is in org-capture-bookmark-last-stored-position. Here: > > (defun org-capture-bookmark-last-stored-position () > "Bookmark the last-captured position." > (let* ((where (org-capture-get :position-for-last-stored 'local)) > ) > > WHERE gets bound to NIL, the return of ORG-CAPTURE-GET, causing an error. > > I'm quite prepared to believe that I have this horribly misconfigured, > since I really didn't configure it at all, but it's disappointing that > the buffer creation works so well without configuration, but leaves me > in this pickle. It's also disappointing that the refile command doesn't > work --- any chance of hacking it so that it does something sensible (I > was thinking involving interactive selection) when org-capture is not > yet configured? > > AFAICT the direct cause of the error is that org-capture-current-plist > is NIL, and the 'local spec in this call means that we consult that > instead of org-capture-plist. > > At this point my ability to understand the code peters out, and I'm > afraid I don't have anything useful to say. Sorta never mind --- I figured out what the problem was. Somehow the default file for org-capture was ~/org//notes.org not ~/org/notes.org, so there was really a "file not found" error here. So this is, in a sense, user error. That said, if it's not too much trouble, maybe reporting a file not found error for this would be more helpful than crashing in this way. On the other hand, this might be tricky to find and handle, so maybe it's not worth the trouble. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug (?) in org-capture
I was trying to experiment for the first time using org-capture together with w3m today, and I get an error. I invoke org-capture, and was pleased to find that it built me a buffer just fine, and made an org link for the URL of the w3m buffer. So far, so good. Unfortunately, when I try to save the buffer, either with C-c C-c or C-c C-w, I get an error. The error is in org-capture-bookmark-last-stored-position. Here: (defun org-capture-bookmark-last-stored-position () "Bookmark the last-captured position." (let* ((where (org-capture-get :position-for-last-stored 'local)) ) WHERE gets bound to NIL, the return of ORG-CAPTURE-GET, causing an error. I'm quite prepared to believe that I have this horribly misconfigured, since I really didn't configure it at all, but it's disappointing that the buffer creation works so well without configuration, but leaves me in this pickle. It's also disappointing that the refile command doesn't work --- any chance of hacking it so that it does something sensible (I was thinking involving interactive selection) when org-capture is not yet configured? AFAICT the direct cause of the error is that org-capture-current-plist is NIL, and the 'local spec in this call means that we consult that instead of org-capture-plist. At this point my ability to understand the code peters out, and I'm afraid I don't have anything useful to say. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Any other Aquamacs + org-mode users?
On 10/12/10 Oct 12 -10:50 PM, Nick Dokos wrote: > Robert Goldman wrote: > >> If so, are any of you having trouble with the faces in agenda buffers? >> >> I'm finding that I get all of the todo keywords in what looks like the >> warning face --- bright red. It's a problem because it looks like the >> display is shouting at me about tasks that are DONE, not just ones that >> are still TODO. >> >> I don't see this problem in the ordinary org buffers. In those buffers >> the todo keywords are colored differently -- e.g., red for TODO and >> green for DONE. >> >> I was wondering if this is a misconfiguration on my part (I don't >> /think/ I have customized any aspect of org-mode display), or if there's >> some bad interaction between aquamacs (I'm using 2.1) faces and >> org-mode, or if I've misconfigured aquamacs, so it doesn't handle the >> org-mode faces properly. >> >> Any suggestions would be very welcome. >> > > C-u C-x = > > is your friend: it'll tell you some details about the face. That in turn > might provide a clue as to how it ended up this way. Disappointingly, it doesn't. When I drop the cursor onto a red "DONE" and do this, I see what looks like a correct set of face attributes, but the wrong face being selected. done-faceorg-agenda-done face org-todo todo-state [Show] txt "DONE RSVP about party" type "scheduled" undone-face org-scheduled-today So the faces seem to be configured right --- the done face is correctly set (and is the correct muted green), as is the org-todo face. The problem is that my "DONE" string is assigned the org-todo face and not the org-agenda-done face. So this is not a problem of the faces being set up wrong, but of their being assigned to text incorrectly. Anyone have any idea how I might fix that? Or please let me know if I have misdiagnosed this. thanks! r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Any other Aquamacs + org-mode users?
If so, are any of you having trouble with the faces in agenda buffers? I'm finding that I get all of the todo keywords in what looks like the warning face --- bright red. It's a problem because it looks like the display is shouting at me about tasks that are DONE, not just ones that are still TODO. I don't see this problem in the ordinary org buffers. In those buffers the todo keywords are colored differently -- e.g., red for TODO and green for DONE. I was wondering if this is a misconfiguration on my part (I don't /think/ I have customized any aspect of org-mode display), or if there's some bad interaction between aquamacs (I'm using 2.1) faces and org-mode, or if I've misconfigured aquamacs, so it doesn't handle the org-mode faces properly. Any suggestions would be very welcome. thanks! r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Worg buglet
The link to the sample presentation, from http://orgmode.org/worg/org-tutorials/org-beamer/tutorial.php to http://orgmode.org/worg/org-tutorials/org-beamer/presentation.org is broken. Sorry if this is the wrong place to report this. best, r ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
