Re: [O] [BUG] Inconsistency in src block hiding
Hi Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte eric.schu...@gmx.com writes: Well maybe we should roll back this change. Please don't. _That_ would be a regression. These changes /have/ caused a software regression, and should be reverted immediately, since: - they change current expected and implemented behavior to the cost of users expectations and current use, with no prior discussion and agreement on behavior changes It has been proven that to achieve the required consistency set out by this thread /without/ breaking current expectations is less than straight-forward, and the changes should therefore be moved to EXPERIMENTAL - at least until the changes are proven not to break current expectations. Much of org-mode is currently inconsistent - and while it is highly desirable to improve on that situation, it should not become the major decision to change code at the cost of regression - org-mode is a very practical system used successfully by lots of (very appreciative) people, and while all users appreciate bug fixes / enhancements in the fast-moving repository that is org-mode (thanks Carsten), clear regression such as this should be avoided in master at all costs. At least that is my understanding of the development model as established by Carsten. If this is /not/ the case, then many people are wasting their time writing regression tests IMHO. Best, Martyn [...]
[O] IMAP support for VM links in orgmode (org-vm.el)
The attached patch (relative to yesterday's state of the orgmode git repository) adds the possibility to have org-mode links to IMAP folders in VM and to messages inside IMAP folders. It requires VM 8.2.0a or later. IMAP links have the format vm-imap:account:imap-folder-name for a folder and vm-imap:account:imap-folder-name#message-id for a message. The account:imap-folder notation is the same that is used in VM when entering a folder name in the minibuffer. I ended up creating a new link type (vm-imap) instead of overloading the vm link type with some cryptic syntax. This also seems more consistent with how VM considers IMAP folders to be in a separate universe from local folders. I hope this will be useful to others! Konrad. org-vm.patch Description: Binary data
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Hi Bernt, Bernt Hansen be...@norang.ca writes: * lisp/org-agenda.el (org-agenda-clock-in): Save restriction when clocking in from the agenda Narrowed org buffers are now retained when clocking in from the agenda. We only widen the buffer when the task to clock in is outside the existing restriction. It seems that adding save-restriction to org-agenda-clock-in causes the following: When one clocks in from the agenda, all preexisting drawers in a buffer are aligned to org-tags-column (i.e., the right side of the file). I can confirm this using emacs -Q. Here's a sample file. Before clocking in it looks like this: --8---cut here---start-8--- * A headline SCHEDULED: 2012-01-18 Wed +1d :LOGBOOK: CLOCK: [2012-01-18 Wed 20:10]--[2012-01-19 Thu 07:18] = 11:08 :END: :PROPERTIES: :HELLO: there :END: * And another :PROPERTIES: :NOW: and again :END: --8---cut here---end---8--- After clocking in from the agenda -- (org-agenda-clock-in) -- the file looks like this: --8---cut here---start-8--- * A headline SCHEDULED: 2012-01-18 Wed +1d :LOGBOOK: CLOCK: [2012-01-19 Thu 07:19] CLOCK: [2012-01-18 Wed 20:10]--[2012-01-19 Thu 07:18] = 11:08 :END: :PROPERTIES: :HELLO: there :END: * And another :PROPERTIES: :NOW: and again :END: --8---cut here---end---8--- Strangely (though not demonstrated in the above example), all tags in the buffer are also realigned. Note: org-indent-mode is not on. My emacs version is: GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.24.8) of 2012-01-18 on archeee Org-version: release_7.8.03-149-g46ff3 Org-mode version 7.8.03 (release_7.8.03.149.g46ff3) Best, Matt P.S. I hope all on the list are doing well. I look forward to participating more in the near future. Bernt Hansen be...@norang.ca writes: * lisp/org-agenda.el (org-agenda-clock-in): Save restriction when clocking in from the agenda Narrowed org buffers are now retained when clocking in from the agenda. We only widen the buffer when the task to clock in is outside the existing restriction. --- lisp/org-agenda.el | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 780794e..f240f5e 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7797,14 +7797,15 @@ The cursor may be at a date in the calendar, or in the Org agenda. newhead) (org-with-remote-undo (marker-buffer marker) (with-current-buffer (marker-buffer marker) - (widen) - (goto-char pos) - (org-show-context 'agenda) - (org-show-entry) - (org-cycle-hide-drawers 'children) - (org-clock-in arg) - (setq newhead (org-get-heading))) - (org-agenda-change-all-lines newhead hdmarker) + (save-restriction + (widen) + (goto-char pos) + (org-show-context 'agenda) + (org-show-entry) + (org-cycle-hide-drawers 'children) + (org-clock-in arg) + (setq newhead (org-get-heading))) + (org-agenda-change-all-lines newhead hdmarker)) (defun org-agenda-clock-out () Stop the currently running clock.
[O] [bug] Table editing is enabled in source code blocks!
#+TITLE: Table editing is enabled in source code blocks! #+AUTHOR:Seb Vauban #+DATE: 2012-01-19 * Summary Table editing comes into play when editing source code blocks! * Example #+begin_src sh ls *.org \ | grep this #+end_src Take the above code: 1. Go at the end of this 2. Press `RET' It becomes: #+begin_src sh ls *.org \ | grep this | | | #+end_src * Version info Org-mode version 7.8.03 (release_7.8.03.164.ga5347) GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-07 on MARVIN Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Eeek! I'm not running into this (as far as I know) in my current setup but I vote we just revert the clocking restriction patches. There are other unresolved issues with these patches that I've seen and don't currently have a fix for. - column view clocking totals on the agenda are wrong if a restriction is in place in the org file In my current setup recreating the restriction with a speed key is easy so I can live with that until a proper fix can be created or we decide to drop this patch series. Bastien/Carsten: Please revert the following commits (again). Sorry :( - 7a73e15 (Remove file restrictions when generating clock report data, 2012-01-09) - e8f93a75 (Honour existing restrictions when visiting tasks from the agenda, 2011-12-30) - c41a6f5 (Honour existing restrictions when clocking in from the agenda, 2011-12-30) - a0a26cd (Honour existing restrictions when regenerating the agenda, 2011-12-30) Regards, Bernt Matt Lundin m...@imapmail.org writes: Hi Bernt, Bernt Hansen be...@norang.ca writes: * lisp/org-agenda.el (org-agenda-clock-in): Save restriction when clocking in from the agenda Narrowed org buffers are now retained when clocking in from the agenda. We only widen the buffer when the task to clock in is outside the existing restriction. It seems that adding save-restriction to org-agenda-clock-in causes the following: When one clocks in from the agenda, all preexisting drawers in a buffer are aligned to org-tags-column (i.e., the right side of the file). I can confirm this using emacs -Q. Here's a sample file. Before clocking in it looks like this: * A headline SCHEDULED: 2012-01-18 Wed +1d :LOGBOOK: CLOCK: [2012-01-18 Wed 20:10]--[2012-01-19 Thu 07:18] = 11:08 :END: :PROPERTIES: :HELLO: there :END: * And another :PROPERTIES: :NOW: and again :END: After clocking in from the agenda -- (org-agenda-clock-in) -- the file looks like this: * A headline SCHEDULED: 2012-01-18 Wed +1d :LOGBOOK: CLOCK: [2012-01-19 Thu 07:19] CLOCK: [2012-01-18 Wed 20:10]--[2012-01-19 Thu 07:18] = 11:08 :END: :PROPERTIES: :HELLO: there :END: * And another :PROPERTIES: :NOW: and again :END: Strangely (though not demonstrated in the above example), all tags in the buffer are also realigned. Note: org-indent-mode is not on. My emacs version is: GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.24.8) of 2012-01-18 on archeee Org-version: release_7.8.03-149-g46ff3 Org-mode version 7.8.03 (release_7.8.03.149.g46ff3) Best, Matt P.S. I hope all on the list are doing well. I look forward to participating more in the near future. Bernt Hansen be...@norang.ca writes: * lisp/org-agenda.el (org-agenda-clock-in): Save restriction when clocking in from the agenda Narrowed org buffers are now retained when clocking in from the agenda. We only widen the buffer when the task to clock in is outside the existing restriction. --- lisp/org-agenda.el | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 780794e..f240f5e 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7797,14 +7797,15 @@ The cursor may be at a date in the calendar, or in the Org agenda. newhead) (org-with-remote-undo (marker-buffer marker) (with-current-buffer (marker-buffer marker) - (widen) - (goto-char pos) - (org-show-context 'agenda) - (org-show-entry) - (org-cycle-hide-drawers 'children) - (org-clock-in arg) - (setq newhead (org-get-heading))) -(org-agenda-change-all-lines newhead hdmarker) + (save-restriction +(widen) +(goto-char pos) +(org-show-context 'agenda) +(org-show-entry) +(org-cycle-hide-drawers 'children) +(org-clock-in arg) +(setq newhead (org-get-heading))) + (org-agenda-change-all-lines newhead hdmarker)) (defun org-agenda-clock-out () Stop the currently running clock.
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Hi Bernt and Matt, Bernt Hansen be...@norang.ca writes: Bastien/Carsten: Please revert the following commits (again). Sorry :( Done. Thanks, -- Bastien
Re: [O] [BUG] Inconsistency in src block hiding
On 19.01.2012 07:10, Martyn Jago wrote: Hi Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte eric.schu...@gmx.com writes: Well maybe we should roll back this change. Please don't. _That_ would be a regression. These changes /have/ caused a software regression, and should be reverted immediately, since: Also, the exporting of a specific drawers seems to be inconsistent w/ the existing semantics for drawers in general... rick
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Correction to the commit SHA1s - 7a73e15 (Remove file restrictions when generating clock report data, 2012-01-09) - 8f93a75 (Honour existing restrictions when visiting tasks from the agenda, 2011-12-30) - c41a6f5 (Honour existing restrictions when clocking in from the agenda, 2011-12-30) - a0a26cd (Honour existing restrictions when regenerating the agenda, 2011-12-30) -Bernt Bernt Hansen be...@norang.ca writes: Please revert the following commits (again). Sorry :( - 7a73e15 (Remove file restrictions when generating clock report data, 2012-01-09) - e8f93a75 (Honour existing restrictions when visiting tasks from the agenda, 2011-12-30) - c41a6f5 (Honour existing restrictions when clocking in from the agenda, 2011-12-30) - a0a26cd (Honour existing restrictions when regenerating the agenda, 2011-12-30)
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Hi Bernt, Bernt Hansen wrote: Eeek! I'm not running into this (as far as I know) in my current setup but I vote we just revert the clocking restriction patches. There are other unresolved issues with these patches that I've seen and don't currently have a fix for. Please revert the following commits (again). Sorry :( - 7a73e15 (Remove file restrictions when generating clock report data, 2012-01-09) - e8f93a75 (Honour existing restrictions when visiting tasks from the agenda, 2011-12-30) - c41a6f5 (Honour existing restrictions when clocking in from the agenda, 2011-12-30) - a0a26cd (Honour existing restrictions when regenerating the agenda, 2011-12-30) FYI, I have the (subjective) impression that the below bug just came up a couple of days ago. I would say less than one calendar week. But I may be wrong. After clocking in from the agenda -- (org-agenda-clock-in) -- the file looks like this: * A headline SCHEDULED: 2012-01-18 Wed +1d :LOGBOOK: CLOCK: [2012-01-19 Thu 07:19] CLOCK: [2012-01-18 Wed 20:10]--[2012-01-19 Thu 07:18] = 11:08 :END: :PROPERTIES: :HELLO: there :END: * And another :PROPERTIES: :NOW: and again :END: Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: FYI, I have the (subjective) impression that the below bug just came up a couple of days ago. I would say less than one calendar week. But I may be wrong. Same here. -- Bastien
[O] rfc: link type html
IIUC, opening the link type http triggers ‘browse-url’ which eventually wants to talk to a server using URL that begins with http://;, and opening the link type file basically triggers ‘find-file’. What if i want to ‘browse-url’ with scheme file://? That is, i don't want to bother going through a server. This is what i was able to cook up: (defun ttn-view-html-file-in-browser (path) (browse-url (browse-url-file-url path))) (org-add-link-type html 'ttn-view-html-file-in-browser) This allows me to write in ~/build/GNU/rcs/.ttn.org, e.g.: [[html:.,lcov/rcs/src/index.html][lcov output]] and see in the browser's location box: file:///home/ttn/build/GNU/rcs/.%2clcov/rcs/src/index.html My questions: - Is this already builtin somewhere? - If so, where? - If not, is the above code the recommended way?
[O] C-u C-c C-q refuses to work, sometimes
Hi to my fellow Orgers! In (org) Setting tags, there is in the paragraph for `C-c C-q (`org-set-tags-command')': When called with a `C-u' prefix, all tags in the current buffer will be aligned to that column, just to make things look nice. If I open file epsilon.org with the cursor at the very beginning, just before #+TITLE:', command `C-u C-c C-q' yields: Before first headline at position 1 in buffer epsilon.org in the minibuffer, and reformatting does not occur. When I advance a few lines until the first header, the command works as expected. Since the command is meant to adjust all tags in the current buffer, I would think the cursor should not have to be somewhere in particular before issuing it. Agreed? François
Re: [O] [BUG] Inconsistency in src block hiding
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte eric.schu...@gmx.com writes: Well maybe we should roll back this change. Please don't. _That_ would be a regression. I'll wait to see if Nicolas has a solution which is both functional and conforms to the Org-mode wide syntax norms. The problem comes from the current exporter, which isn't neutral about drawers, by default. I think that a temporary fix should be to: 1. Change default drawer formatting function to the following (neutral): #+begin_src emacs-lisp (defun org-export-format-drawer (name contents) Export contents of a drawer as-is. Property drawers are ignored. (if (string= PROPERTIES name) contents)) #+end_src 2. Handle drawers earlier in org-export-preprocess-string function, i.e. just before footnote handling, so its contents can benefit from further modifications. 3. Allow drawers in export by default (excepted PROPERTIES drawers). That is change `org-export-with-drawers' default value to t. I'm packaging this in the following quick patch, highly untested. Thanks for taking the time to collect these changes into a patch, however I believe the changes you describe present /new/ behavior (e.g., new export semantics for drawers), rather than a bug repair. For the time being I am going to bring back results folding until an acceptable alternative can be agreed upon and implemented. Best, Regards, -- Nicolas Goaziou From 0c15bf694f8051eb58fd131868059460f28f2e0d Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou n.goaz...@gmail.com Date: Wed, 18 Jan 2012 18:34:11 +0100 Subject: [PATCH] org-exp: Set neutral behaviour towards drawers * lisp/org-exp.el (org-export-with-drawers): Change default value so all drawers are exportable as a default. (org-export-preprocess-string): Handle drawers earlier in the preprocess, so their contents can be modified further. (org-export-format-drawer): Change default behaviour contents of drawers are exported as Org code. As a special case, property drawers are still ignored. --- lisp/org-exp.el | 26 -- 1 files changed, 8 insertions(+), 18 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index c7e1a94..d9b0a3e 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -406,7 +406,7 @@ This option can also be set with the +OPTIONS line, e.g. \tags:nil\. (const :tag Not in TOC not-in-toc) (const :tag On t))) -(defcustom org-export-with-drawers nil +(defcustom org-export-with-drawers t Non-nil means export with drawers like the property drawer. When t, all drawers are exported. This may also be a list of drawer names to export. @@ -1156,6 +1156,10 @@ on this string to produce the exported version. ;; Get rid of tasks, depending on configuration (org-export-remove-tasks (plist-get parameters :tasks)) + ;; Get rid of drawers + (org-export-remove-or-extract-drawers + drawers (plist-get parameters :drawers)) + ;; Prepare footnotes for export. During that process, footnotes ;; actually included in the exported part of the buffer go ;; though some transformations: @@ -1209,10 +1213,6 @@ on this string to produce the exported version. ;; Find HTML special classes for headlines (org-export-remember-html-container-classes) - ;; Get rid of drawers - (org-export-remove-or-extract-drawers - drawers (plist-get parameters :drawers)) - ;; Get the correct stuff before the first headline (when (plist-get parameters :skip-before-1st-heading) (goto-char (point-min)) @@ -1500,19 +1500,9 @@ EXP-DRAWERS will be removed. name content)) (insert content))) -(defun org-export-format-drawer (name content) - Format the content of a drawer as a colon example. - (if (string-match [ \t]+\\' content) - (setq content (substring content (match-beginning 0 - (while (string-match \\`[ \t]*\n content) -(setq content (substring content (match-end 0 - (setq content (org-remove-indentation content)) - (setq content (concat : (mapconcat 'identity - (org-split-string content \n) - \n: ) - \n)) - (setq content (concat : (upcase name) \n content)) - (org-add-props content nil 'org-protected t)) +(defun org-export-format-drawer (name contents) + Export contents of a drawer as-is. + (if (string= PROPERTIES name) contents)) (defun org-export-handle-export-tags (select-tags exclude-tags) Modify the buffer, honoring SELECT-TAGS and EXCLUDE-TAGS. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [BUG] Inconsistency in src block hiding
Martyn Jago martyn.j...@btinternet.com writes: Hi Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte eric.schu...@gmx.com writes: Well maybe we should roll back this change. Please don't. _That_ would be a regression. These changes /have/ caused a software regression, and should be reverted immediately, since: - they change current expected and implemented behavior to the cost of users expectations and current use, with no prior discussion and agreement on behavior changes I'm inclined to agree. I've just reverted the removal of results folding pending further discussion. I apologize for the inconvenience. It has been proven that to achieve the required consistency set out by this thread /without/ breaking current expectations is less than straight-forward, and the changes should therefore be moved to EXPERIMENTAL - at least until the changes are proven not to break current expectations. Much of org-mode is currently inconsistent - and while it is highly desirable to improve on that situation, it should not become the major decision to change code at the cost of regression - org-mode is a very practical system used successfully by lots of (very appreciative) people, and while all users appreciate bug fixes / enhancements in the fast-moving repository that is org-mode (thanks Carsten), clear regression such as this should be avoided in master at all costs. My adviser is fond of saying something along the lines of programming languages should let you break the rules. To the extent that Org-mode is a document programming language its rules should be flexible as well. Best, At least that is my understanding of the development model as established by Carsten. If this is /not/ the case, then many people are wasting their time writing regression tests IMHO. Best, Martyn [...] -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] functions from cl package called at runtime
Thanks for catching this, I've just pushed up a fix. Is there a convention for which macros from cl-macs are allowable and which are forbidden? For example `flet' is used extensively throughout the Org-mode code base. Is the convention that macros are allowable while functions are not? Also, while intersection below is a function defined in cl-seq, the use of `intersection' in ob.el refers to a local function and not the cl-seq function, so it should be fine. Thanks, Achim Gratz strom...@nexgo.de writes: The sources in ob.el have picked up several runtime invocations to functions from the cl package via two commits from Eric: fc92b2e2 lisp/ob.el (let ((tempvar (gensym file))) fc92b2e2 lisp/ob.el (let ((tempvar (gensym file))) fc92b2e2 lisp/ob.el (let ((tempvar (gensym file))) fc92b2e2 lisp/ob.el (let ((tempvar (gensym file)) fc92b2e2 lisp/ob.el (rx (gensym rx))) abf3060e lisp/ob.el (flet ((intersection (as bs) abf3060e lisp/ob.el (intersection (cdr as) bs) abf3060e lisp/ob.el (intersection (case context These may need to be revised... Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [BUG] Inconsistency in src block hiding
Hello, Martyn Jago martyn.j...@btinternet.com writes: These changes /have/ caused a software regression, and should be reverted immediately, since: - they change current expected and implemented behavior to the cost of users expectations and current use, with no prior discussion and agreement on behavior changes Surprisingly, I do remember discussing about this change not so long ago. Thus, I think the no prior discussion is fallacious. To sum it up, in that discussion, I had suggested that allowing to fold keywords wasn't a good idea since: 1. Every element could get a #+name keyword, so everything would be eventually foldable (and think about the mess to unfold piece-wise, or everything). 2. Drawers would have consequently no more purpose (properties drawer excepted). It has been proven that to achieve the required consistency set out by this thread /without/ breaking current expectations is less than straight-forward, and the changes should therefore be moved to EXPERIMENTAL - at least until the changes are proven not to break current expectations. Much of org-mode is currently inconsistent - and while it is highly desirable to improve on that situation, it should not become the major decision to change code at the cost of regression - org-mode is a very practical system used successfully by lots of (very appreciative) people, and while all users appreciate bug fixes / enhancements in the fast-moving repository that is org-mode (thanks Carsten), clear regression such as this should be avoided in master at all costs. As a side note, master isn't maint, which is the place for stability and also bug fixing. On the other hand, if a change doesn't hit master branch, it won't get enough testing. Now, there is no regression here: it has never been specified that #+results keywords must allow to fold code. Folding is about headlines, blocks, drawers and, optionally, items. Period. Relying on #+keyword folding is a mistake. It would be better to improve and correct drawers export (one of the things I address in the new exporter). I talked in this thread about drawers rehabilitation. Reverting this change will postpone this goal or, worse, bury it. Regards, -- Nicolas Goaziou
Re: [O] functions from cl package called at runtime
Eric Schulte eric.schu...@gmx.com writes: Is there a convention for which macros from cl-macs are allowable and which are forbidden? You might want to ask on the Emacs list, but my understanding is that no Emacs core packages should depend on cl _at runtime_, but it is OK to use the cl package during byte-compilation. For example `flet' is used extensively throughout the Org-mode code base. Is the convention that macros are allowable while functions are not? A macro would typically be expanded at compile time, so that would be OK. AFAIK gensym is a function, not a macro. The calls to gensym that the byte-compiler complains about are expanded at runtime because they are themselves inside a macro definition. Also, while intersection below is a function defined in cl-seq, the use of `intersection' in ob.el refers to a local function and not the cl-seq function, so it should be fine. The byte-compiler thinks otherwise, so I'd check that assumption again... but it might be a good idea to disambiguate the name with a prefix anyway. I've just tested the latter approach (renaming intersection to ob-intersection) and it does work, so somehow the byte-compiler doesn't quite get what is going on in the flet expansion when the symbol is already present via the cl package. I've just looked at the comments in cl-macs.el and it seems that flet should be used with care anyway, since it is not quite doing what it is supposed to do... Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] [BUG] Inconsistency in src block hiding
Hello, Eric Schulte eric.schu...@gmx.com writes: Thanks for taking the time to collect these changes into a patch, however I believe the changes you describe present /new/ behavior (e.g., new export semantics for drawers), rather than a bug repair. I'd rather say that its intent is to fix an old bug: incomplete specifications of drawers. Also, I don't add export semantics for drawers: I remove any, by default. Again, drawers allow to fold any part of an Org buffer without adding semantics to its contents. It's a more general solution than keywords. But you already know that. For the time being I am going to bring back results folding until an acceptable alternative can be agreed upon and implemented. There is already an acceptable alternative. I sincerely hope that reverting this won't make it impossible to be implemented later. Regards, -- Nicolas Goaziou
Re: [O] [ODT] image scaling overridden by long caption
Hello Andreas Hi all, I experience unexpected behaviour with the excellent odt exporter in case of included images. When I add a #+caption the text width of that caption overrides the specified image width (#ATTR_ODT: :witdh X), which I use to downscale the image in the odt. Especially if that caption will span across multiple lines, that effect is visible. Here is the example: --- * odt image test #+caption: foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src #+caption: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo #+ATTR_ODT: :width 8 #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src - I'd expect the image scaling to take place in either case. Maybe even the caption should wrap at the specified width. I have pushed a fix for this. Hope the new behaviour is according to your expectation. On a related note: Could I place two (correctly scaled) images side-by-side? For the sake of record, your request is much similar to what is discussed here http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html - save for (dynamically-generated) images taking the place of src blocks. Try something like this: #+begin_list-table - [[./foo1.png]] - [[./foo2.png]] #+end_list-table Make sure that the images are small images. If you replace the image links above with R srcblocks or attach caption/attr_odt to the above above images, the results are less than satisfactory. So the answer to your question is a soft no. Notes to self: There are multiple ways to achieve side-by-side effect. - use tables (aka list tables) - use 2-Column sections - 2-column frames (what is this?) side-by-side has surfaced in the list for the second time, I think it deserves to be supported out of the box. Jambunathan K.
Re: [O] latex export of #+header: lines
Andreas Leha andreas.l...@med.uni-goettingen.de writes: Andreas Leha andreas.l...@med.uni-goettingen.de writes: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Andreas, Andreas Leha wrote: I am experiencing a problem with the latex exporter: #+header: lines are visible in the exported file. Example: /==\ * test header tag #+caption: foo #+label: fig:fig1 #+name: foo #+header: :file foo.png #+header: :width 3600 :height 3600 :res 600 #+begin_src R :exports results :results graphics plot(1:10, 1:10) #+end_src \==/ Try using #+LaTeX_HEADER: lines, instead. Best regards, Seb Hi Seb, thanks for the reply! But as far as I know, #+LaTeX_HEADER (as described here http://orgmode.org/org.html#Header-and-sectioning) is a different thing from babel source block header arguments (as described here http://orgmode.org/org.html#Code-block-specific-header-arguments) I use both quite extensively. The #+header: tags can be avoided by creating lng #+begin_src lines. But still, they should not appear in the exported tex code, I think. Best, Andreas Just tried, and the odt export has them as well. Maybe a problem on my test file? Or is the #+header(s): tag somehow deprecated? If you remove the indentation of #+header: line (and thereby force it to start at column 0) you will see that (atleast) the ODT export doesn't have the header lines. I think the problem is not with the latex or odt backends as such but in the export pre-processor. - Andreas --
Re: [O] [PATCH 2/3] Honour existing restrictions when clocking in from the agenda
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hi Bernt, Bernt Hansen wrote: Eeek! I'm not running into this (as far as I know) in my current setup but I vote we just revert the clocking restriction patches. There are other unresolved issues with these patches that I've seen and don't currently have a fix for. Please revert the following commits (again). Sorry :( - 7a73e15 (Remove file restrictions when generating clock report data, 2012-01-09) - e8f93a75 (Honour existing restrictions when visiting tasks from the agenda, 2011-12-30) - c41a6f5 (Honour existing restrictions when clocking in from the agenda, 2011-12-30) - a0a26cd (Honour existing restrictions when regenerating the agenda, 2011-12-30) FYI, I have the (subjective) impression that the below bug just came up a couple of days ago. I would say less than one calendar week. But I may be wrong. Hi Seb, These patches were created by me back in December and recently applied by Bastien on Jan 11th so that's probably when the problem showed up. I saw the initial report about this alignment problem on the mailing list when my gmane access came back but I couldn't reproduce it with my setup (using org-indent-mode, but I didn't try very hard at the time) so I just assumed incorrectly that this was caused by later commits I hadn't pulled yet. The 4 patches really all go in the same topic. There are still other problems with this series and right now I'm leaning towards dropping them completely. There are lots of places in the agenda where things seem to go wrong if the org file restriction is retained. Regards, Bernt
Re: [O] functions from cl package called at runtime
Also, while intersection below is a function defined in cl-seq, the use of `intersection' in ob.el refers to a local function and not the cl-seq function, so it should be fine. The byte-compiler thinks otherwise, so I'd check that assumption again... but it might be a good idea to disambiguate the name with a prefix anyway. I've just tested the latter approach (renaming intersection to ob-intersection) and it does work, so somehow the byte-compiler doesn't quite get what is going on in the flet expansion when the symbol is already present via the cl package. I've just looked at the comments in cl-macs.el and it seems that flet should be used with care anyway, since it is not quite doing what it is supposed to do... Thanks for looking into this, I've just disambiguated the name of intersection as you suggest. The word of warning with respect to flet is well taken, in looking at gensym it seems it also doesn't quite deliver on its promises. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Minimal overhead Org-mode blogging system
Puneeth Chaganti puncha...@gmail.com: This is totally home brew stuff. Well, thank you for sharing this home brew stuff. I've been trying to use the other org based blog solutions, but they have all failed for some reason or other, and they have also seemed abandoned. Sorry for the trouble you are having, in getting it to run. No worries! :-) Try commenting out the lines 257, 258 in reprise.py and see if that works for you. I'll take a look later, and try to see if this can be improved. Yep, commenting out the tag cloud generation made the reprise.py script run witout failing. Thanks!
Re: [O] [bug] Tables in lists not exported to ODT
One comment: for tables that are indented, it probably makes sense to have the table take up 100% of the width available to it? Do you want to maximize the real-estate available for tables - indented or otherwise. Indentation for tables consume some real estate. Are you saying that you want no indentation for tables AND have them occupy 100% of paper-width (save for margins). In any case, is there an easy way to customise this from within LibreOffice? I note that, in etc/styles/OrgOdtContentTemplate.xml, you have defined OrgTable with 96% for the width but I have no idea how to change that value from within LibreOffice. I am open to bumping the number to 100% by default, if that makes the exporter more usable. Btw, I was trying to make the tables cute-looking (i.e., have them occupy just the right amount of space) There is no easy way to do it from within org-odt + LibreOffice combo. This OrgTable style does not appear anywhere in the style chooser (F11). Tables and table related things are not cusotmizable through the LibreOffice stylist. The OASIS spec does allow for common styles for tables - styles that you typically see in the LibreOffice stylist or OrgOdtStyles.xml. Since LibreOffice's implementation doesn't honor common styles for tables and totally ignore those, I have no option but to put them in the OrgOdtContentTemplate.xml file as automatic styles. The only easiest way is to modify the XML file directly. By the way, I was surprised, upon reading your comments in the git log, that OpenDocument doesn't support tables within lists. This seems like a silly restriction? Given that OpenDocument uses XML for its encoding, I would have thought that a hierarchical structure in a document would be trivial to represent. Do you know what the reasoning was? Just curious! I have no clue. To my untrained eye, OASIS spec seems more like a documentation of an existing system (as an after-thought) and doesn't provide any commentaries on underlying design principle. So the user is left with his own (subjective) judgments. Based on your (LaTeX) experience, what is the best way to typeset tables. Should they be put in a frame and configurable as floats? Thanks again, eric
[O] custom agenda command with function doesn't work
Hello, I'm trying to write a custom agenda command that cycles through a list of names and builds an agenda block for each one with his tasks. I wrote a command, that I have called org-sec-tasksbymember that throws a list of tags-todo with the parameters I want. For example, for a list of members (Me Pablo Miguel Carlos), defined in a variable, the evaluation of (org-sec-tasksbymember) throws: ((tags-todo +Resp=\Me\) (tags-todo +Resp=\Pablo\) (tags-todo +Resp=\Miguel\) (tags-todo +Resp=\Carlos\)) If I define a custom agenda command like (without using the command): (q Tasks by member ((tags-todo +Resp=\Me\) (tags-todo +Resp=\Pablo\) (tags-todo +Resp=\Miguel\) (tags-todo +Resp=\Carlos\))) It works, but if use this agenda command: (q Tasks by member (org-sec-tasksbymember)) I got an error of Wrong type argument: listp, org-sec-tasksbymember I can't find a solution. Can anyone help me. I'm sorry if this is dumb. Thanks -- *Juan Queipo de Llano Moya* Instituto de Ciencias de la Construcción Eduardo Torroja - CSIC c/ Serrano Galvache, 4 28033 MADRID jque...@ietcc.csic.es mailto:jque...@ietcc.csic.es Tel: 91 302 04 40 ext. 202
