Re: [O] Error exporting org file in ics format
Nicolas Goaziou m...@nicolasgoaziou.fr writes: [...] In the Message buffer I see this message: org-ascii--table-cell-width: Args out of range: [nil], 1 The other files are exported normally and the only difference I can see is in fact the file with error has appointments lasting over the midnight (because I work at night). I don't think this is related. If somebody tells me how to enable debug I could give more details. Could you provide an ECM, What is an ECM? or even the full file if it doesn't contain sensitive information? I could send you privately, not in list: nothing really sensitive, job appointments but not to be indexed in the internet for the ethernity! Another thing I discovered today looking into my org directory is: the archive file related to this giving error is really big, 12 Mega, because it contains some parts encrypted using a very gpg key. -- leandro http://6xukrlqedfabdjrb.onion signature.asc Description: PGP signature
Re: [O] Error exporting org file in ics format
Hello, Leandro Noferini lnofe...@cybervalley.org writes: I found an error trying to export an org file to ics format also via the standard command Ctrl-C-Ctrl-E and via org-caldav sync process. In the Message buffer I see this message: org-ascii--table-cell-width: Args out of range: [nil], 1 The other files are exported normally and the only difference I can see is in fact the file with error has appointments lasting over the midnight (because I work at night). I don't think this is related. If somebody tells me how to enable debug I could give more details. Could you provide an ECM, or even the full file if it doesn't contain sensitive information? Thank you. Regards, -- Nicolas Goaziou
[O] [BUG] shell not working as sh?
Hello, I remember that sh was renamed to shell some time ago. But shell sometimes does not work, while sh does. Is there a difference between the two (and when i should use one over another?) or is it a bug? The minimal example follows: #+PROPERTY: header-args:shell :dir /vagrant@127.0.0.1:/vagrant #+PROPERTY: header-args:shell+ :exports both :results output verbatim replace #+PROPERTY: header-args:sh :dir /vagrant@127.0.0.1:/vagrant #+PROPERTY: header-args:sh+ :exports both :results output verbatim replace * setup #+BEGIN_SRC sh cat $HOME/.ssh/id_rsa.pub $HOME/.ssh/authorized_keys # TODO accept the host key automatically or use StrictHostKeyChecking no # not sure if tramp is smart enough to handle this by default #+END_SRC #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (python . t) (shell . t) (sh . t))) #+END_SRC #+RESULTS: #+RESULTS: * sh works #+BEGIN_SRC sh ls | wc -l #+END_SRC #+RESULTS: : 5 * shell does not work #+BEGIN_SRC shell ls | wc -l #+END_SRC Will show in *Messages* org-babel-execute:shell: Wrong number of arguments: #[(session body optional params stdin) [... binary code cut ...] * org version #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC #+RESULTS: : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
[O] Error exporting org file in ics format
Ciao a tutti, I found an error trying to export an org file to ics format also via the standard command Ctrl-C-Ctrl-E and via org-caldav sync process. In the Message buffer I see this message: org-ascii--table-cell-width: Args out of range: [nil], 1 The other files are exported normally and the only difference I can see is in fact the file with error has appointments lasting over the midnight (because I work at night). If somebody tells me how to enable debug I could give more details. -- leandro http://6xukrlqedfabdjrb.onion signature.asc Description: PGP signature
[O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
Hello, my attempt to use org-mode for both interactive presentation and final report was unsuccessful due to a series of bugs and nuisances. Fortunately I can use the result of tangle. Will report the issues encountered to the list in the next few days. Here is a minor one. The following code, taken from [[info:org#Languages]] works if run after manually selecting it and running with M-x eval-region. But with M-x org-babel-execute-src-block it triggers an error. The *Messages* buffer shows: #+BEGIN_EXAMPLE executing Emacs-Lisp code block... orgtbl-to-orgtbl: Wrong type argument: listp, t #+END_EXAMPLE #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (R . t))) #+END_SRC #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC #+RESULTS: : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
Re: [O] duplicate PROPERTIES drawers
On 2015-02-23 at 03:35, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Ken Mankoff mank...@gmail.com writes: I have found many task with duplicate PROPERTIES drawers. I saw mention on the list that, ...it will be invalid for a LOGBOOK to appear before PROPERTIES in Org 8.3. It seems that tasks don't have properties by default, and if I LOG an item, I get a LOGBOOK drawer. If properties are added later (by touching the item with MobileOrg, or adding a property with C-c C-x p, then PROPERTIES go below the LOGBOOK. This shouldn't happen in master branch. Hmm. It is happening on the latest melpa install. Or maybe on an earlier version and I'm only seeing it now. I run melpa, no git versions. There is a function in ORG-NEWS that will repair old documents, but it will _not_ merge duplicate properties drawers. Thanks for the hint. I've found that and run it, but get an error because org-planning-line-re 'symbols variable is void'. Searching that I see mention that error is indicative of a mixed installation. But when I grep (or ack) for org-planning-line-re in the elpa/org-20150216 folder, it doesn't exist. If I rewrite that line to org-planning-or-clock-line-re, then it works, and I see items get repaired. I can run this on all my Org files, but as you point out, it won't help with tasks that are already messed up with two property drawers. I also don't think I have a mixed install because I cons elpa to the load-path before I access any Org functions. I've tried to run the code you sent: (org-element-map (org-element-parse-buffer 'element) 'headline (lambda (h) (and (org-element-map h 'drawer (lambda (d) (equal (org-element-property :name d) PROPERTIES)) nil t 'headline) (let ((begin (org-element-property :begin h))) (message Entry with erroneous properties drawer at %d begin) begin But nothing happens. It seems to be an incomplete solution. I tried wrapping it in an interactive function call, but I'm a lisp newbie and it doesn't list the entries with duplicate properties for me, on this system. -k.
Re: [O] control tangling from section header
Daniele Pizzolli d...@toel.it writes: Hello Ken, Ken Mankoff writes: I'm working with my literate init file (emacs.org), and would like to have certain sections not tangle. I currently do this with :tangle no at the SRC block level. Is it possible to control tangling with tags at the header level? Not with tag but with PROPERTIES: * outline header :PROPERTIES: :header-args: :tangle no :END: More at http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html It would make it much easier to disable/enable sections, and see what sections are enabled/disabled, if the tangling state were more clearly visible like tags are. I do not think that this is currently possible. If I am not mistaken, you can mark the header as COMMENT and no code blocks under this header are tangled. Cheers, Rainer Best, Daniele -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
John Kitchin writes: I am pretty sure this is a long-standing feature. Try this: #+BEGIN_SRC emacs-lisp :results raw (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (R . t))) #+END_SRC I have never been able to use a babel block that outputs a list of cons cells without explicitly setting results to raw or code. The problem here is your code evaluates to ((emacs-lisp) (R . t)), and the t somehow gets interpreted like it should be a list, which it is not. So, it cannot be made into a table for output, and you get your error. Changing the header just bypasses this function and outputs the results more directly. Hello John, thanks for the explanation. Unfortunately my lisp knowledge is too limited to understand you. As a naive org-mode user, if possible I do not want to be exposed to org internals error, especially the confusing ones, where the custom code works fine. Maybe we can get a warning instead of an error? It is not a really big issue, a newcomer can be confused, if not scared, having an error on the fist babel usage. Best, Daniele
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
I am pretty sure this is a long-standing feature. Try this: #+BEGIN_SRC emacs-lisp :results raw (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (R . t))) #+END_SRC I have never been able to use a babel block that outputs a list of cons cells without explicitly setting results to raw or code. The problem here is your code evaluates to ((emacs-lisp) (R . t)), and the t somehow gets interpreted like it should be a list, which it is not. So, it cannot be made into a table for output, and you get your error. Changing the header just bypasses this function and outputs the results more directly. Daniele Pizzolli writes: Hello, my attempt to use org-mode for both interactive presentation and final report was unsuccessful due to a series of bugs and nuisances. Fortunately I can use the result of tangle. Will report the issues encountered to the list in the next few days. Here is a minor one. The following code, taken from [[info:org#Languages]] works if run after manually selecting it and running with M-x eval-region. But with M-x org-babel-execute-src-block it triggers an error. The *Messages* buffer shows: #+BEGIN_EXAMPLE executing Emacs-Lisp code block... orgtbl-to-orgtbl: Wrong type argument: listp, t #+END_EXAMPLE #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (R . t))) #+END_SRC #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC #+RESULTS: : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) Best, Daniele -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] control tangling from section header
Daniele Pizzolli d...@toel.it writes: Hello Ken, Ken Mankoff writes: I'm working with my literate init file (emacs.org), and would like to have certain sections not tangle. I currently do this with :tangle no at the SRC block level. Is it possible to control tangling with tags at the header level? Not with tag but with PROPERTIES: * outline header :PROPERTIES: :header-args: :tangle no :END: More at http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html This is what I would do as well. It would make it much easier to disable/enable sections, and see what sections are enabled/disabled, if the tangling state were more clearly visible like tags are. I do not think that this is currently possible. I haven't tried, but maybe one could use org-babel-pre-tangle-hook or org-export-before-parsing-hook, depending on the context, to set/update properties based on tags. For an init file the timing might matter. I don't know how init.org works, but presumably there's a ignite.el that starts the init process using init.org? —Rasmus -- Need more coffee. . .
Re: [O] markup text with leading, trailing spaces
hymie! hy...@lactose.homelinux.net writes: Sorry to resurrect an old thread, but this isn't actually working. hymie! hymie at lactose.homelinux.net writes: hymie! hymie at lactose.homelinux.net writes: So while I strongly prefer the exported version of - ~command1~ - ~command2~ - ~command3~ it's hard to copy-n-paste with the tildes in the way. org-hide-emphasis-markers is the answer. Setting this to true, the tildes disappear. The tildes disappear from the visual screen, but when I copy-n-paste, the tildes are still copied. :( Still looking for a solution that I like. Customize org-ascii-verbatim-format and use ox-ascii export. -- And when I’m finished thinking, I have to die a lot
Re: [O] control tangling from section header
On 2015-02-23 at 09:39, Rainer M Krug rai...@krugs.de wrote: I'm working with my literate init file (emacs.org), and would like to have certain sections not tangle. I currently do this with :tangle no at the SRC block level. Is it possible to control tangling with tags at the header level? If I am not mistaken, you can mark the header as COMMENT and no code blocks under this header are tangled. That would be a great solution, but it does not work on my system (8.2.10) -k.
[O] BUG? Text in the code and verbatim string is not processed
So the documentation says You can make words *bold*, /italic/, _underlined_, =verbatim= and ~code~, and, if you must, ‘+strike-through+’. Text in the code and verbatim string is not processed for Org mode specific syntax, it is exported verbatim. However, that is not the behavior I am seeing. In this construct: - ~cd ~/test~ - ~cp foo foo1~ The tilde in the path ~/test is hidden when org-hide-emphasis-markers is turned on. Maybe that is confusing org, so I changed it to this construct: - =cd ~/test= - ~cp foo foo1~ In this case, the word cd is formatted as verbatim, but the word /test along with the - on the next line are all formatted as code. Am I misunderstanding what is supposed to happen, or is this a bug? --hymie!
Re: [O] markup text with leading, trailing spaces
Sorry to resurrect an old thread, but this isn't actually working. hymie! hymie at lactose.homelinux.net writes: hymie! hymie at lactose.homelinux.net writes: So while I strongly prefer the exported version of - ~command1~ - ~command2~ - ~command3~ it's hard to copy-n-paste with the tildes in the way. org-hide-emphasis-markers is the answer. Setting this to true, the tildes disappear. The tildes disappear from the visual screen, but when I copy-n-paste, the tildes are still copied. :( Still looking for a solution that I like. --EbH
Re: [O] control tangling from section header
Ken Mankoff mank...@gmail.com writes: On 2015-02-23 at 09:39, Rainer M Krug rai...@krugs.de wrote: I'm working with my literate init file (emacs.org), and would like to have certain sections not tangle. I currently do this with :tangle no at the SRC block level. Is it possible to control tangling with tags at the header level? If I am not mistaken, you can mark the header as COMMENT and no code blocks under this header are tangled. That would be a great solution, but it does not work on my system (8.2.10) Just confirmed here - works here: Org-mode version 8.3beta (release_8.3beta-846-g38ab8b @/Users/rainerkrug/.emacs.d/org-mode/lisp/) GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local Cheers, Rainer -k. -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] control tangling from section header
On 2015-02-23 at 10:03, Rainer M Krug rai...@krugs.de wrote: Just confirmed here - works here: Org-mode version 8.3beta (release_8.3beta-846-g38ab8b @/Users/rainerkrug/.emacs.d/org-mode/lisp/) Yes it does. I've upgraded to 8.3 from git. Thanks, -k.
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
thanks for the explanation. Unfortunately my lisp knowledge is too limited to understand you. As a naive org-mode user, if possible I do not want to be exposed to org internals error, especially the confusing ones, where the custom code works fine. Maybe we can get a warning instead of an error? It is not a really big issue, a newcomer can be confused, if not scared, having an error on the fist babel usage. I agree. Even for experienced people, this is pretty annoying. Something as simple as #+BEGIN_SRC emacs-lisp '((1 . nil) (2 . 3)) #+END_SRC fails with a cryptic error. While this works fine. I would vote for a fall-back to code or even a plain string in this case. #+BEGIN_SRC emacs-lisp :results code '((1 . nil) (2 . 3)) #+END_SRC #+RESULTS: #+BEGIN_SRC emacs-lisp ((1) (2 . 3)) #+END_SRC Best, Daniele -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] Citation syntax and ODT
Vaidheeswaran kjambunat...@gmail.com writes: We haven't really discussed how styles should be specified (yet), or the formatting of bibliographies. But we have been discussing a syntax that lets you specify those formatting properties which commonly differ between individual citations. IMO, it is better to roll out the citation feature WITHOUT any formatting properties. The specific formatting chosen is at the mercy of capabilities of the export backend or citation engine it works with. I still don't understand what it would mean for an exported citation not to have any formatting properties. If I write a citation like [cite: See @Doe99 p. 43] how should that be represented in an ODT/HTML/etc. document without any formatting? Just copy the text verbatim into the output...? According to the proposal we've been discussing, a citation like this is an in-text (as opposed to parenthetical) citation with a prefix and a suffix, and thus should render something like See Doe (1999, p. 43) or See Doe [1, p. 43] etc. where the choice between those options would depend on the citation style. I agree that there is an issue about those styles; it seems likely that Org will have to be fairly flexible about those, perhaps falling back to a default if the requested style is not available on a particular backend. (Probably it would be useful, too, to be able to separately specify styles for LaTeX vs. non-LaTeX backends.) But whatever style is chosen, I would still think that the fact that the citation is in-text rather than parenthetical, and that it has a prefix and suffix, should be represented in the output. Perhaps not all backends will be able to do even that at first -- that's fine -- but I think that should be treated as a bug to be fixed at some point, not as acceptable behavior. Do you disagree? Do you think of a scenario where: 1. Org acts like a citation engine. (A self-contained Org-ecosystem) 2. Org-backends interfaces with a 3rd-party engine (like pandoc, zotero, JabRef) If the current effort is to build (1), ODT backend will have no reason to complain. If the effort is geared more towards (2), the ground reality is that JabRef's style catalog is not as extensive or mature as, say Zotero's or LaTeXs. The implication is that the PDF document produced via the LaTeX document WILL DIFFER IN STYLE from the PDF document produced via the ODT backend. Yes, that is inevitable, and fine, I think. But as far as I can tell, this is an issue of the document-level style selection (Chicago vs. APA vs. ACM...), not an issue of the more fine-grained differences between e.g. parenthetical and in-text, or having a prefix or not; these fine-grained differences are (mostly) independent of the style, and I think they should be represented in the output. I am imagining something along a mix of (1) and (2), with more initial thrust in favor of (2). Me too. I am guessing we will want to `bless' one or two external tools, both on the side of reference databases (perhaps Bib(La)TeX and Zotero, in addition to Org-bibtex) and on the side of formatting processors (perhaps Bib(La)TeX and citeproc-js or zotxt). We can then make it clear that exporting citations to a particular format requires these tools, much like exporting an Org document to PDF requires a TeX installation. I am only saying that the people who work on the specification take sufficient care to TEMPER what a user can reasonably expect when he moves between different backends. My primary motivation is to draw the attention of people like you (who are hammering out the syntax) to factor the case of a backend-like ODT. I agree, this is important. Unfortunately, like I said, I don't personally know much about ODT, so I need to rely on people who know more about it (like you) in order to factor in the details. My focus in not so much on syntax-richness but on quick roll-out of citation support. ... My only suggestion is to MERELY TO TAKE COGNIZANCE of the need for bells-and-whistles without the current momentum being dragged down by an attempt to arrive at a consensus that will keep all parties happy. That is fair enough, and I agree. I would just add that we've worked pretty hard to come up with a list of features that are important enough that they should be supported by all backends. While we might not be able to implement them all on all backends right away, my hope is that they eventually will be fully supported. But you're right, let's not have the perfect be the enemy of the good in the meantime. Best, Richard
Re: [O] duplicate PROPERTIES drawers
On 2015-02-23 at 09:02, Ken Mankoff mank...@gmail.com wrote: On 2015-02-23 at 03:35, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Hmm. It is happening on the latest melpa install. Or maybe on an earlier version and I'm only seeing it now. I run melpa, no git versions. There is a function in ORG-NEWS that will repair old documents, but it will _not_ merge duplicate properties drawers. Thanks for the hint. I've found that and run it, but get an error because org-planning-line-re 'symbols variable is void'. Searching that I see mention that error is indicative of a mixed installation... It looks like that function exists in 8.3 I've upgraded to 8.3beta (git) and now things work better. -k.
Re: [O] Error exporting org file in ics format
Leandro Noferini lnofe...@cybervalley.org writes: What is an ECM? French acronym for minimal complete example. or even the full file if it doesn't contain sensitive information? I could send you privately, not in list: nothing really sensitive, job appointments but not to be indexed in the internet for the ethernity! OK. You can also use the following function, which will produce a copy of the original buffer, with scrambled contents (defun scramble-contents () (interactive) (let ((tree (org-element-parse-buffer))) (org-element-map tree '(code comment comment-block example-block fixed-width keyword link node-property plain-text verbatim) (lambda (obj) (cl-case (org-element-type obj) ((code comment comment-block example-block fixed-width keyword node-property verbatim) (let ((value (org-element-property :value obj))) (org-element-put-property obj :value (replace-regexp-in-string [[:alnum:]] x value (link (unless (string= (org-element-property :type obj) radio) (org-element-put-property obj :raw-link http://orgmode.org;))) (plain-text (org-element-set-element obj (replace-regexp-in-string [[:alnum:]] x obj) nil nil nil t) (let ((buffer (get-buffer-create *Scrambled text*))) (with-current-buffer buffer (insert (org-element-interpret-data tree)) (goto-char (point-min))) (switch-to-buffer buffer However make sure you can reproduce the problem on that copy first. Regards,
Re: [O] org-agenda - how to move columns
look into org-agenda-prefix-format. However, you can also change the category of your org files by putting #+CATEGORY: MYCAT at the very top of your org files, and that decouples the category (the first column in agenda) from the filename. On Mon, Feb 23, 2015 at 11:59 AM, David Belohrad da...@belohrad.ch wrote: Dear All, I'm using quite long filenames for my org files (e.g. emails_sent-pcbe13433.org). I get into troubles when constructing an agenda as there is not enough space between the first filename column and second time column. Is there any way how to adjust the widths of the columns in the agenda? many thanks .d.
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
Fabulous! Thanks! Nicolas Goaziou writes: Hello, John Kitchin jkitc...@andrew.cmu.edu writes: I agree. Even for experienced people, this is pretty annoying. Something as simple as #+BEGIN_SRC emacs-lisp '((1 . nil) (2 . 3)) #+END_SRC fails with a cryptic error. While this works fine. I would vote for a fall-back to code or even a plain string in this case. Indeed. This should be fixed in ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29. If fall-backs to a plain string. Thank you. Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] FR: Fontify links even when in comments
It would be nice to have an [[Org mode link]] # in a line that is [[commented]] and still be able to see that link. Currently, there is no visual indication that the link exists, although it still does work. -k.
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
Nicolas Goaziou writes: Hello, [] Indeed. This should be fixed in ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29. If fall-backs to a plain string. Thank you. Thanks to you for taking care so quickly! Best, Daniele
Re: [O] FR: Fontify links even when in comments
Hi Nicolas, On 2015-02-23 at 14:32, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Ken Mankoff mank...@gmail.com writes: It would be nice to have an [[Org mode link]] # in a line that is [[commented]] and still be able to see that link. Currently, there is no visual indication that the link exists, although it still does work. It works as a convenience feature. However, I don't think we should publicize it much, as a comment is first and foremost, dead data. To me comments are mainly things that don't get exported. I don't know what you mean by dead, but comments are certainly data, and data is not dead. Their utility and data density is reduced if they can't contain links (or I can't see that the link is there, which is sort-of the same thing). When writing a document it is useful to leave informal notes to myself that say see X where X is an external file, or a section (or some code) elsewhere in this document, etc. This can be done with #+BEGIN_EXAMPLE :exports none, or **SECTION :noexport:, but both of those are awful hacks when a single line or a few words are all that is needed. -k.
[O] org-agenda - how to move columns
Dear All, I'm using quite long filenames for my org files (e.g. emails_sent-pcbe13433.org). I get into troubles when constructing an agenda as there is not enough space between the first filename column and second time column. Is there any way how to adjust the widths of the columns in the agenda? many thanks .d.
Re: [O] Publishing orgmode files
Hi, Xavier Maillard xav...@maillard.im writes: Hello, I am trying to publish my org project but I am lost in the way I can tweak my projects. Is there some good tutorial I can follow step by step in order to publish several files at once ? My site tree is like this: web/ ├── Makefile ├── css │ └── style.css ├── gnupg.org ├── header │ └── header.org ├── index.org ├── org-templates │ └── level-0.org └── publish_config.el I am using a Makefile to build it from the command line but it is just a gadget that just make a call to `org-publish-project'. Where I am totally lost is with how I can tweak my publish option. Turns out I can add many options directly into org-mode files but that's not practical to clone/duplicate them in several places. This is where org-templates should enter the dance but either I use them bad or it just not the way to go. I am tryng as a simple example, to replace the default (included) style with my own (stored in css/style.css). My org-templates/level-0.org has this: #+STYLE: link rel=stylesheet type=text/css href=css/style.css / # Local Variables: # org-html-head-include-default-style: nil # org-html-head-include-scripts: nil # End: All of this has been stolen here and there but it just does nothing. Elsewhere I have seen we can embed :style in the `org-publish-project-alist' (same result). Some people are using #+HTML_HEAD_EXTRA instead. So what is the way to go just for this basic stuff ? I have nothing configured with org-mode (8.2.10 version by the way) and I am using the defaults eveywhere. I don't know of org-template, but I generally set some elisp variables to provide my own customization before calling `org-publish-project'. Wouldn't it be enough for your use case? For instance, I guess your call to `org-publish-project' could look like: --8---cut here---start-8--- (let ( (org-export-html-style link rel=\stylesheet\ type=\text/css\ href=\css/style.css\ /) (org-html-head-include-default-style nil) (org-html-head-include-scripts nil) ) (org-publish-project ...) ) --8---cut here---end---8--- Would it do the trick? -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A signature.asc Description: PGP signature
Re: [O] Publishing orgmode files
Hello, Xavier Maillard xav...@maillard.im writes: I am trying to publish my org project but I am lost in the way I can tweak my projects. Is there some good tutorial I can follow step by step in order to publish several files at once ? My site tree is like this: web/ ├── Makefile ├── css │ └── style.css ├── gnupg.org ├── header │ └── header.org ├── index.org ├── org-templates │ └── level-0.org └── publish_config.el I am using a Makefile to build it from the command line but it is just a gadget that just make a call to `org-publish-project'. Where I am totally lost is with how I can tweak my publish option. Did you read (info (org) Publishing options) and (info (org) Complex example) ? It might help you getting started. For most back-end specific options, however, you will need development version (Org 8.3). Regards, -- Nicolas Goaziou
Re: [O] duplicate PROPERTIES drawers
Hello, Ken Mankoff mank...@gmail.com writes: I have found many task with duplicate PROPERTIES drawers. I saw mention on the list that, ...it will be invalid for a LOGBOOK to appear before PROPERTIES in Org 8.3. It seems that tasks don't have properties by default, and if I LOG an item, I get a LOGBOOK drawer. If properties are added later (by touching the item with MobileOrg, or adding a property with C-c C-x p, then PROPERTIES go below the LOGBOOK. This shouldn't happen in master branch. There is a function in ORG-NEWS that will repair old documents, but it will _not_ merge duplicate properties drawers. I'm not sure what is going on to create the second PROPERTIES drawer. Has anyone else seen this? Any ideas what I am doing wrong. I've found many of these tasks manually. I haven't been able to search and list them progragmatically (I've been trying using grep and other shell tools on my Org files). Is there a way to list all tasks with duplicate properties, or all tasks where :PROPERTIES: is not the first item listed, if that is a requirement? This should find such entries. (org-element-map (org-element-parse-buffer 'element) 'headline (lambda (h) (and (org-element-map h 'drawer (lambda (d) (equal (org-element-property :name d) PROPERTIES)) nil t 'headline) (let ((begin (org-element-property :begin h))) (message Entry with erroneous properties drawer at %d begin) begin Regards, -- Nicolas Goaziou
Re: [O] Citation syntax and ODT
On 2015-02-24T10:25:39+1100, Richard Lawrence said: RL Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: But whatever style is chosen, I would still think that the fact that the citation is in-text rather than parenthetical, and that it has a prefix and suffix, should be represented in the output. 1. When you choose 'style' (Chicago etc.) wouldn't be one of in-text or parenthetical already chosen for you? Stated other way, is the choice between parenthetical or in-text document-wide or is it that one could intermix the two styles in the same document. RL These could be intermixed in the same document. The RL document-level style determines how each type ultimately looks, RL but the choice of style is (mostly) independent of using RL parenthetical vs. in-text citations. Fwiw, it seems to me that there might be some confusion here arising from two separate usages of the word 'style': (a) 'style' to mean writing style, i.e. which words are used, how they're put together, etc. For example, Plain English. (b) 'style' to mean presentation style, i.e. how words, symbols, glyphs etc. are presented visually or (for vision-impaired people) aurally. For example, the sort of things specified by Cascading Style Sheets. Thus, the citation 'style' can be independent of the presentation style used for that citation style. For examle, one might have a citation style like: [Smith 2001] which in certain contexts is expected to have a presentation style of 'bolded'. So what i understand Vaidheeswaran to be asking is: Please don't code things such that presentation style is /necessarily/ carried along with citation style. Make it so that exporting a document faithfully reproduces the citation style in the target format, but don't /force/ the presentation style used in the source format for citation style to be the presentation style used in the destination format. Vaidheeswaran, is that correct? Alexis.
Re: [O] Citation syntax and ODT
On Tuesday 24 February 2015 08:56 AM, Alexis wrote: For examle, one might have a citation style like: [Smith 2001] which in certain contexts is expected to have a presentation style of 'bolded'. So what i understand Vaidheeswaran to be asking is: Please don't code things such that presentation style is /necessarily/ carried along with citation style. Make it so that exporting a document faithfully reproduces the citation style in the target format, but don't /force/ the presentation style used in the source format for citation style to be the presentation style used in the destination format. Vaidheeswaran, is that correct? That is the sense in which I used the word 'style'. I also used 'style' in the sense of the relative order or form (abbreviated or not) of how the fields from citation database entry gets presented. I also used 'style' in the sense of Chicago, APA etc. When Richard uses 'formatting' he really means how pre and post notes should be injected in to the inline expansion of a citation reference (in the body text) so that a reader's experience is uneven due to jarring parenthetical marks. Even though we use terms differently, (I think) I have a feel for what the 'big' discussion is about. May be the citation spec, should come with a glossary of of terms that defines the sense in which those need to be understood/interpreted :-P
Re: [O] Citation syntax and ODT
On Tuesday 24 February 2015 10:31 AM, Thomas S. Dye wrote: Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. Every day? Ok. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. Yes, but the author will certainly choose to use a tool that doesn't require this. (Let me remind you, when it comes to LaTeX, I have zero knowledge.) 1. When you say 'tool' what exactly do you mean? 2. Give us some concrete examples of what 'this tool' does. a) Can an elisp module aspire to replicate what 'this tool' does? b) 'The task' that 'this tool' accomplishes, is it 'common' across all the citation engines that the participants (in this discussion) have in mind. Org crowd is essentially a LaTeX crowd and Emacs crowd is invariably academic in nature. It is for this sole reason, that one often doesn't hear much frequent complaints regarding lack of citation support. (I think), if we could keep the OTHER users -- by this I mean, users of ASCII or HTML or ODT backends happy or 'just happy' we have made a good progress. Pleasing LaTeX crowd, which is already pleased with status-quo seems a bit pointless to me. Put other way, the LaTeX crowd should represent just those aspects which it is displeased with.
Re: [O] Citation syntax and ODT
On Tuesday 24 February 2015 04:55 AM, Richard Lawrence wrote: Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: But whatever style is chosen, I would still think that the fact that the citation is in-text rather than parenthetical, and that it has a prefix and suffix, should be represented in the output. 1. When you choose 'style' (Chicago etc.) wouldn't be one of in-text or parenthetical already chosen for you? Stated other way, is the choice between parenthetical or in-text document-wide or is it that one could intermix the two styles in the same document. These could be intermixed in the same document. The document-level style determines how each type ultimately looks, but the choice of style is (mostly) independent of using parenthetical vs. in-text citations. Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. 2. Citation processor like JabRef just takes a cite-key. It doesn't take a pre or post-note. So, the pre and post notes should be spliced in to the exported document by the elisp module that interfaces with the citation processor. Right. That's what I'm thinking, anyway. If we are going to interface with a citation-processor, the best course of action would be to have someone first 'gauge' the capabilities provided by the citation processor and let that experience inform what Org should aspire to do. Yes. Other people have more experience with this than me. But based on what Pandoc is able to do, I am pretty confident that everything that has been proposed could be handled by a CSL processor like citeproc-js (or Pandoc's own). The possible exceptions are the common prefix and common suffix in a multi-work citation, which I imagine would be easy enough to add to the output of the citation processor. In case of JabRef or bibtex2html, it is the 'command line' that is used for interfacing. In case of pandoc (I could be wrong here), the nature of interface is most likely to be a post-processing step on the produced document. This post-processing could happen as part of elisp hook or the document may be pipelined through a pandoc provided command-line tool. The point is that the choice of the citation processor will determine the nature of investments that need to be made in to the export module. JabRef or bibtex2html are really very poor cousins when compared to modern tools like Zotero. They would continue to remain poor cousins. So, I can imagine a scenario where JabRef or bibtex2html is relegated to the background (i.e., a contrib/ Org-module) while Zotero/Pandoc takes the prime-time (i.e., a lisp/ Org-module). In so far as zotero is concerned, there 'used to be' no standalone JS command-line environment or the toolchain was cumbersome. I am reluctant to invest my time in citeproc-js or pandoc related integration work (so far as it concerns ODT exporter). Part of the reason for this relucatance is that setting up of the toolchain would involve more than a simple 'apt-get ...'. (My Debian is a bit old.) I am reluctant to work on JabRef integration unless I get an apriori commitment from the maintainers that it will be part of the Emacs distribution. Best, Richard
Re: [O] Citation syntax and ODT
Aloha Vaidheeswaran C, Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: On Tuesday 24 February 2015 10:31 AM, Thomas S. Dye wrote: Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. Every day? Ok. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. Yes, but the author will certainly choose to use a tool that doesn't require this. (Let me remind you, when it comes to LaTeX, I have zero knowledge.) 1. When you say 'tool' what exactly do you mean? A citation manager. 2. Give us some concrete examples of what 'this tool' does. Manages citations. The author wants to do as little of this as possible. a) Can an elisp module aspire to replicate what 'this tool' does? Yes, I believe so. b) 'The task' that 'this tool' accomplishes, is it 'common' across all the citation engines that the participants (in this discussion) have in mind. I don't know. Do other citation engines require that a document author re-word his work in such a way that in-text or parenthetical citations could be replaced by the other? Org crowd is essentially a LaTeX crowd and Emacs crowd is invariably academic in nature. It is for this sole reason, that one often doesn't hear much frequent complaints regarding lack of citation support. Actually, Org mode supports citations quite well through links, so there is no need to complain. In my field of archaeology it is not unusual to find a journal that does not accept LaTeX. When the journal requires Word, which is very common, I've been converting from LaTeX with tex4ht, but it would be neat to export directly to ODT. (I think), if we could keep the OTHER users -- by this I mean, users of ASCII or HTML or ODT backends happy or 'just happy' we have made a good progress. Agreed. Are they unhappy now? I use the ASCII and HTML exporters regularly, and I'm quite happy with them. Pleasing LaTeX crowd, which is already pleased with status-quo seems a bit pointless to me. Put other way, the LaTeX crowd should represent just those aspects which it is displeased with. There is no displeasure in my corner of the LaTeX crowd. I believe we are all here on this list because we enjoy Emacs and Org mode, which is an awesome tool for authors. 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] Citation syntax: a revised proposal
On Tuesday 17 February 2015 10:48 PM, Richard Lawrence wrote: Another, more serious reason is that I work in a field where some journals do not accept LaTeX submissions, or disprefer them; so having some citation support in ODT export is important.) You are lobbying for two things: 1. An improvement in existing citation syntax. 2. Citation support for ODT backend. If you need help with ODT/JabRef integration, I am willing to lend a hand. (Only thing is) I would expect that someone hand-hold me wrt what one wants in the final exporter on a case-by-case basis. I would rather build bottom-up, rather than top-down.
Re: [O] Citation syntax and ODT
On Tuesday 24 February 2015 11:37 AM, Thomas S. Dye wrote: Aloha Vaidheeswaran C, Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: On Tuesday 24 February 2015 10:31 AM, Thomas S. Dye wrote: Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. Every day? Ok. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. Yes, but the author will certainly choose to use a tool that doesn't require this. (Let me remind you, when it comes to LaTeX, I have zero knowledge.) 1. When you say 'tool' what exactly do you mean? 2. Give us some concrete examples of what 'this tool' does. a) Can an elisp module aspire to replicate what 'this tool' does? b) 'The task' that 'this tool' accomplishes, is it 'common' across all the citation engines that the participants (in this discussion) have in mind. If someone could respond to above questions with concrete examples I will give it due attention. In my field of archaeology it is not unusual to find a journal that does not accept LaTeX. When the journal requires Word, which is very common, I've been converting from LaTeX with tex4ht, but it would be neat to export directly to ODT. I will be happy to excuse myself from this discussion if ODT/JabRef integration is of no interest to the community.
Re: [O] Embedding diagrams in Org
On 2015-02-18, at 15:19, Eric S Fraga e.fr...@ucl.ac.uk wrote: Support for tikz is there implicitly in that there is support for LaTeX. I use tikz all the time. Yes, but I wanted to be able both to see the diagram in the Org file itself /and/ to export it properly to LaTeX. (It seems that your solutions did support both these things, though. Thanks!) Simple example attached. I have one question. #+begin_src latex :results latex raw :exports results Why :results latex raw and not :results latex? HTH, eric Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
[O] How to extract raw link and description from the link element?
Hi all, so I have this: [[file:whatever.org][Some link]] How do I extract bith parts of this link programmatically? My use case is that I have an Org tree of links, and I want to export them to certain XML format. TIA, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] How to extract raw link and description from the link element?
Probably there is some more elegant way but if you run this on a link, you get the two pieces I think. In a filter or exporter, you might replace (org-element-context) with the link element/object #+BEGIN_SRC emacs-lisp (defun parse-link () (interactive) (message-box %s (cons ;; path (org-element-property :path (org-element-context)) ;; description (buffer-substring (org-element-property :contents-begin (org-element-context)) (org-element-property :contents-end (org-element-context)) #+END_SRC Marcin Borkowski writes: Hi all, so I have this: [[file:whatever.org][Some link]] How do I extract bith parts of this link programmatically? My use case is that I have an Org tree of links, and I want to export them to certain XML format. TIA, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] Problem with relative paths of links in export
I have an old org file, with some source blocks that create a table with some hyperlinks like [[file:../receipts/2015/02/aj140212_1.pdf][19998-DUPLT]] (the file is in receipts subdirectory of the parent directory). Export from the org file used to work fine. But just now, these paths are now working in exported pdf files. What could I be doing wrong? Vikas
Re: [O] Citation syntax and ODT
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. Every day? 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. Yes, but the author will certainly choose to use a tool that doesn't require this. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Citation syntax and ODT
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: On Tuesday 24 February 2015 11:37 AM, Thomas S. Dye wrote: Aloha Vaidheeswaran C, Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: On Tuesday 24 February 2015 10:31 AM, Thomas S. Dye wrote: Vaidheeswaran Cvaidheeswaran.chinnar...@gmail.com writes: Often times there is a difference between what is possible and what is the common practice. So, 1. How often do you intermix in-text and parenthetical styles. Every day? Ok. 2. Can the document author re-word his work in such a way that an in-text or parenthetical citation could be replaced by the other without compromising on the overall style of the produced document. Yes, but the author will certainly choose to use a tool that doesn't require this. (Let me remind you, when it comes to LaTeX, I have zero knowledge.) 1. When you say 'tool' what exactly do you mean? 2. Give us some concrete examples of what 'this tool' does. a) Can an elisp module aspire to replicate what 'this tool' does? b) 'The task' that 'this tool' accomplishes, is it 'common' across all the citation engines that the participants (in this discussion) have in mind. If someone could respond to above questions with concrete examples I will give it due attention. AFAIK, the only software that has proposed a solution to the problem of maintaining a citation database that can support the universe of citation styles developed in the wild is BibLaTeX. I've been trying to impart what I know of this so the citation syntax developed by the Org mode community doesn't limit what Org mode can do in the future. I'm not too concerned if the backend support is uneven at first. I'll be happy if the syntax doesn't have to change as citation support in ODT and other backends matures, as it certainly will. BibLaTeX includes a well-written manual that has influenced my thinking on citation managers. I recommend it highly. In my field of archaeology it is not unusual to find a journal that does not accept LaTeX. When the journal requires Word, which is very common, I've been converting from LaTeX with tex4ht, but it would be neat to export directly to ODT. I will be happy to excuse myself from this discussion if ODT/JabRef integration is of no interest to the community. No offense intended. I tried, apparently unsuccessfully, to indicate my interest in Org mode support for ODT. Let me indicate my interest again. I would definitely like to export my documents to ODT so I can submit them directly to journals in my field that require Word files. The translation through tex4ht is, for me, an adventure and I'd much prefer to skip it if I could. I have no idea if this is possible with the citation managers that work with ODT. I'll be pleased to learn that it is possible, and happy to wait if it is not. I fully expect that other users have different needs, I'm just trying to indicate my interest in Org mode support for ODT citations here. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Citation syntax and ODT
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: But whatever style is chosen, I would still think that the fact that the citation is in-text rather than parenthetical, and that it has a prefix and suffix, should be represented in the output. 1. When you choose 'style' (Chicago etc.) wouldn't be one of in-text or parenthetical already chosen for you? Stated other way, is the choice between parenthetical or in-text document-wide or is it that one could intermix the two styles in the same document. These could be intermixed in the same document. The document-level style determines how each type ultimately looks, but the choice of style is (mostly) independent of using parenthetical vs. in-text citations. 2. Citation processor like JabRef just takes a cite-key. It doesn't take a pre or post-note. So, the pre and post notes should be spliced in to the exported document by the elisp module that interfaces with the citation processor. Right. That's what I'm thinking, anyway. If we are going to interface with a citation-processor, the best course of action would be to have someone first 'gauge' the capabilities provided by the citation processor and let that experience inform what Org should aspire to do. Yes. Other people have more experience with this than me. But based on what Pandoc is able to do, I am pretty confident that everything that has been proposed could be handled by a CSL processor like citeproc-js (or Pandoc's own). The possible exceptions are the common prefix and common suffix in a multi-work citation, which I imagine would be easy enough to add to the output of the citation processor. Best, Richard
