Re: [O] [PATCH] Markdown: Add publishing in markdown
Hi Brice, applied, thank you! - Carsten On 22.9.2013, at 20:32, Brice Waegenire wrote: > * lisp/ox-md.el > > Add the possibility to publish in Markdown by using the function > org-md-publish-to-md. > > TINYCHANGE > --- > diff --git a/lisp/ox-md.el b/lisp/ox-md.el > index f7e4875..71759ac 100644 > --- a/lisp/ox-md.el > +++ b/lisp/ox-md.el > @@ -31,7 +31,7 @@ > > (eval-when-compile (require 'cl)) > (require 'ox-html) > - > +(require 'ox-publish) > > ^L > ;;; User-Configurable Variables > @@ -477,6 +477,17 @@ Return output file's name." > (org-export-to-file 'md outfile async subtreep visible-only))) > > > +;;;###autoload > +(defun org-md-publish-to-md (plist filename pub-dir) > + "Publish an org file to Markdown. > + > +FILENAME is the filename of the Org file to be published. PLIST > +is the property list for the given project. PUB-DIR is the > +publishing directory. > + > +Return output file name." > + (org-publish-org-to 'md filename ".md" plist pub-dir)) > + > (provide 'ox-md) > > ;; Local variables: > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
"Sebastien Vauban" writes: > Hi Carsten, > > Carsten Dominik wrote: >> On 24.9.2013, at 18:17, Sebastien Vauban wrote: >>> Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug wrote: > > When starting to edit a code block via C-c ' everything works as expected > and the code block is highlighted and an indirect buffer is opened. > > When I click into the highlighted block, I an "send" to the indirect > buffer. > This behavior changes, after saving with C-s, even when nothing has been > edited: the area in the original org file looses its magic, and looks > normal > again and can also be edited! > > The indirect buffer stays functional and, upon close via C-c ' saves the > changes into the original buffer and *overwrites* changes done in this > block > in the org document. This is a bug which is difficult to fix in all generality. What should really happen is that the text in the original buffer is made read-only. But so far this does not happen in our implementation (due to Dan Davison IIRC). The reason for this is that read-only text properties left by accident in a buffer are difficult to get rid of. There are many things the user could go back and screw up the original. That's why Org choses to protect with highlighting with an overlay. Note that this is not a protection against editing, but it is a visual warning. >>> >>> I never knew that "your" goal was to make the code block read-only in the >>> Org >>> buffer. Note that I would be really opposed to such a change. Editing code >>> in >>> the prose would really become a pain to me -- please know that I NEVER use >>> the >>> indirect buffer. >> >> I only mean while there is a special buffer also editing this block! > > Pfff! I'm relieved -- I should have understood it ;-) While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. Cheers, Rainer > > Best regards, > Seb <#secure method=pgpmime mode=sign> -- Rainer M. Krug email: RMKruggmailcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Carsten Dominik writes: > Hi Rainer, hi Carsten, > > it does not get lost - it is in my queue. As are, unfortunately, > another 35 threads with possible bugs. Help is definitely wanted. That's what I was looking for - confirmation that is in somebodys processing queue. Thanks Carsten. Unfortunately I can't hel as I have barely the elisp knowledge to maintain my .emacs file. > > Please see below for my comments and a possible fix. > > On 23.9.2013, at 09:40, Rainer M Krug wrote: > >> I just resend this bug report which has been confirmed by Ista Zahn. >> >> Updated via git ust now: >> >> Org-mode version 8.2 (release_8.2-14-ge5f16b @ >> /Users/rainerkrug/.emacs.d/org-mode/lisp/) >> >> >> When starting to edit a code block via C-c ' everything works as expected >> and the code block is highlighted and an indirect buffer is opened. >> >> When I click into the highlighted block, I an "send" to the indirect >> buffer. This behavior changes, after saving with C-s, even when nothing >> has been edited: the area in the original org file looses its magic, and >> looks normal again and can also be edited! >> >> The indirect buffer stays functional and, upon close via C-c ' saves the >> changes into the original buffer and *overwrites* changes done in this >> block in the org document. > > This is a bug which is difficult to fix in all generality. What > should really happen is that the text in the original buffer is made > read-only. Yup - exactly. That would be the best solution. > But so far this does not happen in our implementation (due > to Dan Davison IIRC). The reason for this is that read-only text > properties left by accident in a buffer are difficult to get rid of. > > There are many things the user could go back and screw up the > original. That's why Org choses to protect with highlighting with an > overlay. Note that this is not a protection against editing, but it > is a visual warning. Possibly because I am using the mouse most of the time to navigate in text and select buffers, I did not realize this. > > However, what happens during saving is indeed a problem - the overlay > gets lost (not really, it gets squeezed to zero by first removing the > source code and then inserting the modified version). > > Could you please try this patch and test it to see if it is stable and > does the right thing? Tried briefly and it seems to work: 1) the visual overlay stays there upon C-x s from indirect buffer 2) If I click with the mouse into it, I am redirected to the indirect buffer (correct terminology here?) Let me know when you pushed it to git, than I can upgrade again. Thanks, Rainer > > Thank you. > > - Carsten > > diff --git a/lisp/org-src.el b/lisp/org-src.el > index 0f88174..062d2d7 100644 > --- a/lisp/org-src.el > +++ b/lisp/org-src.el > @@ -757,6 +757,8 @@ with \",*\", \",#+\", \",,*\" and \",,#+\"." > (delete-region beg (max beg end)) > (unless (string-match "\\`[ \t]*\\'" code) > (insert code)) > + ;; Make sure the overlay stays in place > + (when (eq context 'save) (move-overlay ovl beg (point))) > (goto-char beg) > (if single (just-one-space > (if (memq t (mapcar (lambda (overlay) > > <#secure method=pgpmime mode=sign> -- Rainer M. Krug email: RMKruggmailcom
[O] Org mode issue tracker
Hi everyone, we do not have an issue tracker for Org. However, if you have some time to help, the file with open issues that need attention can be found here: https://dl.dropboxusercontent.com/u/530458/org-tracker.html Note that I do not enter every issue into this file. Normally I wait and see if a report gets addressed on the mailing list, and only if that does not happen, than I make a note in this file. I think this keeps it more manageable for me - an official online bug tracker would probably quickly fill with many small things we can better handle on the list. If you feel that this is not going well enough and if I am missing important reports in this way, let me know and we will find a better solution. Some of these bugs still need confirmation by a second party, and patches are always welcome. If possible, reply in the original thread, while still mentioning the bug number in the above link. Regards - Carsten signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] org mode R remote code evaluation
Hi Michael, The patch seems to be working, the only thing I noticed is having http://www.emacswiki.org/emacs/setup-cygwin.el loaded together with the patched ob-core.el makes tramp prepend "/cygwin" to /tmp/. When I disabled (require 'setup-cygwin) the patch works as expected. Outside of org/babel setup-cygwin has no effect on Tramp. Thanks, Alex On Tue, Sep 24, 2013 at 1:40 PM, Michael Albinus wrote: > Alexander Vorobiev writes: > > > Hi Michael, > > Hi Alex, > > > Here it is. > > Thanks. I believe, the following patch shall cure it: > > --8<---cut here---start->8--- > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -2735,8 +2735,12 @@ > value of `temporary-file-directory' temporarily set to the value > of `org-babel-temporary-directory'." >(if (file-remote-p default-directory) >(let ((prefix > +;; We cannot use `temporary-file-directory' as local part > +;; on the remote host, because it might be another OS > +;; there. So we assume "/tmp", which ought to exist on > +;; relevant architectures. > (concat (file-remote-p default-directory) > - (expand-file-name prefix temporary-file-directory > + (expand-file-name prefix "/tmp/" > (make-temp-file prefix nil suffix)) > (let ((temporary-file-directory >(or (and (boundp 'org-babel-temporary-directory) > --8<---cut here---end--->8--- > > Could you, please, test? > > > Thanks, > > Alex > > Best regards, Michael. >
Re: [O] using orgtbl-sqlinsert
On 25.9.2013, at 02:31, Jason Riedy wrote: > And Eric Abrahamsen writes: >> I've got a table I'm trying to insert into a sqlite >> database. I've been looking at orgtbl-sqlinsert and this >> page[fn:1], but I suspect all that is out of date. > > FYI, I have changed employers and thus no longer have up-to-date > paperwork at the FSF for assignment. That is only one reason I > haven't updated anything relevant to the orgtbl-sqlinsert > procrasti-working hack... > > A more important reason is that I suspect a method using > org-babel would be much better. > > I was looking for a semi-one-off method to convert a table > definition into something within my workflow at the time. Org > mode was somewhat new and seemed useful (now proven that it is > very useful). I was focused on *my* workflow, but the mindset > behind org-babel is more general. I apologize, but I have not > had the time to look into adapting the mechanism or pursuing the > generalization. I must have overlooked this, my apologies. Thanks! Bug queue one down :) - Carsten > -- > Jason signature.asc Description: Message signed with OpenPGP using GPGMail
[O] Spurious exporting of text before first header
Hi, Org people. This is an old annoyance of the Org exporter, yet I'm not sure what would be its best resolution. Whenever I use :export: tags on headers within an Org file, I expect only those headers and their contents to be exported (to HTML in my case), and almost nothing else, which I then consider private. However, if I have text and other contents prior to the first header of a file, those contents are indeed exported, while I would prefer not. Of course, #+TITLE and some other directives prior to the first header should be honored for their effect. One might surely debate on the best way to handle #+INCLUDE directive. I wish the above comments might generate either a correction in Org, or an advice for me! :-) François P.S. Some might suggest me that I avoid text prior to the first header. Surely, I have hundreds of Org files and for them all, have some personal conventions for their format and structure. For regularity reasons, I would much like to continue having private initial text.
Re: [O] using orgtbl-sqlinsert
Carsten Dominik writes: > Hi Eric, > > do you have orgtbl-to-sqlite defined? What does it look like? > Do you have the BEGIN RECEIVE and END RECEIVE lines in the buffer? > Are you working in a buffer that is not in Org-mode? Do you have orgtbl-mode > turned on? Hi Carsten, I later replied to that thread (at least, I think it should have been part of the same thread) with a patch to orgtbl-to-sqlite. Bastien applied it, and to my knowledge all is well. As Jason mentioned, this and I guess the other orgtbl-* functions seem sort of out of date at this point (should they all be replaced with Babel?), but the problem I brought up here, at least, is fixed. Thanks! Eric > On 26.5.2013, at 08:56, Eric Abrahamsen wrote: > >> I've got a table I'm trying to insert into a sqlite database. I've been >> looking at orgtbl-sqlinsert and this page[fn:1], but I suspect all that >> is out of date. I haven't seen anyone talking about #+ORGTBL: keywords, >> or things like "#+BEGIN RECEIVE ORGTBL exsql" in the past year or so. >> >> Do those still work? I can't for the life of me get it to do anything. >> I've got a sqlite database called "market.sqlite" in the same directory >> as a file containing this: >> >> #+TBLNAME: terms >> #+ORGTBL: SEND market.sqlite orgtbl-to-sqlinsert :sqlname "terms" >> | Chinese | English| >> |--+| >> | 音像制品出版 | A/V Publishing | >> | 定价总金额 | Aggregate Retail Price | >> (etc) >> >> I've tried C-c C-c on that header, calling >> `org-babel-execute-src-block', waving my fingers at it, and cursing >> loudly, one of which usually works. But I get no error, no insertion >> into the database, and no results block with INSERT statements (I tried >> making a #+BEGIN RECEIVE ORGTBL marketdb.sqlite block as noted on worg). >> >> Does this still work? Or is it still possible to jimmy orgtbl-sqlinsert >> to either insert directly, or create a block of INSERT statements? >> >> Thanks! >> >> Footnotes: >> >> [fn:1] http://orgmode.org/worg/org-tutorials/multitarget-tables.html >> >>
Re: [O] a lisp question
"tuma...@gmail.com" writes: > How can i convert (1 2 3 5 7 8 9 10 11 12 13) to > ((1 2 3 ) (5) (7) (8 9) (10 11 12 13))? > Two problems: Wrong list: try comp.lang.lisp instead. Incomplete problem description: see "How to ask questions the smart way" at http://www.catb.org/esr/faqs/smart-questions.html. -- Nick
Re: [O] Using org-goto loses org-todo-keyword-faces settings
Hi Dale, I tried it again today, and I do not see the problem you are
describing.
I am closing this bug report until others chime in with supporting information.
- carsten
On 2.9.2013, at 07:42, Carsten Dominik wrote:
> Hi Dale,
>
> thank you for the report and detailed example. I have followed your recipe
> and cannot reproduce the issue.
>
> Regards
>
> - Carsten
>
> On 21.8.2013, at 02:25, Dale wrote:
>
>> Hi,
>>
>> My thanks to everyone who works on org-mode. It is a truly
>> indispensable tool.
>>
>> I'm not sure if I have a bug or a feature request: I have custom faces
>> set up for my todo keywords (see my file local variable for
>> org-todo-keyword-faces at the bottom of this report). When I use org-goto
>> (C-c C-j) and then exit goto mode, my custom colors for todo keywords are
>> reset to the defaults.
>>
>> Explicitly:
>>
>> 1. Create and save an org file with the following contents:
>>
>> --8<--Cut here--8<--
>> * WAITING test1
>>
>> #+TODO: NEW(n) PENDING(p!) WAITING(w!) HOLD(h!) | DONE(d!) CANCELLED(c!)
>>
>> # Local Variables:
>> # org-todo-keyword-faces: (("WAITING" . "dark orange")
>> # ("HOLD" . "dark orange"))
>> # End:
>> --8<--Cut here--8<--
>>
>> 2. Revert the buffer to pick up the in-buffer configuration including file
>> local variables.
>>
>> 3. C-c C-j followed by C-g to exit goto mode.
>>
>> What I expected: WAITING would still be "dark orange" when I exit goto mode.
>>
>> What I observed: WAITING reverts to the default red color when I exit goto
>> mode.
>>
>> (WAITING is also red while I'm in org-goto mode, which is less of a problem
>> for me. I'd be happy enough if the color was just restored when I'm done
>> with org-goto.)
>>
>> I would, of course, be grateful if my org-todo-keyword-faces would
>> still be respected after using goto mode.
>>
>> I am using Emacs 24.3.1, apparently, the unofficial Emacs Mac Port
>> (ftp://ftp.math.s.chiba-u.ac.jp/emacs/). I just confirmed this behavior
>> using org-mode's master branch from git://orgmode.org/org-mode.git as of a
>> few minutes ago. The output from org-submit-bug-report is below.
>>
>> Thanks for everything,
>> Dale
>>
>>
>> Emacs : GNU Emacs 24.3.1 (x86_64-apple-darwin12.4.0, Carbon Version 1.6.0
>> AppKit 1187.39)
>> of 2013-06-26
>> Package: Org-mode version 8.0.7 (release_8.0.7-383-g927f1b @
>> /Users/dale/.emacs.d/packages/org-mode/)
>>
>> current state:
>> ==
>> (setq
>> org-hide-leading-stars t
>> org-tab-first-hook '(org-hide-block-toggle-maybe
>> org-src-native-tab-command-maybe
>> org-babel-hide-result-toggle-maybe
>> org-babel-header-arg-expand)
>> org-speed-command-hook '(org-speed-command-default-hook
>> org-babel-speed-command-hook)
>> org-reverse-note-order t
>> org-time-clocksum-format "%d:%02d"
>> org-occur-hook '(org-first-headline-recenter)
>> org-metaup-hook '(org-babel-load-in-session-maybe)
>> org-agenda-todo-ignore-deadlines 'far
>> org-src-window-setup 'other-window
>> org-confirm-shell-link-function 'yes-or-no-p
>> org-agenda-todo-ignore-scheduled 1
>> org-default-notes-file "~/todo.org"
>> org-startup-indented t
>> org-after-todo-state-change-hook '(org-clock-out-if-current)
>> org-src-mode-hook '(org-src-babel-configure-edit-buffer
>>org-src-mode-configure-edit-buffer)
>> org-tags-column -76
>> org-agenda-before-write-hook '(org-agenda-add-entry-text)
>> org-babel-pre-tangle-hook '(save-buffer)
>> org-agenda-dim-blocked-tasks nil
>> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
>> [org-add-hook change-major-mode-hook org-show-block-all
>> append local]
>> 5]
>>#[nil "\300\301\302\303\304$\207"
>> [org-add-hook change-major-mode-hook
>> org-babel-show-result-all append local]
>> 5]
>>org-babel-result-hide-spec org-babel-hide-all-hashes
>>my:org-mode-hook)
>> org-outline-path-complete-in-steps nil
>> org-agenda-todo-list-sublevels nil
>> org-replace-disputed-keys t
>> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
>> org-babel-execute-safely-maybe)
>> org-refile-use-outline-path t
>> org-enforce-todo-dependencies t
>> org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
>> org-cycle-hide-inline-tasks org-cycle-show-empty-lines
>> org-optimize-window-after-visibility-change)
>> org-after-refile-insert-hook '(my:org-maybe-note-refile)
>> org-metareturn-hook '(my:org-meta-return-hook)
>> org-confirm-elisp-link-function 'yes-or-no-p
>> org-metadown-hook '(org-babel-pop-to-session-maybe)
>> org-default-priority 68
>> org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
>> org-completion-use-ido t
>> org-src-prese
Re: [O] using orgtbl-sqlinsert
Hi Eric, do you have orgtbl-to-sqlite defined? What does it look like? Do you have the BEGIN RECEIVE and END RECEIVE lines in the buffer? Are you working in a buffer that is not in Org-mode? Do you have orgtbl-mode turned on? Regards - Carsten On 26.5.2013, at 08:56, Eric Abrahamsen wrote: > I've got a table I'm trying to insert into a sqlite database. I've been > looking at orgtbl-sqlinsert and this page[fn:1], but I suspect all that > is out of date. I haven't seen anyone talking about #+ORGTBL: keywords, > or things like "#+BEGIN RECEIVE ORGTBL exsql" in the past year or so. > > Do those still work? I can't for the life of me get it to do anything. > I've got a sqlite database called "market.sqlite" in the same directory > as a file containing this: > > #+TBLNAME: terms > #+ORGTBL: SEND market.sqlite orgtbl-to-sqlinsert :sqlname "terms" > | Chinese | English| > |--+| > | 音像制品出版 | A/V Publishing | > | 定价总金额 | Aggregate Retail Price | > (etc) > > I've tried C-c C-c on that header, calling > `org-babel-execute-src-block', waving my fingers at it, and cursing > loudly, one of which usually works. But I get no error, no insertion > into the database, and no results block with INSERT statements (I tried > making a #+BEGIN RECEIVE ORGTBL marketdb.sqlite block as noted on worg). > > Does this still work? Or is it still possible to jimmy orgtbl-sqlinsert > to either insert directly, or create a block of INSERT statements? > > Thanks! > > Footnotes: > > [fn:1] http://orgmode.org/worg/org-tutorials/multitarget-tables.html > > signature.asc Description: Message signed with OpenPGP using GPGMail
[O] org-caldav for Google or Zimbra?
Does anyone have org-caldav working with the new Google endpoint or Zimbra? The former errors out (there's an issue on github, but I don't want a github account to ask there), and the latter uses a different URL scheme... Zimbra's URL scheme is https://server.example.com/dav/username/calendarname with a calendarname is Calendar. Special-casing org-caldav-events-url for my server appears to work. Feels like that function could be over-ridden per server / target org file, but I'm not quite sure what the right granularity should be. Hm. Perhaps having each synced calendar in a separate org file might work. Each org file could set some file-wide parameters like calendar URL. -- Jason, who no longer has relevant papers on file...
Re: [O] org mode R remote code evaluation
Alexander Vorobiev writes: > Hi Michael, Hi Alex, > Here it is. Thanks. I believe, the following patch shall cure it: --8<---cut here---start->8--- --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2735,8 +2735,12 @@ value of `temporary-file-directory' temporarily set to the value of `org-babel-temporary-directory'." (if (file-remote-p default-directory) (let ((prefix +;; We cannot use `temporary-file-directory' as local part +;; on the remote host, because it might be another OS +;; there. So we assume "/tmp", which ought to exist on +;; relevant architectures. (concat (file-remote-p default-directory) - (expand-file-name prefix temporary-file-directory + (expand-file-name prefix "/tmp/" (make-temp-file prefix nil suffix)) (let ((temporary-file-directory (or (and (boundp 'org-babel-temporary-directory) --8<---cut here---end--->8--- Could you, please, test? > Thanks, > Alex Best regards, Michael.
[O] Using org-lookup-all to count values in a table column
I'm taking a stab at keeping my reading diary in Org. I keep track of all the books I read, and some other facts about them, including whether they're fiction (F) or nonfiction (N). So I would have a table something like the books table below, and I'd like to do some analysis on it and put the results in another table. I'd like to count how many books are of Type F and how many of Type N, and it looks like matching values with org-lookup-all (as explained in [1]) is the right way, but I can't get it to work. I have this: #+TBLNAME: books | Title| Author | Type | |--++--| | NOS4A2 | Joe Hill | F| | Gun Machine | Warren Ellis | F| | Carry On, Jeeves | P.G. Wodehouse | F| | Time Reborn | Lee Smolin | N| #+TBLNAME: analysis | Fact | Value | |---+---| | Fiction books | 1 | | Nonfiction books | | #+TBLFM: $2@2='(length(org-lookup-all "F" '(remote(books,$3@2..$3@>)) nil)) The fiction count should be 3, not 1. Can anyone see what I'm doing wrong? Thanks, Bill [1] http://orgmode.org/worg/org-tutorials/org-lookups.html -- William Denton Toronto, Canada http://www.miskatonic.org/
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hi Carsten, Carsten Dominik wrote: > On 24.9.2013, at 18:17, Sebastien Vauban wrote: >> Carsten Dominik wrote: >>> On 23.9.2013, at 09:40, Rainer M Krug wrote: When starting to edit a code block via C-c ' everything works as expected and the code block is highlighted and an indirect buffer is opened. When I click into the highlighted block, I an "send" to the indirect buffer. This behavior changes, after saving with C-s, even when nothing has been edited: the area in the original org file looses its magic, and looks normal again and can also be edited! The indirect buffer stays functional and, upon close via C-c ' saves the changes into the original buffer and *overwrites* changes done in this block in the org document. >>> >>> This is a bug which is difficult to fix in all generality. What should >>> really >>> happen is that the text in the original buffer is made read-only. But so far >>> this does not happen in our implementation (due to Dan Davison IIRC). The >>> reason for this is that read-only text properties left by accident in a >>> buffer are difficult to get rid of. >>> >>> There are many things the user could go back and screw up the original. >>> That's why Org choses to protect with highlighting with an overlay. Note >>> that >>> this is not a protection against editing, but it is a visual warning. >> >> I never knew that "your" goal was to make the code block read-only in the Org >> buffer. Note that I would be really opposed to such a change. Editing code in >> the prose would really become a pain to me -- please know that I NEVER use >> the >> indirect buffer. > > I only mean while there is a special buffer also editing this block! Pfff! I'm relieved -- I should have understood it ;-) Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
On 24.9.2013, at 18:17, Sebastien Vauban wrote: > Hello Carsten, > > Carsten Dominik wrote: >> On 23.9.2013, at 09:40, Rainer M Krug wrote: >>> >>> When starting to edit a code block via C-c ' everything works as expected >>> and the code block is highlighted and an indirect buffer is opened. >>> >>> When I click into the highlighted block, I an "send" to the indirect buffer. >>> This behavior changes, after saving with C-s, even when nothing has been >>> edited: the area in the original org file looses its magic, and looks normal >>> again and can also be edited! >>> >>> The indirect buffer stays functional and, upon close via C-c ' saves the >>> changes into the original buffer and *overwrites* changes done in this block >>> in the org document. >> >> This is a bug which is difficult to fix in all generality. What should really >> happen is that the text in the original buffer is made read-only. But so far >> this does not happen in our implementation (due to Dan Davison IIRC). The >> reason for this is that read-only text properties left by accident in a >> buffer are difficult to get rid of. >> >> There are many things the user could go back and screw up the original. >> That's why Org choses to protect with highlighting with an overlay. Note that >> this is not a protection against editing, but it is a visual warning. > > I never knew that "your" goal was to make the code block read-only in the Org > buffer. Note that I would be really opposed to such a change. Editing code in > the prose would really become a pain to me -- please know that I NEVER use the > indirect buffer. Hi Sebastian, I only mean while there is a special buffer also editing this block! - Carsten > > I hope that we will block such a functionality, would the read-only feature > become possible. > >> However, what happens during saving is indeed a problem - the overlay gets >> lost (not really, it gets squeezed to zero by first removing the source code >> and then inserting the modified version). >> >> Could you please try this patch and test it to see if it is stable and does >> the right thing? > > Best regards, > Seb > > -- > Sebastien Vauban > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Question: How to suppress the generation of toc in html export?
Daniel Thom writes: > i am trying to transform my html output via jekyll to my website. > jekyll needs the first lines for its config. > > i use html export config from worg > (http://orgmode.org/worg/org-tutorials/org-jekyll.html) > > but this line seems to be ignored > :body-only t ;; Only export section between > > i am not able to produce a html output without a table of content. > > I use orgmode in Version: 8.1.2 maybe just put a ,- | #+OPTIONS toc:nil `- before the first headline of your org file? -- cheers, Thorsten
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hello Carsten, Carsten Dominik wrote: > On 23.9.2013, at 09:40, Rainer M Krug wrote: >> >> When starting to edit a code block via C-c ' everything works as expected >> and the code block is highlighted and an indirect buffer is opened. >> >> When I click into the highlighted block, I an "send" to the indirect buffer. >> This behavior changes, after saving with C-s, even when nothing has been >> edited: the area in the original org file looses its magic, and looks normal >> again and can also be edited! >> >> The indirect buffer stays functional and, upon close via C-c ' saves the >> changes into the original buffer and *overwrites* changes done in this block >> in the org document. > > This is a bug which is difficult to fix in all generality. What should really > happen is that the text in the original buffer is made read-only. But so far > this does not happen in our implementation (due to Dan Davison IIRC). The > reason for this is that read-only text properties left by accident in a > buffer are difficult to get rid of. > > There are many things the user could go back and screw up the original. > That's why Org choses to protect with highlighting with an overlay. Note that > this is not a protection against editing, but it is a visual warning. I never knew that "your" goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I hope that we will block such a functionality, would the read-only feature become possible. > However, what happens during saving is indeed a problem - the overlay gets > lost (not really, it gets squeezed to zero by first removing the source code > and then inserting the modified version). > > Could you please try this patch and test it to see if it is stable and does > the right thing? Best regards, Seb -- Sebastien Vauban
[O] Question: How to suppress the generation of toc in html export?
Hi, i am trying to transform my html output via jekyll to my website. jekyll needs the first lines for its config. i use html export config from worg (http://orgmode.org/worg/org-tutorials/org-jekyll.html) but this line seems to be ignored :body-only t ;; Only export section between i am not able to produce a html output without a table of content. I use orgmode in Version: 8.1.2 -- Gru� Daniel http://netbunker.de
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hi Rainer, hi Carsten, it does not get lost - it is in my queue. As are, unfortunately, another 35 threads with possible bugs. Help is definitely wanted. Please see below for my comments and a possible fix. On 23.9.2013, at 09:40, Rainer M Krug wrote: > I just resend this bug report which has been confirmed by Ista Zahn. > > Updated via git ust now: > > Org-mode version 8.2 (release_8.2-14-ge5f16b @ > /Users/rainerkrug/.emacs.d/org-mode/lisp/) > > > When starting to edit a code block via C-c ' everything works as expected > and the code block is highlighted and an indirect buffer is opened. > > When I click into the highlighted block, I an "send" to the indirect > buffer. This behavior changes, after saving with C-s, even when nothing > has been edited: the area in the original org file looses its magic, and > looks normal again and can also be edited! > > The indirect buffer stays functional and, upon close via C-c ' saves the > changes into the original buffer and *overwrites* changes done in this > block in the org document. This is a bug which is difficult to fix in all generality. What should really happen is that the text in the original buffer is made read-only. But so far this does not happen in our implementation (due to Dan Davison IIRC). The reason for this is that read-only text properties left by accident in a buffer are difficult to get rid of. There are many things the user could go back and screw up the original. That's why Org choses to protect with highlighting with an overlay. Note that this is not a protection against editing, but it is a visual warning. However, what happens during saving is indeed a problem - the overlay gets lost (not really, it gets squeezed to zero by first removing the source code and then inserting the modified version). Could you please try this patch and test it to see if it is stable and does the right thing? Thank you. - Carsten diff --git a/lisp/org-src.el b/lisp/org-src.el index 0f88174..062d2d7 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -757,6 +757,8 @@ with \",*\", \",#+\", \",,*\" and \",,#+\"." (delete-region beg (max beg end)) (unless (string-match "\\`[ \t]*\\'" code) (insert code)) + ;; Make sure the overlay stays in place + (when (eq context 'save) (move-overlay ovl beg (point))) (goto-char beg) (if single (just-one-space (if (memq t (mapcar (lambda (overlay) signature.asc Description: Message signed with OpenPGP using GPGMail
[O] build errors on os x
For the last few days, building org with make up2 results in the following failed tests with Emacs for Mac OS X 24.3.1: Ran 456 tests, 448 results as expected, 8 unexpected (2013-09-24 10:59:21-0400) 5 expected failures 8 unexpected results: FAILED test-ob/org-babel-remove-result--results-code FAILED test-ob/org-babel-remove-result--results-default FAILED test-ob/org-babel-remove-result--results-html FAILED test-ob/org-babel-remove-result--results-latex FAILED test-ob/org-babel-remove-result--results-list FAILED test-ob/org-babel-remove-result--results-org FAILED test-ob/org-babel-remove-result--results-pp FAILED test-ob/org-babel-remove-result--results-wrap
Re: [O] Wanted: Caretaker of the ODT backend
Carsten Dominik writes: > Hi Christian, > > On 24.9.2013, at 15:18, Christian Moe wrote: > >> >> Hi, >> >> I don't have the developer skillz. >> >> Otherwise I'd be happy to help out any way I can, e.g. tracking issues >> and requests, digging into ODT format, replicating bugs and testing >> patches on a more systematic basis. > > Thanks, this would be great. > >> >> (The latter two assuming I can root out the setup/installation weirdness >> that seems to affect my local ODT export.) >> >> I see Jambunathan has placed his patches in the public domain under a >> GPL-compatible CC0 license. Other considerations aside, doesn't that >> mean they could be applied in Org? > > Putting them under CC0 means that we could use them, and that Emacs > could in principle use them as well. However, Emacs has made the *choice* > to only include stuff for which they have the copyright assignment to > the FSF. (Stefan does reiterate this in the thread following Jambunathans > message). Since Org is distributed as part of Emacs, this also applies > to us. > > I have looked at the patches. > > 1. Implement an alternative format for description lists. Description >lists are, I think, already "supported" by the odt exporter, even >though odt does not seem to support them natively. > 2. As far as I can see, this mainly implements a simpler way to access >attributes internally. It does not fix any bug I would know about. > 3. Introduces some kind of new way to force page breaks. I don't >see why we need it. > 4. adds jabref support. Sounds interesting, but I don't know if anyone >here uses it or would like to use it. I use this feature now. In my opinion, this is very cool. I use org-mode to write paper draft and export the draft to odf file instead of pdf file, the reason is that I can't develop a suitable latex style for our university... so ox-jabref.el + ox-odt.el become a easy approach. > > So I don't think any of this is required at this moment. But it would > be great if you could keep en eye out for mailing list requests and > bug reports around this exporter and try to get things fixed when necessary. > > Thanks! > > - Carsten > > >> >> Yours, >> Christian >> >> >> Carsten Dominik writes: >> >>> Hi eager Org mode contributors >>> >>> One more try - it would be really nice to find a volunteer for this task. >>> I can do this myself - but it would take time away from other tasks. >>> >>> - Carsten >>> >>> On 18.9.2013, at 06:38, Carsten Dominik wrote: >>> Hi, I am looking for someone who knows about the internals of the ODT file format, and who would have time to become the responsible person for ox-odt.el. Since we cannot take patches from the original author (Jambunathan) anymore, this module is currently orphaned. There are a few recent patches Jambunathan has made and published here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15384>>> We cannot take them (due to FSF rules and for other reasons as well) - but the new maintainer can take a look at them and see if there is functionality or bug fixes we need and re-implment those. For the rest I would hope that you can watch the mailing list and Emacs bug reports for issues related to this backend and try to fix them, obviously with support from the mailing list. Also,maybe there are ideas for additional functionality? Please write to me if you are interested. Thank you. - Carsten >> --
[O] A elisp quesion
Hello everyone: How can I convert list '(1 2 3 5 6 8 9 13 48) to '((1 2 3) (5 6) (8 9)(13) (48)) ? Thanks --
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hi before this gets lost - I think this is an serious bug, as it can easily lead to data loss. Thanks, Rainer Rainer M Krug writes: > I just resend this bug report which has been confirmed by Ista Zahn. > > Updated via git ust now: > > Org-mode version 8.2 (release_8.2-14-ge5f16b @ > /Users/rainerkrug/.emacs.d/org-mode/lisp/) > > > When starting to edit a code block via C-c ' everything works as expected > and the code block is highlighted and an indirect buffer is opened. > > When I click into the highlighted block, I an "send" to the indirect > buffer. This behavior changes, after saving with C-s, even when nothing > has been edited: the area in the original org file looses its magic, and > looks normal again and can also be edited! > > The indirect buffer stays functional and, upon close via C-c ' saves the > changes into the original buffer and *overwrites* changes done in this > block in the org document. > > Rainer -- Rainer M. Krug email: RMKruggmailcom pgpra9bI3_smn.pgp Description: PGP signature
Re: [O] Wanted: Caretaker of the ODT backend
Hi Christian, On 24.9.2013, at 15:18, Christian Moe wrote: > > Hi, > > I don't have the developer skillz. > > Otherwise I'd be happy to help out any way I can, e.g. tracking issues > and requests, digging into ODT format, replicating bugs and testing > patches on a more systematic basis. Thanks, this would be great. > > (The latter two assuming I can root out the setup/installation weirdness > that seems to affect my local ODT export.) > > I see Jambunathan has placed his patches in the public domain under a > GPL-compatible CC0 license. Other considerations aside, doesn't that > mean they could be applied in Org? Putting them under CC0 means that we could use them, and that Emacs could in principle use them as well. However, Emacs has made the *choice* to only include stuff for which they have the copyright assignment to the FSF. (Stefan does reiterate this in the thread following Jambunathans message). Since Org is distributed as part of Emacs, this also applies to us. I have looked at the patches. 1. Implement an alternative format for description lists. Description lists are, I think, already "supported" by the odt exporter, even though odt does not seem to support them natively. 2. As far as I can see, this mainly implements a simpler way to access attributes internally. It does not fix any bug I would know about. 3. Introduces some kind of new way to force page breaks. I don't see why we need it. 4. adds jabref support. Sounds interesting, but I don't know if anyone here uses it or would like to use it. So I don't think any of this is required at this moment. But it would be great if you could keep en eye out for mailing list requests and bug reports around this exporter and try to get things fixed when necessary. Thanks! - Carsten > > Yours, > Christian > > > Carsten Dominik writes: > >> Hi eager Org mode contributors >> >> One more try - it would be really nice to find a volunteer for this task. >> I can do this myself - but it would take time away from other tasks. >> >> - Carsten >> >> On 18.9.2013, at 06:38, Carsten Dominik wrote: >> >>> Hi, >>> >>> I am looking for someone who knows about the internals of the ODT file >>> format, and who would have time to become the responsible person for >>> ox-odt.el. Since we cannot take patches from the original author >>> (Jambunathan) anymore, this module is currently orphaned. >>> >>> There are a few recent patches Jambunathan has made and published here: >>> >>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15384 >>> >>> We cannot take them (due to FSF rules and for other reasons as well) - but >>> the new maintainer can take a look at them and see if there is >>> functionality or bug fixes we need and re-implment those. For the rest I >>> would hope that you can watch the mailing list and Emacs bug reports for >>> issues related to this backend and try to fix them, obviously with support >>> from the mailing list. Also,maybe there are ideas for additional >>> functionality? >>> >>> Please write to me if you are interested. >>> >>> Thank you. >>> >>> - Carsten > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] org mode R remote code evaluation
Alexander Vorobiev writes: > Here is what I have: > > ELISP> emacs-version > "24.3.1" > ELISP> tramp-version > "2.2.7" > ELISP> org-version > "8.2" Well, that sounds recent. Could you, please, perform (setq tramp-verbose 6) prior your test? There will be a Tramp debug buffer, which I would like to analyze. > Thanks, > Alex Best regards, Michael.
Re: [O] org mode R remote code evaluation
Here is what I have: ELISP> emacs-version "24.3.1" ELISP> tramp-version "2.2.7" ELISP> org-version "8.2" Thanks, Alex On Tue, Sep 24, 2013 at 7:57 AM, Michael Albinus wrote: > Alexander Vorobiev writes: > > > The ":results output" doesn't help in my setup (I'm on Windows, the > > remote system is linux, access is via putty/plink) > > I do not run Windows, so I cannot reproduce exactly. However, ... > > > #+BEGIN_SRC sh :results output :dir /grid: > > ls > > #+END_SRC > > > > executing Sh code block... > > Tramp: Encoding region using function `base64-encode-region'...done > > Tramp: Decoding region into remote file > > /plinkx:grid:/Users/avorobi/AppData/Local/Temp/ob-input-6116fuY...done > > byte-code: Couldn't write region to > > `/plinkx:grid:/Users/avorobi/AppData/Local/Temp/ob-input-6116fuY', > > decode using `tramp_perl_decode_with_module >%s' failed > > > > The /Users directory obviously does not exist on linux. > > ... this looks like an old problem. Which Emacs/Tramp version are you > using? > Check variables `emacs-version' and `tramp-version'. > > > Thanks, > > Alex > > Best regards, Michael. >
Re: [O] Wanted: Caretaker of the ODT backend
Hi, I don't have the developer skillz. Otherwise I'd be happy to help out any way I can, e.g. tracking issues and requests, digging into ODT format, replicating bugs and testing patches on a more systematic basis. (The latter two assuming I can root out the setup/installation weirdness that seems to affect my local ODT export.) I see Jambunathan has placed his patches in the public domain under a GPL-compatible CC0 license. Other considerations aside, doesn't that mean they could be applied in Org? Yours, Christian Carsten Dominik writes: > Hi eager Org mode contributors > > One more try - it would be really nice to find a volunteer for this task. > I can do this myself - but it would take time away from other tasks. > > - Carsten > > On 18.9.2013, at 06:38, Carsten Dominik wrote: > >> Hi, >> >> I am looking for someone who knows about the internals of the ODT file >> format, and who would have time to become the responsible person for >> ox-odt.el. Since we cannot take patches from the original author >> (Jambunathan) anymore, this module is currently orphaned. >> >> There are a few recent patches Jambunathan has made and published here: >> >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15384 >> >> We cannot take them (due to FSF rules and for other reasons as well) - but >> the new maintainer can take a look at them and see if there is functionality >> or bug fixes we need and re-implment those. For the rest I would hope that >> you can watch the mailing list and Emacs bug reports for issues related to >> this backend and try to fix them, obviously with support from the mailing >> list. Also,maybe there are ideas for additional functionality? >> >> Please write to me if you are interested. >> >> Thank you. >> >> - Carsten
Re: [O] org-publish: docview all pdf files
Hi Vikas, maybe you could make me a minimal setup so that I can reproduce this? Just a little folder with two files and a minimal .emacs that defines publishing of these files to some other directory. That would be useful. - Carsten On 7.6.2013, at 18:15, Vikas Rawal wrote: > When I publish the project, orgmode attempts to open all pdf files > (which are static content). It seems to me that some sort of indexing > is being attempted though I am not sure. I think it started happening > after I included creation of a sitemap. > > I get messages like this: > > DocView: process pdf/ps->png changed status to killed. > > This slows down publishing considerably. I have just added some large > pdf files, and now it asks me for each such file whether I want to > open it. org-publish gets stuck if I say yes, and aborts publishing if > I say no. > > Is there a way, I could tell orgmode to not try to process these pdf > files. pdf files are being processed through a sub-project that deals > with static content (org-publish-attachment). > > Would be grateful for any advice. > > Best, > > Vikas > > > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [PATCH] [org-table] user-chosen separator in org-table-convert-region
Hi Francois,
could you please explain what this does and show an example on how this should
be used?
Thank you.
- Carsten
On 3.9.2013, at 12:20, franc...@avalenn.eu wrote:
> Hello,
>
> I made this patch to make easier conversion to
> org-table from csv-like text with arbitrary separator.
>
> ---
> lisp/org-table.el |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/lisp/org-table.el b/lisp/org-table.el
> index c7e7eb8..c8c2462 100644
> --- a/lisp/org-table.el
> +++ b/lisp/org-table.el
> @@ -575,6 +575,8 @@ nil When nil, the command tries to be smart and
> figure out the
>(if (< separator 1)
>(user-error "Number of spaces in separator must be >= 1")
> (format "^ *\\| *\t *\\| \\{%d,\\}" separator)))
> + ((stringp separator)
> +(format "^ *\\|%s" separator))
> (t (error "This should not happen"
> (while (re-search-forward re end t)
> (replace-match "| " t t)))
> --
> 1.7.9
>
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [O] org mode R remote code evaluation
Alexander Vorobiev writes: > The ":results output" doesn't help in my setup (I'm on Windows, the > remote system is linux, access is via putty/plink) I do not run Windows, so I cannot reproduce exactly. However, ... > #+BEGIN_SRC sh :results output :dir /grid: > ls > #+END_SRC > > executing Sh code block... > Tramp: Encoding region using function `base64-encode-region'...done > Tramp: Decoding region into remote file > /plinkx:grid:/Users/avorobi/AppData/Local/Temp/ob-input-6116fuY...done > byte-code: Couldn't write region to > `/plinkx:grid:/Users/avorobi/AppData/Local/Temp/ob-input-6116fuY', > decode using `tramp_perl_decode_with_module >%s' failed > > The /Users directory obviously does not exist on linux. ... this looks like an old problem. Which Emacs/Tramp version are you using? Check variables `emacs-version' and `tramp-version'. > Thanks, > Alex Best regards, Michael.
Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data
Hi Eric, > Currently the :missing header argument for gnuplot code blocks does two > things. It adds the "set datafile missing..." line to the code block > body *and* it binds `*org-babel-gnuplot-missing*' to the value of the > :missing header argument when the datafile is written, so empty table > cells are replaced with the value of the :missing header argument. Thanks for the explanation. > The reason you're not getting a blank line is because it is replaced > with three "missing" values, in this case "? ? ?". > > Do you think this behavior should be changed or split between two header > arguments? I think the :missing header should not replace empty fields in an org table by the missing character as blank lines have a special meaning in gnuplot. To fully use the versatility of gnuplot one needs blank lines and missing values. The "set datafile missing" command sets a specific character string to be treated as a missing value. The character string can even be a number, eg. set datafile missing "-1". It says under gnuplot's "help missing" that: "There is no default character for `missing`, but in many cases any non-parsible string of characters found where a numerical value is expected will be treated as missing data." My view is that for the purposes of exporting org tables for plotting with gnuplot all blank entries in the org table (fields and whole lines) should be exported as blanks, and all characters (letters or numerical digits etc.) should be exported exactly as they appear in the table (without any additional surrounding quotes being added). Maybe I'm missing the point of the :missing header, but I find it easier and clearer to include the datafile missing command in the gnuplot code block. I don't really see a need for the :missing header. Maybe the need stems from wanting to be able to use different plotting packages to plot the same org table data, but it's not clear to me. Kind regards, Paul
[O] a lisp question
How can i convert (1 2 3 5 7 8 9 10 11 12 13) to ((1 2 3 ) (5) (7) (8 9) (10 11 12 13))?
Re: [O] Wanted: Caretaker of the ODT backend
Hi eager Org mode contributors One more try - it would be really nice to find a volunteer for this task. I can do this myself - but it would take time away from other tasks. - Carsten On 18.9.2013, at 06:38, Carsten Dominik wrote: > Hi, > > I am looking for someone who knows about the internals of the ODT file > format, and who would have time to become the responsible person for > ox-odt.el. Since we cannot take patches from the original author > (Jambunathan) anymore, this module is currently orphaned. > > There are a few recent patches Jambunathan has made and published here: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15384 > > We cannot take them (due to FSF rules and for other reasons as well) - but > the new maintainer can take a look at them and see if there is functionality > or bug fixes we need and re-implment those. For the rest I would hope that > you can watch the mailing list and Emacs bug reports for issues related to > this backend and try to fix them, obviously with support from the mailing > list. Also,maybe there are ideas for additional functionality? > > Please write to me if you are interested. > > Thank you. > > - Carsten signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [Babel] Lisp error: (wrong-type-argument listp hline)
Hi Eric,
Eric Schulte wrote:
> I think you're confused by headers which are re-added by the colnames
> machinery.
Blush! I mixed the two in my head, yes.
> See the following which returns scalar output avoiding any colnames
> post-processing.
Why are you talking of *post* processing machinery for colnames?
The documentation[1] says that ":colnames no" means "no column name *pre*
processing takes place."
I may miss something important here.
> #+Property: results scalar
>
> #+name: table
> | Key | Value |
> |-+---|
> | ABJ | 1 |
> | DEK | 2 |
>
> #+begin_src emacs-lisp :var data=table :hlines no
> data
> #+end_src
>
> #+RESULTS:
> : (("Key" "Value") ("ABJ" 1) ("DEK" 2))
>
> #+begin_src emacs-lisp :var data=table :hlines yes
> data
> #+end_src
>
> #+RESULTS:
> : (("Key" "Value") hline ("ABJ" 1) ("DEK" 2))
>
>> * Set :hlines to "yes"
>>
>> `:hlines yes' should leave the horizontal line, but generates an error.
>>
>> #+begin_src emacs-lisp :var data=table :results output :hlines yes
>> (mapc (lambda (item) (princ (format "UPDATE dim SET val=%s WHERE
>> code='%s'\n"
>> (nth 1 item) (nth 0 item
>>data)
>> #+end_src
>
> This is not a babel error, this is an error in your code block body,
> which assumes that every element of `data' will be a list. The symbol
> `hline' is not a list.
OK, that now becomes clear to me!
>> Finally, how am I then supposed to *ignore the header line*? By adding
>>
>> #+begin_src emacs-lisp
>> (setq table (cdr table))
>> #+end_src
>>
>> ?
>>
>> Do I have to do that explicitly in my code block, or is there an option for
>> telling that to Babel?
>
> Use the :colnames processing to strip the headings.
>
> #+begin_src emacs-lisp :var data=table :colnames yes
> data
> #+end_src
>
> #+RESULTS:
> : (("ABJ" 1) ("DEK" 2))
I always wondered why emacs-lisp is the _only_ language with ":colnames no" as
its default. Is there a reason therefore? If no really good reason, could we
suppress that?
Best regards,
Seb
--
Sebastien Vauban
[1] http://orgmode.org/org.html#colnames
