Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi Christian, On 3/21/13, Christian Moe m...@christianmoe.com wrote: The new exporter adds paragraph breaks around the anchor for the marginal comment. This is the wrong behavior in all cases. These comments are meant to be anchored inside paragraphs that are not meant to be broken. (Using a fresh Org-mode version 8.0-pre on Emacs 24.3.1.) A similar issue arises with inline footnotes. Over the years I have built a lot of documents, each a subtree, that use them. To me, this naturally and definitely looks like a single paragraph with a 2-paragraph footnote, regardless of what the new exporter thinks: a[fn::b c] d e. In my case I was able with Nicolas's supplied code to create a hook that normalized footnotes before export. Maybe extracting in a hook will work for you. However, I fear that incorporating the parser into the font lock engine will break these paragraphs. :( Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] Different spacing in html output compared to info and pdf
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: The export framework usually treats differently empty string from nil output. Only in the former blank lines/white spaces are preserved. With this patch it will not be possible anymore to make this distinction with export snippets. What do you think? I think it is good, please go ahead! Thanks, -- Bastien
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Matt, Matt Lundin m...@imapmail.org writes: A 12-char width causes misalignment with a sample file and emacs -Q. (See output below). Indeed -- I fixed this, we're back to 11 chars. Thanks for reporting this and great to have you back :) -- Bastien
Re: [O] [PATCH] bugfix: fix `org-babel-execute-src-block' on remote hosts
Hi Suhail, Suhail Shergill suhailsherg...@gmail.com writes: see attached patch. Applied, thanks a lot for the detailed change log. PS: Please submit further patches against the master branch, not the maint branch. -- Bastien
Re: [O] Frustrated user of orgmode
Hi John, John Hendy jw.he...@gmail.com writes: That seemed to be my best guess, but it read more like a formal announcement vs. some of the more down and dirty finer-detailed Worg pages I've seen. Please amend this page as you want -- the target audience is users who will make the switch to Org 8.0. Give as many details as needed. The formal change logs will be on http://orgmode.org/Changes.html as usual, and this page will point to the Worg page for details. *Thanks* for any help in this area, it's badly needed! -- Bastien
Re: [O] Is Worg publishing?
Hi Tom, t...@tsdye.com (Thomas S. Dye) writes: I pushed some small additions to Worg yesterday, but they aren't showing on the web page. I just pushed a test change which shows fine, and I see yours is here: http://orgmode.org/worg/org-contrib/babel/languages.html (But I have noticed some hiccups too with previous changes.) Best, -- Bastien
Re: [O] Bug: View not returning to column 0 on fill while in truncate mode [7.9.3f (release_7.9.3f-17-g7524ef @ c:/emacs/lisp/org/)]
Hi Tom, thanks for the report. I don't understand why Org should set the view back to colummn 0 after filling. Does Org behaves differently than other major modes here? If not, I suggest this is a larger issue with Emacs, not really with Org. Thanks for further details, -- Bastien
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Bastien b...@altern.org writes: This is a problem with Org -- I have a patch for this on my local branch, but I will push this branch only tomorrow. Applied now, thanks. -- Bastien
Re: [O] Programmatically insert source-blocks
Hi Thorsten and Eric, Eric Schulte schulte.e...@gmail.com writes: I don't see that Org-mode itself will ever want to programatically and non-interactively insert a code block in an Org-mode file (if fact that sounds rather dangerous to me), so I would vote against adding such a function to the core. FWIW +1 here too. -- Bastien
Re: [O] [patch] LaTeX export using tabu tables
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: Attached is a non-clever version that includes a :spread keyword, and a (hopefully) correctly-written commit message. Thanks! I was surprised not to find you on the list of FSF-signed contributors -- did you assigned your copyright to the FSF already? If not, you'll need to go through this for the patch to be included I'm afraid... Thanks for letting us know. Best, -- Bastien
Re: [O] Versioning and releases
Hi Gustav, Gustav Wikström gustav.e...@gmail.com writes: As of this writing, the current version on orgmode.org says 7.9.4, but looking at the link of the zip-archive, it will download version 7.9.3f. Fixed, thanks. And the release-notes doesn't mention a version 7.9.4. Fixed too. On the same note. Looking in the README in the ZIP downloaded (7.9.3f that is), the document states that the version is 7.9.1. Deleted, thanks. To me this seems like a lot of unnecessary confusion about what is the current state of the software, and about which version I'm really downloading. Please have a look at the number fragmentation, make sure the links are correct, and that the version history (http://orgmode.org/ Changes.html) of the releases are updated to a current status. Thanks for raising this, best, -- Bastien
Re: [O] not found when refiling
Much more helpful, thank you! -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] Fixing footnote HTML
On 3/19/13, Bastien b...@altern.org wrote: It might be good to add a blank line after the Footnotes section. The default is fine IMHO. You'd need to define the #footnotes css id for this. I'm not familiar with CSS enough to know here. It wouldn't come for free with the header code? Here is what it looks like in Firefox: === Footnotes: 1 asdfasdfadf. === I expected text after Footnotes (hmm, I should remove the colon if possible) to be like text after any other section. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] Block agendas and filtering
On 3/19/13, Bastien b...@altern.org wrote: (org-agenda-tag-filter (+Tag)) org-agenda-filter-preset? -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] Fixing footnote HTML
Samuel Wales samolog...@gmail.com writes: I expected text after Footnotes (hmm, I should remove the colon if possible) to be like text after any other section. It is for me. Screenshots help a lot with those issues, especially when they are often not bugs, but small quirks wrt personal preferences. Thanks for sending screenshots if you can. Best, -- Bastien
[O] Setting taskjuggler project start date (ox-taskjuggler)
Having trouble setting the project start date, which results in a
build error since my project started before today, and the default
project start appears to be today's date. This was with no
customization to the top level headline. Intuitively, I added a
:start: property like so:
#+begin_src org
* Project :taskjuggler_project:
:PROPERTIES:
:start:2013-03-01
:END:
#+end_src
This results in (no change from exporting with no :start: property:
#+begin_src TJ
project nil Project 1.0 2013-03-25 +280d {
}
#+end_src
From digging around in ox-taskjuggler.el, it looks like the project
gets defined here:
#+begin_src ox-taskjuggler.el (line 607)
(defun org-taskjuggler--build-project (project info)
Return a project declaration.
PROJECT is a headline. INFO is a plist used as a communication
channel. If no start date is specified, start today. If no end
date is specified, end `org-taskjuggler-default-project-duration'
days from now.
(format project %s \%s\ \%s\ %s %s {\n}\n
(org-taskjuggler-get-id project info)
(org-taskjuggler-get-name project)
;; Version is obtained through :TASKJUGGLER_VERSION:
;; property or `org-taskjuggler-default-project-version'.
(or (org-element-property :VERSION project)
org-taskjuggler-default-project-version)
(or (org-taskjuggler-get-start project)
(format-time-string %Y-%m-%d))
(let ((end (org-taskjuggler-get-end project)))
(or (and end (format - %s end))
(format +%sd org-taskjuggler-default-project-duration)]
#+end_src
I'm no esliper, but I think I can track that the consecutive =%s=
arguments are replaced by the successive function calls. That, and
=org-taskjuggler-get-start project= looks like the ticket. That
function is here:
#+begin_src ox-taskjuggler.el (line 372)
(defun org-taskjuggler-get-start (item)
Return start date for task or resource ITEM.
ITEM is a headline. Return value is a string or nil if ITEM
doesn't have any start date defined..
(let ((scheduled (org-element-property :scheduled item)))
(and scheduled (org-timestamp-format scheduled %Y-%02m-%02d
#+end_src
So, that suggested that perhaps I needed to use :scheduled: instead of
:start:. I tried that with the same results. It appears that this
property /is/ applied at the task level for the top headline, however:
#+begin_src TJ
task project Project {
purge allocate
allocate jwhendy
start 2013-03-01
...
}
#+end_src
So, it applies :start: to the top level project in the /task/
definition area, but doesn't apply it to the very top level project
definition.
Any suggestions?
John
Re: [O] Frustrated user of orgmode
On Mon, Mar 25, 2013 at 12:16 AM, Bastien b...@altern.org wrote: Hi John, John Hendy jw.he...@gmail.com writes: That seemed to be my best guess, but it read more like a formal announcement vs. some of the more down and dirty finer-detailed Worg pages I've seen. Please amend this page as you want -- the target audience is users who will make the switch to Org 8.0. Give as many details as needed. That blanket permission helps... I started to add a walkthrough section at the end and then realized I was duplicating some notes you had in there, so I stopped as I didn't want to mess the document up too much. I may make a fairly liberal attempts at a re-org just to try and make sure the document still flows well as I add various things in that I encountered and think others might too. Thanks, John The formal change logs will be on http://orgmode.org/Changes.html as usual, and this page will point to the Worg page for details. *Thanks* for any help in this area, it's badly needed! -- Bastien
Re: [O] python sessions
Am 25.03.2013 03:59, schrieb John Hendy: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). John Thanks, Nick The python-mode(s) question should not be at stake, as in context it matters only for the choice, which command should start the Python shell - run-python or py-shell. All ob-python needs is a known buffer, commonly *Python*, connected to a python-process. This seems done by both modes, so don't expect the bug here. Andreas
Re: [O] Is Worg publishing?
Hi Bastien, Bastien b...@altern.org writes: Hi Tom, t...@tsdye.com (Thomas S. Dye) writes: I pushed some small additions to Worg yesterday, but they aren't showing on the web page. I just pushed a test change which shows fine, and I see yours is here: http://orgmode.org/worg/org-contrib/babel/languages.html (But I have noticed some hiccups too with previous changes.) There it is. Thanks. Nice to see the unicorn back to original colors :) All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] [patch] LaTeX export using tabu tables
Bastien b...@altern.org writes: Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: Attached is a non-clever version that includes a :spread keyword, and a (hopefully) correctly-written commit message. Thanks! I was surprised not to find you on the list of FSF-signed contributors -- did you assigned your copyright to the FSF already? If not, you'll need to go through this for the patch to be included I'm afraid... Huh, that surprises me too! I looked in my files and I'm supposed to be RT:710483, whatever that means -- they told me it would apply to any emacs-related packages... Thanks for letting us know. Best,
Re: [O] [patch] LaTeX export using tabu tables
Hi Eric, Eric Abrahamsen e...@ericabrahamsen.net writes: Huh, that surprises me too! I looked in my files and I'm supposed to be RT:710483, whatever that means -- they told me it would apply to any emacs-related packages... We're all set then, I added you to the page: http://orgmode.org/worg/org-contribute.html#contributors_with_fsf_papers Thanks for confirming! -- Bastien
Re: [O] Fixing footnote HTML
Samuel Wales samolog...@gmail.com writes: So in Firefox for me at least, there is no blank line between Footnotes: and 1. Footnotes: is inserted as a h2 header in the HTML file. So there should be a visual space after it. -- Bastien
[O] Off for one week / Help on Org's manual and Worg's org-8.0.org page
Dear all, I put a stab at updating Org's manual to reflect some of the changes triggered by the new export engine and the new export back-ends. This is far from being finished, though -- we need your help. You can help by editing Worg's page org-8.0.org: http://orgmode.org/worg/org-8.0.html If you don't have write access to Worg, you can still send patches against Worg's repository, someone will review/apply them: ~$ git clone git://orgmode.org/worg.git You can also help by pointing at inconsistencies in the manual and sending patches to fix them. If you don't have write access to Org, you can still send patches against Org's repository, someone will review/apply them: ~$ git clone git://orgmode.org/org-mode.git Last but not least, I started a draft for the list of Changes in 8.0: http://orgmode.org/Changes.html Please explore this and test new features heavily. Updating the Worg page and the manual are crucial tasks: the better we are here, the smoother it will be for tons of users to switch to Org 8.0 -- a *major* challenge... let's be collectively proud of helping all those silent users! I'll be offline most of the time this week. I will fix some of the remaining bugs next week-end and, most probably, next week. If you have important issues, please mark them as important. Thanks!! -- Bastien
Re: [O] Setting taskjuggler project start date (ox-taskjuggler)
On Mon, Mar 25, 2013 at 1:27 AM, John Hendy jw.he...@gmail.com wrote:
Having trouble setting the project start date, which results in a
build error since my project started before today, and the default
project start appears to be today's date. This was with no
customization to the top level headline. Intuitively, I added a
:start: property like so:
#+begin_src org
* Project :taskjuggler_project:
:PROPERTIES:
:start:2013-03-01
:END:
#+end_src
This results in (no change from exporting with no :start: property:
#+begin_src TJ
project nil Project 1.0 2013-03-25 +280d {
}
#+end_src
From digging around in ox-taskjuggler.el, it looks like the project
gets defined here:
#+begin_src ox-taskjuggler.el (line 607)
(defun org-taskjuggler--build-project (project info)
Return a project declaration.
PROJECT is a headline. INFO is a plist used as a communication
channel. If no start date is specified, start today. If no end
date is specified, end `org-taskjuggler-default-project-duration'
days from now.
(format project %s \%s\ \%s\ %s %s {\n}\n
(org-taskjuggler-get-id project info)
(org-taskjuggler-get-name project)
;; Version is obtained through :TASKJUGGLER_VERSION:
;; property or `org-taskjuggler-default-project-version'.
(or (org-element-property :VERSION project)
org-taskjuggler-default-project-version)
(or (org-taskjuggler-get-start project)
(format-time-string %Y-%m-%d))
(let ((end (org-taskjuggler-get-end project)))
(or (and end (format - %s end))
(format +%sd org-taskjuggler-default-project-duration)]
#+end_src
I'm no esliper, but I think I can track that the consecutive =%s=
arguments are replaced by the successive function calls. That, and
=org-taskjuggler-get-start project= looks like the ticket. That
function is here:
#+begin_src ox-taskjuggler.el (line 372)
(defun org-taskjuggler-get-start (item)
Return start date for task or resource ITEM.
ITEM is a headline. Return value is a string or nil if ITEM
doesn't have any start date defined..
(let ((scheduled (org-element-property :scheduled item)))
(and scheduled (org-timestamp-format scheduled %Y-%02m-%02d
#+end_src
So, that suggested that perhaps I needed to use :scheduled: instead of
:start:. I tried that with the same results. It appears that this
property /is/ applied at the task level for the top headline, however:
#+begin_src TJ
task project Project {
purge allocate
allocate jwhendy
start 2013-03-01
...
}
#+end_src
So, it applies :start: to the top level project in the /task/
definition area, but doesn't apply it to the very top level project
definition.
Any suggestions?
This works, though I know approximately nil (didja see what I did
there) about elisp:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler--build-project (project info)
Return a project declaration.
PROJECT is a headline. INFO is a plist used as a communication
channel. If no start date is specified, start today. If no end
date is specified, end `org-taskjuggler-default-project-duration'
days from now.
(format project %s \%s\ \%s\ %s %s {\n}\n
(org-taskjuggler-get-id project info)
(org-taskjuggler-get-name project)
;; Version is obtained through :TASKJUGGLER_VERSION:
;; property or `org-taskjuggler-default-project-version'.
(or (org-element-property :VERSION project)
org-taskjuggler-default-project-version)
(or (org-element-property :START project)
(format-time-string %Y-%02m-%02d))
(let ((end (org-element-property :END project)))
(or (and end (format - %s end))
(format +%sd org-taskjuggler-default-project-duration)
#+end_src
I don't know why the org-taskjuggler-get-start function works for the
task definition and not the project definition... but just looking for
the contents of the :start: and :end: properties directly is my
current hack. I'll leave it like that just so I don't have to manually
change the .tjp file at every export, but I'm sure there's a proper
way to fix :)
John
John
Re: [O] Setting taskjuggler project start date (ox-taskjuggler)
On Mon, Mar 25, 2013 at 2:17 AM, John Hendy jw.he...@gmail.com wrote:
On Mon, Mar 25, 2013 at 1:27 AM, John Hendy jw.he...@gmail.com wrote:
Having trouble setting the project start date, which results in a
build error since my project started before today, and the default
project start appears to be today's date. This was with no
customization to the top level headline. Intuitively, I added a
:start: property like so:
#+begin_src org
* Project :taskjuggler_project:
:PROPERTIES:
:start:2013-03-01
:END:
#+end_src
This results in (no change from exporting with no :start: property:
#+begin_src TJ
project nil Project 1.0 2013-03-25 +280d {
}
#+end_src
From digging around in ox-taskjuggler.el, it looks like the project
gets defined here:
#+begin_src ox-taskjuggler.el (line 607)
(defun org-taskjuggler--build-project (project info)
Return a project declaration.
PROJECT is a headline. INFO is a plist used as a communication
channel. If no start date is specified, start today. If no end
date is specified, end `org-taskjuggler-default-project-duration'
days from now.
(format project %s \%s\ \%s\ %s %s {\n}\n
(org-taskjuggler-get-id project info)
(org-taskjuggler-get-name project)
;; Version is obtained through :TASKJUGGLER_VERSION:
;; property or `org-taskjuggler-default-project-version'.
(or (org-element-property :VERSION project)
org-taskjuggler-default-project-version)
(or (org-taskjuggler-get-start project)
(format-time-string %Y-%m-%d))
(let ((end (org-taskjuggler-get-end project)))
(or (and end (format - %s end))
(format +%sd org-taskjuggler-default-project-duration)]
#+end_src
I'm no esliper, but I think I can track that the consecutive =%s=
arguments are replaced by the successive function calls. That, and
=org-taskjuggler-get-start project= looks like the ticket. That
function is here:
#+begin_src ox-taskjuggler.el (line 372)
(defun org-taskjuggler-get-start (item)
Return start date for task or resource ITEM.
ITEM is a headline. Return value is a string or nil if ITEM
doesn't have any start date defined..
(let ((scheduled (org-element-property :scheduled item)))
(and scheduled (org-timestamp-format scheduled %Y-%02m-%02d
#+end_src
So, that suggested that perhaps I needed to use :scheduled: instead of
:start:. I tried that with the same results. It appears that this
property /is/ applied at the task level for the top headline, however:
#+begin_src TJ
task project Project {
purge allocate
allocate jwhendy
start 2013-03-01
...
}
#+end_src
So, it applies :start: to the top level project in the /task/
definition area, but doesn't apply it to the very top level project
definition.
Any suggestions?
This works, though I know approximately nil (didja see what I did
there) about elisp:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler--build-project (project info)
Return a project declaration.
PROJECT is a headline. INFO is a plist used as a communication
channel. If no start date is specified, start today. If no end
date is specified, end `org-taskjuggler-default-project-duration'
days from now.
(format project %s \%s\ \%s\ %s %s {\n}\n
(org-taskjuggler-get-id project info)
(org-taskjuggler-get-name project)
;; Version is obtained through :TASKJUGGLER_VERSION:
;; property or `org-taskjuggler-default-project-version'.
(or (org-element-property :VERSION project)
org-taskjuggler-default-project-version)
(or (org-element-property :START project)
(format-time-string %Y-%02m-%02d))
(let ((end (org-element-property :END project)))
(or (and end (format - %s end))
(format +%sd org-taskjuggler-default-project-duration)
#+end_src
I don't know why the org-taskjuggler-get-start function works for the
task definition and not the project definition... but just looking for
the contents of the :start: and :end: properties directly is my
current hack. I'll leave it like that just so I don't have to manually
change the .tjp file at every export, but I'm sure there's a proper
way to fix :)
Ah. org-taskjuggler-get-start /isn't/ working for the tasks... I've
just set them with :start: and that's a keyword that I think the
exporter is directly inserting. I don't think that function returns
anything at all... but for the build-project function, it has a backup
value of today's date (format-date-string).
Could it be as simple as the org-taskjuggler-get-start function
needing a capitalized org-element-property call?
Currently, it's:
(let ((scheduled (org-element-property :scheduled item)))
But the other calls to org-element-property have things like :VERSION.
I changed
Re: [O] [BUG] ob-perl variable handling broken
Am 25.03.2013 01:27, schrieb Eric Schulte: The attached patch fixes this behavior, however I haven't committed it because I fear it would undo some of Achim's intentions in commit ca125b82b. I'll leave the final solution to Achim. This should be the right solution, please commit. However, the format string should be q(%s) and not q(~a) I suppose (unless my newsreader is fooling me). Regards, -- Achim. (on the road :-)
[O] Setupfile regression?
Hi, I am reading Bastien's writeup about upgrading to 8.0. There I see this part: #+SETUPFILE: myfile - #+INCLUDE: myfile However, if I do this replacement, one of the purposes of #+setupfile no longer works. The idea was to be able to have a file with lines like #+TODO and #+TAGS, so that some central file specific setup is possible in this way. In particular, when a file is loaded and scanned for setup information, files defined by #+setupfile will be parsed as well. This still works currently, but I read Bastien's document as an intention to remove this property? Or to at least no longer treat such files as include files during export? I have tried, and #+include files are *not* scanned for setup information. I would like to know what the plans are here. Thanks. - Carsten
Re: [O] Can I clone worg using http protocol?
Am 24.03.2013 18:52, schrieb John Hendy: $ git clone http://orgmode.org/w/worg.git Try $ git clone http://orgmode.org/r/worg.git (note how the w/ changes to an r/). Regards, -- Achim. (on the road :-)
Re: [O] Org spreadsheet formula range destination and per-cell placement for Lisp
Paul, Paul Michael Reilly wrote: I am in the throes of setting up an Org mode spreadsheet for an invoicing/status/planning tool and came across this fabulous thread: *[O] org table calc and lisp for hh:mm timetablehttp://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00972.html *at http://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00972.htmlwhich provided me much of what I need. So thanks to all involved for that excellent piece of work. The one problem I am having trouble grasping is in how to use Emacs Lisp to generate a range of values automagically. I have no trouble with a single cell using Lisp and passing in a rectangular region to process or in setting up a region using the Org table/spreadsheet/calc support described in the various Google accessible documentation. What I am trying to do at a high level is setup a table with rows of actions spanning a start and stop time. Each action row has a bill-to category column. In the table, as part of a Lisp based formula, I want to process these action rows and build a list of bill-to : total time summary values and then place these summaries in a range in the table, so a fragment of the table might look like: ... | Client1 | Client2 | Commute | ... ... | 12.50 | 22.00 | 10.5| ... where the numbers (hours) have been summed by filtering the task rows by clients. Hope that's clear. So there are essentially two issues for me: the first is understanding how to associate a range destination for a Lisp based formula result, which I think can be done, I just do not understand how to do it yet, and second, probably an enhancement request, is to figure out how to pass a list of cell addresses to a List form (along with other data) and have the form compute and store values to those cells. The latter would a sort of holy grail, at least for me. I won't answer your post, but will present you what I'm doing, as I'm using Org for billing my clients. How I do is: - Clock my time in the client file - Generate a dynamic block for each client file Quite easy. So, this is just to show you an alternative, in case you did overlook that. Best regards, Seb -- Sebastien Vauban
Re: [O] Setupfile regression?
Am 25.03.2013 10:14, schrieb Carsten Dominik: I would like to know what the plans are here. Does this discussion help? http://thread.gmane.org/gmane.emacs.orgmode/68940 Regards, -- Achim. (on the road :-)
[O] :session question
Hi all, org-babel uses the header argument :session keeping the environment for consecutive evaluations. That feels the opposite of all on-the-fly evaluations commonly done by a (language)-shell. Commonly a shell keeps is values until a new one is created. Would find it more natural if :session is the default, while a command refresh makes a new one. Also instead of :session a header argument :dedicated would provide a new process every time. As we have a bug around, maybe it's a good moment to consider that, Andreas
Re: [O] Setupfile regression?
On 25 mrt. 2013, at 10:34, Achim Gratz strom...@nexgo.de wrote: Am 25.03.2013 10:14, schrieb Carsten Dominik: I would like to know what the plans are here. Does this discussion help? http://thread.gmane.org/gmane.emacs.orgmode/68940 Yes. Thank you, and my apologies that I did not find this by myself. This means that the description in org-8.0.org was incorrect, I just fixed that. Regards - Carsten
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 25.03.2013 06:45, schrieb Bastien: Bastien b...@altern.org writes: This is a problem with Org -- I have a patch for this on my local branch, but I will push this branch only tomorrow. Applied now, thanks. I'd like to ask you to revisit that change. I don't think the question of whether #+SETUPFILE should be honored can be decided based on whether the buffer is read-only. I'm not entirely sure what Gnus does to trigger that foray into Org (a quick glance in the documentation didn't show anything), but if anything this indicates that we might need a safe mode for Org to open untrusted files. Regards, -- Achim. (on the road :-)
Re: [O] [BUG] [ODT] Annotations break paragraphs
Samuel Wales writes: A similar issue arises with inline footnotes. [...] In my case I was able with Nicolas's supplied code to create a hook that normalized footnotes before export. Maybe extracting in a hook will work for you. However, I fear that incorporating the parser into the font lock engine will break these paragraphs. Thanks for the tip. I don't think user-side hacks are the way to go here, though. Org-odt provides an annotation feature for ODT export, based on using the special-block syntax, that no longer works as intended. I'm hoping it can simply be fixed, but if putting the annotation in a block must lead to paragraph breaks under the new exporter, a different solution is needed. Yours, Christian
Re: [O] [BUG] [ODT] Annotations break paragraphs
Am 25.03.2013 11:29, schrieb Christian Moe: Thanks for the tip. I don't think user-side hacks are the way to go here, though. Org-odt provides an annotation feature for ODT export, based on using the special-block syntax, that no longer works as intended. I'm hoping it can simply be fixed, but if putting the annotation in a block must lead to paragraph breaks under the new exporter, a different solution is needed. I've been trying to sell Nicolas the idea of paragraph continuations, but so far I haven't had much luck. It's OK (I think) that Org intially parses this as two paragraphs with an annotation inbetween, but there should be a way for the exporter to pull the two paragraphs together based on context (blank lines or not, etc.). Regards, -- Achim. (on the road :-)
[O] Maxima tests fail in devel on OSX
I just ran make up1 on the latest version from git and the tests failed on maxima. I have not changed the configuration of maxima since the last tests I ran probably a month ago. 7 unexpected results: FAILED ob-maxima/integer-input FAILED ob-maxima/list-input FAILED ob-maxima/matrix-output FAILED ob-maxima/simple-list-input FAILED ob-maxima/string-input FAILED ob-maxima/table-input1 FAILED ob-maxima/table-input2 make[1]: *** [test-dirty] Error 1 make: *** [up1] Error 2
Re: [O] Off for one week / Help on Org's manual and Worg's org-8.0.org page
Am 25.03.2013 08:04, schrieb Bastien: Dear all, I put a stab at updating Org's manual to reflect some of the changes triggered by the new export engine and the new export back-ends. This is far from being finished, though -- we need your help. You can help by editing Worg's page org-8.0.org: http://orgmode.org/worg/org-8.0.html If you don't have write access to Worg, you can still send patches against Worg's repository, someone will review/apply them: ~$ git clone git://orgmode.org/worg.git You can also help by pointing at inconsistencies in the manual and sending patches to fix them. If you don't have write access to Org, you can still send patches against Org's repository, someone will review/apply them: ~$ git clone git://orgmode.org/org-mode.git Last but not least, I started a draft for the list of Changes in 8.0: http://orgmode.org/Changes.html Please explore this and test new features heavily. Updating the Worg page and the manual are crucial tasks: the better we are here, the smoother it will be for tons of users to switch to Org 8.0 -- a *major* challenge... let's be collectively proud of helping all those silent users! I'll be offline most of the time this week. I will fix some of the remaining bugs next week-end and, most probably, next week. If you have important issues, please mark them as important. Thanks!! Hi, current revision does not compile docs without errors. make -C doc info make[1]: Entering directory `/cygdrive/c/Users/rainer/AppData/Roaming/.emacs.d/org/doc' makeinfo --no-split org.texi -o org org.texi:10088: Kein übereinstimmendes „@end table“. makeinfo: Entferne Ausgabedatei „org“ wegen Fehler; --force benutzen, um diese beizubehalten. Makefile:55: recipe for target `org' failed make[1]: *** [org] Error 1 make[1]: Leaving directory `/cygdrive/c/Users/rainer/AppData/Roaming/.emacs.d/org/doc' mk/targets.mk:121: recipe for target `info' failed make: *** [info] Error 2 Regards, Rainer
Re: [O] Off for one week / Help on Org's manual and Worg's org-8.0.org page
Hi Rainer, Rainer Stengele rainer.steng...@online.de writes: current revision does not compile docs without errors. Fixed, sorry for the typo. -- Bastien
Re: [O] Block agendas and filtering
I got this working as I wanted, I had a problem with the custom agenda commands that I had defined. Below is the agenda command that implements the desired view. (c Agenda and Home-related tasks ((agenda -chore) (tags chore+TIMESTAMP=today))) I think part of my problem was having a key binding defined twice (c in this case), and org not warning about it. The two happened to be somewhat similar, and so there was confusion on my part as to why it wasn't showing the right thing. Thanks for all of the help and suggestions. -Tom -- Thomas Moyer tommo...@gmail.com On Mon, Mar 25, 2013 at 2:11 AM, Bastien b...@altern.org wrote: Samuel Wales samolog...@gmail.com writes: On 3/19/13, Bastien b...@altern.org wrote: (org-agenda-tag-filter (+Tag)) org-agenda-filter-preset? Both will work. Note that `org-agenda-filter-preset' has been renamed to `org-agenda-tag-filter-preset' a while ago. -- Bastien
[O] no info files created w/ current git-repo
Hi, building from current git-repo make all builds some .pdf and .html docu, but not info directory doc contains: dir Makefile orgguide.texi org-version.inc doclicense.texi org org.html pdflayout.sty Documentation_Standards.org orgcard.tex org.pdftexinfo.tex library-of-babel.org orgguide.pdf org.texi Any help? Thanks, Andreas
Re: [O] Maxima tests fail in devel on OSX
Neuwirth Erich erich.neuwi...@univie.ac.at writes: I have not changed the configuration of maxima since the last tests I ran probably a month ago. 7 unexpected results: FAILED ob-maxima/integer-input [...] I have failures too, but I'm not sure if they are related because I *did* update maxima (compiled with ECL instead of GCL because that's required for Sage). I think this will make it clear why there is a problem : : $ maxima --very-quiet -r 'batchload(tmp/max)$' : ;;; Loading #P/usr/lib/ecl-12.12.1/sb-bsd-sockets.fas : ;;; Loading #P/usr/lib/ecl-12.12.1/sockets.fas : ;;; Loading #P/usr/lib/ecl-12.12.1/defsystem.fas : ;;; Loading #P/usr/lib/ecl-12.12.1/cmp.fas : 4 My attempts at finding a maxima option to avoid these lines were unsuccessful (I mainly tried adding (setq *load-verbose* nil) to a maxima-init.lisp file, but that doesn't help). I suppose that ignoring any line that begins with ;;; Loading #P will be the easiest way. Here's an obvious patch in that direction : --- a/lisp/ob-maxima.el +++ b/lisp/ob-maxima.el @@ -83,6 +83,7 @@ called by `org-babel-execute-src-block'. (mapcar (lambda (line) (unless (or (string-match batch line) (string-match ^rat: replaced .*$ line) + (string-match ^;;; Loading #P line) (= 0 (length line))) line)) (split-string raw [\r\n]))) \n)) -- Nico.
Re: [O] [BUG] ob-perl variable handling broken
Achim Gratz strom...@nexgo.de writes: Am 25.03.2013 01:27, schrieb Eric Schulte: The attached patch fixes this behavior, however I haven't committed it because I fear it would undo some of Achim's intentions in commit ca125b82b. I'll leave the final solution to Achim. This should be the right solution, please commit. Committed. However, the format string should be q(%s) and not q(~a) I suppose (unless my newsreader is fooling me). Sorry, I'm writing more Common Lisp than Emacs Lisp these days. Cheers, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] no info files created w/ current git-repo
On Mon, Mar 25, 2013 at 6:53 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, building from current git-repo make all builds some .pdf and .html docu, but not info directory doc contains: dir Makefile orgguide.texi org-version.inc doclicense.texi org org.html pdflayout.sty Documentation_Standards.org orgcard.tex org.pdftexinfo.tex library-of-babel.org orgguide.pdf org.texi Any help? Thanks, Is it the related as this? - http://permalink.gmane.org/gmane.emacs.orgmode/69071 John Andreas
Re: [O] Setupfile regression?
On Mon, Mar 25, 2013 at 4:54 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On 25 mrt. 2013, at 10:34, Achim Gratz strom...@nexgo.de wrote: Am 25.03.2013 10:14, schrieb Carsten Dominik: I would like to know what the plans are here. Does this discussion help? http://thread.gmane.org/gmane.emacs.orgmode/68940 Yes. Thank you, and my apologies that I did not find this by myself. This means that the description in org-8.0.org was incorrect, I just fixed that. Sorry -- meant to fix this myself per that other thread. Started changing the org-8.0 file yesterday, including this, but then wasn't quite sure how to re-organize it with the other stuff I wanted to add and never pushed. Thanks for taking care of that! John Regards - Carsten
Re: [O] Setupfile regression?
On 25 mrt. 2013, at 14:43, John Hendy jw.he...@gmail.com wrote: On Mon, Mar 25, 2013 at 4:54 AM, Carsten Dominik carsten.domi...@gmail.com wrote: On 25 mrt. 2013, at 10:34, Achim Gratz strom...@nexgo.de wrote: Am 25.03.2013 10:14, schrieb Carsten Dominik: I would like to know what the plans are here. Does this discussion help? http://thread.gmane.org/gmane.emacs.orgmode/68940 Yes. Thank you, and my apologies that I did not find this by myself. This means that the description in org-8.0.org was incorrect, I just fixed that. Sorry -- meant to fix this myself per that other thread. Started changing the org-8.0 file yesterday, including this, but then wasn't quite sure how to re-organize it with the other stuff I wanted to add and never pushed. Hi John, looking forward to reading other fixes and additions from you. Thanks - Carsten
Re: [O] Can I clone worg using http protocol?
On Mon, Mar 25, 2013 at 4:17 AM, Achim Gratz strom...@nexgo.de wrote: Am 24.03.2013 18:52, schrieb John Hendy: $ git clone http://orgmode.org/w/worg.git Try $ git clone http://orgmode.org/r/worg.git (note how the w/ changes to an r/). #+begin_example $ git clone http://orgmode.org/r/worg.git Cloning into 'worg'... fatal: http://orgmode.org/r/worg.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server? #+end_example Having not much of an idea of what I'm doing, I also tried: #+begin_example $ git update-server-info http://orgmode.org/r/worg.git fatal: Not a git repository (or any of the parent directories): .git #+end_example Thoughts? John P.S. Ideally, I'd like to clone with ssh/push access via http as well. I'd love the http alternative to (if that's possible): $ git clone w...@orgmode.org:worg.git Regards, -- Achim. (on the road :-)
[O] Error message: (void-variable org-element-affiliated-keywords)
I use flyspell on my org files. With the most recent org-mode from git, when I switch to an org buffer, I receive the following message: Error in post-command-hook (flyspell-post-command-hook): (void-variable org-element-affiliated-keywords) I have compiled org mode with make clean make all. I notice that there is a defvar in org.el (line 23392): (defvar org-element-affiliated-keywords) ; From org-element.el Yet it seems this variable is not defined when I open org buffers. Any advice would be much appreciated. Best, Matt
Re: [O] Can I clone worg using http protocol?
Am 25.03.2013 14:49, schrieb John Hendy: $ git clone http://orgmode.org/r/worg.git Cloning into 'worg'... fatal: http://orgmode.org/r/worg.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server? It looks like thios for of HTTP access has been switched off in preference to cgit. $ git update-server-info http://orgmode.org/r/worg.git fatal: Not a git repository (or any of the parent directories): .git This is something that should be done on the server. It generates some files with info that can otherwise be obtained via the Git protocol. P.S. Ideally, I'd like to clone with ssh/push access via http as well. I'd love the http alternative to (if that's possible): You can't have authenticated push access via HTTP using SSH keys. You could maybew use SSH tunneling via HTTP. Regards, -- Achim. (on the road :-)
Re: [O] no info files created w/ current git-repo
Am 25.03.2013 14:42, schrieb John Hendy: On Mon, Mar 25, 2013 at 6:53 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Hi, building from current git-repo make all builds some .pdf and .html docu, but not info directory doc contains: dir Makefile orgguide.texi org-version.inc doclicense.texi org org.html pdflayout.sty Documentation_Standards.org orgcard.tex org.pdftexinfo.tex library-of-babel.org orgguide.pdf org.texi Any help? Thanks, Is it the related as this? - http://permalink.gmane.org/gmane.emacs.orgmode/69071 John Andreas IIRC that was 2 commits before and no docu were built at all. Now this remains. Thanks looking at, Andreas
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@nexgo.de writes: Am 25.03.2013 06:45, schrieb Bastien: Bastien b...@altern.org writes: This is a problem with Org -- I have a patch for this on my local branch, but I will push this branch only tomorrow. Applied now, thanks. I'd like to ask you to revisit that change. I don't think the question of whether #+SETUPFILE should be honored can be decided based on whether the buffer is read-only. I acknowledge this is not the ideal solution but it is better than the current behavior. I'm not entirely sure what Gnus does to trigger that foray into Org (a quick glance in the documentation didn't show anything), but if anything this indicates that we might need a safe mode for Org to open untrusted files. Feel free to propose a better behavior here. -- Bastien
Re: [O] Can I clone worg using http protocol?
On Mon, Mar 25, 2013 at 9:33 AM, Achim Gratz strom...@nexgo.de wrote: Am 25.03.2013 14:49, schrieb John Hendy: $ git clone http://orgmode.org/r/worg.git Cloning into 'worg'... fatal: http://orgmode.org/r/worg.git/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server? It looks like thios for of HTTP access has been switched off in preference to cgit. $ git update-server-info http://orgmode.org/r/worg.git fatal: Not a git repository (or any of the parent directories): .git This is something that should be done on the server. It generates some files with info that can otherwise be obtained via the Git protocol. P.S. Ideally, I'd like to clone with ssh/push access via http as well. I'd love the http alternative to (if that's possible): Good to know. So the definitive answer is, No. You can't have authenticated push access via HTTP using SSH keys. You could maybew use SSH tunneling via HTTP. Eh. Not that critical. I'll just have to not be at work to push or pull. I imagine that the majority of Worg pullers are wanting to push as well, so there probably isn't a huge motivation to have http enabled for pull if you can only push with git. Thanks! John Regards, -- Achim. (on the road :-)
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 25.03.2013 15:57, schrieb Bastien: I'm not entirely sure what Gnus does to trigger that foray into Org (a quick glance in the documentation didn't show anything), but if anything this indicates that we might need a safe mode for Org to open untrusted files. Feel free to propose a better behavior here. As I said, I don't even know why Gnus decides it should treat this mail as an Org file. From the sources of Gnus, it appears that it should only do this if the MIME type was text/x-org. Rainers mail didn't have this MIME type nor was it a multipart MIME mail that had such a part, yet Gnus triggered the buffer with Org as the major mode, which seems to indicate that the MIME type must somehow have been inferred. I can prevent that using orgstruct-mode instead, but as I proposed already there should be a safe variant of org-mode (a derived mode perhaps) that doesn't load any axtra files and doesn't run any source blocks. Of course, Gnus then should use this mode (it is only meant for proper fontification anyway, which I suppose must be possible without firing a whole major mode). Regards, -- Achim. (on the road :-)
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi Christian, Christian Moe m...@christianmoe.com writes: Paragraphs currently break around ODT annotations when they shouldn't. Annotations are a useful feature of the ODT exporter: There is an annotation by the original author here #+BEGIN_ANNOTATION I never meant to break this paragraph. #+END_ANNOTATION in the middle of the paragraph. The expected result would be one paragraph, with the annotation displayed as a comment in the page margin, anchored after the word here. The new exporter adds paragraph breaks around the anchor for the marginal comment. Fixed, thanks. -- Bastien
Re: [O] no info files created w/ current git-repo
Am 25.03.2013 12:53, schrieb Andreas Röhler: make all builds some .pdf and .html docu, but not info It does, the info file is called org. Regards, -- Achim. (on the road :-)
[O] export presentations: org to ppt or odp
Hi everyone, This question is probably for Jambunathan K: is an org to ppt or odp exporter in the works? Was wondering whether most of the work could be borrowed form the org to odt exporter. If anyone is wondering, why export presentations to odp or ppt when export to pdf (via beamer) and html (S5) are available? Those two works well for me personally, but for work, we tend to collaborate with others, and truth of the matter is that everyone else uses powerpoint. The files need to be editable and re-usable by others in a format they could work with. If anyone else has a current work flow they use to convert org to ppt, please do share. Any way to go from org to latex to ppt? Or org to s5 to ppt? I did a quick google but wasn't able to find anything. Thanks! -- Vinh
Re: [O] python sessions
John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] export presentations: org to ppt or odp
On Mon, Mar 25, 2013 at 10:34 AM, Vinh Nguyen vinhdi...@gmail.com wrote: Hi everyone, This question is probably for Jambunathan K: is an org to ppt or odp exporter in the works? Was wondering whether most of the work could be borrowed form the org to odt exporter. If anyone is wondering, why export presentations to odp or ppt when export to pdf (via beamer) and html (S5) are available? Those two works well for me personally, but for work, we tend to collaborate with others, and truth of the matter is that everyone else uses powerpoint. The files need to be editable and re-usable by others in a format they could work with. I'd definitely love this, primarily if it allowed one to use a pre-defined POTX template file for export. My division at work has a new VP who is quite particular about *everyone* using the new template. I'm going to keep using Beamer, but may be asked directly to conform. I'd hate to lose all of my Org usage just for the sake of having to get a PPT for the sake of creating mostly-one-time presentations at business updates. I've considered just trying to re-create the template as a Beamer template, but that can get pretty involved from my previous attempt to do so. Also, like Vinh, others ask me, Say, can you send me that presentation? I've love to use some of the stuff from it. They intend to re-use pictures or copy/paste information. It's not uncommon for me to have to say, Um. Yeah. The thing is that I use this kind of weird program. Basically, no, I can't give you anything usable. For most purposes, Beamer is just fine, but this would be awesome for those types of situations. Look forward to what others have to say! John If anyone else has a current work flow they use to convert org to ppt, please do share. Any way to go from org to latex to ppt? Or org to s5 to ppt? I did a quick google but wasn't able to find anything. Thanks! -- Vinh
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@nexgo.de writes: As I said, I don't even know why Gnus decides it should treat this mail as an Org file. From the sources of Gnus, it appears that it should only do this if the MIME type was text/x-org. Rainers mail didn't have this MIME type nor was it a multipart MIME mail that had such a part, yet Gnus triggered the buffer with Org as the major mode, which seems to indicate that the MIME type must somehow have been inferred. I can prevent that using orgstruct-mode instead, but as I proposed already there should be a safe variant of org-mode (a derived mode perhaps) that doesn't load any axtra files and doesn't run any source blocks. Of course, Gnus then should use this mode (it is only meant for proper fontification anyway, which I suppose must be possible without firing a whole major mode). What about this patch? The change in Gnus is then trivial (see other patch). diff --git a/lisp/org.el b/lisp/org.el index 04a0f20..88f9ea0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -1266,6 +1266,26 @@ smartMake point visible, and do insertion/deletion if it is (const :tag Show invisible part and do the edit show) (const :tag Be smart and do the right thing smart))) +(defcustom org-read-setup-file 'ask + Should Org read setup files? +A setup file can be specified with the #+SETUPFILE keyword. +When reading someone else Org files, Emacs will try to read +arbitrary read an arbitrary file on your computer. + +The default is to ask users before reading a file. +Setting this option to 'if-interactive will read the setup +file when `org-mode' has been called interactively. +Setting this option to t will always read setup files. + :group 'org-startup + :version 24.4 + :package-version '(Org . 8.0) + :type '(choice + (const :tag Never read a setup file nil) + (const :tag Ask before trying to read a setup file 'ask) + (const :tag Read a setup file when `org-mode' is called interactively + 'if-interactive) + (const :tag Always try to read a setup file t))) + (defcustom org-yank-folded-subtrees t Non-nil means when yanking subtrees, fold them. If the kill is a single subtree, or a sequence of subtrees, i.e. if @@ -4828,8 +4848,10 @@ Support for group tags is controlled by the option (assoc (car e) org-tag-alist)) (push e org-tag-alist -(defun org-set-regexps-and-options () - Precompute regular expressions used in the current buffer. +(defun org-set-regexps-and-options (optional interactivep) + Precompute regular expressions used in the current buffer. +If INTERACTIVEP is non-nil, `org-set-regexps-and-options' has +been called from an interactive call to `org-mode'. (when (derived-mode-p 'org-mode) (org-set-local 'org-todo-kwd-alist nil) (org-set-local 'org-todo-key-alist nil) @@ -4912,7 +4934,11 @@ Support for group tags is controlled by the option (setq scripts (read (match-string 2 value) ((and (equal key SETUPFILE) ;; Prevent checking in Gnus messages - (not buffer-read-only)) + (or (and (eq org-read-setup-file 'if-interactive) interactivep) + (and (eq org-read-setup-file 'ask) + (yes-or-no-p (format Read setup file %s? value))) + (eq org-read-setup-file t) + (progn (message Setup file %s not read value) (sit-for 2 (setq setup-contents (org-file-contents (expand-file-name (org-remove-double-quotes value)) @@ -5272,7 +5298,7 @@ The following commands are available: (if (stringp org-ellipsis) org-ellipsis ... (setq buffer-display-table org-display-table)) (org-set-regexps-and-options-for-tags) - (org-set-regexps-and-options) + (org-set-regexps-and-options (org-called-interactively-p 'any)) (when (and org-tag-faces (not org-tags-special-faces-re)) ;; tag faces set outside customize force initialization. (org-set-tag-faces 'org-tag-faces org-tag-faces)) @@ -20152,7 +20178,7 @@ This command does many different things, depending on context: Restart Org-mode, to scan again for special lines. Also updates the keyword regular expressions. (interactive) - (org-mode) + (call-interactively 'org-mode) (message Org-mode restarted)) (defun org-kill-note-or-show-branches () diff --git a/lisp/mm-view.el b/lisp/mm-view.el index ac6170a..690402c 100644 --- a/lisp/mm-view.el +++ b/lisp/mm-view.el @@ -647,7 +647,9 @@ If MODE is not set, try to find mode automatically. (defun mm-display-org-inline (handle) Show an Org mode text from HANDLE inline. - (mm-display-inline-fontify handle 'org-mode)) + (mm-display-inline-fontify + handle + (lambda () (let (org-read-setup-file) (org-mode) (defun mm-display-shell-script-inline (handle) Show a shell script from HANDLE inline. -- Bastien
Re: [O] Error message: (void-variable org-element-affiliated-keywords)
Hi Matt, Matt Lundin m...@imapmail.org writes: I use flyspell on my org files. With the most recent org-mode from git, when I switch to an org buffer, I receive the following message: Error in post-command-hook (flyspell-post-command-hook): (void-variable org-element-affiliated-keywords) This should be fixed, thanks. -- Bastien
Re: [O] python sessions
On Mon, Mar 25, 2013 at 10:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. Have *any* changes been made related to python recently? See my mailing list post with reproducible example: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html This was definitely working for me with a minimal config and starting with `emacs -Q`. I cannot reproduce that example anymore. Sessions don't work any longer, named or un-named for me, and we had two data points (myself and Ista) for whom it worked (at least for named). I think something was changed that broke it for my working setup. Might be nice to figure out what that was. Is there a way to see one's local git history? Not the git log, but something like what git versions I've been hopping from/to with each successive pull? I could try and see what I was at on 3/20 when I posted that and when I last pulled? I see a change related to ob-python from Bastien on 3/19... perhaps I could switch to a commit prior to that and try again? John -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] python sessions
On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Best, Ista -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] export presentations: org to ppt or odp
Vinh Nguyen writes: If anyone is wondering, why export presentations to odp or ppt when export to pdf (via beamer) and html (S5) are available? Those two works well for me personally, but for work, we tend to collaborate with others, and truth of the matter is that everyone else uses powerpoint. I feel your pain... You're probably aware of this already, but: if your Org presentation is organized in headings with subheadings for bullet points, you can export it to ODT, then use the OpenOffice/LibreOffice command File Send Outline to Presentation. But that only takes care of the outline, not your pictures, quotations etc. Yours, Christian
Re: [O] python sessions
Currently I'd say session support for python is completely broken. Have *any* changes been made related to python recently? See my mailing list post with reproducible example: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html This was definitely working for me with a minimal config and starting with `emacs -Q`. I cannot reproduce that example anymore. Sessions don't work any longer, named or un-named for me, and we had two data points (myself and Ista) for whom it worked (at least for named). I think something was changed that broke it for my working setup. Might be nice to figure out what that was. I certainly haven't touched this code. The latest change I see to the relevant portions of the code is commit 4a0afac6 from Bastien on Feb. 23rd. Is there a way to see one's local git history? Not the git log, but something like what git versions I've been hopping from/to with each successive pull? I could try and see what I was at on 3/20 when I posted that and when I last pulled? I see a change related to ob-python from Bastien on 3/19... perhaps I could switch to a commit prior to that and try again? I don't know of a way to show what versions you have used recently. There are tools to help find the commits causing a change in behavior. See http://git-scm.com/book/en/Git-Tools-Debugging-with-Git for a pretty good summary. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi, Bastien, Thanks for looking into this. I just pulled and tested, but I cannot confirm the fix yet. I still get paragraph breaks around annotations with Org-mode version 8.0-pre (release_8.0-pre-219-g8eb0d6). Yours, Christian Bastien writes: Hi Christian, Christian Moe m...@christianmoe.com writes: Paragraphs currently break around ODT annotations when they shouldn't. Annotations are a useful feature of the ODT exporter: There is an annotation by the original author here #+BEGIN_ANNOTATION I never meant to break this paragraph. #+END_ANNOTATION in the middle of the paragraph. The expected result would be one paragraph, with the annotation displayed as a comment in the page margin, anchored after the word here. The new exporter adds paragraph breaks around the anchor for the marginal comment. Fixed, thanks.
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 25.03.2013 16:54, schrieb Bastien: What about this patch? I don't think Gnus should be switching major modes just to get fontification and definitely not with Org. The change in Gnus is then trivial (see other patch). Again, I'd rather have a derived mode (org-safe-mode, perhaps) that simply switches off anything related to loading other files, changing setups and executing code. This is useful in other situations as well and if one determines that the file is safe the full org-mode can be switched on and the file reloaded if necessary. That makes the patch in Gnus even more trivial (if they really can't use a more sensible method of fontiffication). Regards, -- Achim. (on the road :-)
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi Christian, Christian Moe m...@christianmoe.com writes: Thanks for looking into this. I just pulled and tested, but I cannot confirm the fix yet. I still get paragraph breaks around annotations with Org-mode version 8.0-pre (release_8.0-pre-219-g8eb0d6). Before the fix, I could see no annotation at all in the ODT export; after the fix, I see the annotation -- do you confirm *this* problem at least existed for you, and does not exist anymore? As for annotation breaking the paragraph, I'll digg further. Best, -- Bastien
Re: [O] python sessions
On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. John Best, Ista -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [BUG] [ODT] Annotations break paragraphs
Am 25.03.2013 17:12, schrieb Christian Moe:
Thanks for looking into this. I just pulled and tested, but I cannot
confirm the fix yet. I still get paragraph breaks around annotations
with Org-mode version 8.0-pre (release_8.0-pre-219-g8eb0d6).
It can't be fixed this way since annotations end the paragraph and
whatever comes next is a new element. The ODT exporter gets two
paragraphs and has no way of knowing that these should actually be
exported as a single paragraph. Inline source blocks might work (i.e.
src_ANNOTATION{...}), I don't know.
--
Achim.
(on the road :-)
Re: [O] python sessions
Eric Schulte schulte.e...@gmail.com wrote: Currently I'd say session support for python is completely broken. Have *any* changes been made related to python recently? See my mailing list post with reproducible example: - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html This was definitely working for me with a minimal config and starting with `emacs -Q`. I cannot reproduce that example anymore. Sessions don't work any longer, named or un-named for me, and we had two data points (myself and Ista) for whom it worked (at least for named). I think something was changed that broke it for my working setup. Might be nice to figure out what that was. I certainly haven't touched this code. The latest change I see to the relevant portions of the code is commit 4a0afac6 from Bastien on Feb. 23rd. At least, we now all agree that it's broken ;-) Is there a way to see one's local git history? Not the git log, but something like what git versions I've been hopping from/to with each successive pull? I could try and see what I was at on 3/20 when I posted that and when I last pulled? I see a change related to ob-python from Bastien on 3/19... perhaps I could switch to a commit prior to that and try again? I don't know of a way to show what versions you have used recently. I think `git reflog' can do that, but it's kinda cryptic, so it might be more trouble than it's worth. Nick
Re: [O] python sessions
John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@nexgo.de writes: Am 25.03.2013 16:54, schrieb Bastien: What about this patch? I don't think Gnus should be switching major modes just to get fontification and definitely not with Org. But it does. The change in Gnus is then trivial (see other patch). Again, I'd rather have a derived mode (org-safe-mode, perhaps) that simply switches off anything related to loading other files, changing setups and executing code. This is useful in other situations as well and if one determines that the file is safe the full org-mode can be switched on and the file reloaded if necessary. That makes the patch in Gnus even more trivial (if they really can't use a more sensible method of fontiffication). Can you evaluate my patch against the current state of affair? Evaluating it against your ideal fix will obvisouly make it look rudimentary. But I think it's better than the current situation. -- Bastien
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Bastien b...@altern.org writes: Evaluating it against your ideal fix will obvisouly make it look rudimentary. But I think it's better than the current situation. PS: that's not to say that the door is closed for your ideal fix, of course. But I favor existing patches vs. ideal solutions. -- Bastien
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi Christian, Christian Moe m...@christianmoe.com writes: Thanks for looking into this. I just pulled and tested, but I cannot confirm the fix yet. I still get paragraph breaks around annotations with Org-mode version 8.0-pre (release_8.0-pre-219-g8eb0d6). I gave it another try. Please let me know. -- Bastien
[O] void-variable org-list-allow-alphabetical
Hi,
when trying to load git-devel-repo after make all get the error.
Traceback attached
If defvarred before defcustom, that error is gone.
Andreas
Debugger entered--Lisp error: (void-variable org-list-allow-alphabetical)
byte-code(\306\307\310\307\311\307\312\313\307\314\307\315\307\316\307\317\307\320 \n \fF!\307
\321=\203$ \322\202/
\323=\203. \324\202/ \325\2055 \326 \327 \330 \330\331\260*\332\260\207 [org-outline-regexp org-scheduled-string org-deadline-string org-closed-string org-clock-string org-plain-list-ordered-item-terminator ^\\(?: \\| \\[\\(?:[0-9]+\\|fn:[-_[:word:]]+\\)\\] %%( [ ]*\\(?: $ \\(?:|\\|\\+-[-+]\\) [#:] -\\{5,\\}[ ]*$ begin{\\([A-Za-z0-9]+\\*?\\)} regexp-opt 41 ) 46 \\. [.)] \\|[A-Za-z] \\(?:[-+*]\\|\\(?:[0-9]+ \\) \\(?:[ ]\\|$\\) \\)\\) org-list-allow-alphabetical alpha term] 26)
(defconst org-element-paragraph-separate (byte-code \306\307\310\307\311\307\312\313\307\314\307\315\307\316\307\317\307\320 \n \fF!\307
\321=\203$ \322\202/
\323=\203. \324\202/ \325\2055 \326 \327 \330 \330\331\260*\332\260\207 [org-outline-regexp org-scheduled-string org-deadline-string org-closed-string org-clock-string org-plain-list-ordered-item-terminator ^\\(?: \\| \\[\\(?:[0-9]+\\|fn:[-_[:word:]]+\\)\\] %%( [ ]*\\(?: $ \\(?:|\\|\\+-[-+]\\) [#:] -\\{5,\\}[ ]*$ begin{\\([A-Za-z0-9]+\\*?\\)} regexp-opt 41 ) 46 \\. [.)] \\|[A-Za-z] \\(?:[-+*]\\|\\(?:[0-9]+ \\) \\(?:[ ]\\|$\\) \\)\\) org-list-allow-alphabetical alpha term] 26) (MY-PATH/org-element.elc . 533))
load(MY-PATH/org-element.elc nil nil t)
load-file(MY-PATH/org-element.elc)
(if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))
(let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove (concat file c) files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file)))
(while files (let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove (concat file c) files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))) (setq files (cdr files)))
(let ((files (directory-files (expand-file-name (substitute-in-file-name dir)) t \\.elc?$))) (while files (let ((file (car files))) (if (file-exists-p (concat file c)) (progn (if (file-newer-than-file-p file (concat file c)) (setq files (remove ... files)) (setq files (cdr files)) (setq file (concat file c) (if ask (if (y-or-n-p (concat file load?)) (progn (load-file file))) (load-file file))) (setq files (cdr files
Re: [O] [BUG] [ODT] Annotations break paragraphs
Am 25.03.2013 18:05, schrieb Bastien: I gave it another try. Please let me know. Now add an annotation at the end of a paragraph... it simply doesn't work unless org-element gets proper support for telling the exporter which Org paragraph elements should be exported together as a single paragraph. Regards, -- Achim. (on the road :-)
Re: [O] python sessions
Am 25.03.2013 17:43, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, Please give me some time still to investigate. Still doubt it's python.el But if yes, probably will be able to tell more. Best, Andreas
Re: [O] [BUG] [ODT] Annotations break paragraphs
Achim Gratz writes:
It can't be fixed this way since annotations end the paragraph and
whatever comes next is a new element. The ODT exporter gets two
paragraphs and has no way of knowing that these should actually be
exported as a single paragraph.
Yeah, that's what I was afraid of.
Inline source blocks might work (i.e.
src_ANNOTATION{...}), I don't know.
Sure. I had a macro solution going before I discovered Jambunathan had
put in an annotation feature. I've updated it now to use export snippets:
#+MACRO: comment
@@odt:office:annotationdc:creator@@{{{author}}}@@odt:/dc:creatordc:date@@{{{date(%Y-%m-%dT%T)}}}@@odt:/dc:datetext:p
text:style-name=P1text:span
text:style-name=T1$1/text:span/text:p/office:annotation@@
That allows using annotations like this{{{comment(You can annotate with
macros\, but remember to escape your commas)}}}.
Yours,
Christian
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Am 25.03.2013 17:57, schrieb Bastien: Can you evaluate my patch against the current state of affair? The current state of affairs is this: 1. Gnus is doing something it shouldn't do, even though it may once have been OK or at least not dangerous. 2. Org doesn't have something that can directly be used in Gnus instead. The first one's a bug in Gnus, not Org. The second would be an enhancement to Org that might be useful in other places as well, independently of the issue with Gnus. Evaluating it against your ideal fix will obvisouly make it look rudimentary. But I think it's better than the current situation. Both solutions rely on Gnus fixing their bug, so we might just as well wait until Gnus has done it. Depending on which way Gnus does this, we may be talking different implementations of the second point above. But given that Gnus expects to use a major mode with no setup, why not give them this: (define-derived-mode org-safe-mode org-mode Org-Safe ;; docstring etc. ) and then conditionalize on the value of mode-name instead of an extra variable that they should bind? This would also help to later add more safe functionality without changing things again and again in Org, Gnus or elsewhere. For example, not running source blocks (we already have a way of doing that for export, so it shouldn't be hard to add this). I'm not arguing against your fix, I'd just prefer we'd start with something we just need to extend into a proper safe-mode instead of having to start again from scratch after hot-fixing this unfortunate interaction with Gnus (and I still don't know how Gnus gets there, anyway). Regards, -- Achim. (on the road :-)
Re: [O] python sessions
On Mon, Mar 25, 2013 at 12:27 PM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 25.03.2013 17:43, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, Please give me some time still to investigate. Still doubt it's python.el But if yes, probably will be able to tell more. Possibly, but know that for me it works with one Emacs version and not another, both using the same git version of Org and same minimal config/setup/test file. Perhaps those affected here should post their Emacs versions? John Best, Andreas
Re: [O] org-mode 7.9.4 now returns org-strip-protective-commas
Nick Dokos nicholas.dokos at hp.com writes: My guess is that you have a seriously mixed-up installation. That's what org-version just told me. I downloaded the latest version of Emacs for windows which includes org-mode v7.9.3f. I'll try start from there. ///Luke
Re: [O] Agenda for 14 days, but still starting on Sat
Try this: (z test ((agenda test ((org-agenda-start-on-weekday 6) (org-agenda-start-day 0) (org-agenda-span 14) On Wed, Mar 20, 2013 at 4:39 PM, David An david64...@gmail.com wrote: In my progress of configuring Org-Mode, I set 'org-agenda-start-on-weekday' to 6 so my Agenda week will start on Saturday and show the next 7 days including whatever current day it may be. Next, I wanted 14 days (2 weeks) displayed, so I then set 'org-agenda-span' to 14. However, the agenda started on the current day, not the Saturday of the current week. For example, if today is Wednesday the 9th, the agenda would show 14 days starting with today, Wednesday the 9th...not this past Saturday the 5th and then showing 14 days from there. Is this normal? How (if possible) can I get my 2 week agenda but starting on my current week's Saturday start-of-week? Thanks! -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] python sessions
On Mon, Mar 25, 2013 at 1:41 PM, John Hendy jw.he...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:27 PM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 25.03.2013 17:43, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, Please give me some time still to investigate. Still doubt it's python.el But if yes, probably will be able to tell more. Possibly, but know that for me it works with one Emacs version and not another, both using the same git version of Org and same minimal config/setup/test file. Perhaps those affected here should post their Emacs versions? Worked for me last week with emacs 24.2.1 and org 8.0-pre (release_8.0-pre-54-gb5a853. Not working now with emacs 24.3.1 and org 8.0-pre
Re: [O] :EXPORT_FILE_NAME: in new exporter possible?
Achim Gratz strom...@nexgo.de writes: talking different implementations of the second point above. But given that Gnus expects to use a major mode with no setup, why not give them this: (define-derived-mode org-safe-mode org-mode Org-Safe ;; docstring etc. ) My feeling is that having a new mode just for preventing users to read setup files is too much. Do you have an idea on how to make org-safe-mode not too heavy? and then conditionalize on the value of mode-name instead of an extra variable that they should bind? The extra defcustom is useful IMHO: the problem we have in Gnus, users will have it anytime when opening a file that is not theirs and that contains a #+SETUPFILE (e.g. files in Worg.) Paranoids (or those who don't use #+SETUPFILE) will probably want to be asked when Org tries to read an arbitrary file in their paths. Others will just set this to (setq org-read-setup-file t). So even if we have a org-safe-mode, I don't see how it will spare us with the cost of a new option. This would also help to later add more safe functionality without changing things again and again in Org, Gnus or elsewhere. For example, not running source blocks (we already have a way of doing that for export, so it shouldn't be hard to add this). Yeah, I see where you go, but you know my dreadful tendency to favor actual things against potential ones, and to go the ugly way rather than going the clean one :) Half-joking -- the thing is I really don't know what org-safe-mode would look like, where else it would be useful, and how it spares us the option for paranoid. If you can help on each of these three points, that'd great (no hurry, as I don't know if I'll have time to follow this thread in the next few days.) I'm not arguing against your fix, I'd just prefer we'd start with something we just need to extend into a proper safe-mode instead of having to start again from scratch after hot-fixing this unfortunate interaction with Gnus (and I still don't know how Gnus gets there, anyway). See my second patch, it gives directions on the Gnus side. -- Bastien
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi, please have a go against latest HEAD and let me know if it works. I tried with annotations at the beginning of a section, of a paragraph, in the middle of a paragraph, at the end of a paragraph and at the end of a section. The fix qualifies as the Most Ugly Hack On Earth, but does the job for me. Thanks, -- Bastien
Re: [O] Different spacing in html output compared to info and pdf
Hello, Bastien b...@altern.org writes: The export framework usually treats differently empty string from nil output. Only in the former blank lines/white spaces are preserved. With this patch it will not be possible anymore to make this distinction with export snippets. What do you think? I think it is good, please go ahead! Done. Regards, -- Nicolas Goaziou
Re: [O] python sessions
On Mar 25, 2013, at 11:27 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 25.03.2013 17:43, schrieb Eric Schulte: John Hendy jw.he...@gmail.com writes: On Mon, Mar 25, 2013 at 11:01 AM, Ista Zahn istaz...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:40 AM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: On Sun, Mar 24, 2013 at 9:38 PM, Nick Dokos nicholas.do...@hp.com wrote: Eric Schulte schulte.e...@gmail.com wrote: From participating in evaluating code throughout the discussion and catching the comments throughout, I'd say yes, at least in terms of how other babel languages function. In other words =#+begin_src R :session foo= creates an R session named foo whereas doing the same with =python= instead of =R= does not yield a named session. From what others experienced, however, the functionality was working correctly (results were persistent across blocks and two differently names blocks created two different sessions), just not named correctly. See the cond form starting at line 169 in ob-python.el. Different session functionality is used based on the `org-babel-python-mode' variable, and on the version of Emacs in use (prior to 24.1 or not). The branch taken when `org-babel-python-mode' equals 'python is certainly broken, as it never saves the name of the newly created buffer, so session re-use and use of multiple named sessions probably works only when `org-babel-python-mode' equals 'python-mode. That's me: org-babel-python-mode's value is python, so it's no wonder it's broken given what Eric says. I'm on emacs 24.3.50 where there is python.el but no python-mode.el. I tried the cheap workaround of switching the value to python-mode, but that does a (require 'python-mode) somewhere, so that option is out as well. I'm on Emacs 24.3.1 and have no python-mode.el, either (only python.el). My setup is working correctly (again, with the caveat of not having named sessions). It sounds like we have the same setup, and the following un-named session example does not work for me. The first code block evaluates successfully, but it doesn't appear to be having any impact on the default session (e.g., in the *Python* buffer). Returns the value of x as expected. #+begin_src python :session x = 1 return x #+end_src #+RESULTS: : 1 #+begin_src python :session return x #+end_src #+RESULTS: The second code block /should/ have access to the x variable defined previous, but instead it throws an error because x is undefined. Currently I'd say session support for python is completely broken. As of this morning I've joined the it does not work crowd. Python sessions worked for me last week, but are now completely broken for me in the way Eric and others describe. Interesting... checked out back to that commit (eff59a15d76647ce8282626b9eb463dc3706d56e) and it still doesn't work. On a whim, I checked my pacman log (Arch's install system) and coincidentally on Mar 20 /after/ I wrote that post in which things work, I ran a system package update. $ grep -i emacs /var/log/pacman.log [2013-03-20 12:51] upgraded emacs (24.2-4 - 24.3-1) Using the Arch Rollback Machine, I downloaded Emacs 24.2.4 and downgraded (also required downgrading imageMagick from 6.8.3.10 - 6.8.2.3). Now it works again (refer to the reproducible example from the mailing list post): - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg68238.html Eric, your example fails for me. I get: Yes, because my example only works in external (non session) execution with the current buggy code, where as your example works with session execution in the old working code. x = 1 return x File stdin, line 1 SyntaxError: 'return' outside function This works, hoever: #+begin_src python :session x = 1 x #+end_src #+RESULTS: : 1 #+begin_src python :session x #+end_src #+RESULTS: : 1 So, with emacs 24.2.4 and current Org-mode (pulled just now) and clean make, *both* named and un-named sessions work for me on Arch Linux. Aha! Thanks for sleuthing this out. So the problem lies in changes to the python.el distributed with Emacs. I don't suppose we can ask whoever made these changes to python.el to fix the breakage they've caused in Org-mode? Thanks, Please give me some time still to investigate. Still doubt it's python.el But if yes, probably will be able to tell more. I think 24.3 is where they changed python.el to fgallina's python.el. So I'd be willing to bet that it _is_ the problem since it's a complete rewrite and many things changed. -Ivan
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi, Bastien, Thanks. Annotations now work inside paragraphs, where they now leave only an extra space instead of paragraph breaks. However, an annotation at the end of a paragraph swallows up the *intended* paragraph break before the next paragraph. And the fix doesn't seem to be quite safe. An annotation immediately before a list item causes an ODT document error -- invalid XML. Examples below. Yours, Christian * Test 1 A paragraph. #+begin_annotation An annotation at the end of a paragraph #+end_annotation Another paragraph that should not be run together with the first, but is. * Test 2 1. A list item. 2. A list item with an annotation at the end. #+begin_annotation This is an annotation. #+end_annotation 3. Another list item. A format error is triggered. Bastien writes: Hi Christian, Christian Moe m...@christianmoe.com writes: Thanks for looking into this. I just pulled and tested, but I cannot confirm the fix yet. I still get paragraph breaks around annotations with Org-mode version 8.0-pre (release_8.0-pre-219-g8eb0d6). I gave it another try. Please let me know.
Re: [O] [patch] LaTeX export using tabu tables
Hello,
Eric Abrahamsen e...@ericabrahamsen.net writes:
I was trying to be too clever! Attached is a non-clever version that
includes a :spread keyword, and a (hopefully) correctly-written commit
message.
Nice. A few more comments follow.
Subject: [PATCH 8/8] ox-latex.el (org-latex--org-table, org-latex-table-row):
Allow use of the tabu table environment when exporting tables to
LaTeX.
Actually the first line of the commit should be more general (and
shouldn't end with a full stop). Perhaps something like:
ox-latex: Allow use of tabu table environment
* ox-latex.el (org-latex--org-table): New latex export attribute
:spread accommodates weird width specification syntax of the tabu
package.
I would drop a note about the tabu and longtabu support in the
description of the patch.
+;; - `:spread' is a boolean attribute specific to the tabu and
+;; longtabu environments, and only takes effect when used in
+;; conjunction with the `:width' attribute. When `:spread' is
Nitpick: Emacs documentation and comments require two spaces after
a sentence.
+ (spread (plist-member attr :spread))
I think you mean (plist-get attr :spread), otherwise :spread nil will
still activate spread. Also, since it's a predicate, I suggest to name
the variable spreadp.
(placement (or (plist-get attr :placement)
(format [%s] org-latex-default-figure-position)))
(centerp (if (plist-member attr :center) (plist-get attr :center)
@@ -2460,6 +2467,23 @@ This function assumes TABLE has `org' as its `:type'
property and
(concat caption \n))
\\end{longtable}\n
(and fontsize })))
+ ;; Longtabu
+ ((equal longtabu table-env)
+ (concat (and fontsize (concat { fontsize))
+ (format \\begin{longtabu}%s{%s}\n
+ (if width
+ (format %s %s
+ (if spread spread to) width) )
+ alignment)
+ (and org-latex-table-caption-above
+(org-string-nw-p caption)
+(concat caption \n))
+ contents
+ (and (not org-latex-table-caption-above)
+(org-string-nw-p caption)
+(concat caption \n))
+ \\end{longtabu}\n
+ (and fontsize })))
;; Others.
(t (concat (cond
(float-env
@@ -2471,7 +2495,10 @@ This function assumes TABLE has `org' as its `:type'
property and
(fontsize (concat { fontsize)))
(format \\begin{%s}%s{%s}\n%s\\end{%s}
table-env
- (if width (format {%s} width) )
+ (if width (format
+(if (equal tabu table-env)
+(if spread spread %s to %s)
+ {%s}) width) )
longtabu gets its own cond branch, but not tabu. I think that
defeats the purpose of the separation, which is to be able to add
support for features of this rich table environment without cluttering
the rest of the code. Doing it partially isn't worth the code
duplication it implies.
IOW, either we separate both tabu and longtabu completely, or we
separate none of them. Your call.
Thank you again.
Regards,
--
Nicolas Goaziou
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hello, Achim Gratz strom...@nexgo.de writes: Am 25.03.2013 18:05, schrieb Bastien: I gave it another try. Please let me know. Now add an annotation at the end of a paragraph... it simply doesn't work unless org-element gets proper support for telling the exporter which Org paragraph elements should be exported together as a single paragraph. Each export back-end has full control over the parse tree generated by Elements, and each transcoding function has full access to the context of the element being transcoded. There are a few examples of this already in back-ends. Hence, ox-latex will wrap contiguous tables sharing the same math mode within the same environment. I didn't look at the problem (nor at Bastien's solution): could someone post the proper code that should be generated? Regards, -- Nicolas Goaziou
Re: [O] Setting taskjuggler project start date (ox-taskjuggler)
Hello, John Hendy jw.he...@gmail.com writes: I think I've narrowed this down to two things: 1) org-taskjuggler-get-start (and probably *-get-end) is not working properly 2) project applicable keywords stored in property drawer should be being parsed, but they're not That's about all I'm good for with my current elisp knowledge! Did you try to set a schedule for the task at the root of the project (with C-c C-s)? `org-taskjuggler-get-start' expects a SCHEDULED: ... line below the headline. Regards, -- Nicolas Goaziou
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi, No, sorry. I see the same issues as in my previous message: an annotation at the end of a paragraph swallows the (intended) paragraph break before the next paragraph; an annotation before a list item causes a format error. The last commit I see from you is at 18:28:50, though: Fix previous commit again / Now off. Should I be looking at something newer? Yours, Christian Bastien writes: Hi, please have a go against latest HEAD and let me know if it works. I tried with annotations at the beginning of a section, of a paragraph, in the middle of a paragraph, at the end of a paragraph and at the end of a section. The fix qualifies as the Most Ugly Hack On Earth, but does the job for me. Thanks,
[O] [ox-html] Using a different title in the head and in the body
Hello, I'm building a small web site using org-mode, and I cannot find out how to have a short title in the head of the generated html, and a longer one in the body. Is this possible? Thanks, Alan
Re: [O] python sessions
Am 24.03.2013 19:41, schrieb Nick Dokos:
running into this, func def seems missing:
Debugger entered--Lisp error: (void-function org-babel-result-cond)
(org-babel-result-cond result-params results
(org-babel-python-table-or-string results))
(if (string= (substring org-babel-python-eoe-indicator 1 -1) results) nil
(org-babel-result-cond result-params results (org-babel-python-table-or-string
results)))
(unless (string= (substring org-babel-python-eoe-indicator 1 -1) results)
(org-babel-result-cond result-params results (org-babel-python-table-or-string
results)))
(lambda (results) (unless (string= (substring org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results
(org-babel-python-table-or-string results(Traceback (most recent call last):\n File \stdin\, line 1, in module\nNameError: name 'foo' is not defined\nbye)
(let* ((send-wait (lambda nil (comint-send-input nil t) (sleep-for 0 5))) (dump-last-value (lambda (tmp-file pp) (mapc (lambda (statement) (insert statement) (funcall
send-wait)) (if pp (list import pprint (format open('%s', 'w').write(pprint.pformat(_)) ...)) (list (format open('%s', 'w').write(str(_)) ...)) (input-body
(lambda (body) (mapc (lambda (line) (insert line) (funcall send-wait)) (split-string body [ \n])) (funcall send-wait ((lambda (results) (unless (string= (substring
org-babel-python-eoe-indicator 1 -1) results) (org-babel-result-cond result-params results (org-babel-python-table-or-string results (case result-type (output
(mapconcat (function org-babel-trim) (butlast (org-babel-comint-with-output (session org-babel-python-eoe-indicator t body) (funcall input-body body) (funcall send-wait)
(funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait)) 2) \n)) (value (let ((tmp-file (org-babel-temp-file python-)))
(org-babel-comint-with-output (session org-babel-python-eoe-indicator nil body) (let (...) (funcall input-body body) (funcall dump-last-value tmp-file ...) (funcall
send-wait) (funcall send-wait) (insert org-babel-python-eoe-indicator) (funcall send-wait))) (org-babel-eval-read-file tmp-file))
org-babel-python-evaluate-session(#buffer *Python* print(foo(100)) \nprint \bye\ output
(output replace))
(if session (org-babel-python-evaluate-session session body result-type
result-params) (org-babel-python-evaluate-external-process body result-type
result-params preamble))
org-babel-python-evaluate(#buffer *Python* print(foo(100)) \nprint \bye\ output
(output replace) nil)
(let* ((session (org-babel-python-initiate-session (cdr (assoc :session params (result-params (cdr (assoc :result-params params))) (result-type (cdr (assoc
:result-type params))) (return-val (when (and (eq result-type (quote value)) (not session)) (cdr (assoc :return params (preamble (cdr (assoc :preamble params)))
(full-body (org-babel-expand-body:generic (concat body (if return-val (format \nreturn %s return-val) )) params (org-babel-variable-assignments:python params))) (result
(org-babel-python-evaluate session full-body result-type result-params preamble))) (org-babel-reassemble-table result (org-babel-pick-name (cdr (assoc :colname-names
params)) (cdr (assoc :colnames params))) (org-babel-pick-name (cdr (assoc :rowname-names params)) (cdr (assoc :rownames params)
org-babel-execute:python(print(foo(100)) \nprint \bye\ ((:comments . #1=) (:shebang . #1#) (:cache . no) (:padline . #1#) (:noweb . no) (:tangle . no)
(:exports . results) (:results . replace output) (:hlines . no) (:padnewline . yes) (:session) (:result-type . output) (:result-params output replace)
(:rowname-names) (:colname-names)))
org-babel-execute-src-block(nil (python print(foo(100)) \nprint \bye\ ((:comments . #1=) (:shebang . #1#) (:cache . no) (:padline . #1#) (:noweb . no)
(:tangle . no) (:exports . results) (:results . replace output) (:hlines . no) (:padnewline . yes) (:session) (:result-type . output) (:result-params output
replace) (:rowname-names) (:colname-names)) nil 0))
org-babel-execute-src-block-maybe()
org-babel-execute-maybe()
org-babel-execute-safely-maybe()
run-hook-with-args-until-success(org-babel-execute-safely-maybe)
org-ctrl-c-ctrl-c(nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
Re: [O] Bug formatting source code in new latex exporter
Hello,
Rick Frankel r...@rickster.com writes:
The cross reference approach seems clever, but maybe a simpler
approach would simply be to add an ATTR_LaTeX(:longlisting) and leave
it up to the user.
That's the most reasonable option, indeed.
The following patch implements :long-listing attribute for src-blocks.
What do you think?
Works for me.
Good. I wonder if :long wouldn't be better. Since the attribute only
applies to src-blocks, the listing is redundant.
BTW, a couple of other small things:
1. I think `elisp' should be added to the default
`org-latex-minted-langs'.
There is no elisp language in Babel, is it? I think it's emacs-lisp.
2. Unrelated, but I spent some time trying to get relative file
links working. At least in Acrobat Reader on windows, the only
way file links work is with no protocol at all
(\url{path/to/file}).
Do you mean the file: part should be dropped for files with a relative
path?
Regards,
--
Nicolas Goaziou
Re: [O] [BUG] [ODT] Annotations break paragraphs
Nicolas Goaziou writes: I didn't look at the problem (nor at Bastien's solution): could someone post the proper code that should be generated? Hi, I'll try. This Org code: A paragraph. #+begin_annotation An annotation. #+end_annotation Another paragraph. ...should result in this ODT XML snippet: text:p text:style-name=Text_20_bodyA paragraph.office:annotationdc:creatorChristian Moe/dc:creatortext:p text:style-name=Text_20_bodyAn annotation./text:p/office:annotation/text:p text:pAnother paragraph./text:p It should not close the first paragraph before the office:annotation element, and it should not wrap that element in a paragraph of its own, as it did before this evening's fixes. But it should close the first paragraph with /text:p after the office:annotation element, and it should open a new text:p element for the second paragraph. The fixes I tested did not. Hope this made sense. Yours, Christian
Re: [O] python sessions
running into this, func def seems missing: Debugger entered--Lisp error: (void-function org-babel-result-cond) My guess is that you have a mixed install. You are mostly running the Org-mode which ships with Emacs (in which `org-babel-result-cond' is not defined), but you are running the version of ob-python.el from the master branch (which expects `org-babel-result-cond' to be defined). This is an increasingly common problem. Maybe the following can help. http://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi Christian,
okay, I reverted my wrong fixes. I'll let Nicolas have a look.
I would not favor a solution that allows more #+begin_ blocks to
be inlined.
The proper way to handle this is to introduce a new syntax for
inlined annotations and to treat them appropriately in exporters.
Since we have both #+begin_src and src_lang{...} I'd suggest
having annotation_{...} or something similar.
The LaTeX exporter could use \marginpar{...} and the HTML back-end
could make them appear when hovering with the mouse on the annotated
parts (just an idea.)
Maybe we will have to live with the current regression for 8.0
and implement the new syntax for 8.1. Or for 8.0, if Nicolas thinks
the change is okay and not too error prone.
Best,
--
Bastien
[O] org-babel-tangle-file not parsing code blocks
Hi list, I have a simple babel file with an Emacs Lisp code block, that looks like this: peepopen-config.org: * Load it #+BEGIN_SRC emacs_lisp (add-to-list 'load-path (concat fullofcaffeine-vendor-dir /peepopen)) (require 'peepopen) (textmate-mode) #+END_SRC (provide 'peepopen-config) I'm trying to tangle it with (org-babel-tangle-file peepopen-config.org), but I get the following in the Messages buffer: Tangled 0 code blocks from peepopen-config.org I'm confused, since the file *does* contain a code block. Am I doing something wrong? Thanks in advance, - Marcelo.
Re: [O] org-babel-tangle-file not parsing code blocks
Versions: Org-mode version 8.0-pre (release_8.0-pre-186-g8aeea9.dirty) GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2013-03-12 On Mon, Mar 25, 2013 at 4:02 PM, Marcelo de Moraes Serpa celose...@gmail.com wrote: Hi list, I have a simple babel file with an Emacs Lisp code block, that looks like this: peepopen-config.org: * Load it #+BEGIN_SRC emacs_lisp (add-to-list 'load-path (concat fullofcaffeine-vendor-dir /peepopen)) (require 'peepopen) (textmate-mode) #+END_SRC (provide 'peepopen-config) I'm trying to tangle it with (org-babel-tangle-file peepopen-config.org), but I get the following in the Messages buffer: Tangled 0 code blocks from peepopen-config.org I'm confused, since the file *does* contain a code block. Am I doing something wrong? Thanks in advance, - Marcelo.
Re: [O] Setting taskjuggler project start date (ox-taskjuggler)
On Mon, Mar 25, 2013 at 3:15 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: I think I've narrowed this down to two things: 1) org-taskjuggler-get-start (and probably *-get-end) is not working properly 2) project applicable keywords stored in property drawer should be being parsed, but they're not That's about all I'm good for with my current elisp knowledge! Did you try to set a schedule for the task at the root of the project (with C-c C-s)? `org-taskjuggler-get-start' expects a SCHEDULED: ... line below the headline. No. Unfortunately, though obvious now, it evaded me that =scheduled= needed an orgmode time stamp. If you have =org-taskjuggler-keep-project-as-task=, it will take the :start: property and use this in the project-as-top-level-task output. Could this be used after =scheduled= and before defaulting to today's date? This would seem to unify the syntax. It strikes me as reasonable to take 1) scheduled, 2) :start: in property drawer and 3) default to today's date (in that order). What do you think? I didn't see this mentioned at the tutorial: - http://orgmode.org/worg/org-tutorials/org-taskjuggler.html I'm writing an updated version for tj3, so I'll include this. Thanks! John Regards, -- Nicolas Goaziou
