[O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
The line mentioning Jambunathan K was committed by me not by the
maintainer. Don't be misled by what the annotate says, it shows who
made the most recent edit and not added the original line.
ps: If the maintainer is removing acknowledgements he should also remove
the files - both from regular org and contrib.
Someone from the community can fork ox-html.el and ox-odt.el. I will
still make the files available via GNU ELPA and maintain it from Emacs
Bzr Repo. Since the copyright is assigned to FSF, GNU ELPA will be the
best place to distribute it and I can also have an element of control on
who commits to the file and what gets committed.
ps: I don't claim original ownership of ox-html.el but if I remove the
commits I made to that file, you will be left with something that is
really not useful.
Jambunathan K.
,
| org.texi (History and Acknowledgments): Remove Jambunathan from my own
acknowledgments
|
| * org.texi (History and Acknowledgments): Remove Jambunathan from
|
| my own acknowledgments.
|
| index f2659da..2deaa9d 100644 (file)
|
|
| --- a/doc/org.texi
| +++ b/doc/org.texi
| @@ -10893,7 +10893,6 @@ For more information, see the documentation on Worg.
|
| @node OpenDocument Text export, iCalendar export, @LaTeX{} and PDF export,
Exporting
| @section OpenDocument Text export
| -@cindex K, Jambunathan
| @cindex ODT
| @cindex OpenDocument
| @cindex export, OpenDocument
| @@ -16447,12 +16446,6 @@ Nicolas is maintaining the consistency of the
deepest parts of Org. His work
| on @file{org-element.el} and @file{org-export.el} has been outstanding, and
| opened the doors for many new ideas and features.
|
| -@item Jambunathan K
| -Jambunathan contributed the ODT exporter, definitely a killer feature of
| -Org mode. He also contributed the new HTML exporter, which is another core
| -feature of Org. Here too, I knew I could rely on him to fix bugs in these
| -areas and to patiently explain the users what was the problems and solutions.
| -
| @item Achim Gratz
| Achim rewrote the building process of Org, turning some @emph{ad hoc} tools
| into a flexible and conceptually clean process. He patiently coped with the
`
--
Re: [O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
Jambunathan K kjambunat...@gmail.com writes: ps: If the maintainer is removing acknowledgements he should also remove the files - both from regular org and contrib. What this means is that if the file of which I am one of the author or one of the principal author (if moved to GNU ELPA and re-distributed with regular Org distribution), I will vehemently argue that my efforts are acknowledged in the Org manual. --
Re: [O] org-export raises stringp nil error
Glenn Morris r...@gnu.org writes: I assumed it was okay to fix bugs after the last pretest, is it so? No, it is not ok, and I don't know why you would think it is. I missed the distinction between pretest and release candidate. The reason for this policy is (obviously) to prevent inadvertently introducing mistakes. This seems to be exactly what has bitten us in this case, where your patch just reverts the change from http://lists.gnu.org/archive/html/emacs-diffs/2013-02/msg00058.html Was that fixing a regression? I doubt it. I find it hard to draw a clear line between regressions and bugs, especially since Org 7.9.x versions are way behind the current Org master branch. Please apply the first patch as soon as possible. Done. The second includes stuff like deleting comments, declaring functions, and changing autoload for org-autoload. No, you may not apply this. If there were any fixes in there for important regression bugs against Emacs 24.2, please make a separate patch with just those items. Those are not critical regressions, so I won't apply them. -- Bastien
Re: [O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
Jambunathan K kjambunat...@gmail.com writes: What this means is that if the file of which I am one of the author or one of the principal author (if moved to GNU ELPA and re-distributed with regular Org distribution), I will vehemently argue that my efforts are acknowledged in the Org manual. They are: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=728793 I did not mention your efforts to destroy this community but I can. -- Bastien
Re: [O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
Aloha Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: ps: If the maintainer is removing acknowledgements he should also remove the files - both from regular org and contrib. What this means is that if the file of which I am one of the author or one of the principal author (if moved to GNU ELPA and re-distributed with regular Org distribution), I will vehemently argue that my efforts are acknowledged in the Org manual. It looks like Bastien has removed you from his *personal* acknowledgments. Since these are meant to express his sentiments, this is understandable given the acrimonious exchanges between you two. I agree that your good work should be acknowledged in the manual. In the List of Contributions, I find this line: * Jambunathan K contributed the ODT exporter. Perhaps this is the place to flesh out your contributions? The line seems somewhat dated to me. Peace, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
Hi, t...@tsdye.com (Thomas S. Dye) writes: * Jambunathan K contributed the ODT exporter. Perhaps this is the place to flesh out your contributions? The line seems somewhat dated to me. I update this line to include the rewrite of the HTML exporter. If there are other important contributions to the code or to the community (e.g., bug reports, bug fixes, etc.), I will include them here. -- Bastien
Re: [O] org-export raises stringp nil error
On 2013-03-08 14:40 +0800, Bastien wrote: I find it hard to draw a clear line between regressions and bugs, especially since Org 7.9.x versions are way behind the current Org master branch. I think org-mode is better in ELPA, a better distribution channel than the core for things like org-mode. Bundling it in emacs doesn't help anybody. Leo
Re: [O] org-export raises stringp nil error
Leo Liu sdl@gmail.com writes: On 2013-03-08 14:40 +0800, Bastien wrote: I find it hard to draw a clear line between regressions and bugs, especially since Org 7.9.x versions are way behind the current Org master branch. I think org-mode is better in ELPA, a better distribution channel than the core for things like org-mode. Bundling it in emacs doesn't help anybody. I strongly think otherwise: Emacs needs a good outline and editing tool. outline.el is not usable enough and I can see no other Emacs tool than Org-mode for exporting to HTML/LaTeX/ODT easily. I understand the temptation in terms of maintainance, but I think maintainance problems should not take priority over usefulness of the code. -- Bastien
Re: [O] org-export raises stringp nil error
On 2013-03-08 15:37 +0800, Bastien wrote: I strongly think otherwise: Emacs needs a good outline and editing tool. outline.el is not usable enough and I can see no other Emacs tool than Org-mode for exporting to HTML/LaTeX/ODT easily. I understand the temptation in terms of maintainance, but I think maintainance problems should not take priority over usefulness of the code. I am not doubting maintainance cost or the usefulness of the code. It is about distribution of your code to the users. I think ELPA is the way to go. Leo
Re: [O] org-export raises stringp nil error
On 03/08/2013 02:40 PM, Bastien wrote: I missed the distinction between pretest and release candidate. What's the difference between pretest and release candidate? Doesn't the latter belong to the former? The rc1/rc1.1 was released on the pretest directory. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] org-export raises stringp nil error
Xue Fuqiao xfq.f...@gmail.com writes: On 03/08/2013 02:40 PM, Bastien wrote: I missed the distinction between pretest and release candidate. What's the difference between pretest and release candidate? Doesn't the latter belong to the former? The rc1/rc1.1 was released on the pretest directory. Maybe this is just a difference of degree: only fix really-very-very- critical-regressions in rc, while fix bugs in pretest (and rc maybe is just the name for the last pretest releases, so a subset of them.) With two maybe I'm not helping very much, sorry. -- Bastien
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Achim Gratz strom...@nexgo.de writes: Bastien, I think it would make sense to clear up this confusion by tagging 8dd2bfc291 with version 7.9.9 or 8.0-pre or something like that (must be an annotated tag, of course). That'll help to easier determine who's using the new and the old exporter. I used 8.0-pre -- thanks for the suggestion! -- Bastien
Re: [O] org-export raises stringp nil error
On 03/08/2013 03:37 PM, Bastien wrote: I think org-mode is better in ELPA, a better distribution channel than the core for things like org-mode. Bundling it in emacs doesn't help anybody. I strongly think otherwise: Emacs needs a good outline and editing tool. outline.el is not usable enough and I can see no other Emacs tool than Org-mode for exporting to HTML/LaTeX/ODT easily. I agree. And I think some packages in GNU ELPA like AUCTeX and js2-mode should also be contained. The built-in modes for editing TeX related files and EMCAScript are not quite usable. I understand the temptation in terms of maintainance, but I think maintainance problems should not take priority over usefulness of the code. +1 -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] preview latex fragment with latex_header
Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Achim Gratz strom...@nexgo.de writes: Andreas Leha writes: In this particular situation (the \subtitle will always be document specific) the latex class is not possible here -- I won't create latex classes per document. Classes can have arguments and the argument would be the subtitle to set, so I don't understand that objection. Right. That holds for properly designed LaTeX classes. But I was talking about one of my LaTeX classes Here, the macro was just so much cheaper, so again no pressure to improve my LaTeX class ;-) I introduced LATEX_HEADER_EXTRA keyword, which will do the same as LATEX_HEADER but will not be used to preview latex snippets. Note that lines included in LATEX_HEADER_EXTRA will always appear after those defined by LATEX_HEADER keywords in the output. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] Captions for tables made by source blocks
Hello, Mike McLean mike.mcl...@pobox.com writes: On Wed, Mar 6, 2013 at 7:28 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Vikas Rawal vikasli...@agrarianresearch.org writes: CAPTION keyword above a source block applies to the source block only. If the source block generates a table, you have to put a CAPTION above it, as it will not inherit the caption of the source block. It also implies that you need to name the results. Otherwise, source block will not recognize its own production, due to the CAPTION keyword above it. Thank you once again Nicolas. I understand from this that the variable org-babel-results-keyword has to be changed to NAME. I did this and it works. Is there a way that this could be file-specific? I wasn't clear. By naming the results, I mean that you must provide your source block a #+NAME: something attribute, so the generated table gets a #+RESULTS: something attribute. Interesting that this topic comes up today just as I noticed it. I'm still unclear about how to put the CAPTION keyword in when using a dynamic block via org-collector.el. I have the lines below and I do not get a table caption like I used to in the old exporter. #+NAME: tbl-coi #+CAPTION: COI Table #+BEGIN: propview :colnames ( Area Shorthand COI ) :cols ( AREA CATEGORY ITEM ) :match +COI+LEVEL=2-ARCHIVE :noquote t :scope agenda :inherit (AREA) For the same reason, caption here applies to the dynamic block, not to its contents. The usual way to handle it is to provide a :caption argument in the header, which will in turn create a #+CAPTION keyword above the table upon updating. However, I don't think that org-collector handles it. You may want to patch it (you can look at `org-clocktable-write-default' for an example). Regards, -- Nicolas Goaziou
Re: [O] org-exp-bibtex missing in git?
Hi Andreas,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
But it looks very verbose to me. I expect the introduction to a
scientific paper (with typically many \cite{}s) to look disrupted.
Each \cite{...} would be nothing more than
[[cite:A.N.Whitehead][A.N.Whitehead]] in the Org file.
The config happens in the #+LINK: cite ... line.
I also think the proposal makes it easy to use several
bibliographic files, with several #+LINK: citeN ... lines.
In general, the idea is just to be able to hook an export
function to a link after it has been expanded, and maybe
this can be useful beyond this use-case. For example:
#+LINK: local file://%s org-odt-local-link
#+LINK: local file://%s org-odt-global-link
The first line would be used for documents that you want
to use locally, creating links to your files on your machine.
The second line would be used for documents that want to
share with others.
--
Bastien
Re: [O] preview latex fragment with latex_header
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Achim Gratz strom...@nexgo.de writes: Andreas Leha writes: In this particular situation (the \subtitle will always be document specific) the latex class is not possible here -- I won't create latex classes per document. Classes can have arguments and the argument would be the subtitle to set, so I don't understand that objection. Right. That holds for properly designed LaTeX classes. But I was talking about one of my LaTeX classes Here, the macro was just so much cheaper, so again no pressure to improve my LaTeX class ;-) I introduced LATEX_HEADER_EXTRA keyword, which will do the same as LATEX_HEADER but will not be used to preview latex snippets. Note that lines included in LATEX_HEADER_EXTRA will always appear after those defined by LATEX_HEADER keywords in the output. Thank you very much for this convenient keyword! Much appreciated. Haven't tested yet, but will use this a lot, I guess. (I will definitely *not* improve my LaTeX class now ;-) Regards, Andreas
Re: [O] org-exp-bibtex missing in git?
Hi Bastien,
Bastien b...@altern.org writes:
Hi Andreas,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
But it looks very verbose to me. I expect the introduction to a
scientific paper (with typically many \cite{}s) to look disrupted.
Each \cite{...} would be nothing more than
[[cite:A.N.Whitehead][A.N.Whitehead]] in the Org file.
In this case, you can ignore my comment on verbosity.
The config happens in the #+LINK: cite ... line.
I also think the proposal makes it easy to use several
bibliographic files, with several #+LINK: citeN ... lines.
In general, the idea is just to be able to hook an export
function to a link after it has been expanded, and maybe
this can be useful beyond this use-case. For example:
#+LINK: local file://%s org-odt-local-link
#+LINK: local file://%s org-odt-global-link
The first line would be used for documents that you want
to use locally, creating links to your files on your machine.
The second line would be used for documents that want to
share with others.
Now, that there is a proposal supporting additional citation command,
and pre-, post-notes
(http://permalink.gmane.org/gmane.emacs.orgmode/67818) I would
definitely love to see that supported.
So my question is: are your proposals mergable? Or are they orthogonal?
Regards,
Andreas
Re: [O] [new exporter] [html] Tables of Contents
Jambunathan K kjambunat...@gmail.com writes: Bastien b...@altern.org writes: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. I asked you to exercise moderator controls. Why should I ban myself? I am not a moderator of this list. And I would not like moderators to exercise their control on anybody on this list. Why should they make you a favor? I suspect you would enjoy it. So this is a no. I think staying away from this list would be good both for the list and for you. We could continue working without dealing with your weird and sometimes insulting messages. You could realize that what you really want is to contribute to Org and Emacs, and that the best way to achieve this is to amend your behavior, not to send patches. There is a persistent myth among programmers: because some great coders are plain jerks, we have a tendancy to believe jerks are often great programmers. But this is not the case. And you are not a great programmer, you are just an average one, good at some things, with time at hand. So step aside for a while, think about what you can learn from others, and come back when you learned how to behave correctly. This is much harder to achieve than contributing code, it can take a lifetime. A high-hanging fruit, like the ones you love. -- Bastien
[O] automagically changing roman enumeration to alphabetical
I was surprised by this behaviour. Find a new org-mode file. Type i) and then hit M-Ret. The i) gets renamed as a) and b) is added on the next line. I would have expected that we get ii) on the next line and the i) would be left alone. Is this working as intended?
Re: [O] org-caldav can't find org-prepare-agenda-buffers
David Engster d...@randomsample.de writes: Thanks. I've now pushed a further fix which should hopefully make things work with the new exporter. Julien, please let me know if it works. Sorry, it doesn't. I get the following when running org-caldav with the latest org-mode and org-caldav from git. --8---cut here---start-8--- byte-code: Wrong type argument: number-or-marker-p, nil --8---cut here---end---8--- Let me know what additional information you need to debug it, a backtrace...
Re: [O] [new exporter] [html] Tables of Contents
Bastien b...@altern.org writes: Jambunathan K kjambunat...@gmail.com writes: Bastien b...@altern.org writes: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. I asked you to exercise moderator controls. Why should I ban myself? I am not a moderator of this list. And I would not like moderators to exercise their control on anybody on this list. Why should they make you a favor? I suspect you would enjoy it. So this is a no. Oh, Ok. It looks like we are in a pissing contest. Jambunathan K.
Re: [O] [new exporter] is #+bind supported?
Achim Gratz strom...@nexgo.de writes: Eric S Fraga writes: No, nothing complete yet. Here's what I have so far, some autoload definitions might still be there, but will error out due to the fact that their target files are not in load-path anymore. Thanks for this. I've incorporated it into my emacs startup. It should help! I name you the official tester for this code. :-) An honour! ;-) Please keep in mind that the assumption is that no actual Org code has been loaded, eg. no symbols starting with ob- or org- would be features. So you need to do this very early in the startup sequence. Yes, this was understood. I have put your suggested code very early on in my initialisation, well before anything is loaded beyond the usual Emacs startup outside my control. However, my attempt to use this caused problems with Emacs starting up. I had too many things to do yesterday to investigate properly so I commented the code out. I will try again later to see what is happening. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] org-exp-bibtex missing in git?
aarone...@gmail.com writes: [...] I’ve got some mostly-working code that exports citations, only for latex, using a different approach (similar to Eric’s). I’ve cleaned it up some, and attached it as a patch to this email. This looks quite nice. I am unlikely to try it out, however, as my simple cite: (and related citep:) link definition does the job for me. I keep things simple when writing papers... I let the journal editors and publishers worry about detail ;-). Nevertheless, I can see this enhancement being quite useful for those that need the extra features in reference citations. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Christopher W. Ryan cr...@binghamton.edu writes: Well, with the little test file I initially posted, things worked OK with org version 7.9.3f. But things are bit more complicated: [...] Put cursor on * Hello above and then C-c C-e 1 d Are you sure you are using the new exporter? This binding doesn't work for me but did work for the old exporter. The equivalent in the new exporter would be C-c C-e C-s l o, I believe. Your configuration must be mixing up old and new exporters and, believe me, you're not the only one in this situation. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] automagically changing roman enumeration to alphabetical
Hi Paul, Paul Rudin paul-sqpymovxoov10xsdtd+...@public.gmane.org writes: Is this working as intended? Yes, because roman enumeration is not supported by Org. Org believes i) is the 9th item in an alphabetical list and converts it to a) if it is the first one. HTH, -- Bastien
Re: [O] org-exp-bibtex missing in git?
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
\footfullcite[prenote][postnote]{key}
What would prenote and postnote typically contain. Where would they
appear in the exported document - In the citation reference or in the
citation definition. Can the same key have different pre-note and
post-note attached to it.
I see Notes in Chicago-related style. Do these notes have anything to
do with Chicago stuff.
ps: I believe different faculties - by faculties I mean science,
humanities, engineering, law etc. - have their own preferred citation
style. So for the sake of discussion and finalizing the overall
spec. it would be beneficial if people can circulate what styles they
use and how it looks in the print format - journal or book. Sticking to
LaTeX (alone) will only result it LaTeX only solution but not a
cross-backend solution (A cross-backend solution is what Nicolas seems
to be proposing right now.)
--
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Hi, Same here. But the error is not in org-caldav, because it is triggered like this: (org-icalendar--combine-files nil ~/Desktop/ECM.org) where ~/Desktop/ECM.org is a file with nothing but one headline. /v -- Vincent Beffara On Thursday, March 7, 2013 at 10:13 , Julien Cubizolles wrote: David Engster d...@randomsample.de (mailto:d...@randomsample.de) writes: Thanks. I've now pushed a further fix which should hopefully make things work with the new exporter. Julien, please let me know if it works. Sorry, it doesn't. I get the following when running org-caldav with the latest org-mode and org-caldav from git. --8---cut here---start-8--- byte-code: Wrong type argument: number-or-marker-p, nil --8---cut here---end---8--- Let me know what additional information you need to debug it, a backtrace...
Re: [O] org-exp-bibtex missing in git?
Hi Aaron, I now see where you and Eric go and this is good! Here is a revised suggestion, allowing to add link types from withing the #+LINK keyword. 1. Allow more syntax for #+LINK: #+LINK: bib;%s;%s file:my.bib::%s org-bib-follow-link org-bib-export-link If `org-bib-follow-link' is nil, it'll follow [[bib:my.bib::key][key]] like it does right now, jumping to the key line in the my.bib file. If `org-bib-follow-link' is non-nil, it will operate on [[bib:my.bib::key;prenote;postnote][key]] and find the correct key. If `org-bib-export-link' is non-nil, it will operate on [[bib:my.bib::key;prenote;postnote][key]] and export it correctly depending on the backend. The change required for the exporter is to let `org-bib-follow-link' and `org-bib-export-link' operate on [[bib::my.bib::key;prenote;postnote]], not on the expanded link. IOW, link expansion should happen within the backend export routines, treating abbreviated links with formatting strings (aka bib;%s;%s) in a special way. I see two advantages: - adding new types will be easier -- e.g.: #+LINK: cite file:my.bib::%s org-bib-follow-link org-bib-export-link - users can decide what syntactic glue they want to their abbreviated links (using ; or another separator). Nicolas, do you think it is feasible/good to delay link expansion till the backend knows whether the abbreviated link is associated to follow/export function that would understand formatting strings in the abbreviated form? -- Bastien
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Hello, Vincent Beffara vbeff...@ens-lyon.fr writes: Same here. But the error is not in org-caldav, because it is triggered like this: (org-icalendar--combine-files nil ~/Desktop/ECM.org) where ~/Desktop/ECM.org is a file with nothing but one headline. I cannot reproduce it. Maybe a larger backtrace would help. Regards, -- Nicolas Goaziou
Re: [O] org-exp-bibtex missing in git?
Hi Bastien, On Thu, Mar 7, 2013 at 5:21 AM, Bastien b...@altern.org wrote: Hi Aaron, I now see where you and Eric go and this is good! Here is a revised suggestion, allowing to add link types from withing the #+LINK keyword. I suspect you may be targeting the wrong layer. Don't we want to use org-link-protocols, not org-link-abbrev-alist? Protocols are already handled by the exporter, so there should be no need for a change like this one: [...] Nicolas, do you think it is feasible/good to delay link expansion till the backend knows whether the abbreviated link is associated to follow/export function that would understand formatting strings in the abbreviated form? My proposal works without any changes to the exporter's structure (except adding the #+BIBLIOGRAPHY keyword, which is a one-line emendation). It does not allow the equivalent of your #+LINK: bib:%s;%s;%s for specifying the pre/post delimiters, but maybe it would be better from a standardization-of-syntax point of view to have just one way of encoding them? Aaron
Re: [O] org-exp-bibtex missing in git?
Hi Aaron, Aaron Ecay aarone...@gmail.com writes: I suspect you may be targeting the wrong layer. Don't we want to use org-link-protocols, not org-link-abbrev-alist? Protocols are already handled by the exporter, so there should be no need for a change like this one: [...] I want to allow adding link protocols (what I called adding link types) from #+LINK. Nicolas, do you think it is feasible/good to delay link expansion till the backend knows whether the abbreviated link is associated to follow/export function that would understand formatting strings in the abbreviated form? My proposal works without any changes to the exporter's structure (except adding the #+BIBLIOGRAPHY keyword, which is a one-line emendation). It does not allow the equivalent of your #+LINK: bib:%s;%s;%s for specifying the pre/post delimiters, but maybe it would be better from a standardization-of-syntax point of view to have just one way of encoding them? IIUC your proposal introduces some syntactic glue here: [[type:key;pre;post][desc]] ^ ^ If we allow this, it's better to allow this in general than just for a specific link type. Hence my proposal to extend link abbreviation to be recognized as new link types when the #+LINK line contains more than two strings. See for example this new link type (or protocol): #+LINK: with-title::%s http://orgmode.org/worg/doc.html# nil org-html-link-with-title [[with-title::org-mode::A link title][org-mode]] org-html-link-with-title would then take care of exporting this as a link like a href=... title=A link titleorg-mode/a. There are really two changes here: 1. extending #+LINK so that the third and fourth strings are recognized as follow and export functions 2. extending #+LINK so that a formatting string in the link abbreviation name is handle later on by those functions. What do you think? -- Bastien
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Here is an ECM.el file, run with emacs -Q triggers the crash: (custom-set-variables '(org-icalendar-store-UID t) ) (setq-default debug-on-error t) (add-to-list 'load-path ~/.emacs.d/el-get/org-mode/lisp) (require 'ox-icalendar) (org-icalendar--combine-files nil ~/Desktop/ECM.org) without org-icalendar-store-UID it works fine. Not sure the option is needed anymore, but at least the crash can be reproduced. BTW my org-mode is at commit 516f0df. HTH, /v -- Vincent Beffara On Thursday, March 7, 2013 at 11:54 , Nicolas Goaziou wrote: Hello, Vincent Beffara vbeff...@ens-lyon.fr (mailto:vbeff...@ens-lyon.fr) writes: Same here. But the error is not in org-caldav, because it is triggered like this: (org-icalendar--combine-files nil ~/Desktop/ECM.org (http://ECM.org)) where ~/Desktop/ECM.org (http://ECM.org) is a file with nothing but one headline. I cannot reproduce it. Maybe a larger backtrace would help. Regards, -- Nicolas Goaziou
Re: [O] org-exp-bibtex missing in git?
Hi Bastien, On Thu, Mar 7, 2013 at 6:16 AM, Bastien b...@altern.org wrote: I want to allow adding link protocols (what I called adding link types) from #+LINK. Hmm. I think I am beginning to understand your motivation for this. IIUC your proposal introduces some syntactic glue here: [[type:key;pre;post][desc]] ^ ^ If we allow this, it's better to allow this in general than just for a specific link type. Hence my proposal to extend link abbreviation to be recognized as new link types when the #+LINK line contains more than two strings. Will this be general enough, though? HTML links can have a target in addition to a title. What if we used a key/value syntax? Something like: [[type:address;key1=value1,key2=value2][description]] The key/value pairs could be handled by the parser, and passed to the link export function as an additional argument (or somehow stored in one of the plists that gets shuffled around). Then org-html-link would have to learn how to handle title, target, and alt properties (the latter for images), as well as perhaps class (for CSS styles). I think there was a thread in the past couple weeks, wherein it came to light that it's not possible presently to uniquely associate an alt text with an image link (but I could be misremembering, I didn't pay very close attention); this would fix that issue as well. org-bib-link would handle pre and post keywords. (Obviously, the delimiters for this syntax would have to be chosen carefully: semicolon and comma may not be the best choices.) Then, it could be possible to have a keyword (perhaps LINK, but perhaps PROTOCOL to decrease ambiguity) that behaves like a BIND for org-link-protocols. That is in the document #+PROTOCOL: foo org-follow-foo org-export-foo would be equivalent to the following lisp (org-add-link-type foo #'org-follow-foo #'org-export-foo) This still doesn't meet your desideratum of being able to specify new syntaxes on the fly in a #+LINK keyword. But one still has to write lisp on your proposal (the org-html-link-with-title function), so it just comes down to whether the customization goes in the document or in the lisp. (Which is ultimately a matter of taste, although my impression is that one of the themes of the switch to the new exporter has been to constrain the syntax and provide richer interfaces at the lisp level for customizing behavior.) Does that sound like a sensible proposal? It has grown a bit beyond the original let's have bibliographies motivation, but I hope that it facilitates that while also being helpful more broadly. Aaron
Re: [O] [new exporter] Captions for tables made by source blocks
I wasn't clear. By naming the results, I mean that you must provide
your source block a #+NAME: something attribute, so the generated
table gets a #+RESULTS: something attribute.
There is something strange happening. Cross-references to captions of
tables that are produced thus get exported to latex as
\texttt{something} rather than as \ref{something}.
Am not able to figure out what have I missed up. It was working fine
yesterday but then [perhaps] I did something.
Vikas
Re: [O] [new exporter] Captions for tables made by source blocks
Vikas Rawal vikasli...@agrarianresearch.org writes:
I wasn't clear. By naming the results, I mean that you must provide
your source block a #+NAME: something attribute, so the generated
table gets a #+RESULTS: something attribute.
There is something strange happening. Cross-references to captions of
tables that are produced thus get exported to latex as
\texttt{something} rather than as \ref{something}.
Am not able to figure out what have I missed up. It was working fine
yesterday but then [perhaps] I did something.
Could you provide an ECM?
Regards,
--
Nicolas Goaziou
Re: [O] org-caldav can't find org-prepare-agenda-buffers
Vincent Beffara vbeff...@ens-lyon.fr writes: Here is an ECM.el file, run with emacs -Q triggers the crash: (custom-set-variables '(org-icalendar-store-UID t) ) (setq-default debug-on-error t) (add-to-list 'load-path ~/.emacs.d/el-get/org-mode/lisp) (require 'ox-icalendar) (org-icalendar--combine-files nil ~/Desktop/ECM.org) without org-icalendar-store-UID it works fine. Not sure the option is needed anymore, but at least the crash can be reproduced. BTW my org-mode is at commit 516f0df. The problem should be fixed in master. Could anyone confirm it? Thank you for reporting this problem. Regards, -- Nicolas Goaziou
Re: [O] org-exp-bibtex missing in git?
Bastien b...@altern.org writes: Hi Aaron, I now see where you and Eric go and this is good! Here is a revised suggestion, allowing to add link types from withing the #+LINK keyword. 1. Allow more syntax for #+LINK: #+LINK: bib;%s;%s file:my.bib::%s org-bib-follow-link org-bib-export-link If `org-bib-follow-link' is nil, it'll follow [[bib:my.bib::key][key]] like it does right now, jumping to the key line in the my.bib file. If `org-bib-follow-link' is non-nil, it will operate on [[bib:my.bib::key;prenote;postnote][key]] and find the correct key. If `org-bib-export-link' is non-nil, it will operate on [[bib:my.bib::key;prenote;postnote][key]] and export it correctly depending on the backend. The change required for the exporter is to let `org-bib-follow-link' and `org-bib-export-link' operate on [[bib::my.bib::key;prenote;postnote]], not on the expanded link. IOW, link expansion should happen within the backend export routines, treating abbreviated links with formatting strings (aka bib;%s;%s) in a special way. I see two advantages: - adding new types will be easier -- e.g.: #+LINK: cite file:my.bib::%s org-bib-follow-link org-bib-export-link - users can decide what syntactic glue they want to their abbreviated links (using ; or another separator). Nicolas, do you think it is feasible/good to delay link expansion till the backend knows whether the abbreviated link is associated to follow/export function that would understand formatting strings in the abbreviated form? I think that if we ever implement a bibliography/citations handlers, they should be first class objects in Org syntax (like footnotes). Overloading link syntax would, IMO, be wrong in that case. Also, link abbrevs and link protocol handlers are meant for the end-user, not for official syntax. I suggest to avoid using link syntax for citations altogether, but if we do, the citation must not depend on an user-defined function. The whole syntax must be attached to the link. Therefore, I agree that link syntax needs to be extended. I'm thinking in particular about per-link export properties. Adding in separator in the path part is an interesting idea, as long as it isn't a string widely used in paths. In a nutshell, my POV is: - we should avoid overloading #+LINK syntax and overusing link-abbrevs. - citations, if implemented globally, deserve their own syntax. - changing the general link type to: [[PROTOCOL:PATH/SEP/OPTIONS][DESCRIPTION]] is fine. Regards, -- Nicolas Goaziou
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
I have to admit I'm not yet experienced enough with org mode to know about the new exporter versus the old. I've been trying to ignore the conversations on the list about the new exporter, since, at least until now, whatever org mode was doing was what I needed it to do. I have org mode 7.9.3f. Does that mean I am using any particular exporter? How do I tell which exporter I am using with C-c C-e d ? I will try C-c C-e C-s l o with my little test file next time I am on the Windows system where I am having the problem. Thanks. --Chris On Thu, Mar 7, 2013 at 3:42 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Christopher W. Ryan cr...@binghamton.edu writes: Well, with the little test file I initially posted, things worked OK with org version 7.9.3f. But things are bit more complicated: [...] Put cursor on * Hello above and then C-c C-e 1 d Are you sure you are using the new exporter? This binding doesn't work for me but did work for the old exporter. The equivalent in the new exporter would be C-c C-e C-s l o, I believe. Your configuration must be mixing up old and new exporters and, believe me, you're not the only one in this situation. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] org-caldav can't find org-prepare-agenda-buffers
It doesn't crash anymore, thanks! OTOH when I ran org-caldav, it removed everything from the online calendar, and it won't put anything back there ... -- Vincent Beffara On Thursday, March 7, 2013 at 13:56 , Nicolas Goaziou wrote: Vincent Beffara vbeff...@ens-lyon.fr (mailto:vbeff...@ens-lyon.fr) writes: Here is an ECM.el file, run with emacs -Q triggers the crash: (custom-set-variables '(org-icalendar-store-UID t) ) (setq-default debug-on-error t) (add-to-list 'load-path ~/.emacs.d/el-get/org-mode/lisp) (require 'ox-icalendar) (org-icalendar--combine-files nil ~/Desktop/ECM.org (http://ECM.org)) without org-icalendar-store-UID it works fine. Not sure the option is needed anymore, but at least the crash can be reproduced. BTW my org-mode is at commit 516f0df. The problem should be fixed in master. Could anyone confirm it? Thank you for reporting this problem. Regards, -- Nicolas Goaziou
Re: [O] org-caldav can't find org-prepare-agenda-buffers
OTOH when I ran org-caldav, it removed everything from the online calendar, and it won't put anything back there ... Mmmkay, something weird is happening. I create a headline with a date, and call org-caldav. An UID is created, and the file looks like this: *** Gayet, Damien : Une majoration de l'espérance des nombres de Betti :PROPERTIES: :ID: BD783419-0D10-4B88-8540-730ACF03B42E :END: 2013-03-06 Wed 14:00 So far so good. But on trying to sync, I get the error that Could not find UID TS1-BD783419-0D10-4B88-8540-730ACF03B42E. (Which is the UID in the generated ICS file.) So now, iCalendar export works, all that remains is fixing the sync code in org-caldav ... /v -- Vincent Beffara On Thursday, March 7, 2013 at 13:56 , Nicolas Goaziou wrote: Vincent Beffara vbeff...@ens-lyon.fr (mailto:vbeff...@ens-lyon.fr) writes: Here is an ECM.el file, run with emacs -Q triggers the crash: (custom-set-variables '(org-icalendar-store-UID t) ) (setq-default debug-on-error t) (add-to-list 'load-path ~/.emacs.d/el-get/org-mode/lisp) (require 'ox-icalendar) (org-icalendar--combine-files nil ~/Desktop/ECM.org (http://ECM.org)) without org-icalendar-store-UID it works fine. Not sure the option is needed anymore, but at least the crash can be reproduced. BTW my org-mode is at commit 516f0df. The problem should be fixed in master. Could anyone confirm it? Thank you for reporting this problem. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] Captions for tables made by source blocks
Could you provide an ECM? See the attached dummy file. Vikas #+STARTUP: hidestars #+TITLE: Title of the paper #+DATE: #+AUTHOR: name of author #+COLUMNS: %25ITEM %TAGS %PRIORITY %T #+property: exports results #+property: session fbi #+OPTIONS: H:2 toc:nil num:1 #+LaTeX_CLASS: article * Introduction Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. * Levels and variation in farm business incomes ** Annual income from crop production + For a large majority of cultivating households in all the villages, crop production provided only meagre incomes. Table [[crop-median]] shows median incomes from crop production in each village. The Table shows that the median annual income was only Rs. 1290 per household in Mahatwar, a village where agriculture was primarily rainfed. Even in Ananthavaram, where Xx of the gross cropped area was irrigated, annual income was only Rs. 2654 per household. In Warwat Khanderao, a cotton-growing village in Vidarbha region, median income from crop production was only Rs. 14755 per household. In Nimshirgaon, where sugarcane was the most important crop, the median income from crop production was only Rs. 9991 per household. #+CAPTION: Median and ninth decile annual income from crop production, by village (2005-06 prices) #+NAME: crop-median #+BEGIN_SRC R :results value :colnames yes :hline yes c(1:5)-a data.frame(name=paste(a,a),id=a,id2=a^2)-b b #+END_SRC #+CAPTION: Median and ninth decile annual income from crop production, by village (2005-06 prices) #+RESULTS: crop-median | name | id | id2 | |--++-| | a 1 | 1 | 1 | | a 2 | 2 | 4 | | a 3 | 3 | 9 | | a 4 | 4 | 16 | | a 5 | 5 | 25 |
Re: [O] org-caldav can't find org-prepare-agenda-buffers
... sorry for replying to myself like this - here is a patch that seems to work: diff --git a/org-caldav.el b/org-caldav.el index 0383366..14cca8f 100644 --- a/org-caldav.el +++ b/org-caldav.el @@ -786,7 +786,7 @@ is no UID to rewrite. Returns the UID. ((re-search-forward ^UID:\\(orgsexp-[0-9]+\\) nil t) ;; This is a sexp entry, so do nothing. (match-string 1)) - ((re-search-forward ^UID:\\(\\s-*\\)\\([A-Z][A-Z]-\\)?\\(.+\\)\\s-*$ + ((re-search-forward ^UID:\\(\\s-*\\)\\([A-Z][A-Z][0-9]?-\\)?\\(.+\\)\\s-*$ nil t) (when (match-string 1) (replace-match nil nil nil 1)) I made a pull request to org-caldav, hoping I got it right! /v -- Vincent Beffara On Thursday, March 7, 2013 at 14:31 , Vincent Beffara wrote: OTOH when I ran org-caldav, it removed everything from the online calendar, and it won't put anything back there ... Mmmkay, something weird is happening. I create a headline with a date, and call org-caldav. An UID is created, and the file looks like this: *** Gayet, Damien : Une majoration de l'espérance des nombres de Betti :PROPERTIES: :ID: BD783419-0D10-4B88-8540-730ACF03B42E :END: 2013-03-06 Wed 14:00 So far so good. But on trying to sync, I get the error that Could not find UID TS1-BD783419-0D10-4B88-8540-730ACF03B42E. (Which is the UID in the generated ICS file.) So now, iCalendar export works, all that remains is fixing the sync code in org-caldav ... /v -- Vincent Beffara On Thursday, March 7, 2013 at 13:56 , Nicolas Goaziou wrote: Vincent Beffara vbeff...@ens-lyon.fr (mailto:vbeff...@ens-lyon.fr) writes: Here is an ECM.el file, run with emacs -Q triggers the crash: (custom-set-variables '(org-icalendar-store-UID t) ) (setq-default debug-on-error t) (add-to-list 'load-path ~/.emacs.d/el-get/org-mode/lisp) (require 'ox-icalendar) (org-icalendar--combine-files nil ~/Desktop/ECM.org (http://ECM.org)) without org-icalendar-store-UID it works fine. Not sure the option is needed anymore, but at least the crash can be reproduced. BTW my org-mode is at commit 516f0df. The problem should be fixed in master. Could anyone confirm it? Thank you for reporting this problem. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] Captions for tables made by source blocks
Could you provide an ECM? Please see the attached file. Vikas #+STARTUP: hidestars #+TITLE: Title of the paper #+DATE: #+AUTHOR: name of author #+COLUMNS: %25ITEM %TAGS %PRIORITY %T #+property: exports results #+property: session fbi #+OPTIONS: H:2 toc:nil num:1 #+LaTeX_CLASS: article * Introduction Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. * Levels and variation in farm business incomes ** Annual income from crop production + For a large majority of cultivating households in all the villages, crop production provided only meagre incomes. Table [[crop-median]] shows median incomes from crop production in each village. The Table shows that the median annual income was only Rs. 1290 per household in Mahatwar, a village where agriculture was primarily rainfed. Even in Ananthavaram, where Xx of the gross cropped area was irrigated, annual income was only Rs. 2654 per household. In Warwat Khanderao, a cotton-growing village in Vidarbha region, median income from crop production was only Rs. 14755 per household. In Nimshirgaon, where sugarcane was the most important crop, the median income from crop production was only Rs. 9991 per household. #+CAPTION: Median and ninth decile annual income from crop production, by village (2005-06 prices) #+NAME: crop-median #+BEGIN_SRC R :results value :colnames yes :hline yes c(1:5)-a data.frame(name=paste(a,a),id=a,id2=a^2)-b b #+END_SRC #+CAPTION: Median and ninth decile annual income from crop production, by village (2005-06 prices) #+RESULTS: crop-median | name | id | id2 | |--++-| | a 1 | 1 | 1 | | a 2 | 2 | 4 | | a 3 | 3 | 9 | | a 4 | 4 | 16 | | a 5 | 5 | 25 |
Re: [O] org-exp-bibtex missing in git?
Hi Nicolas, I like Aaron's idea (maybe others proposed this too) of having parameters in links: [[file:my.bib::keyprenote=my prenotepostnote=my postnote]] [[http://perdu.comtitle=You're lost?]] This is orthogonal to my proposal of extending #+LINK to be able to define new protocols (by allowing to add a follow and an export functions); and this is orthogonal to whether link abbrevs can have more than one formatting string %s. We would just need to pass the parameters as keywords to the export function, either the default one, either the defined by the protocol. E.g., the first link would be represented by the parser like this: (:type file :path my.bib :raw-link file:orgmode.org::test2 :application nil :search-option test2 :parameters '(:title You're lost) :begin 63 :end 97 :contents-begin 90 :contents-end 95 :post-blank 0 :parent #3) Then org-html-link would get the parameters with (org-element-property :parameters link) = '(:title You're lost) I think this is general and useful. If we implement this, it would be nice to extend link abbrevs to support multiple formatters in `org-link-abbrev-alist'. #+LINK: citeA file:my.bib::%sprenote=%spostnote=%s And this would spare us for the need of another object dedicated to bibliographic citations: [[citeA::keyprenote=my notepostnote=my note]] What do you think? -- Bastien
Re: [O] [new exporter] Captions for tables made by source blocks
Vikas Rawal vikasli...@agrarianresearch.org writes: Could you provide an ECM? I have always used something along these lines #+label: crop-median just before the table to define the target. This works for your ECM. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Christopher W Ryan cr...@binghamton.edu writes: I have to admit I'm not yet experienced enough with org mode to know about the new exporter versus the old. I've been trying to ignore the conversations on the list about the new exporter, since, at least until now, whatever org mode was doing was what I needed it to do. I have org mode 7.9.3f. Does that mean I am using any particular exporter? How do I tell which exporter I am using with C-c C-e d ? I believe that, if you are using 7.9.3f, you should be using the new exporter. However, the key bindings you mentioned in the previous posting indicated that you were accessing the old exporter. This may mean that you have a confused configuration (easy to do at the moment due to the transition taking place between old and new exporters). One way to find out what you are using is to check what C-c C-e is bound to: C-h c C-c C-e. If this says org-export-dispatch, it is the new one. The old one, I believe, was bound to org-export alone. The former gives a two level selection mechanism (e.g. you choose l for LaTeX first and then another letter for actual target for the export, e.g. tex vs pdf). The latter uses only one letter to accomplish both selections. I hope this makes sense. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] Org documentation patches party next week on IRC?
Bastien b...@altern.org writes: Hi all, with the advent of Org 8.0, a special effort needs to be made to keep the manual and Worg updated. I thought it would be nice to gather on IRC and focus on this together for a few hours, so here is a doodle: http://doodle.com/s7fhueeifaex54t8 Also, I'll to discuss with people I only know by email... Thanks in advance for your help! Bastien, my schedule is such that I would find it difficult to commit to any specific time. However, I will strive to update the beamer example and tutorial for the new exporter by mid next week; I had already started on it but got sidetracked by my recent move back from Australia to the UK... If I get a chance, I will join in on IRC when you have all chosen a time slot. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
[O] [new exporter] feature request: BEGIN_LATEX_HEADER
Prompted by Nicolas's recent addition of the LATEX_HEADER_EXTRA
directive, I would like to request another related feature. Just as we
have the related LATEX and BEGIN_LATEX directives, I would like to see a
BEGIN_LATEX_HEADER directive for multi-line LATEX_HEADER lines:
#+begin_src org
#+BEGIN_LATEX_HEADER
\usepackage{tikz}
\usepackage[british]{babel}
\newcommand{\esf}[1]{\footnote{#1}\marginpar{\fbox{\thefootnote}}
#+END_LATEX_HEADER
#+end_src
(example taken from a recent org file).
Not urgent, of course, but it would make it easier to write this type of
content, especially if it were fontified as well... ;-)
Thanks,
eric
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Thanks John. I will post the babel-related part of my .emacs when I am back at the office, on the computer in question. Could you try exporting just the * Hello subtree with C-c C-e 1 p ? That's where I am experiencing the trouble, rather than with exporting the whole document with C-c C-e p. --Chris On Thu, Mar 7, 2013 at 10:00 AM, John Hendy jw.he...@gmail.com wrote: On Thu, Mar 7, 2013 at 7:13 AM, Christopher W Ryan cr...@binghamton.edu wrote: I have to admit I'm not yet experienced enough with org mode to know about the new exporter versus the old. I've been trying to ignore the conversations on the list about the new exporter, since, at least until now, whatever org mode was doing was what I needed it to do. I have org mode 7.9.3f. Does that mean I am using any particular exporter? How do I tell which exporter I am using with C-c C-e d ? I will try C-c C-e C-s l o with my little test file next time I am on the Windows system where I am having the problem. Cursor on * Hello, C-c C-e p and I get the attached (seems to work). Have not removed ** Big foo. I'm using the old exporter. Can you post your babel-related .emacs section? John Thanks. --Chris On Thu, Mar 7, 2013 at 3:42 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Christopher W. Ryan cr...@binghamton.edu writes: Well, with the little test file I initially posted, things worked OK with org version 7.9.3f. But things are bit more complicated: [...] Put cursor on * Hello above and then C-c C-e 1 d Are you sure you are using the new exporter? This binding doesn't work for me but did work for the old exporter. The equivalent in the new exporter would be C-c C-e C-s l o, I believe. Your configuration must be mixing up old and new exporters and, believe me, you're not the only one in this situation. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] contrib directory not present in orgmode.org/elpa
Achim Gratz strom...@nexgo.de writes: Carmine Casciato writes: I downloaded the org-plus-contrib-20130304 package from the org-mode elpa repo, and it does not seem to contain the contrib directory. Should I be looking elsewhere for this? There is no contrib directory in this archive because ELPA packages can not (easily) contain subdirectories. The files from contrib have been integrated into the package instead (compare to the contents of the org package if you need to be convinced). Regards, Achim. I couldn't locate the ditaa.jar file in the package, that was the main reason for my asking. Thanks, Carmine
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
On Thu, Mar 7, 2013 at 9:54 AM, Christopher W Ryan cr...@binghamton.edu wrote: Thanks John. I will post the babel-related part of my .emacs when I am back at the office, on the computer in question. Could you try exporting just the * Hello subtree with C-c C-e 1 p ? That's where I am experiencing the trouble, rather than with exporting the whole document with C-c C-e p. Yikes, and duh. I completely forgot the whole point. I do *not* get the right behavior! Odd, as I thought I had been with your original post. I'm on 7.9.3e. C-c C-e is bound to =org-export= for me (old exporter). John --Chris On Thu, Mar 7, 2013 at 10:00 AM, John Hendy jw.he...@gmail.com wrote: On Thu, Mar 7, 2013 at 7:13 AM, Christopher W Ryan cr...@binghamton.edu wrote: I have to admit I'm not yet experienced enough with org mode to know about the new exporter versus the old. I've been trying to ignore the conversations on the list about the new exporter, since, at least until now, whatever org mode was doing was what I needed it to do. I have org mode 7.9.3f. Does that mean I am using any particular exporter? How do I tell which exporter I am using with C-c C-e d ? I will try C-c C-e C-s l o with my little test file next time I am on the Windows system where I am having the problem. Cursor on * Hello, C-c C-e p and I get the attached (seems to work). Have not removed ** Big foo. I'm using the old exporter. Can you post your babel-related .emacs section? John Thanks. --Chris On Thu, Mar 7, 2013 at 3:42 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Christopher W. Ryan cr...@binghamton.edu writes: Well, with the little test file I initially posted, things worked OK with org version 7.9.3f. But things are bit more complicated: [...] Put cursor on * Hello above and then C-c C-e 1 d Are you sure you are using the new exporter? This binding doesn't work for me but did work for the old exporter. The equivalent in the new exporter would be C-c C-e C-s l o, I believe. Your configuration must be mixing up old and new exporters and, believe me, you're not the only one in this situation. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
Re: [O] [new exporter] Captions for tables made by source blocks
Nicolas Goaziou writes: For the same reason, caption here applies to the dynamic block, not to its contents. This seems to be a common enough mistake and it is currently impossible to put captions and other arguments on results blocks save with yet another source block that produces the correct org code (well you can put the headers there after the result has been generated, but then you have to delete all that stuff before generating a new result). Would it be possible to either change the insertion of the results so that the user has a chance to put any options before the place where it should go or (I'm not fond of that idea, but I'll put it out there anyway) have yet more option arguments (along the lines of #+RESULTS_HEADER…) that will be transferred to the results block along with the actual result? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] [new exporter] Captions for tables made by source blocks
Vikas Rawal vikasli...@agrarianresearch.org writes:
Could you provide an ECM?
Please see the attached file.
I cannot reproduce it, i.e. I get \ref{crop-median} in the output.
Regards,
--
Nicolas Goaziou
Re: [O] org-exp-bibtex missing in git?
Bastien writes: I like Aaron's idea (maybe others proposed this too) of having parameters in links: We've had some of this discussion about two years ago IIRC, so here I am again: there's an internet standard for this kind of thing, it's called URN/URI. If we adhere to this, we can at least hope for interoperability and outside tool support. I don't think we should try to invent something that is almost, but not entirely unlike the standard. (with apologies to the late Douglas N. Adams) Back to citations, I don't know if an URI scheme for citations already exists. Citation tools are complicated because nobody really agrees on what they should do exactly and there are many different citation styles. The common ground is that there is a key/handle for the citation itself and then different fields for different types of citations to pull the various bits of information together into an actual citation, in whatever order and form that is prescribed. If you're writing for the Journal of Irreproducible Results and the Magazine of Things that go Boom!, you'll likely have just two definitions that you will somehow reference in the respective articles. Here's what Wikipedia says is around, and that surely is only the tip of the iceberg: https://en.wikipedia.org/wiki/Comparison_of_reference_management_software If there's no support for BibTeX however, you probably shouldn't play at all. BibTeX itself has a long and colored past: https://en.wikipedia.org/wiki/BibTeX That it is still used should be an indication that its basic principles are sound. The most interesting part of this history from the Org/Emacs perspective is perhaps CL-BibTeX. At least Bibsonomy.org has several response formats for queries including JSON (and BibTeX, of course) and lets you ask for the whole database entry and a pre-formatted citation. I haven't payed close attention to Zotero, but I think they are doing something similar. So it might be possible today to simply (or not so simply) have a reference scheme and have all the database and formatting work done by one of these (or more likely several of them) services. But even coming up with a good reference scheme (the links with parameters part) for this will be a sizeable project. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] [RFC] Org version of the Org manual
Aloha Yagnesh Raghava Yakkala, Yagnesh Raghava Yakkala h...@yagnesh.org writes: Hello Thomas, These instructions assume more knowledge than I have. Could you be more specific about in the Org worktree? Should I create a branch where I do this? Or, should I put this in one of the upstream branches and arrange to push it into the Org repo? In any case, can you suggest a location? /contrib? /doc? IIUC, Achim means, cd /source/directory/of/org-mode git clone http:github.com/tsdye/orgmanual # or your most updated repo of orgmanual git submodule add orgmanual# optional git commit -m Commit Message # optional cd orgmanual Create_Makefile# [1] ln -s ../doc/org-version.inc . cd .. update_local.mk_file # [2] make orgmanual For me also texi2dvi failed, but orgmanual.info is generated fine and looks great. Thanks for the detailed instructions, which helped me greatly. The orgmanual now creates a pdf file, too, but one lacking the indexes and with links that look like they need another run through TeX. When I'm done running `make orgmanual', my directory is very neat and tidy, which is nice, but I'll need to look at the auxiliary files used to build the indexes, so I can debug. Should I run texi2dvi outside `make orgmanual', or would some other workflow better fit my needs? Suggestions warmly welcomed. Thanks again for your help. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Eric S Fraga writes: I believe that, if you are using 7.9.3f, you should be using the new exporter. The question to answer is whether he's using the maint or the master branch. I'd think the Op is using the 7.9.3f release, i.e. maint. Bastien, I think it would make sense to clear up this confusion by tagging 8dd2bfc291 with version 7.9.9 or 8.0-pre or something like that (must be an annotated tag, of course). That'll help to easier determine who's using the new and the old exporter. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [RFC] Org version of the Org manual
Thomas S. Dye writes: The orgmanual now creates a pdf file, too, but one lacking the indexes and with links that look like they need another run through TeX. In that case, texi2dvi and hence make should have signaled an error (I've just pulled from your repo and it does). When I'm done running `make orgmanual', my directory is very neat and tidy, which is nice, but I'll need to look at the auxiliary files used to build the indexes, so I can debug. Add TEXI2PDF+=--tidy at the beginning of orgmanual/Makefile, then look in the orgmanual.t2d directory. Or if you'd rather have all the files in the same directory like before: TEXI2PDF+=--build=local Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [RFC] Org version of the Org manual
Achim Gratz strom...@nexgo.de writes: Thomas S. Dye writes: The orgmanual now creates a pdf file, too, but one lacking the indexes and with links that look like they need another run through TeX. In that case, texi2dvi and hence make should have signaled an error (I've just pulled from your repo and it does). Yes, it signals two errors here: Output written on orgmanual.pdf (269 pages, 1122108 bytes). Transcript written on orgmanual.log. /opt/local/bin/texi2dvi: pdftex exited with bad status, quitting. make[1]: *** [orgmanual.pdf] Error 1 make: *** [orgmanual] Error 2 When I'm done running `make orgmanual', my directory is very neat and tidy, which is nice, but I'll need to look at the auxiliary files used to build the indexes, so I can debug. Add TEXI2PDF+=--tidy at the beginning of orgmanual/Makefile, then look in the orgmanual.t2d directory. There they are, in orgmanual.t2d/pdf/build. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] [RFC] Org syntax (draft)
Hello, As discussed a few days ago, here is a document describing the complete Org syntax as read by the parser. I also added some comments. I am going to put the Org file on Worg, so anyone can update it and fix mistakes. ORG SYNTAX (DRAFT) Table of Contents ─ 1 Headlines and Sections 2 Affiliated Keywords 3 Greater Elements .. 3.1 Greater Blocks .. 3.2 Drawers and Property Drawers .. 3.3 Dynamic Blocks .. 3.4 Footnote Definitions .. 3.5 Inlinetasks .. 3.6 Plain Lists and Items .. 3.7 Tables 4 Elements .. 4.1 Babel Call .. 4.2 Blocks .. 4.3 Clock, Diary Sexp and Planning .. 4.4 Comments .. 4.5 Fixed Width Areas .. 4.6 Horizontal Rules .. 4.7 Keywords .. 4.8 LaTeX Environments .. 4.9 Node Properties .. 4.10 Paragraphs .. 4.11 Table Rows 5 Objects .. 5.1 Entities and LaTeX Fragments .. 5.2 Export Snippets .. 5.3 Footnote References .. 5.4 Inline Babel Calls and Source Blocks .. 5.5 Line Breaks .. 5.6 Links .. 5.7 Macros .. 5.8 Targets and Radio Targets .. 5.9 Statistics Cookies .. 5.10 Subscript and Superscript .. 5.11 Table Cells .. 5.12 Timestamps .. 5.13 Text Markup This document describes and comments Org syntax as it is currently read by its parser (Org Elements) and, therefore, by the export framework. It also includes a few comments on that syntax. A core concept in this syntax is that only headlines and sections are context-free[1][2]. Every other syntactical part only exists within specific environments. Three categories are used to classify these environments: “Greater elements”, “elements”, and “objects”, from the broadest scope to the narrowest. The paragraph is the unit of measurement. An element defines syntactical parts that are at the same level as a paragraph, i.e. which cannot contain or be included in a paragraph. An object is a part that could be included in an element. Greater elements are all parts that can contain an element. Empty lines belong to the largest element ending before them. For example, in a list, empty lines between items belong are part of the item before them, but empty lines at the end of a list belong to the plain list element. Unless specified otherwise, case is not significant. 1 Headlines and Sections A headline is defined as: ╭ │ STARS KEYWORD PRIORITY TITLE TAGS ╰ STARS is a string starting at column 0 and containing at least one asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask' library is loaded). It’s the sole compulsory part of a headline. KEYWORD is a TODO keyword, which have to belong to the list defined in `org-todo-keywords'. Case is significant. PRIORITY is a priority cookie, i.e. a single letter preceded by a hash sign # and enclosed within square brackets. Case is significant. TITLE can be made of any character but a new line. Though, it will match after every other part have been matched. TAGS is made of words containing any alpha-numeric character, underscore, at sign, hash sign or percent sign, and separated with colons. Examples of valid headlines include: ╭ │ * │ │ ** DONE │ │ *** Some e-mail │ │ TODO [#A] COMMENT Title :tag:a2%: ╰ If the first word appearing in the title is `org-comment-keyword', the headline will be considered as “commented”. If that first word is `org-quote-string', it will be considered as “quoted”. In both situations, case is significant. If its title is `org-footnote-section', it will be considered as a “footnote section”. Case is significant. If `org-archive-tag' is one of its tags, it will be considered as “archived”. Case is significant. A headline contains directly at most one section, followed by any number of headlines. Only a section can contain another section. A section contains directly any greater element or element. Only a headline can contain a section. As an exception, text before the first headline in the document also belongs to a section. In a quoted headline contains a section, the latter will be considered as a “quote section”. As an example, consider the following document: ╭ │ An introduction. │ │ * A Headline │ │ Some text. │ │ ** Sub-Topic 1 │ │ ** Sub-Topic 2 │ │ *** Additional entry │ │ ** QUOTE Another Sub-Topic │ │Some other text. ╰ Its internal structure could be summarized as: ╭ │ (document │ (section) │ (headline │ (section) │ (headline) │ (headline │(headline)) │ (headline │(quote-section ╰ 2 Affiliated Keywords ═ With the exception of [inlinetasks], [items], [planning], [clocks], [node properties] and [table rows], every other element type can be assigned attributes. This is done by adding specific keywords, named
Re: [O] [RFC] Org syntax (draft)
woow, this is awesome Nicolas, thank you! - Carsten On 7.3.2013, at 21:37, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, As discussed a few days ago, here is a document describing the complete Org syntax as read by the parser. I also added some comments. I am going to put the Org file on Worg, so anyone can update it and fix mistakes. ORG SYNTAX (DRAFT) Table of Contents ─ 1 Headlines and Sections 2 Affiliated Keywords 3 Greater Elements .. 3.1 Greater Blocks .. 3.2 Drawers and Property Drawers .. 3.3 Dynamic Blocks .. 3.4 Footnote Definitions .. 3.5 Inlinetasks .. 3.6 Plain Lists and Items .. 3.7 Tables 4 Elements .. 4.1 Babel Call .. 4.2 Blocks .. 4.3 Clock, Diary Sexp and Planning .. 4.4 Comments .. 4.5 Fixed Width Areas .. 4.6 Horizontal Rules .. 4.7 Keywords .. 4.8 LaTeX Environments .. 4.9 Node Properties .. 4.10 Paragraphs .. 4.11 Table Rows 5 Objects .. 5.1 Entities and LaTeX Fragments .. 5.2 Export Snippets .. 5.3 Footnote References .. 5.4 Inline Babel Calls and Source Blocks .. 5.5 Line Breaks .. 5.6 Links .. 5.7 Macros .. 5.8 Targets and Radio Targets .. 5.9 Statistics Cookies .. 5.10 Subscript and Superscript .. 5.11 Table Cells .. 5.12 Timestamps .. 5.13 Text Markup This document describes and comments Org syntax as it is currently read by its parser (Org Elements) and, therefore, by the export framework. It also includes a few comments on that syntax. A core concept in this syntax is that only headlines and sections are context-free[1][2]. Every other syntactical part only exists within specific environments. Three categories are used to classify these environments: “Greater elements”, “elements”, and “objects”, from the broadest scope to the narrowest. The paragraph is the unit of measurement. An element defines syntactical parts that are at the same level as a paragraph, i.e. which cannot contain or be included in a paragraph. An object is a part that could be included in an element. Greater elements are all parts that can contain an element. Empty lines belong to the largest element ending before them. For example, in a list, empty lines between items belong are part of the item before them, but empty lines at the end of a list belong to the plain list element. Unless specified otherwise, case is not significant. 1 Headlines and Sections A headline is defined as: ╭ │ STARS KEYWORD PRIORITY TITLE TAGS ╰ STARS is a string starting at column 0 and containing at least one asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask' library is loaded). It’s the sole compulsory part of a headline. KEYWORD is a TODO keyword, which have to belong to the list defined in `org-todo-keywords'. Case is significant. PRIORITY is a priority cookie, i.e. a single letter preceded by a hash sign # and enclosed within square brackets. Case is significant. TITLE can be made of any character but a new line. Though, it will match after every other part have been matched. TAGS is made of words containing any alpha-numeric character, underscore, at sign, hash sign or percent sign, and separated with colons. Examples of valid headlines include: ╭ │ * │ │ ** DONE │ │ *** Some e-mail │ │ TODO [#A] COMMENT Title :tag:a2%: ╰ If the first word appearing in the title is `org-comment-keyword', the headline will be considered as “commented”. If that first word is `org-quote-string', it will be considered as “quoted”. In both situations, case is significant. If its title is `org-footnote-section', it will be considered as a “footnote section”. Case is significant. If `org-archive-tag' is one of its tags, it will be considered as “archived”. Case is significant. A headline contains directly at most one section, followed by any number of headlines. Only a section can contain another section. A section contains directly any greater element or element. Only a headline can contain a section. As an exception, text before the first headline in the document also belongs to a section. In a quoted headline contains a section, the latter will be considered as a “quote section”. As an example, consider the following document: ╭ │ An introduction. │ │ * A Headline │ │ Some text. │ │ ** Sub-Topic 1 │ │ ** Sub-Topic 2 │ │ *** Additional entry │ │ ** QUOTE Another Sub-Topic │ │Some other text. ╰ Its internal structure could be summarized as: ╭ │ (document │ (section) │ (headline │ (section) │ (headline) │ (headline │(headline)) │ (headline │(quote-section ╰ 2 Affiliated Keywords
Re: [O] [new exporter] Captions for tables made by source blocks
Hello, Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou writes: For the same reason, caption here applies to the dynamic block, not to its contents. This seems to be a common enough mistake and it is currently impossible to put captions and other arguments on results blocks save with yet another source block that produces the correct org code (well you can put the headers there after the result has been generated, but then you have to delete all that stuff before generating a new result). It's very easy to have a caption on the generated output: name the code. Hence, the following code block: #+NAME: calculation #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC will produce: #+RESULTS: calculation 2 If you add a caption to the results, like: #+CAPTION: Basic arithmetic #+RESULTS: calculation 2 you can update the source block without ever needing to remove the caption. At some point, it would be nice if Babel could find captioned anonymous results (so you wouldn't even have to name the block). I'll have a look at it. But meanwhile, this solution is sufficient. Regards, -- Nicolas Goaziou
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Hello,
Eric S Fraga e.fr...@ucl.ac.uk writes:
Prompted by Nicolas's recent addition of the LATEX_HEADER_EXTRA
directive, I would like to request another related feature. Just as we
have the related LATEX and BEGIN_LATEX directives, I would like to see a
BEGIN_LATEX_HEADER directive for multi-line LATEX_HEADER lines:
#+begin_src org
#+BEGIN_LATEX_HEADER
\usepackage{tikz}
\usepackage[british]{babel}
\newcommand{\esf}[1]{\footnote{#1}\marginpar{\fbox{\thefootnote}}
#+END_LATEX_HEADER
#+end_src
(example taken from a recent org file).
Not urgent, of course, but it would make it easier to write this type of
content, especially if it were fontified as well... ;-)
There are already many ways to handle latex header. `org-latex-classes',
setupfile keywords, include keywords, latex_header,
latex_header_extra...
Adding one more is not without consequences. For example, where should
it go? After latex_header values? Before? Would the location be
configurable in `org-latex-classes'? What placeholder to use?
I admit I'm not very keen on this idea. Not because of the coding work,
it would be around 10 loc, but because of syntax fester.
Regards,
--
Nicolas Goaziou
Re: [O] org-export raises stringp nil error
Assuming this is a recent regression, then if anyone from Org wants this fixed in Emacs 24.3, they should investigate this very quickly and suggest the _minimum_ change. See also the possibly related, unanswered http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg00028.html Lele Gaifax wrote: Using current emacs-snapshot[1], trying to export even the following very simple file: # -*- mode: org; coding: utf-8 -*- * hi http://www.gnu.org/ to HTML results in this error: org-export-protect-sub-super: Wrong type argument: stringp, nil with the following traceback: string-match(\\([^]\\)\\([_^]\\) nil) org-export-protect-sub-super(nil) org-export-normalize-links() org-export-preprocess-string(#(# -*- mode: org; coding: utf-8 -*-\n\n* hi\n\n http://www.gnu.org/\n; 0 34 (fontified t font-lock-fontified t face font-lock-comment-face) 34 36 (fontified t) 36 38 (fontified t face org-level-1) 38 40 (fontified t face org-level-1) 40 44 (fontified t) 44 62 (fontified t org-no-flyspell t mouse-face highlight face org-link keymap (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 . org-open-at-mouse))) 62 63 (fontified t org-no-flyspell t mouse-face highlight face org-link keymap (keymap (follow-link . mouse-face) (mouse-3 . org-find-file-at-mouse) (mouse-2 . org-open-at-mouse)) rear-nonsticky (mouse-face highlight keymap invisible intangible help-echo org-linked-text htmlize-link)) 63 64 (fontified t)) :emph-multiline t :for-backend html :skip-before-1st-heading nil :drawers nil :todo-keywords t :tasks t :tags not-in-toc :priority nil :footnotes t :timestamps t :archived-trees headline :select-tags (export) :exclude-tags (noexport) :add-text nil :LaTeX-fragments t) org-export-as-html(nil) call-interactively(org-export-as-html) org-export(nil) call-interactively(org-export nil nil) command-execute(org-export) If this isn't already known/fixed, should I report it as a bug? And eventually, on Emacs itself or on org-mode? thanks in advance, bye, lele. [1] GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-03-04 on dex, modified by Debian
Re: [O] [new exporter] Captions for tables made by source blocks
Nicolas Goaziou writes: It's very easy to have a caption on the generated output: name the code. Hence, the following code block: #+NAME: calculation #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC will produce: #+RESULTS: calculation 2 If you add a caption to the results, like: #+CAPTION: Basic arithmetic #+RESULTS: calculation 2 you can update the source block without ever needing to remove the caption. Great. I could swear the last time I was trying this it would add a new result block on top of the old one, but I may have changed the name inbetween. It would still be nice (I think) if an unnamed source block would simply replace the next unnamed result block if there is one. At some point, it would be nice if Babel could find captioned anonymous results (so you wouldn't even have to name the block). I'll have a look at it. But meanwhile, this solution is sufficient. Oh absolutely. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] org-exp-bibtex missing in git?
Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: I like Aaron's idea (maybe others proposed this too) of having parameters in links: We've had some of this discussion about two years ago IIRC, so here I am again: there's an internet standard for this kind of thing, it's called URN/URI. I'm all for following established standards, but I'm not sure what is the concrete proposal here. Do you mean using something like this [[file:my.bibkey=key;prenote=note1;postnote=note2][key]] for the file: protocol, where key, prenote and postnote would be parsed as keywords by the export function? Obvisouly we cannot use this for the http protocol, local parameters would conflict with the URL ones -- but maybe I didn't understand. Thanks for further enlightenment! -- Bastien
Re: [O] [RFC] Org syntax (draft)
Nicolas Goaziou writes: As discussed a few days ago, here is a document describing the complete Org syntax as read by the parser. I also added some comments. I am going to put the Org file on Worg, so anyone can update it and fix mistakes. Wonderful. This will be really useful! Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] org-export raises stringp nil error
Glenn Morris r...@gnu.org writes: Assuming this is a recent regression, then if anyone from Org wants this fixed in Emacs 24.3, they should investigate this very quickly and suggest the _minimum_ change. The minimal fix is attached. The other attachment is the full patch I wanted to apply to merge Org 7.9.4 into Emacs 24.3. The changes are all safe bugfixes. I assumed it was okay to fix bugs after the last pretest, is it so? Let me know when is the best time for me to merge and I'll release and merge Org 7.9.4. Thanks, diff --git a/lisp/org/org-exp.el b/lisp/org/org-exp.el index 5ccaec3..63a0659 100644 --- a/lisp/org/org-exp.el +++ b/lisp/org/org-exp.el @@ -2113,8 +2110,7 @@ Also, store forced alignment information found in such lines. (put-text-property (match-beginning 0) (match-end 0) 'org-normalized-link t)) (goto-char (point-min)) (while (re-search-forward re-plain-link nil t) - (unless (or (get-text-property (match-beginning 0) 'org-normalized-link) - (assoc :tags (org-context))) + (unless (get-text-property (match-beginning 0) 'org-normalized-link) (goto-char (1- (match-end 0))) (org-if-unprotected-at (1+ (match-beginning 0)) (let* ((s (concat (match-string 1) Changes in master Modified lisp/org/org-agenda.el diff --git a/lisp/org/org-agenda.el b/lisp/org/org-agenda.el index 79217b6..48328d8 100644 --- a/lisp/org/org-agenda.el +++ b/lisp/org/org-agenda.el @@ -6987,6 +6987,8 @@ If the line does not have an effort defined, return nil. (defun org-agenda-filter-apply (filter type) Set FILTER as the new agenda filter and apply it. + ;; Deactivate `org-agenda-entry-text-mode' when filtering + (if org-agenda-entry-text-mode (org-agenda-entry-text-mode)) (let (tags cat) (if (eq type 'tag) (setq org-agenda-tag-filter filter) @@ -7418,17 +7420,23 @@ so that the date SD will be in that range. (defun org-agenda-entry-text-mode (optional arg) Toggle entry text mode in an agenda buffer. (interactive P) - (setq org-agenda-entry-text-mode (or (integerp arg) - (not org-agenda-entry-text-mode))) - (org-agenda-entry-text-hide) - (and org-agenda-entry-text-mode - (let ((org-agenda-entry-text-maxlines - (if (integerp arg) arg org-agenda-entry-text-maxlines))) - (org-agenda-entry-text-show))) - (org-agenda-set-mode-name) - (message Entry text mode is %s. Maximum number of lines is %d - (if org-agenda-entry-text-mode on off) - (if (integerp arg) arg org-agenda-entry-text-maxlines))) + (if (or org-agenda-tag-filter + org-agenda-category-filter + org-agenda-top-category-filter) + (user-error Can't show entry text in filtered views) +(setq org-agenda-entry-text-mode (or (integerp arg) + (not org-agenda-entry-text-mode))) +(org-agenda-entry-text-hide) +(and org-agenda-entry-text-mode + (let ((org-agenda-entry-text-maxlines + (if (integerp arg) arg org-agenda-entry-text-maxlines))) + (org-agenda-entry-text-show))) +(org-agenda-set-mode-name) +(message Entry text mode is %s%s + (if org-agenda-entry-text-mode on off) + (if (not org-agenda-entry-text-mode) + (format (maximum number of lines is %d) + (if (integerp arg) arg org-agenda-entry-text-maxlines)) (defun org-agenda-clockreport-mode (optional with-filter) Toggle clocktable mode in an agenda buffer. Modified lisp/org/org-bibtex.el diff --git a/lisp/org/org-bibtex.el b/lisp/org/org-bibtex.el index 6ed6abc..704b204 100644 --- a/lisp/org/org-bibtex.el +++ b/lisp/org/org-bibtex.el @@ -120,6 +120,7 @@ (declare-function bibtex-generate-autokey bibtex ()) (declare-function bibtex-parse-entry bibtex (optional content)) (declare-function bibtex-url bibtex (optional pos no-browse)) +(declare-function longlines-mode longlines (optional arg)) (declare-function org-babel-trim ob (string optional regexp)) @@ -380,7 +381,7 @@ This variable is relevant only if `org-bibtex-export-tags-as-keywords' is t. (buf-name (format *Bibtex Help %s* name))) (with-output-to-temp-buffer buf-name (princ (cdr (assoc field org-bibtex-fields - (with-current-buffer buf-name (visual-line-mode 1)) + (with-current-buffer buf-name (longlines-mode t)) (org-fit-window-to-buffer (get-buffer-window buf-name)) ((lambda (result) (when ( (length result) 0) result)) (read-from-minibuffer (format %s: name)) Modified lisp/org/org-clock.el diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el index a536d02..b89e644 100644 --- a/lisp/org/org-clock.el +++ b/lisp/org/org-clock.el @@ -1524,7 +1524,15 @@ to, overriding the existing value of `org-clock-out-switch-to-state'. (force-mode-line-update) (message (concat Clock stopped at %s after HH:MM = org-time-clocksum-format %s) te h m (if remove = LINE REMOVED )) - (run-hooks 'org-clock-out-hook) + (let ((h org-clock-out-hook)) + ;; If a closing note needs to be
Re: [O] org-exp-bibtex missing in git?
Bastien writes: I'm all for following established standards, but I'm not sure what is the concrete proposal here. I don't have one yet, mainly because I'm fuzzy on what direction this will take. I ask again to consider what's already out there and that's mainly BibTeX and things that work in principle like BibTex: in the document itself you only say here's a citation and the rest of the handling takes place outside (there are style files, databases in files and online, tools for making and converting them). You make the connection by specifying a configuration in the document. Now if Org would abstract away some of these differences and maybe work in conjunction with some of these outside programs to maybe pull references from online sources and cache them locally (I always hate this step since it is so repetitive), then we're talking. Do you mean using something like this [[file:my.bibkey=key;prenote=note1;postnote=note2][key]] for the file: protocol This is a prime example of how _not_ to do this, IMHO. The file protocol is an established protocol that you shouldn't bolt any extra parameters on. In fact there is no reason to even think of it as a file: protocol since the filename is just another parameter; you don't want to get a file at all. Choose another more suitable protocol or, if none exists, define your own. Assuming I interpret the intent of this link correctly, you want to look up key in file my.bib and then construct a citation with a post- and prenote, while (redundantly?) using key again for display in the Org document. This is involving a lot of things that don't necessarily belong into the same invocation: where the data is stored, how to get at it, what parts of the data to extract and lastly how to present the result. I submit that this is is probably too complicated to try and cram all of this into the link syntax. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] [new exporter] Captions for tables made by source blocks
Could you provide an ECM?
Please see the attached file.
I cannot reproduce it, i.e. I get \ref{crop-median} in the output.
This is odd!! Please see the .tex file attached with this mail. This
is what I get. Any idea, how do I debug this?
Vikas
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Nicolas Goaziou n.goaz...@gmail.com writes:
Prompted by Nicolas's recent addition of the LATEX_HEADER_EXTRA
directive, I would like to request another related feature. Just as we
have the related LATEX and BEGIN_LATEX directives, I would like to see a
BEGIN_LATEX_HEADER directive for multi-line LATEX_HEADER lines:
#+begin_src org
#+BEGIN_LATEX_HEADER
\usepackage{tikz}
\usepackage[british]{babel}
\newcommand{\esf}[1]{\footnote{#1}\marginpar{\fbox{\thefootnote}}
#+END_LATEX_HEADER
#+end_src
(example taken from a recent org file).
Not urgent, of course, but it would make it easier to write this type of
content, especially if it were fontified as well... ;-)
There are already many ways to handle latex header. `org-latex-classes',
setupfile keywords, include keywords, latex_header,
latex_header_extra...
Adding one more is not without consequences. For example, where should
it go? After latex_header values? Before? Would the location be
configurable in `org-latex-classes'? What placeholder to use?
I admit I'm not very keen on this idea. Not because of the coding work,
it would be around 10 loc, but because of syntax fester.
You could have a LaTeX block and tangle it to preamble.tex and input
preamble.tex in a LATEX_HEADER.
–Rasmus
--
Enough with the bla bla!
Re: [O] org-exp-bibtex missing in git?
Achim Gratz strom...@nexgo.de writes: Do you mean using something like this [[file:my.bibkey=key;prenote=note1;postnote=note2][key]] for the file: protocol This is a prime example of how _not_ to do this, IMHO. The file protocol is an established protocol that you shouldn't bolt any extra parameters on. I very much agree. The current hacks using links are annoying and ugly, and if we were to do citations properly in Org—and I think we should—it should NOT be using links (as Nicolas also pointed out). It's a hack and shouldn't be made official. In my book it would seem 'natural' to strive towards the following: 1. It should be Bibtex-based. I.e. Bibtex should be the 'database' or storage for citation information. It may be stored in Org-Bibtex-whatever, but Bibtex should be the natural base. 2. Citation selection should be possible via Reftex. 3. It should look nice in the buffer. For instance, with the current link hacks I am shown the pre or post notes in place of the citation. Ideally, it should be able to specify a reftex-cite-format string on how to display stuff in the buffer. Notes should be viewable in an non-disturbing way. Ideally, I would want to see something like: (POSTFIX, Jensen, 1906, SUFFIX) or Jensen (POSTFIX, 1906, SUFFIX) (If my memory serves me correctly this is how BibLatex places notes). (4. If we are to adopt LaTeX terminology we should adopt the terminology of BibLatex as opposed to Natbib). –Rasmus -- May the Force be with you
Re: [O] [new exporter] Captions for tables made by source blocks
Could you provide an ECM?
Please see the attached file.
I cannot reproduce it, i.e. I get \ref{crop-median} in the output.
Regards,
For me, it works if I change the value of org-babel-results-keyword
to NAME. Then the results block is produced with #+NAME: crop-median
The cross-reference picks this up fine.
But when org-babel-results-keyword is set to RESULTS, the results
block is produced with #+RESULTS: crop-median
The cross-reference does not pick it up correctly. The latex backend
does not export it with a \ref but with a \texttt. The odt backend
also produces crop-median in cross-reference rather than the table
number.
Vikas
Re: [O] org-exp-bibtex missing in git?
Rasmus ras...@gmx.us writes: Achim Gratz strom...@nexgo.de writes: Do you mean using something like this [[file:my.bibkey=key;prenote=note1;postnote=note2][key]] for the file: protocol This is a prime example of how _not_ to do this, IMHO. The file protocol is an established protocol that you shouldn't bolt any extra parameters on. I very much agree. The current hacks using links are annoying and ugly, and if we were to do citations properly in Org—and I think we should—it should NOT be using links (as Nicolas also pointed out). It's a hack and shouldn't be made official. In my book it would seem 'natural' to strive towards the following: 1. It should be Bibtex-based. I.e. Bibtex should be the 'database' or storage for citation information. It may be stored in Org-Bibtex-whatever, but Bibtex should be the natural base. 2. Citation selection should be possible via Reftex. 3. It should look nice in the buffer. For instance, with the current link hacks I am shown the pre or post notes in place of the citation. Ideally, it should be able to specify a reftex-cite-format string on how to display stuff in the buffer. Notes should be viewable in an non-disturbing way. Ideally, I would want to see something like: (POSTFIX, Jensen, 1906, SUFFIX) or Jensen (POSTFIX, 1906, SUFFIX) (If my memory serves me correctly this is how BibLatex places notes). (4. If we are to adopt LaTeX terminology we should adopt the terminology of BibLatex as opposed to Natbib). Given that 1., 2., and 4. are possible with link hacks doesn't this leave just 3. in need of solution? If the current link syntax would take another function used to display the link, then wouldn't that solve 3.? Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-export raises stringp nil error
Bastien wrote: Glenn Morris r...@gnu.org writes: Assuming this is a recent regression, then if anyone from Org wants this fixed in Emacs 24.3, they should investigate this very quickly and suggest the _minimum_ change. The minimal fix is attached. The other attachment is the full patch I wanted to apply to merge Org 7.9.4 into Emacs 24.3. The changes are all safe bugfixes. I assumed it was okay to fix bugs after the last pretest, is it so? No, it is not ok, and I don't know why you would think it is. Release candidate means this IS the release unless something CRITICAL occurs. I hoped my various posts to this list had made this clear. It's also been the traditional policy of at least the more recent Emacs releases as far as I know. I should have been stricter in insisting that Org follow the same policy as everybody else during pretesting, in only installing regression bug fixes. I'm pretty sure this has not been happening, given the size and nature of the changes that keep landing. The reason for this policy is (obviously) to prevent inadvertently introducing mistakes. This seems to be exactly what has bitten us in this case, where your patch just reverts the change from http://lists.gnu.org/archive/html/emacs-diffs/2013-02/msg00058.html Was that fixing a regression? I doubt it. Please apply the first patch as soon as possible. The second includes stuff like deleting comments, declaring functions, and changing autoload for org-autoload. No, you may not apply this. If there were any fixes in there for important regression bugs against Emacs 24.2, please make a separate patch with just those items.
[O] [BUG] attr_latex in new exporter
Aloha all,
I think this behavior was introduced in the last week or so.
This in the Org file:
#+attr_latex: :height 2in
[[file:saa-fig/wet-dry.jpeg]]
yields this in LaTeX output:
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth,height=2in]{saa-fig/wet-dry.jpeg}
\end{figure}
I think when :height is set, then the default :width should not be set.
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] org-special-ctrl-a/e broken [7.9.3f (release_7.9.3f-1447-gb2e1d6-git @ org-loaddefs.el can not be found!)]
jeff stern jas.61...@gmail.com wrote: Hi, all. i am noticing that in at least the latest git pull version of org-mode, org-special-ctrl-a/e (if setq'd to t) does not work correctly in Org-mode version 7.9.3f (release_7.9.3f-1447-gb2e1d6-git but does work correctly in Org-mode version 7.8.03 (release_7.8.03.268.g9706.dirty). I run neither version fully installed - -just run via source in a subdir which is on my load-path (~/git/org-mode/lisp). Are you doing `make autoloads' at least? I am running GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-11-08 on lakoocha, modified by Debian (on Ubuntu 12.10). (My emacs does have an org-mode built-in (apparently 7.8.11) which gets 'redefined' every time I start up, because of my git-pulled org-mode in the load-path. I don't know how to get rid of it. However, that is true both when I am running org-mode 7.8.03 and 7.9.3f..) Because of a 2nd bug which I also experience only in 7.9.3f, I cannot post this bug via M-x org-submit-bug-report, either. (I get as far as being prompted (in the minibuffer) with: Include your Org-mode configuration (yes or no) and I type yes and then in the mini-buffer returns the message, Wrong type argument: stringp, nil, and I am returned only to the blank *scratch* buffer.) This might be a sign that you have a mixed installation. Fortunately, I saved my previous org-mode git directory (7.8.03), and can switch back and forth between that and the new one (7.9.3f) and restart emacs each time to test and confirm. Erroneous behavior has 2 parts: 1) C-a: When (setq org-special-ctrl-a/e t) in the newest org-mode, C-a doesn't work correctly when on a header. Repeated presses of C-a toggle point back and forth between 1st star in the headline (or a later star if #+startup indent is specified and on a 2nd or more level headline) and the first character of text after the todo keyword. That's what I get under 7.8.03 as well. 2) C-e: C-e doesn't work at all. Whether on a headline line, or in normal text, C-e only results in minibuffer message: Symbol's function definition is void: org-element-at-point This might be a sign that you have a mixed installation. Expected Behavior: Of course, correct behavior (as I experience it when running org-mode 7.8.03) is that C-a (no matter how many times typed) takes point ONLY to 1st character of headline title text following any TODO keyword. Correct behavior for C-e is to take point only to just after the last char of headline title text (but before any trailing tags). That's not what the doc says: , | When t, `C-a' will bring back the cursor to the beginning of the | headline text, i.e. after the stars and after a possible TODO | keyword. In an item, this will be the position after bullet and | check-box, if any. When the cursor is already at that position, | another `C-a' will bring it to the beginning of the line. | | `C-e' will jump to the end of the headline, ignoring the presence | of tags in the headline. A second `C-e' will then jump to the | true end of the line, after any tags. This also means that, when | this variable is non-nil, `C-e' also will never jump beyond the | end of the heading of a folded section, i.e. not after the | ellipses. ` Nick
Re: [O] org-special-ctrl-a/e broken [7.9.3f (release_7.9.3f-1447-gb2e1d6-git @ org-loaddefs.el can not be found!)]
Nick Dokos nicholas.do...@hp.com writes: This might be a sign that you have a mixed installation. M-x list-load-path-shadows RET and ensure that your Org files come from only one directory. Keep deleting (or renaming) Org installation directories until you have your Org in only one directory. Remember, to restart Emacs after deleting the directory, for changes to take effect. --
Re: [O] org-exp-bibtex missing in git?
The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Achim Gratz strom...@nexgo.de writes: Do you mean using something like this [[file:my.bibkey=key;prenote=note1;postnote=note2][key]] for the file: protocol This is a prime example of how _not_ to do this, IMHO. The file protocol is an established protocol that you shouldn't bolt any extra parameters on. I very much agree. The current hacks using links are annoying and ugly, and if we were to do citations properly in Org—and I think we should—it should NOT be using links (as Nicolas also pointed out). It's a hack and shouldn't be made official. In my book it would seem 'natural' to strive towards the following: 1. It should be Bibtex-based. I.e. Bibtex should be the 'database' or storage for citation information. It may be stored in Org-Bibtex-whatever, but Bibtex should be the natural base. 2. Citation selection should be possible via Reftex. 3. It should look nice in the buffer. For instance, with the current link hacks I am shown the pre or post notes in place of the citation. Ideally, it should be able to specify a reftex-cite-format string on how to display stuff in the buffer. Notes should be viewable in an non-disturbing way. Ideally, I would want to see something like: (POSTFIX, Jensen, 1906, SUFFIX) or Jensen (POSTFIX, 1906, SUFFIX) (If my memory serves me correctly this is how BibLatex places notes). (4. If we are to adopt LaTeX terminology we should adopt the terminology of BibLatex as opposed to Natbib). –Rasmus -- Dung makes an excellent fertilizer
