Re: [O] S-M-right problem in orgstruct-mode
Hi Alan, Alan Schmitt alan.schm...@polytechnique.org writes: and do a shift-meta-right on the second line, I get: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ** Test2 #+END_SRC I confirm this issue. The easiest thing to do is to prevent some commands to run when `orgstruct-mode' is on and `orgstruct-heading-prefix-regexp' is non-nil. Making those commands to work properly would be nice but I don't think it can be easy enough to implement. Christopher, what do you think? -- Bastien
Re: [O] org-exp-bibtex missing in git?
Hi Aaron, aarone...@gmail.com writes: This is now implemented, in the first of three patches attached to this email. The second patch is a reworked version of the bibliography support in my last patch, and the third implements link attributes for HTML links. This is great -- I'll be offline this week-end, so I won't have time to have a careful look before monday. But I will. Thanks! -- Bastien
Re: [O] [New Exporter] Parameterized wrapper elements
Hi Rick, besides Nicolas good suggestions regarding the code, I think the patch is good and I welcome more flexibility in the HTML exporter so that HTML5-ready derived backends can be written. I'll have a careful look next week. One thing you may double-check in the meantime is: is it compatible with the org-info.js utility? The default should be yes, even if users can replace div by something else (e.g. for the needs of specific backends.) In any case, thanks! -- 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 writes: 8dd2bfc291 release_8.0-alpha (move the new exporter into core) ee3b3eb421 release_8.0-beta (remove /contrib/oldexp/) Okay, please go ahead. Done. Thanks! -- Bastien
Re: [O] Quotes not being converted correctly for LaTeX export
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
It makes sense indeed. latex back-end will use, by default, smart
quotes.
We should turn this on by default unless we have a mechanism to fix
the LaTeX headers, if needed.
The default behavior now is wrong: for example, if I use quotes in
a document with #+LANGUAGE: fr but no LaTeX Babel in the header,
then the \og ... \fg{} will not be processed correctly and the
quotes won't be displayed.
Let's go slowly here. I'm not fan of auto-inserting packages too but
maybe this is just a matter of asking the user once, then letting him
save her choice somehow.
Thanks,
--
Bastien
Re: [O] Quotes not being converted correctly for LaTeX export
Nicolas Goaziou n.goaz...@gmail.com writes: The only problem is when user doesn't load Babel at all, but still wants to use smart quotes. Is it meaningful? It is not meaningful but it is now the default, this is what needs to be fixed. Either by not using smart-quotes by default, or by letting the user what to do. I prefer the second solution :) -- Bastien
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Nicolas Goaziou n.goaz...@gmail.com writes: 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: [...] 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 wasn't proposing anything different other than allowing one to group a whole set of #+latex_header lines into a single begin/end block, akin to what #+begin_latex allows. Just a minor convenience feature. 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. Okay, no worries. Thanks for considering it. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-970-g728c0e
Re: [O] Link colours in new Worg style
Hi Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: I don't know why I did not notice that before! Maybe this time I was browsing around, checking things whereas earlier I knew which entry I was looking for. In any case, it is less confusing after the switch. Thanks for confirming, I made the same change for http://orgmode.org. -- Bastien
Re: [O] [RFC] Org syntax (draft)
Hey Nicolas, this looks very detailed and I think it could be useful for people trying to write other parsers implementations for org-mode. Thanks for sharing! By the way, does it exist somewhere a set of examples of Emacs org-mode - html conversion for all org-mode features? (How are changes from org-mode - html converstion from Emacs tested during development?) I am mantaining the org-ruby gem which is used to render org-mode texts to html, and currently there is no roadmap of features to implement for it. As a result, features and tweaks are added to the library as long as someone submits a ticket requesting the feature in Github. (Here is a list of the export features supported in case someone wants to take a look: https://github.com/bdewey/org-ruby/tree/master/spec/html_examples ) Having a set of examples features from org-mode would be very useful to see how much coverage other implementations of org-mode exporting features have. Cheers everyone, keep org-mode being an awesome tool :) - Waldemar On Sat, Mar 9, 2013 at 7:06 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Nicolas Richard theonewiththeevill...@yahoo.fr writes: Nicolas Goaziou n.goaz...@gmail.com 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. [for the record, the org file mentionned by Nicolas is currently at http://orgmode.org/worg/dev/org-syntax.org] This looks truly awesome. I give some (naïve) comments below, from my non-expert point of view. Thank you for your comments. 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. This is very clear but I'm slightly worried about confusion that might come from Greater element not being an element, and the word element being a common word : element means Element + Greater Element. It is to be understood as the opposite of object. I think there shouldn't be much ambiguity according to context. 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. Is the word element (in /largest element ending.../) to be understood as an element from the above definition ? I guess not (this would require both list items and plain lists to be on the level 'element', from your example) Again, it's a shortcut for in the largest element or greater element ending before them. 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. Perhaps it should be mentionned that STARS has to end by a space (see below). I agree. I suggest adding : The number of stars defines the level of the headline. Does it belong to the syntax definition? Level is how Org uses syntax internally. Also the sentence, although right, is misleading, because level definition also depends on `org-odd-levels-only'. KEYWORD is a TODO keyword, which have to belong to the list defined in `org-todo-keywords'. Case is significant. The option #+TODO: is used also. Then it should be ~org-todo-keywords-1~, which is where all TODO keywords are added eventually. PRIORITY is a priority cookie, i.e. a single letter preceded by a hash sign # and enclosed within square brackets. Case is significant. I suggest dropping Case is significant (or maybe give the whole story : IIRC, it is the ascii code of the given letter that is used as priority) I'm not sure that the purpose of this document should be to explain how syntax will be used. ╭ │ * I don't see a space character after that one in your email and it doesn't seem to be recognized as a headline by the exporter (hence my above suggestion) If the first word appearing in the title is `org-comment-keyword', the That should be `org-comment-string' I guess. Indeed. Btw, I think this variable should be a defconst, not a defcustom. It just makes things harder for little benefit. A headline contains directly at most one section, followed by any number of headlines. Only a section can contain another section. From what I understand, A section is delimited by two headlines (and buffer limits). [I initially thought it was by two headlines of the same level, which it is not from the structure example you give later.]
Re: [O] [new exporter] feature request: BEGIN_LATEX_HEADER
Nicolas Goaziou writes:
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.
Speaking of syntax, having long blocks of #+GRMLLL_SOMETHING: lines is
somewhat of an eyesore, but instead of inventing yet another type of
block, what about allowing implicit naming of keywords:
#+LaTeX_header: %
#+: \newcommand{\Wal}{\operatorname{Wal}}
#+: \newcommand{\Cal}{\operatorname{Cal}}
#+: \newcommand{\Sal}{\operatorname{Sal}}
#+: \newcommand{\sgn}{\operatorname{sgn}}
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Link colours in new Worg style
Bastien writes: Thanks for confirming, I made the same change for http://orgmode.org. The server seems to be down atm (not just the web, also git)? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Link colours in new Worg style
Achim Gratz strom...@nexgo.de writes: Bastien writes: Thanks for confirming, I made the same change for http://orgmode.org. The server seems to be down atm (not just the web, also git)? Yes. The machine is inaccessible, no http, ssh, git or whatever. I asked Jason privately about this, crossing fingers. -- Bastien
Re: [O] Link colours in new Worg style
Bastien b...@altern.org writes: Achim Gratz strom...@nexgo.de writes: Bastien writes: Thanks for confirming, I made the same change for http://orgmode.org. The server seems to be down atm (not just the web, also git)? Yes. The machine is inaccessible, no http, ssh, git or whatever. It is now back. -- Bastien
[O] Small tutorial on how to use Perl within org
hi everybody, I have created a small document that describes how to use perl within org. Hopefully others will find it useful: http://turingmachine.org/~dmg/emacs/examplePerl.org --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
Re: [O] S-M-right problem in orgstruct-mode
Bastien b...@altern.org writes: Alan Schmitt alan.schm...@polytechnique.org writes: and do a shift-meta-right on the second line, I get: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ** Test2 #+END_SRC I confirm this issue. The easiest thing to do is to prevent some commands to run when `orgstruct-mode' is on and `orgstruct-heading-prefix-regexp' is non-nil. I agree. I will come up with a patch ASAP. ( In the long term this should be fixed properly. Considering that point is already on an actual headline, Org just needs to add or remove a star. This should not be too hard with org-heading-regexp. ) Christopher
Re: [O] S-M-right problem in orgstruct-mode
Hi Christopher, Christopher Schmidt christop...@ch.ristopher.com writes: I agree. I will come up with a patch ASAP. Thanks! ( In the long term this should be fixed properly. Considering that point is already on an actual headline, Org just needs to add or remove a star. This should not be too hard with org-heading-regexp. ) Beware that there are *many* commands conditionally called by org-metaright, org-metaleft, etc.: org-do-demote, org-do-promote and the like. It would be too much to make all these commands take the value of `orgstruct-heading-prefix-regexp' into account, even if we end up using a macro `org-with-heading-prefix-regexp' and calling these commands from within the macro. Perhaps accepting some limitations will be the right thing, not sure. Best, -- Bastien
Re: [O] [RFC] Simplify attributes syntax
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: From the user POV, it removes necessity to quote or escape characters. For example, these are now valid: #+attr_latex: :font \footnotesize :align |l|c|c| #+attr_foo: :prop var=value :another-prop nil From the developer POV, each non-nil value is now read as a string by `org-export-read-attribute'. So: #+attr_something: :width 70 will be read as: '(:width 70) Great, thanks! If there's no major problem with it, I'll apply it before Monday. Though, I think ox-odt needs double-checking. How can we help with the double-checking? Thanks, -- Bastien
Re: [O] (no subject)
Hi Terry, I hear you. I completely agree that Org should not be less flexible than it has been so far. At least not for very good reasons, shared by both the developers and the users. IOW: ease of maintainance and code consistency should not let us introduce rigidity for the users. Let's focus on the regressions and let's try to fix the ones that we can fix. As discussions have shown so far, Nicolas holds the keys when it comes to honoring Org's consistency regarding its syntax -- the document he wrote will help us all to speak about the same syntax and rules. But as you may have felt, I'm more on the user conveniency side, even if we need to sacrifice some consistency. There is a balance here, and I hope we keep a good one. So as I said: let's focus on what you perceive as regressions wrt what Org allows. The subject of this thread does not fall in this category: headlines have always been starting with stars, there is no regression here. On the contrary: a few years ago, we had no answer to this FAQ, now we can help users with several solution when the problem is aesthetic. Finally, I agree with Suvayu that the problem *is* mostly aesthetic, so the solutions we provide are enough (i.e., the FAQ, org-bullets.el in contrib/.) The question is rather whether we should have an Org option in core to allow users to tweak the appearance of the stars: my answer here is no, because I don't see why users would stop here. Once we offer such an option for headlines, why not for comments and other characters with a syntactic role? (I replied a question on stackoverflow on how to use % instead of # for comments...) Anyway -- Org still stands on the side of users' freedom, let's fix the real regressions. Thanks! -- Bastien
Re: [O] Link colours in new Worg style
On 9.3.2013, at 11:06, Bastien b...@altern.org wrote: Hi Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: I don't know why I did not notice that before! Maybe this time I was browsing around, checking things whereas earlier I knew which entry I was looking for. In any case, it is less confusing after the switch. Thanks for confirming, I made the same change for http://orgmode.org. What happened to the color of the Unicorn? I don't think these should be changed. - Carsten
Re: [O] [RFC] Org syntax (draft)
On 9.3.2013, at 11:52, Waldemar Quevedo waldemar.quev...@gmail.com wrote: Hey Nicolas, this looks very detailed and I think it could be useful for people trying to write other parsers implementations for org-mode. Thanks for sharing! Maybe someone knowledgeable can turn Nicola's description into a formal parser description that can then be used by something like yacc to produce code for arbitrary languages? I am not sure if I am making sense though. - Carsten By the way, does it exist somewhere a set of examples of Emacs org-mode - html conversion for all org-mode features? (How are changes from org-mode - html converstion from Emacs tested during development?) I am mantaining the org-ruby gem which is used to render org-mode texts to html, and currently there is no roadmap of features to implement for it. As a result, features and tweaks are added to the library as long as someone submits a ticket requesting the feature in Github. (Here is a list of the export features supported in case someone wants to take a look: https://github.com/bdewey/org-ruby/tree/master/spec/html_examples ) Having a set of examples features from org-mode would be very useful to see how much coverage other implementations of org-mode exporting features have. Cheers everyone, keep org-mode being an awesome tool :) - Waldemar On Sat, Mar 9, 2013 at 7:06 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Nicolas Richard theonewiththeevill...@yahoo.fr writes: Nicolas Goaziou n.goaz...@gmail.com 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. [for the record, the org file mentionned by Nicolas is currently at http://orgmode.org/worg/dev/org-syntax.org] This looks truly awesome. I give some (naïve) comments below, from my non-expert point of view. Thank you for your comments. 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. This is very clear but I'm slightly worried about confusion that might come from Greater element not being an element, and the word element being a common word : element means Element + Greater Element. It is to be understood as the opposite of object. I think there shouldn't be much ambiguity according to context. 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. Is the word element (in /largest element ending.../) to be understood as an element from the above definition ? I guess not (this would require both list items and plain lists to be on the level 'element', from your example) Again, it's a shortcut for in the largest element or greater element ending before them. 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. Perhaps it should be mentionned that STARS has to end by a space (see below). I agree. I suggest adding : The number of stars defines the level of the headline. Does it belong to the syntax definition? Level is how Org uses syntax internally. Also the sentence, although right, is misleading, because level definition also depends on `org-odd-levels-only'. KEYWORD is a TODO keyword, which have to belong to the list defined in `org-todo-keywords'. Case is significant. The option #+TODO: is used also. Then it should be ~org-todo-keywords-1~, which is where all TODO keywords are added eventually. PRIORITY is a priority cookie, i.e. a single letter preceded by a hash sign # and enclosed within square brackets. Case is significant. I suggest dropping Case is significant (or maybe give the whole story : IIRC, it is the ascii code of the given letter that is used as priority) I'm not sure that the purpose of this document should be to explain how syntax will be used. ╭ │ * I don't see a space character after that one in your email and it doesn't seem to be recognized as a headline by the exporter (hence my above suggestion) If the first word appearing in the title is `org-comment-keyword', the That should be `org-comment-string' I guess. Indeed. Btw, I think this variable should be a defconst, not a defcustom. It just makes things harder for little benefit.
Re: [O] Small tutorial on how to use Perl within org
D M German writes:
http://turingmachine.org/~dmg/emacs/examplePerl.org
Nice, would you consider contributing it to Worg? I'd like to ask you
to update your Org and that description to the extra features I've
recently implemented for Perl.
--8---cut here---start-8---
#+name: eg
| col1 | col2 |
|--+--|
| a| c|
| b| d|
#+name: hello
#+header: :var x = eg
#+header: :results output
#+BEGIN_SRC perl
print qq(Hi Mom!$/I'm home.)
#+END_SRC
#+RESULTS: hello
: Hi Mom!
: I'm home.
#+name: table-passthrough
#+header: :colnames nil
#+header: :var x = eg
#+begin_src perl
# Look Ma, no code!
#+end_src
#+RESULTS: table-passthrough
| col1 | col2 |
|--+--|
| a| c|
| b| d|
#+name: number-tablerows
#+header: :colnames no
#+header: :var x = eg
#+begin_src perl
my $i = 0;
foreach my $row (@$x) {
unshift $row, $i++;
}
$x;
#+end_src
#+RESULTS: number-tablerows
| 0 | col1 | col2 |
| 1 | a| c|
| 2 | b| d|
--8---cut here---end---8---
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Link colours in new Worg style
Carsten Dominik carsten.domi...@gmail.com writes: What happened to the color of the Unicorn? I don't think these should be changed. This was part of an experiment -- I reverted back to the old Unicorn. -- Bastien
[O] GFDL
Hi, I am wondering, are we required to include the full text of the GFDL in the manual? I find it a big waste of space and feed that a link should do. But I have not been able to find the rules that say what needs to be included in a document distributed under GFDL? Thanks - Carsten
Re: [O] [RFC] Org syntax (draft)
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 9.3.2013, at 11:52, Waldemar Quevedo waldemar.quev...@gmail.com wrote: Hey Nicolas, this looks very detailed and I think it could be useful for people trying to write other parsers implementations for org-mode. Thanks for sharing! Maybe someone knowledgeable can turn Nicola's description into a formal parser description that can then be used by something like yacc to produce code for arbitrary languages? I am not sure if I am making sense though. *cough* you mean GNU Bison or, perhaps better, Wisent (from Semantic). I don't know how well they handle context sensitive grammars, though.. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Simplify attributes syntax
Hello, Bastien b...@altern.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: If there's no major problem with it, I'll apply it before Monday. Though, I think ox-odt needs double-checking. How can we help with the double-checking? Just test features using attributes (in particular :width number attributes). Or just double-check the code (though Jambunathan should be more at ease with this): I did some blind replacement, but I may have missed something. Regards, -- Nicolas Goaziou
Re: [O] GFDL
Carsten Dominik writes: I am wondering, are we required to include the full text of the GFDL in the manual? I find it a big waste of space and feed that a link should do. But I have not been able to find the rules that say what needs to be included in a document distributed under GFDL? http://www.gnu.org/licenses/fdl-howto http://www.gnu.org/licenses/fdl-1.3.html To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:[…] I read this: If there's just one document, it must contain the license in full, if there are several that reference each other, it is enough to include it in the top-level document. 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] Quotes not being converted correctly for LaTeX export
Hello, Bastien b...@altern.org writes: Nicolas Goaziou n.goaz...@gmail.com writes: The only problem is when user doesn't load Babel at all, but still wants to use smart quotes. Is it meaningful? It is not meaningful but it is now the default, Actually, as Suvayu Ali suggested, it is meaningful only in the default case, which is no Babel package and English language. As soon as you tweak either LANGUAGE keyword or `org-export-default-language', you must use Babel. this is what needs to be fixed. Either by not using smart-quotes by default, or by letting the user what to do. I prefer the second solution :) Smart-quotes works by heuristics. It will fail in some cases. That's why I think it shouldn't be on by default (even in latex back-end). Also, smart quotes can be turned on/off at will, so the user can decide what to do. It just a problem of providing sensible defaults. The old exporter provided smart quotes by default in LaTeX, as you know. I'm not sure it is a good move, but at least, it is consistent with the previous implementation. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Org syntax (draft)
On 9.3.2013, at 15:42, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 9.3.2013, at 11:52, Waldemar Quevedo waldemar.quev...@gmail.com wrote: Hey Nicolas, this looks very detailed and I think it could be useful for people trying to write other parsers implementations for org-mode. Thanks for sharing! Maybe someone knowledgeable can turn Nicola's description into a formal parser description that can then be used by something like yacc to produce code for arbitrary languages? I am not sure if I am making sense though. *cough* you mean GNU Bison Told you I am not sure if I am making sense. Anyway, a general parser would be useful for extensions like org-ruby... - Carsten
Re: [O] GFDL
On 9.3.2013, at 16:02, Achim Gratz strom...@nexgo.de wrote: Carsten Dominik writes: I am wondering, are we required to include the full text of the GFDL in the manual? I find it a big waste of space and feed that a link should do. But I have not been able to find the rules that say what needs to be included in a document distributed under GFDL? http://www.gnu.org/licenses/fdl-howto http://www.gnu.org/licenses/fdl-1.3.html To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:[…] I read this: If there's just one document, it must contain the license in full, if there are several that reference each other, it is enough to include it in the top-level document. Yes it sounds like it. Thank you for the link. I still think it is crazy to add these 8 pages to each time someone prints it Regards - Carsten
Re: [O] org-exp-bibtex missing in git?
Hello, aarone...@gmail.com writes: 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. Do you have a proposal for how this syntax would look? You certainly know the parser very well, so you probably have an idea of what will work and not conflict with other things. I think minimally we need to include info on: - how to look up the citation (DOI, arXiv id, in a bibtex file, ...) - how to display/export the citation (parens, footnote, in-text, ...) - a list of properties (incl. at least pre- and post-note) - (of course) the citation key So maybe: [cite:lookup-type:display-type:key:prop1=val1,prop2=val2] I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter (link syntax) implies a (optional) description part. I don't think a description is ever meaningful in citations. Also, as I already mentioned, link syntax is already overloaded: there are many types of links and the link transcoder function in export back-ends is generally one of the most complicated to write (along with tables). Regards, -- Nicolas Goaziou
Re: [O] S-M-right problem in orgstruct-mode
Bastien b...@altern.org writes:
Christopher Schmidt christop...@ch.ristopher.com writes:
( In the long term this should be fixed properly. Considering that
point is already on an actual headline, Org just needs to add or
remove a star. This should not be too hard with
org-heading-regexp. )
Beware that there are *many* commands conditionally called by
org-metaright, org-metaleft, etc.: org-do-demote, org-do-promote and
the like.
It would be too much to make all these commands take the value of
`orgstruct-heading-prefix-regexp' into account, even if we end up
using a macro `org-with-heading-prefix-regexp' and calling these
commands from within the macro. Perhaps accepting some limitations
will be the right thing, not sure.
That is not necessary. The hijacking command already makes sure
org-heading-regexp takes orgstruct-heading-prefix-regexp into account.
Nonetheless It is still a lot of work.
Alan, here is patch for master that should solve the issue. It disables
org-{pr,de}mote and org-{,shift}meta{left,right} in orgstruct-mode iff
orgstruct-heading-prefix-regexp is non-nil. Could you please give it a
try and tell us what you think?
diff --cc lisp/org.el
index 811506a,a7670dc..000
--- a/lisp/org.el
+++ b/lisp/org.el
@@@ -8743,72 -8695,78 +8743,80 @@@ buffer. It will also recognize item co
(defun orgstruct-setup ()
Setup orgstruct keymap.
- (dolist (f
-'(org-meta
- org-shift
- org-shiftmeta
- org-shifttab
- org-backward-element
- org-backward-heading-same-level
- org-ctrl-c-ret
- org-ctrl-c-minus
- org-ctrl-c-star
- org-cycle
- org-forward-heading-same-level
- org-insert-heading
- org-insert-heading-respect-content
- org-kill-note-or-show-branches
- org-mark-subtree
- org-narrow-to-subtree
- org-promote-subtree
- org-reveal
- org-show-subtree
- org-sort
- org-up-element
- outline-demote
- outline-next-visible-heading
- outline-previous-visible-heading
- outline-promote
- outline-up-heading
- show-children))
- (dolist (f (if (stringp f)
-(let ((flist))
- (dolist (postfix
- '(-return tab left right up down)
- flist)
-(let ((f (intern (concat f postfix
- (when (fboundp f)
-(push f flist)
- (list f)))
- (dolist (binding (nconc (where-is-internal f org-mode-map)
- (where-is-internal f outline-mode-map)))
- ;; TODO use local-function-key-map
- (dolist (rep '((tab . TAB)
-(return . RET)
-(escape . ESC)
-(delete . DEL)))
- (setq binding (read-kbd-macro (replace-regexp-in-string
- (regexp-quote (car rep))
- (cdr rep)
- (key-description binding)
- (let ((key (lookup-key orgstruct-mode-map binding)))
- (when (or (not key) (numberp key))
- (condition-case nil
- (org-defkey orgstruct-mode-map
- binding
- (orgstruct-make-binding f binding))
- (error nil)))
+ (dolist (cell '((org-demote . t)
+ (org-metaleft . t)
+ (org-metaright . t)
+ (org-promote . t)
+ (org-shiftmetaleft . t)
+ (org-shiftmetaright . t)
+ org-backward-element
+ org-backward-heading-same-level
+ org-ctrl-c-ret
++ org-ctrl-c-minus
++ org-ctrl-c-star
+ org-cycle
+ org-forward-heading-same-level
+ org-insert-heading
+ org-insert-heading-respect-content
+ org-kill-note-or-show-branches
+ org-mark-subtree
+ org-meta-return
+ org-metadown
+ org-metaup
+ org-narrow-to-subtree
+ org-promote-subtree
+ org-reveal
+ org-shiftdown
+ org-shiftleft
+ org-shiftmetadown
+ org-shiftmetaup
+ org-shiftright
+ org-shifttab
+ org-shifttab
+ org-shiftup
+ org-show-subtree
+ org-sort
+ org-up-element
+ outline-demote
+ outline-next-visible-heading
+ outline-previous-visible-heading
+ outline-promote
+ outline-up-heading
+ show-children))
+ (let ((f (or (car-safe cell) cell))
+ (disable-when-heading-prefix (cdr-safe cell)))
+ (when (fboundp f)
+ (dolist (binding (nconc (where-is-internal f org-mode-map)
+ (where-is-internal f outline-mode-map)))
+ ;; TODO use local-function-key-map
+ (dolist (rep '((tab . TAB)
+ (return . RET)
+ (escape . ESC)
+ (delete . DEL)))
+ (setq binding (read-kbd-macro (replace-regexp-in-string
+ (regexp-quote (car rep))
+ (cdr rep)
+ (key-description
Re: [O] GFDL
Carsten Dominik writes:
I still think it is crazy to add these 8 pages to each time someone prints
it
It fits on exactly two pages (or front and back of one page) if wrapped in
\begin{multicols}{2}
\scriptsize
…
and it is still a lot more readable (even if printed out on A5 instead
of A4) than the fineprint you get with commercial software.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
Re: [O] org-exp-bibtex missing in git?
Nicolas Goaziou n.goaz...@gmail.com writes: I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter (link syntax) implies a (optional) description part. I don't think a description is ever meaningful in citations. I have been holding on to this for a while. Just typing it out as it comes to my mind. I favor the above syntax. I view Citations as closer to Footnotes. The syntax should parallels footnotes syntax. 1. PROPERTIES should be opaque to Org. It is a key or a list of keys possibly bibtex but Org doesn't take stand on how it looks like. 2. There will be a org-BACKEND-citation-reference. 3. There will be a org-BACKEND-bibliography. 2, 3 more likely with interface with respective citation processor (citation processor as opposed to a database) via CLI. Citation processor could be whatever org-exp-bibtex interfaces with right now. I also have some proof-of-concept - see zotcite - for zotero. 2, 3 will parallel footnote-reference and footnote-section callbacks in HTML backend. 4. Footnotes can be introduced with either fn: prefix or cite: prefix. There should be a way to put fn: and cite: in same enumeration context. There should be a way to put fn: and cite: in different enumeration context. The former case could be a degenerate mode where Org can transcode what is seen in the buffer where everything is footnotes. The latter case will result in Citations and Bibliography being generated by the above backend transcoders. 5. Citation definitions in Org buffer will be *ignored*. (It could be considered when the exporter works in a degenerate footnote only mode where plain text transcoding is resorted to because there is no suitable application available for the backend format.) Plain text citation definitions are only to help the author have a glimpse of what he is doing, it has only UI-value but no contents value. 6. There may be an advisory citation style - say APA, Chicago etc - which the backends may honor or ignore. I am not clear about: 1. How multiple keys are to be handled. 2. What prenotes or postnotes mean. 3. Chicago note style etc. I think the community should answer and articulate 1, 2, 3 clearly. With my proposal, there could be some minor changes in Footnotes normalization and some minor changes in existing transcoders. The Org syntax for citations should *at this point* in time should NOT make any assumptions about the Citation Database or the Citation Application. As far Org is concerned, there should be a way for Emacs to interact with these engines and have them return Citation Refernece and Citation Defintion contents in required backend format. --
Re: [O] [New Exporter] Parameterized wrapper elements
On Sat, Mar 09, 2013 at 01:46:37AM +0100, Nicolas Goaziou wrote: Since I don't use html back-end, it would be better to hear from actual users what they think about it. Sorry, forgot that you are not the keeper of ox-html, just the new exporter at large ;). Anyway, just a few comments: +(defcustom org-html-divs + '((preamble div) +(content div) +(postamble div)) + Alist of the main divs for HTML export. Even if this is technically an alist, you don't use it as such, because you do not treat ID as keys. Perhaps something like the following would be better: '((preamble preamble div) (content content div) (postamble postamble div)) One advantage is that you don't have to rely on order of associations. Another advantage is that you can write: (nth 1 (assq 'content org-html-divs)) I agree, but couldn't figure out a way to specify a defcustom alist that requires a fixed set of options. I'm quite new to the defcustom specification format, so maybe there is a way... Given what I see is possible w/ custom alists, the code would have to look like: (nth 1 (or (assq 'content org-html-divs) (assq 'content org-html-default-divs))) Not sure this is any better than the nth nth approach. What do you think? + (if (= 1 (org-export-get-relative-level headline info)) + (plist-get info :html-container Shouldn't you close the div when level is different from 1 here? Yes, it's a bug. Missing the else part. Will amend the patch and repost. thanx for finding this. rick
Re: [O] Small tutorial on how to use Perl within org
Aloha dmg, D M German d...@uvic.ca writes: hi everybody, I have created a small document that describes how to use perl within org. Hopefully others will find it useful: http://turingmachine.org/~dmg/emacs/examplePerl.org Nice. It would be great to use this document as the basis of ob-doc-perl. Perl is one of about 20 languages that need to be documented at http://orgmode.org/worg/org-contrib/babel/languages.html. Note that there is a template that helps create a standard language document: http://orgmode.org/w/?p=worg.git;a=blob;f=org-contrib/babel/languages/ob-doc-template.org;hb=HEAD I don't know the first thing about Perl, but I'll be happy to help if there are questions about getting to ob-doc-perl from the template. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-exp-bibtex missing in git?
Jambunathan K kjambunat...@gmail.com writes: Citation processor could be whatever org-exp-bibtex interfaces with right now. I also have some proof-of-concept - see zotcite - for zotero. I have a proof-of-concept on how to use Jabref to get citations in to ODT export. I will share a recipe sometime (when it will happen I cannot say, my muse should sit with me.) My proposal may sound abstract but I do have some prototype that validates the simplicity and practicality of my suggestions. It will also minimize Nicolas efforts - Get the cite key but don't bother about grokking it for good.
Re: [O] GFDL
On 9.3.2013, at 16:25, Achim Gratz strom...@nexgo.de wrote:
Carsten Dominik writes:
I still think it is crazy to add these 8 pages to each time someone prints
it
It fits on exactly two pages (or front and back of one page) if wrapped in
\begin{multicols}{2}
\scriptsize
…
and it is still a lot more readable (even if printed out on A5 instead
of A4) than the fineprint you get with commercial software.
Cool. We should do this
- Carsten
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] Parameterized wrapper elements
On Sat, Mar 09, 2013 at 10:32:11AM +0100, Bastien wrote:
Hi Rick,
One thing you may double-check in the meantime is: is it
compatible with the org-info.js utility? The default should
be yes, even if users can replace div by something else
(e.g. for the needs of specific backends.)
Yes. Checked the code and tested the script. It works on element ids
and not element types, so changing the element type from `div' has no
effect.
The things that will break infojs are changing the following ids:
- content
- postamble
- footnotes
- table-of-contents
- text-table-of-content
- text-{slidenum}
Note that the current implementation of `org-html-divs' will
potentially break infojs as well.
Attached is a revised patch with the fixes Nicolas found for the
doc-string and the missing closing element.
rick
From d539863475c4c1432b2b5de175d587f57b317453 Mon Sep 17 00:00:00 2001
From: Rick Frankel r...@rickster.com
Date: Fri, 8 Mar 2013 19:00:21 -0500
Subject: [PATCH] Parameterize some html content containers
* lisp/ox-html.el: (define-backend): Add :html-doctype and
:html-container parameters.
(org-html-doctype): New customization variable for doctype
declaration.
(org-html-container-elemnt): New customization variable for specifying
wrapper container element.
(org-html-div): Change to list of pairs id, element type to allow
setting container element.
(org-html--build-preamble): Modified to use new org-html-div settings.
(org-html--build-postamble): Modified to use new org-html-div settings.
(org-html-template): Modified to use doctype and container-element
settings.
---
lisp/ox-html.el | 77 +++--
1 file changed, 58 insertions(+), 19 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 829fe28..b1638e6 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -113,6 +113,8 @@
(org-open-file (org-html-export-to-html nil s v b)))
:options-alist
((:html-extension nil nil org-html-extension)
+ (:html-doctype HTML_DOCTYPE nil org-html-doctype)
+ (:html-container HTML_CONTAINER nil org-html-container-element)
(:html-link-home HTML_LINK_HOME nil org-html-link-home)
(:html-link-up HTML_LINK_UP nil org-html-link-up)
(:html-mathjax HTML_MATHJAX nil space)
@@ -859,19 +861,44 @@ Use utf-8 as the default value.
:package-version '(Org . 8.0)
:type 'coding-system)
-(defcustom org-html-divs '(preamble content postamble)
- The name of the main divs for HTML export.
-This is a list of three strings, the first one for the preamble
-DIV, the second one for the content DIV and the third one for the
-postamble DIV.
+(defcustom org-html-doctype
+ !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;
+ Document type definition to use for exported HTML files.
+Can be set with the in-buffer HTML_DOCTYPE property or for
+publishing, with :html-doctype.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
- :type '(list
- (string :tag Div for the preamble:)
- (string :tag Div for the content:)
- (string :tag Div for the postamble:)))
+ :type 'string)
+
+(defcustom org-html-container-element div
+ Container class to use for wrapping top level sections.
+Can be set with the in-buffer HTML_CONTAINER property or for
+publishing, with :html-container.
+ :group 'org-export-html
+ :version 24.4
+ :package-version '(Org . 8.0)
+ :type 'string)
+(defcustom org-html-divs
+ '((preamble div)
+(content div)
+(postamble div))
+ Alist of the main divs for HTML export.
+This is a list of three pairs, ID and ELEMENT, the first one
+for the preamble, the second one for the content and the
+third one for the postamble.
+ :group 'org-export-html
+ :version 24.4
+ :package-version '(Org . 8.0)
+ :type '(list
+ (list :tag Preamble
+ (string :tag id) (string :tag element))
+ (list :tag Content
+ (string :tag id) (string :tag element))
+ (list :tag Postamble
+ (string :tag id) (string :tag element
Template :: Mathjax
@@ -1482,9 +1509,11 @@ INFO is a plist used as a communication channel.
`((?t . ,title) (?a . ,author)
(?d . ,date) (?e . ,email
(when (org-string-nw-p preamble-contents)
- (concat (format div id=\%s\\n (nth 0 org-html-divs))
+ (concat (format %s id=\%s\\n
+ (nth 1 (nth 0 org-html-divs))
+ (nth 0 (nth 0 org-html-divs)))
(org-element-normalize-string preamble-contents)
- /div\n))
+ (format /%s\n (nth 1 (nth 0 org-html-divs)
(defun org-html--build-postamble (info)
Return document postamble as a string, or nil.
@@ -1534,9 +1563,11 @@ INFO is a plist used as a communication channel.
Re: [O] org-exp-bibtex missing in git?
Jambunathan K kjambunat...@gmail.com writes: I am not clear about: 1. How multiple keys are to be handled. 2. What prenotes or postnotes mean. 3. Chicago note style etc. I think the community should answer and articulate 1, 2, 3 clearly. With my proposal, there could be some minor changes in Footnotes normalization and some minor changes in existing transcoders. 1. One approach to multiple keys is qualified citation lists, see section 3.7.3 of _The biblatex Package Programmable Bibliographies and Citations by Philipp Lehman_ (`texdoc biblatex' on my Mac). 2. (see Lehman 2012:92 for an explanation of prenotes and postnotes). ^^^ prenote postnote 3. BibLaTeX ships with several standard styles, which can be used as starting points for writing specific styles required by publishers. See section 3.3 of the BibLaTeX manual. For an idea of what it takes to support the Chicago style, please see the 129 page manual for the biblatex-chicago style (http://www.ctan.org/pkg/biblatex-chicago). This package supports both the author-date system used in the sciences and the notes bibliography system used in the humanities. (Jambunathan, for your reference, the paper I sent you uses the notes bibliography system--it was written in Org-mode and formatted with LaTeX and BibLaTeX.) We use the Chicago Manual of Style at work and the BibTeX approximation of the Chicago bibliography and reference styles. I looked at biblatex-chicago several years ago and had to let it go because of the heavy data requirements. In particular, the changes needed for the .bib database broke other styles that we thought we might use. Apparently, it's not possible to design a data table that supports all the bibliography styles that one might want to use. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] S-M-right problem in orgstruct-mode
Christopher Schmidt writes:
Alan, here is patch for master that should solve the issue. It disables
org-{pr,de}mote and org-{,shift}meta{left,right} in orgstruct-mode iff
orgstruct-heading-prefix-regexp is non-nil. Could you please give it a
try and tell us what you think?
Thanks a lot. Unfortunately I could not apply the patch:
~/projets/org-mode(master ✗) git apply --stat ~/Documents/Inbox/2.part
fatal: unrecognized input
Looking at it there seems to be occurrences of '++' that are a bit
strange. Was it garbled when attached?
Alan
Re: [O] [New Exporter] Parameterized wrapper elements
Rick
I have my reservations in applying this patch - I am not concerned about
the patch, I have not looked at it.
Any improvements to existing backends should invariably answer the
question - Can this change improve export tools or the parse tree
syntax.
If such a question is never asked and a answer sought, I would blame the
committer - whoever it be - in placing convenience and expediency above
the correct way to do things.
I have not looked at Rick's patch so my comment shouldn't be construed
as disapproval of the patch. I want the patch to improve exporter tools
and it has potential to improve the existing tools (maybe) in small ways
- an improvement is an improvement.
Jambunathan K.
Rick Frankel r...@rickster.com writes:
On Sat, Mar 09, 2013 at 10:32:11AM +0100, Bastien wrote:
Hi Rick,
One thing you may double-check in the meantime is: is it
compatible with the org-info.js utility? The default should
be yes, even if users can replace div by something else
(e.g. for the needs of specific backends.)
Yes. Checked the code and tested the script. It works on element ids
and not element types, so changing the element type from `div' has no
effect.
The things that will break infojs are changing the following ids:
- content
- postamble
- footnotes
- table-of-contents
- text-table-of-content
- text-{slidenum}
Note that the current implementation of `org-html-divs' will
potentially break infojs as well.
Attached is a revised patch with the fixes Nicolas found for the
doc-string and the missing closing element.
rick
--
Re: [O] S-M-right problem in orgstruct-mode
Alan Schmitt alan.schm...@polytechnique.org writes: Looking at it there seems to be occurrences of '++' that are a bit strange. Was it garbled when attached? Ooops, I forgot to finalise my merge. --- a/lisp/org.el +++ b/lisp/org.el @@ -8658,7 +8658,7 @@ If WITH-CASE is non-nil, the sorting will be case-sensitive. ;; command. There might be problems if any of the keys is otherwise ;; used as a prefix key. -(defcustom orgstruct-heading-prefix-regexp +(defcustom orgstruct-heading-prefix-regexp nil Regexp that matches the custom prefix of Org headlines in orgstruct(++)-mode. :group 'org @@ -8743,72 +8743,80 @@ buffer. It will also recognize item context in multiline items. (defun orgstruct-setup () Setup orgstruct keymap. - (dolist (f - '(org-meta - org-shift - org-shiftmeta - org-shifttab - org-backward-element - org-backward-heading-same-level - org-ctrl-c-ret - org-ctrl-c-minus - org-ctrl-c-star - org-cycle - org-forward-heading-same-level - org-insert-heading - org-insert-heading-respect-content - org-kill-note-or-show-branches - org-mark-subtree - org-narrow-to-subtree - org-promote-subtree - org-reveal - org-show-subtree - org-sort - org-up-element - outline-demote - outline-next-visible-heading - outline-previous-visible-heading - outline-promote - outline-up-heading - show-children)) -(dolist (f (if (stringp f) - (let ((flist)) - (dolist (postfix - '(-return tab left right up down) - flist) - (let ((f (intern (concat f postfix - (when (fboundp f) - (push f flist) - (list f))) - (dolist (binding (nconc (where-is-internal f org-mode-map) - (where-is-internal f outline-mode-map))) -;; TODO use local-function-key-map -(dolist (rep '((tab . TAB) - (return . RET) - (escape . ESC) - (delete . DEL))) - (setq binding (read-kbd-macro (replace-regexp-in-string - (regexp-quote (car rep)) - (cdr rep) - (key-description binding) -(let ((key (lookup-key orgstruct-mode-map binding))) - (when (or (not key) (numberp key)) - (condition-case nil - (org-defkey orgstruct-mode-map - binding - (orgstruct-make-binding f binding)) - (error nil))) + (dolist (cell '((org-demote . t) + (org-metaleft . t) + (org-metaright . t) + (org-promote . t) + (org-shiftmetaleft . t) + (org-shiftmetaright . t) + org-backward-element + org-backward-heading-same-level + org-ctrl-c-ret + org-ctrl-c-minus + org-ctrl-c-star + org-cycle + org-forward-heading-same-level + org-insert-heading + org-insert-heading-respect-content + org-kill-note-or-show-branches + org-mark-subtree + org-meta-return + org-metadown + org-metaup + org-narrow-to-subtree + org-promote-subtree + org-reveal + org-shiftdown + org-shiftleft + org-shiftmetadown + org-shiftmetaup + org-shiftright + org-shifttab + org-shifttab + org-shiftup + org-show-subtree + org-sort + org-up-element + outline-demote + outline-next-visible-heading + outline-previous-visible-heading + outline-promote + outline-up-heading + show-children)) +(let ((f (or (car-safe cell) cell)) + (disable-when-heading-prefix (cdr-safe cell))) + (when (fboundp f) + (dolist (binding (nconc (where-is-internal f org-mode-map) +(where-is-internal f outline-mode-map))) + ;; TODO use local-function-key-map + (dolist (rep '((tab . TAB) + (return . RET) + (escape . ESC) + (delete . DEL))) + (setq binding (read-kbd-macro (replace-regexp-in-string + (regexp-quote (car rep)) + (cdr rep) + (key-description binding) + (let ((key (lookup-key orgstruct-mode-map binding))) + (when (or (not key) (numberp key)) + (condition-case nil + (org-defkey orgstruct-mode-map + binding + (orgstruct-make-binding f binding disable-when-heading-prefix)) + (error nil (run-hooks 'orgstruct-setup-hook)) -(defun orgstruct-make-binding (fun key) +(defun orgstruct-make-binding (fun key disable-when-heading-prefix) Create a function for binding in the structure minor mode. FUN is the command to call inside a table. KEY is the key that -should be checked in for a command to execute outside of tables. +should be checked in for a command to execute outside of tables. +Non-nil DISABLE-WHEN-HEADING-PREFIX means to disable the command
[O] two-way sync org agenda/ical
Hi there, Does anybody know how to export deadline or schedule items from org to ical ? thanks M
Re: [O] [BUG] attr_latex in new exporter
Aaron and Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, aarone...@gmail.com writes: I think the following patch (on top of current master) will fix the problem: [...] It does. Thank you. Works here now. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
aarone...@gmail.com writes: 2013ko martxoak 8an, Eric Schulte-ek idatzi zuen: I would agree. I don't believe *any* changes should take place in the buffer when a code block is executed with :results none. A common use case for me is to use a babel block to load a large dataset into R. I want this to be cached, in the sense that I want it not to be run again (by e.g. C-c C-v C-b) unless the code changes. But I also don’t want to see its result in the (mini)buffer. Is there a way to accommodate this usage of the cache functionality? Maybe a better solution would be to add a feature to avoid echoing very large results to the minibuffer. It should be very straightforward to add a user customizable variable (e.g., `org-babel-max-echo-length' or somesuch) which limits the number of characters echo'd to the minibuffer. The hyphen should only be required for multi-word functions, e.g., `listp' has no hyphen but `hash-table-p' does have a hyphen. The context surrounding this code binds cache-p; the lack of a hyphen was just a typo in the patch. I agree that cachep is more idiomatic (in fact, that is what led to the typo), but I tried to make the smallest possible patch to address my intention. Ah, my fault for not completely reading and understanding your previous post. I'm currently working on a set of patches with Achim which should (I believe) resolve this issue. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: I prefer leaving the hash with the results, as it is the results which are hashed. Also, same input does not always guarantee same output, e.g., #+begin_src sh date #+end_src That's not what I'm seeing, but I may be missing something again. The hash is for the parameters of the call, not the result. If I'm editing the result, Babel still marks the cache valid and does not re-compute it. It does re-compute if I change the parameters explicitly or implicitly, even if the result will not change. A hash marks a *result* with an indication of what was used to generate it (code block parameters). The point of a hash is to allow the result to be returned without having to re-execute. For this reason, I think that the hash should live with the result. In general a hash without a result doesn't make sense (because then what is cached?). If one did want to move hashes to code blocks it would be a major refactoring which would (in my opinion) require significant justification. As I understand this particular case, the OP is using a hash not to mark a result as up to date, but rather to mark a side effect (loading data into R) as having taken place. I think this is a misuse of a cache. What if the R process restarts? The hash would still be valid, but the side effects have been lost. I think a better approach would be to implement the logic in R required to check if data is present and conditionally load it if not. Then simply re-run this conditional reloading code in full every time. It is very possible I've missed something. I hope these comments are helpful. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen: Maybe a better solution would be to add a feature to avoid echoing very large results to the minibuffer. It should be very straightforward to add a user customizable variable (e.g., `org-babel-max-echo-length' or somesuch) which limits the number of characters echo'd to the minibuffer. If a very large result is read by emacs, it slows down drastically. This is in fact the raison d’etre of :results none (http://thread.gmane.org/gmane.emacs.orgmode/62115/focus=62665). So I’m afraid this doesn’t help. -- Aaron Ecay
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
2013ko martxoak 9an, Eric Schulte-ek idatzi zuen: A hash marks a *result* with an indication of what was used to generate it (code block parameters). The point of a hash is to allow the result to be returned without having to re-execute. For this reason, I think that the hash should live with the result. In general a hash without a result doesn't make sense (because then what is cached?). A :results none code block is run for its side effects (by definition). Caching a code block with results says “I do not want to recalculate this value unless the code changes.” Caching a null result, by analogy, says “I do not want these side effects again, unless the code changes”. As I understand this particular case, the OP is using a hash not to mark a result as up to date, but rather to mark a side effect (loading data into R) as having taken place. I think this is a misuse of a cache. It depends on whether one looks at a cache as “a place to store results” or “a way to conditionally rerun code blocks only when they change”, I suppose. I guess you hold with the former; I think the latter is a useful conceptual extension. Knitr (http://yihui.name/knitr/) is a very useful literate programming tool for R, and it supports “caching” code with side-effects using clever means. I don’t think org should do all the tricks knitr does, but it would be useful to be able to conditionally reexecute code with no results/with side effects. What if the R process restarts? The hash would still be valid, but the side effects have been lost. This is also an issue if the external data files have changed, the RNG seed is no longer the same, etc. In such cases, the user has to be clever. But the same is true of any cached code that is not a pure function. In practice, if the R process is restarted the “variable not found” errors quickly become apparent, and reloading the data is a simple C-u C-c C-c away. (That being said, including the PID of the R process in the results hash, to the effect that the code would be rerun in the case you mention, might not be a bad idea. But that is a separate discussion.) -- Aaron Ecay
Re: [O] [RFC] Simplify attributes syntax
Hi Nicolas, I think this patch is a welcome simplification. Would it be possible to merge the code that is used for reading babel header args (things like “:results output :file foo.txt”) with the code from the exporter? Unless they are parsed by the same code, the two syntaxes will differ in subtle and headache-inducing ways (for users and developers). Both methods as it stands have their pros and cons. org-export-read-attribute seems* to give the wrong result for the case of #+ATTR_FOO: :key one :two three - (:key \one :two three\) Whereas org-babel-parse-header-arguments (returning an alist, not a plist) gives correctly ((:key . one :two three)) OTOH :key (one :two) makes o-b-parse-header-arguments give an error because it tries to read (one :two) as elisp, and “one” isn’t an elisp function. For o-x-read-attribute we correctly(?) get (:key (one :two)). o-b-parse-header-arguments can cope with :key '(one :two three) (note the single quote to not barf on the lisp-like syntax) giving ((:key one :two three)) – which is a notational variant of ((:key . (one :two three))) – whereas o-x-read-attribute gives (:key '(one :two three)) In this last case I think that either value is arguably correct – but it should be consistently one and not the other. * For testing, I extracted the following function from org-export-read-attribute. #+begin_src emacs-lisp (defun o-test (value) (let ((s value) result) (while (string-match \\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\) s) (let ((value (substring s 0 (match-beginning 0 (push (and (not (member value '(nil ))) value) result)) (push (intern (match-string 1 s)) result) (setq s (substring s (match-end 0 ;; Ignore any string before the first property with `cdr'. (cdr (nreverse (cons (and (org-string-nw-p s) (not (equal s nil)) s) result ) #+end_src -- Aaron Ecay
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Eric Schulte writes: Ah, my fault for not completely reading and understanding your previous post. I'm currently working on a set of patches with Achim which should (I believe) resolve this issue. It doesn't yet, but I#ll add another patch to rename this binding. IIRC, the naming was so that it would rhyme more easily with cache-current-p which has the hyphen (and should keep it, I think). But if cachep is more idiomatic, I'm not the one to argue. 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] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
As I understand this particular case, the OP is using a hash not to mark
a result as up to date, but rather to mark a side effect (loading data
into R) as having taken place. I think this is a misuse of a cache.
It depends on whether one looks at a cache as “a place to store results”
or “a way to conditionally rerun code blocks only when they change”, I
suppose. I guess you hold with the former; I think the latter is a
useful conceptual extension. Knitr (http://yihui.name/knitr/) is a very
useful literate programming tool for R, and it supports “caching” code
with side-effects using clever means. I don’t think org should do all
the tricks knitr does, but it would be useful to be able to
conditionally reexecute code with no results/with side effects.
Could something like the following work? Removing :results none and
adding something small as the returned result which may easily be parsed
and placed in the buffer w/o problem.
#+begin_src R :cache yes
# code to perform side effect
x - 'side effect'
'done'
#+end_src
#+RESULTS[9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a]:
: done
What if the R process restarts? The hash would still be valid, but the
side effects have been lost.
This is also an issue if the external data files have changed, the RNG
seed is no longer the same, etc. In such cases, the user has to be
clever. But the same is true of any cached code that is not a pure
function.
In practice, if the R process is restarted the “variable not found”
errors quickly become apparent, and reloading the data is a simple C-u
C-c C-c away.
(That being said, including the PID of the R process in the results
hash, to the effect that the code would be rerun in the case you
mention, might not be a bad idea. But that is a separate discussion.)
This does not need special built in support, e.g.,
#+name: R-pid
#+begin_src sh :var R=/usr/lib64/R/bin/exec/R
ps auxwww|grep $R|grep -v 'grep'|awk '{print $2}'
#+end_src
#+begin_src R :cache yes :var pid=R-pid
# code to perform side effect
x - 'side effect'
'done'
#+end_src
#+RESULTS[da16f09882a6295815db51247592b77c80ed0056]:
: done
Best,
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] [RFC] Simplify attributes syntax
Hello, Aaron Ecay aarone...@gmail.com writes: I think this patch is a welcome simplification. Would it be possible to merge the code that is used for reading babel header args (things like “:results output :file foo.txt”) with the code from the exporter? It is probably possible, but that's way beyond the scope of this patch. Note that the needs are very different for each reader. Export reader must be very simple (no escaping character) and only needs to read strings. OTOH Babel reader has to determine the type of data it reads (list, number...). Unless they are parsed by the same code, the two syntaxes will differ in subtle and headache-inducing ways (for users and developers). It can be troublesome for users in some corner cases (I think Babel reader uses none or no where Export reader expects nil). I doubt it will be for developers, who should know which reader they are working with. I could replace nil - nil with no - nil in the Export reader, but I don't like this solution. In English, there are no, No, NO, None, NONE, none... but in Elisp, there is only nil. Regards, -- Nicolas Goaziou
[O] [PATCH] Using org babel for generating ASCII art using PlantUML
Hi all, I find the PlantUML support very useful to generate diagrams when presenting designs, but unfortunately, I quite frequently have to send simple descriptions requiring ASCII only. Since PlantUML support generation of ASCII-art diagrams, I updated the org babel PlantUML support to generate ASCII art in place when no :file parameter is provided. Patch is attached. Just my few cents, Mats Kindahl -- Senior Principal Software Developer Oracle, MySQL Department diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el index c17d444..b4e2b01 100644 --- a/lisp/ob-plantuml.el +++ b/lisp/ob-plantuml.el @@ -37,7 +37,7 @@ (require 'ob) (defvar org-babel-default-header-args:plantuml - '((:results . file) (:exports . results)) + '((:exports . results)) Default arguments for evaluating a plantuml source block.) (defcustom org-plantuml-jar-path nil @@ -46,33 +46,43 @@ :version 24.1 :type 'string) +(defvar org-babel-plantuml-ext-alist + '((svg . -tsvg) +(eps . -teps) +(atxt . -txt) +(png . )) + Switch to use for different file name extensions.) + +(defun org-babel-plantuml-switch (filename) + (concat + (if filename + (let ((ext (file-name-extension filename))) + (or (cdr (assoc ext org-babel-plantuml-ext-alist)) + (error Unrecognized file name extension '%s' ext))) + -txt))) + (defun org-babel-execute:plantuml (body params) Execute a block of plantuml code with org-babel. This function is called by `org-babel-execute-src-block'. (let* ((result-params (split-string (or (cdr (assoc :results params)) ))) - (out-file (or (cdr (assoc :file params)) - (error PlantUML requires a \:file\ header argument))) + (out-file (cdr (assoc :file params))) (cmdline (cdr (assoc :cmdline params))) - (in-file (org-babel-temp-file plantuml-)) (java (or (cdr (assoc :java params)) )) (cmd (if (not org-plantuml-jar-path) (error `org-plantuml-jar-path' is not set) (concat java java -jar (shell-quote-argument (expand-file-name org-plantuml-jar-path)) - (if (string= (file-name-extension out-file) svg) - -tsvg ) - (if (string= (file-name-extension out-file) eps) - -teps ) - -p cmdline - (org-babel-process-file-name in-file) - - (org-babel-process-file-name out-file) + (org-babel-plantuml-switch out-file) + -p cmdline + (if out-file + (concat(org-babel-process-file-name out-file)) + ) (unless (file-exists-p org-plantuml-jar-path) (error Could not find plantuml.jar at %s org-plantuml-jar-path)) -(with-temp-file in-file (insert (concat @startuml\n body \n@enduml))) -(message %s cmd) (org-babel-eval cmd ) -nil)) ;; signal that output has already been written to file +(message %s cmd) +(let ((result (org-babel-eval cmd (concat @startuml\n body \n@enduml + (if (string= result ) nil result (defun org-babel-prep-session:plantuml (session params) Return an error because plantuml does not support sessions.
Re: [O] asynchronous exporter and babel confirmation
Nicolas Goaziou writes: I will wait for this patch to be committed. Done in commit 4f7d514f13. The double hyphens have been omitted based on a discussion with Eric Schulte. 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
[O] Create course material with org-mode
Hi, I plan to create new course materials for teaching at university level. These materials should contain - a printable course script - an interactive web-course - lecture slides - exercises - exams I'm looking for a system which enables me to keep all materials together and to reuse as much as possible the same source files. E.g., for a particular topic, I would love to create all the above materials within a single file. This would help me to keep it among all materials coherent, correct errors and do updates effectively and save (hopefully) a lot of time. I was looking into different directions like using HTML5, LaTeX, etc. However, I didn't find a perfect solution yet. I know many of you do similar work and hence, I really would love to hear about any ideas, tricks, systems or solutions. Furthermore, I wonder how much I could use org-mode (to make this thread not off-topic ;)) to solve the above task. Thanks Torsten
Re: [O] [PATCH] ob-core: do not ask for confirmation if cached value is current
Based on discussion with Nicolas Goaziou and Eric Schulte, this patch has been refactored and reimplemented as a patch series. Eric Schulte has contributed additional improvements. The functionality is now in Org. 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] [RFC] Org syntax (draft)
Hi Nicolas, here are my first comments. I'm still trying to wrap my head around some things, so if I'm off the map on something, please be patient. Do you mind if I fix some obvious typos directly on Worg or do you'd rather want patches? Nicolas Goaziou writes: 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. Blank lines or empty lines are also context-free syntactical elements, I'd think. Three categories are used to classify these environments: “Greater elements”, “elements”, and “objects”, from the broadest scope to the narrowest. It might be easier to talk about those things if Greater Element was called Collection to perhaps keep with the thingies theme of naming the syntax. 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. Here's my main contention with that model: I think there should be an greater element, maybe named paragraph block that translates into a paragraph at the backend level. Most backends will have a paragraph model that is much less limited than what the current definition of an Org paragraph is. This could be optionally be an implicit greater block that is defined by the presence or absence of blank lines between elements, I'd think. 3.1 Greater Blocks ── The same naming confusion as with the various elements, for now I'd link to think of these as Box. Greater blocks consist in the following pattern: ╭ │ #+BEGIN_NAME PARAMETERS │ CONTENTS │ #+END_NAME ╰ I'm beginning to wonder if these should have the same syntax as blocks. Maybe that's a too fine a distinction visually, but adding a colon would disambiguate the greater blocks from the normal ones. In other words #+BEGIN_CENTER: humdum … #+END_CENTER: would be a center block, while #+BEGIN_CENTER humdum … #+END_CENTER would be an export block for the center backend. 4.2 Blocks ── Like [greater blocks], pattern for blocks is: ╭ │ #+BEGIN_NAME DATA │ CONTENTS │ #+END_NAME ╰ […] DATA can contain any character but a new line. I'd keep with PARAMETERS here. If NAME is a string matching the name of any export back-end loaded, the block will be an “export block”. Conversely, blocks that are not having a recognizable name will simply insert their content as if the block markers were not there, e.g. it seems to treat these as parsed blocks. I don't think this should happen, instead Org should parse this as an unknown export backend and drop the content with a warning, not unlike a comment. This will be a major sticking point with external parsers: they'd otherwise need to know about the Org export backends to when to use the content of the block and when not. A portable Org document should be able to specify which export backends it expects to be available (and maybe what standard backend it is derived from) to elicit the correct behaviour. CONTENTS can contain any character, including new lines. Though it will only contain Org objects if the block is a verse block. Otherwise, contents will not be parsed. Would it make sense to make a general distinction between parsed and non-parsed blocks based on some configuration, even though this would produce the same issue as with export backends? I suggest to remove angle links. If one needs spaces in PATH, she can use standard link syntax instead. They are very ubiquitous on certain platforms, so copypaste would be made frustrating there if you'd need to re-format them each time around. 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] asynchronous exporter and babel confirmation
Hello, Achim Gratz strom...@nexgo.de writes: Done in commit 4f7d514f13. The double hyphens have been omitted based on a discussion with Eric Schulte. Applied to ox.el in commit 69c617c. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Create course material with org-mode
Torsten Wagner torsten.wag...@gmail.com writes: I plan to create new course materials for teaching at university level. slightly OT, but you could have a look at LaTeX package ,-- | http://www.ctan.org/pkg/tcolorbox `-- and its manual ,- | http://mirrors.ctan.org/macros/latex/contrib/tcolorbox/tcolorbox.pdf `- its well suited for presenting source-code output as well as exercises solutions. -- cheers, Thorsten
Re: [O] [PATCH] Using org babel for generating ASCII art using PlantUML
Mats Kindahl mats.kind...@oracle.com writes: Hi all, I find the PlantUML support very useful to generate diagrams when presenting designs, but unfortunately, I quite frequently have to send simple descriptions requiring ASCII only. Since PlantUML support generation of ASCII-art diagrams, I updated the org babel PlantUML support to generate ASCII art in place when no :file parameter is provided. Patch is attached. Just my few cents, Mats Kindahl Hi Mats, Thanks for sharing this patch, I think defaulting to text output when no :file argument is given is a great idea, and your patch looks good. Unfortunately, being part of Emacs, Org-mode's contribution rules are pretty strict. Would you be willing to go through the Emacs Copyright attribution process described here [1] so that we may apply this patch? Thanks, Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [RFC] Org syntax (draft)
Hello,
Achim Gratz strom...@nexgo.de writes:
Do you mind if I fix some obvious typos directly on Worg or do you'd
rather want patches?
Please go ahead. This is on Worg so anyone can improve it.
Nicolas Goaziou writes:
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.
Blank lines or empty lines are also context-free syntactical elements,
I'd think.
No, the aren't, as they belong to the broadest element ending before
them. So you need to know what this element is.
Three categories are used to classify these environments: “Greater
elements”, “elements”, and “objects”, from the broadest scope to the
narrowest.
It might be easier to talk about those things if Greater Element was
called Collection to perhaps keep with the thingies theme of naming
the syntax.
Collection could also be ambiguous as a paragraph may be seen as
a collection of objects.
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.
Here's my main contention with that model: I think there should be an
greater element, maybe named paragraph block that translates into a
paragraph at the backend level. Most backends will have a paragraph
model that is much less limited than what the current definition of an
Org paragraph is. This could be optionally be an implicit greater
block that is defined by the presence or absence of blank lines between
elements, I'd think.
I don't get it. What would be the exact definition of a paragraph
block? What limitations are you talking about?
3.1 Greater Blocks
──
The same naming confusion as with the various elements, for now I'd
link to think of these as Box.
This naming was for the org-syntax file only. Greater blocks means
nothing for org-element.el, but center block, quote block, special
block do.
Greater blocks consist in the following pattern:
╭
│ #+BEGIN_NAME PARAMETERS
│ CONTENTS
│ #+END_NAME
╰
I'm beginning to wonder if these should have the same syntax as blocks.
Maybe that's a too fine a distinction visually, but adding a colon would
disambiguate the greater blocks from the normal ones. In other words
#+BEGIN_CENTER: humdum
#+END_CENTER:
would be a center block, while
#+BEGIN_CENTER humdum
#+END_CENTER
would be an export block for the center backend.
I agree. More on that below.
4.2 Blocks
──
Like [greater blocks], pattern for blocks is:
╭
│ #+BEGIN_NAME DATA
│ CONTENTS
│ #+END_NAME
╰
[…]
DATA can contain any character but a new line.
I'd keep with PARAMETERS here.
Ok. Just fix it.
If NAME is a string matching the name of any export back-end loaded,
the block will be an “export block”.
Conversely, blocks that are not having a recognizable name will simply
insert their content as if the block markers were not there, e.g. it
seems to treat these as parsed blocks.
You are talking about special blocks, right? They have a special
purpose. In latex back-end,
#+begin_special
...
#+end_special
becomes
\begin{special}
...
\end{special}
IOW this is an Org feature.
I don't think this should happen, instead Org should parse this as an
unknown export backend and drop the content with a warning, not unlike
a comment.
This would remove special blocks.
This will be a major sticking point with external parsers: they'd
otherwise need to know about the Org export backends to when to use the
content of the block and when not. A portable Org document should be
able to specify which export backends it expects to be available (and
maybe what standard backend it is derived from) to elicit the correct
behaviour.
I agree, as notified above. If we want to separate Org /format/ from
Emacs, we need to separate special blocks from export blocks. The former
cannot be the fallback type when the latter isn't recognized.
In that case, a different syntax for export blocks would be needed.
Maybe the colons you suggested above. I think that something more
visible would be better, though.
CONTENTS can contain any character, including new lines. Though it
will only contain Org objects if the block is a verse block.
Otherwise, contents will not be parsed.
Would it make sense to make a general distinction between parsed and
non-parsed blocks based on some configuration, even though this would
produce the same issue as with export backends?
This is inherent from the block type. This mustn't be configurable.
There is no point in parsing a src-block, for example. On the other
hand, if you don't parse (partially) contents of a verse-block, you get
an example-block, and one of them
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). 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 That works nicely. I found the error and orgmanual.pdf is now produced without errors. I found that the common combination of `keybinding org-command', which I simplified in the translation to org, looks good in the info file but not in the pdf file, where the elements weren't easy to distinguish visually. I've changed all these to `keybinding, org-command' which still looks simple but works (for me) in both info and pdf formats. Is the html version of the Org manual generated from the .texi source? If so, could you show me how to augment Makefile so the html document is generated by `make orgmanual'? I want to check if the html document looks reasonable. My next step will be to bring orgmanual up-to-date with the changes that have been made to org.texi since I started the translation several months ago. There are still about a half dozen places where I've substituted a `XXX' placeholder for a problem I haven't been able to solve. Sections with problems have been marked FIXME. Most of the problems have to do with exporting a special character, such as `\' or `,'. I'm afraid these nagging problems will need to be solved by someone clever in the Org community. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] Editing folded headlines and ellipses
Hi Bastien and others, I remember someone (maybe Bastien) putting in a safeguard quite sometime back that would unfold a headline with a warning when you tried to edit near the ellipses. This was to protect against accidental edits. I see this not there anymore, can we have it back? I tried looking for the thread/patch but couldn't find it. Hope this helps, PS: Patchwork seems to be down. -- Suvayu Open source is the future. It sets us free.
Re: [O] GFDL
On 10/03/13 02:11, Carsten Dominik wrote: On 9.3.2013, at 16:02, Achim Gratz strom...@nexgo.de wrote: Carsten Dominik writes: I am wondering, are we required to include the full text of the GFDL in the manual? I find it a big waste of space and feed that a link should do. But I have not been able to find the rules that say what needs to be included in a document distributed under GFDL? http://www.gnu.org/licenses/fdl-howto http://www.gnu.org/licenses/fdl-1.3.html To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:[…] I read this: If there's just one document, it must contain the license in full, if there are several that reference each other, it is enough to include it in the top-level document. Yes it sounds like it. Thank you for the link. I still think it is crazy to add these 8 pages to each time someone prints it Regards - Carsten I also think it is crazy, and I don't think it is necessary. Although the FSF might prefer you to include the whole licence, in my opinion there is no need to do so. The manual is released under the GFDL and so is subject to the terms of the license. In my view, this statement from Creative Commons is accurate: How can I license my work? There is no registration to use the Creative Commons licenses. Licensing a work is as simple as selecting which of the six licenses best meets your goals, and then marking your work in some way so that others know that you have chosen to release the work under the terms of that license. The important part here is that others know, that is, it must be very clear that the manual is released subject to the GFDL. As a courtesy, a link to the GFDL or including a copy as part of the package might be nice. Alan -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
[O] Fixing footnote HTML
On 2/27/13, Samuel Wales samolog...@gmail.com wrote: On 2/13/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Anyway, if you send the correct HTML that should be generated, I will fix it. Probably all that needs to be done is to not use a table. I tested this by manually removing table td tr and their closing tags. I am referring to these: (defun org-html-format-footnote-definition (fn) (defun org-html-footnote-section (info) They output a table, which looks IMO very confusing in both w3m and Firefox. The old exporter worked fine. The solution IMO is to remove the table tags. I tested it in Firefox and w3m. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. Just like AIDS, it attacks MANY body systems. ANYBODY can get it. There is NO hope without activist action. This means YOU.
Re: [O] Has anybody noticed ellipses instead of the top line of the window?
On 6 December 2012 19:43, Brian van den Broek brian.van.den.br...@gmail.com wrote: On 6 Dec 2012 13:46, Samuel Wales samolog...@gmail.com wrote: Has anybody encountered ellipses instead of the first line of the window? On 8/21/12, Samuel Wales samolog...@gmail.com wrote: === beginning of window ... *** Above all Above all, it is a collapse of the uneasy and corrupt I have. Haven't noticed a pattern; I always get mildly concerned and often am motivated to reassure myself there's be no data loss. Never has been. Hi all, I've found one repeatable way to generate these unwanted ellipses. I have an org file with two top-level headings. The second is small and containing only a few lines of text. The first is huge and has a crypt tag and thus is encrypted with org-crypt. (For obvious reasons, I am unwilling to post the file.) Steps: 1) Visit the file 2) Call org-decrypt-entry on the crypt heading 3) Follow a link at the top of the crypt tree to a heading deep within that tree. Ensure that it is not the case that the entire tree is expanded (decription occurs below) 4) Edit somewhere in the heading 5) Save the file (C-x C-s). This causes the heading to be encrypted again. 6) M-x undo to restore the file to its unencrypted state. 7) Observe that the top of the buffer has the ellipses and all data before the heading being edited can no longer be seen. The file looks roughly like: # -*- buffer-auto-save-file-name: nil; -*- Two lines of description not in any heading * vault :crypt: ** Quick links ** stuff ** other stuff ** still more stuff ** more stuff still Each of the various stuff headings (there are plenty more) may have several layers of descendant headings. In the Quick links heading there are org links to the most used headings. At step (3) in the recipe above, I expand the Quick links heading and follow one of the links there which points to a heading buried within the tree. I hit TAB to expand that heading. (It has siblings both before and after.) There is a `...' at the end of the heading when it is expanded. The ellipses observed at (7) seem to appear either before the heading that follows the top level tree that I edited (so, right before `more stuff still' if I edited a tree several layers in `still more stuff' *or* immediately before all of the body text of the headline that I edited and taking the place of the subtree headline to which the link that I followed points. (I've not discerned a pattern, but it seems to depend upon the expansion state around the edit or the location of the cursor when I save; I am not sure, though.) Either way, M-x beginning-of-buffer never takes me past the `...'. Following the same steps but first ensuring that the entire tree is fully expanded does not result in the `...'. I hope both that my description is tolerably clear and that it is some help in the ellipses bug hunt. Best, Brian vdB
[O] [PATCH] Make `org-contacts-message-complete-function' work with byte compilation
Without this patch (when I am _byte-compiling_ org-contacts.el), I am getting error messages like this (when attempting address completion via `completion-at-point' and `org-contacts-message-complete-function'): Symbol's function definition is void: remove-duplicates Symbol's function definition is void: some With this patch, it seems to be working as expected. --- Disclaimer: I'm no Elisp expert. Maybe this should be solved differently. contrib/lisp/org-contacts.el | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index ab44a7b..ac5ff6d 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -36,10 +36,8 @@ ;; ;;; Code: -(eval-when-compile - (require 'cl)) - (eval-and-compile + (require 'cl) (require 'org)) (require 'gnus-util) (require 'gnus-art) -- 1.8.2.rc1
[O] Help with babel results
I'm working with an sqlite database of songs, and I've run into trouble
with titles that start with a '(' (for example,
(I Can't Get No) Satisfaction). 'Verbatim' results work:
#+BEGIN_SRC sqlite :db test-db :results verbatim
.mode csv
.separator |
drop table playlist;
create table playlist (title varchar, artist varchar);
insert into playlist values((I Can't Get No) Satisfaction,
Rolling Stones);
select * from playlist;
#+END_SRC
#+RESULTS:
: (I Can't Get No) Satisfaction|Rolling Stones
But :results table' reports:
eval: Symbol's function definition is void: I
It looks to me like org is trying to interpret (I Can't Get No) as emacs
lisp, but I haven't been able to figure out how to prevent that.
Advice would be greatly appreciated.
Kind Regards,
Mike
signature.asc
Description: OpenPGP digital signature
[O] Macros expanded in Org buffer
Aloha all, I'm not sure how this happened, but chapter 2 of orgmanual now has all the macros replaced by their expansions. You can see this here: https://github.com/tsdye/orgmanual/blob/master/orgmanual.org Please don't ask for an ECM! 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] Fixing footnote HTML
Samuel Wales samolog...@gmail.com writes: On 2/27/13, Samuel Wales samolog...@gmail.com wrote: On 2/13/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Anyway, if you send the correct HTML that should be generated, I will fix it. Probably all that needs to be done is to not use a table. I tested this by manually removing table td tr and their closing tags. I am referring to these: (defun org-html-format-footnote-definition (fn) (defun org-html-footnote-section (info) They output a table, which looks IMO very confusing in both w3m and Firefox. The old exporter worked fine. The solution IMO is to remove the table tags. It is preferable to introduce a footnote, preamble, postamble, toc, bibliography etc as pseudo-elements, with Footnotes and Bibliograph attachable to beginning or end of chapters. This way the HTML exporter can do some light-weight HTML transcoding. Folks can derive from this base HTML exporter and surround their content to heart's pleasure. See my other response to Rick, where I split current exporter to html and HTML backends and have him derive from html backend. I tested it in Firefox and w3m. Catering to one off requests - reading on w3m or export to HTML5, slidy, whatever etc - is exactly what the above pseudo-elements will avoid. People can add their own translators instead of relying on the base HTML exporter for one-off changes. I am sure Samuel will remind us infinitely if we forget about it. As an aside, I would like the following to be cleared before a release actually happens. 1. I would like to split the HTML exporter if pseudo-elements are made available to me. 2. I also want the CSS stylenames to be regularized and improved. 3. CSS stylesheets to be pulled out of the exporter so that one can have users contributing Org themes. A moving CSS stylenames will prevent proliferation of themes. 4. I want support for Htmlfontify as the default fontifier. Htmlize not being part of Emacs shouldn't be the default fontifier. What is mostly preventing me is my poor knowledge of HTML and CSS and my own laziness. ps: I would recommend that release happen just prior to a merge in to Emacs-24.4 and Emacs-25. Considering the requests that happen on HTML front, I feel that export tools can be improved in small and useful ways before freezing their base form. Samuel --
Re: [O] Fixing footnote HTML
Jambunathan K kjambunat...@gmail.com writes: They output a table, which looks IMO very confusing in both w3m and Firefox. The old exporter worked fine. The solution IMO is to remove the table tags. I don't think footnotes export are confusing. I have seen people using it and not complain about it. Unless you say why it is confusing, I would count the above statement as just mis-information and not a fact that other parties could agree with. --
Re: [O] [RFC] Org syntax (draft)
Nicolas Do you mind if I fix some obvious typos directly on Worg or do you'd rather want patches? Please go ahead. This is on Worg so anyone can improve it. Please consider adding the Org spec (and also the exporter reference) document to the Org manual. This will be a good excuse for exercising the TexInfo exporter and see where it leads. Committing to Org or Worg has same load cycle. I feel there is more value if it is right within the Org manual (i.e, part of Emacs). Only reason you may want to have it on Worg is possibly because it is likely to be read by wider audience. People seem to like browsers. (You can consider building a standalone PDF/HTML document out of .texi sources and have people read it) --
Re: [O] Fixing footnote HTML
On 3/9/13, Jambunathan K kjambunat...@gmail.com wrote: I am sure Samuel will remind us infinitely if we forget about it. Unless you say why it is confusing, I would count the above statement as just mis-information and not a fact that other parties could agree with. You promised to leave: On 2/12/13, Jambunathan K kjambunat...@gmail.com wrote: I let go of my commit access sometime ago. Now, I am leaving this forum. Bastien asked you to ban yourself. You need to be taught to take a hint. Samuel Wales -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. It attacks MANY body systems. ANYBODY can get it. There is NO hope without activist action. This means YOU.
Re: [O] Fixing footnote HTML
Samuel Wales samolog...@gmail.com writes: On 3/9/13, Jambunathan K kjambunat...@gmail.com wrote: I am sure Samuel will remind us infinitely if we forget about it. Unless you say why it is confusing, I would count the above statement as just mis-information and not a fact that other parties could agree with. You promised to leave: On 2/12/13, Jambunathan K kjambunat...@gmail.com wrote: I let go of my commit access sometime ago. Now, I am leaving this forum. Bastien asked you to ban yourself. Samuel, I asked him to remove ox-html.el and he indicated how he wanted to proceed ahead. He wants ox-html.el in the tree and not GNU ELPA. As one who re-wrote ox-html.el I have every moral authority to accept or reject proposals or handle it the way I see fit. Bastien has the keys. Hehas commit rights, which I don't have. Tell me why Footnotes export is confusing and I will assure you a sensible debate. I indicated that it is not confusing. The responsibility is on you to convince me of your case. Sorry. The list has to learn to deal with me, even if that amounts to throwing the wares I have written out the window. You need to be taught to take a hint. Samuel Wales
Re: [O] [new exporter] [html] Tables of Contents
On 3/6/13, Bastien b...@altern.org wrote: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. Thanks, Thank you, Bastien. This has been necessary since around May of 2011. How do we make it a reality NOW? Samuel Wales -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. It attacks MANY body systems. ANYBODY can get it. There is NO hope without activist action. This means YOU.
Re: [O] [new exporter] [html] Tables of Contents
Samuel Wales samolog...@gmail.com writes: On 3/6/13, Bastien b...@altern.org wrote: Hello Jambunathan, You are not welcome on this list anymore, please ban yourself. Thanks, Thank you, Bastien. This has been necessary since around May of 2011. How do we make it a reality NOW? I said I want to be banned. Let me suggest ways: 1. Quarantine my posts. 2. Remove ox-html.el (atleast the lines I have made substantial modifications to) and ox-odt.el from Org repo. I will move the stuff to GNU ELPA and obsolete my work if a better replacement comes along. ox-html.el and ox-odt.el is no rocket science, if Bastien or Samuel or even a college intern sits for a day, I promise you they will do a better job than I have done. Don't talk, do. Write your own exporters and then ban me from the list. Otherwise it is just childish prant. Removing me from the list, without disowning my contributions is also ethically/morally reprehensible act which elders will condemn (silently or vocally) Bottomline: Who dares, wins. Samuel Wales --
Re: [O] [RFC] Org syntax (draft)
Hello, Jambunathan K kjambunat...@gmail.com writes: Please consider adding the Org spec (and also the exporter reference) document to the Org manual. This will be a good excuse for exercising the TexInfo exporter and see where it leads. Committing to Org or Worg has same load cycle. I feel there is more value if it is right within the Org manual (i.e, part of Emacs). Only reason you may want to have it on Worg is possibly because it is likely to be read by wider audience. People seem to like browsers. It is not ready to go into the manual in its current state. As specified in its title, it's nothing more than a draft. Some parts have to be rewritten, some information is missing, my notes have to be removed, etc. Once it becomes clear enough, Bastien may consider adding it to the manual. The same holds for the exporter document. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Using org babel for generating ASCII art using PlantUML
On 03/10/2013 12:23 AM, Eric Schulte wrote: Mats Kindahl mats.kind...@oracle.com writes: Hi all, I find the PlantUML support very useful to generate diagrams when presenting designs, but unfortunately, I quite frequently have to send simple descriptions requiring ASCII only. Since PlantUML support generation of ASCII-art diagrams, I updated the org babel PlantUML support to generate ASCII art in place when no :file parameter is provided. Patch is attached. Just my few cents, Mats Kindahl Hi Mats, Hi Eric, Thanks for sharing this patch, I think defaulting to text output when no :file argument is given is a great idea, and your patch looks good. OK. Good. Unfortunately, being part of Emacs, Org-mode's contribution rules are pretty strict. Would you be willing to go through the Emacs Copyright attribution process described here [1] so that we may apply this patch? Sure, I'll be back. Best wishes, Mats Kindahl Thanks, Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Senior Principal Software Developer Oracle, MySQL Department
[O] [Bug?] TexInfo conversion of Org export reference
I see following errors.
Saving file /home/kjambunathan/src/worg/dev/org-export-reference.texi...
Wrote /home/kjambunathan/src/worg/dev/org-export-reference.texi
Processing Texinfo file ./org-export-reference.texi ...
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3117: Misplaced {.
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3117: Misplaced }.
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3306: Cross reference
to nonexistent node `table-cell-starts-ends-header-p' (perhaps incorrect
sectioning?).
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3295: Cross reference
to nonexistent node `table-cell-starts-ends-header-p' (perhaps incorrect
sectioning?).
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3277: Cross reference
to nonexistent node `table-cell-starts-ends-header-p' (perhaps incorrect
sectioning?).
/home/kjambunathan/src/worg/dev/org-export-reference.texi:3267: Cross reference
to nonexistent node `table-cell-starts-ends-header-p' (perhaps incorrect
sectioning?).
/home/kjambunathan/src/worg/dev/org-export-reference.texi:231: Cross reference
to nonexistent node `back-end' (perhaps incorrect sectioning?).
makeinfo: Removing output file
`/home/kjambunathan/src/worg/dev/org-export-reference.info' due to errors; use
--force to preserve.
byte-code: INFO file ./org-export-reference.info wasn't produced: [incorrect
sectioning] [syntax error]
