Re: [O] Regarding commmit: org.texi (History and Acknowledgments): Remove Jambunathan from my own acknowledgments
Bastien b...@altern.org writes: Hi, t...@tsdye.com (Thomas S. Dye) writes: * Jambunathan K contributed the ODT exporter. Perhaps this is the place to flesh out your contributions? The line seems somewhat dated to me. I update this line to include the rewrite of the HTML exporter. If there are other important contributions to the code or to the community (e.g., bug reports, bug fixes, etc.), I will include them here. Fair enough. The acknowledgements can be removed or altered only if there is reason enough to justify it. Remember, you are a maintainer of a community project and you really don't have a Carte Blanche to do what pleases you. Just wanted to get that message straight. --
Re: [O] org-export raises stringp nil error
Bastien writes: I find it hard to draw a clear line between regressions and bugs, especially since Org 7.9.x versions are way behind the current Org master branch. A regression is a feature that is missing, incomplete, or buggy in the current HEAD that was present, complete, and correct in some ancestor of HEAD that preceded the feature freeze. If it's difficult to identify regressions by that definition, you probably should not even try to work on the Emacs prerelease branch except by request of the release engineer. Some release engineers (not me ;-) may restrict ancestor to be the previous released version. All release engineers I know restrict HEAD and ancestor to versions of the project they manage. ;-)
Re: [O] [new exporter] Captions for tables made by source blocks
Hello Achim, Achim Gratz wrote: Nicolas Goaziou writes: It's very easy to have a caption on the generated output: name the code. Hence, the following code block: #+NAME: calculation #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC will produce: #+RESULTS: calculation 2 If you add a caption to the results, like: #+CAPTION: Basic arithmetic #+RESULTS: calculation 2 you can update the source block without ever needing to remove the caption. Great. I could swear the last time I was trying this it would add a new result block on top of the old one, but I may have changed the name inbetween. The thing is: - you try with an unnamed block - you get an unnamed result block inserted - you name the block - you get a named result block inserted - you have to manually remove the unnamed result block It would still be nice (I think) if an unnamed source block would simply replace the next unnamed result block if there is one. I think this is a great proposition, which would make a lot of sense. Best regards, Seb -- Sebastien Vauban
Re: [O] org-export raises stringp nil error
Xue Fuqiao writes: On 03/08/2013 02:40 PM, Bastien wrote: I missed the distinction between pretest and release candidate. What's the difference between pretest and release candidate? A release candidate may be considered to be a kind of pretest. The difference (as Glenn already implied) is that in a release candidate the release engineer proposes to make exactly one change before release: remove rc from the version string and then roll the tarballs and announce. Only if the release is unusable (new crash, data corruption, or security hole since last pretest) will it be patched before release. The way to think about this is that a release candidate is only there to save face for the release engineer. Ordinary bugs aren't his problem any more. ;-)
Re: [O] org-export raises stringp nil error
From: Leo Liu sdl@gmail.com Date: Fri, 08 Mar 2013 15:16:57 +0800 Cc: emacs-de...@gnu.org, emacs-orgmode@gnu.org, Lele Gaifax l...@metapensiero.it Bundling [org-mode] in emacs doesn't help anybody. You never had to work for an organization whose network is closed to outside world, did you? In those situations, using package.el to seamlessly fetch unbundled packages is impossible, which makes building a full and functional Emacs a pain if important packages are left out of the bundle.
Re: [O] org-export raises stringp nil error
Date: Fri, 08 Mar 2013 15:47:57 +0800 From: Xue Fuqiao xfq.f...@gmail.com Cc: Bastien b...@altern.org, emacs-de...@gnu.org, emacs-orgmode@gnu.org, Lele Gaifax l...@metapensiero.it On 03/08/2013 02:40 PM, Bastien wrote: I missed the distinction between pretest and release candidate. What's the difference between pretest and release candidate? A release candidate builds a binary whose version is the same as the upcoming release (24.3 in this case, as opposed to 24.2.XX for the pretests), and will become the release (by just renaming the tarball) if no serious problems are discovered.
Re: [O] org-export raises stringp nil error
From: Stephen J. Turnbull step...@xemacs.org Date: Fri, 08 Mar 2013 17:27:56 +0900 Cc: Lele Gaifax l...@metapensiero.it, emacs-de...@gnu.org, emacs-orgmode@gnu.org, Bastien b...@altern.org [...] in a release candidate the release engineer proposes to make exactly one change before release: remove rc from the version string and then roll the tarballs and announce. Not even that: the release candidate already reports its version as 24.3, so all is needed is to rename the tarball and upload to ftp.gnu.org. Of course, now that some problems _have_ been found, a new tarball will be needed.
Re: [O] org-export raises stringp nil error
Thanks all for the answers, quite educational to me (at least). -- Bastien
[O] Best way of plotting duration (hms) data with R?
Hi, I have some data representing durations in an Org file: | *Run* | *reference* | *test30*| *test31*| *test32*| |---+-+-+-+-+ | Dur 2 | 00h 00' 32 | 00h 00' 44 | 00h 00' 39 | 00h 01' 05 | | Dur 3 | 00h 00' 31 | 00h 00' 41 | 00h 00' 45 | 00h 01' 13 | | Dur 4 | 00h 05' 46 | 00h 21' 54 | 00h 40' 10 | 00h 55' 02 | | Dur 5 | 00h 03' 51 | 00h 13' 37 | 00h 23' 07 | 00h 28' 54 | | Dur 7 | 00h 06' 49 | 00h 28' 48 | 00h 35' 23 | 01h 03' 17 | | Dur 8 | 00h 06' 47 | 00h 22' 54 | 00h 47' 42 | 01h 02' 08 | I would like to plot these using R and I'm not sure what approach to take. One way would be to do some Org/Calc magic to convert all the data to, say seconds, and the pass the data to R. My problem with this is that I can't work out how to convert from HMS in Calc, let alone how this would look in Org. The other way would be to pass the data directly to R. However, dealing with durations in R has always seemed very clumsy to me, everything being much more geared towards date-times. I'd be grateful for any pointers on this. Cheers Loris -- no sig is good sig
Re: [O] org-export raises stringp nil error
Eli Zaretskii e...@gnu.org writes: From: Leo Liu sdl@gmail.com Date: Fri, 08 Mar 2013 15:16:57 +0800 Cc: emacs-de...@gnu.org, emacs-orgmode@gnu.org, Lele Gaifax l...@metapensiero.it Bundling [org-mode] in emacs doesn't help anybody. You never had to work for an organization whose network is closed to outside world, did you? In those situations, using package.el to seamlessly fetch unbundled packages is impossible, which makes building a full and functional Emacs a pain if important packages are left out of the bundle. Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. -- Joakim Verona
Re: [O] org-export raises stringp nil error
Hi Joakim, joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. Thanks for reminding us of this idea, I clearly see the benefits. As long as Org is distributed in Emacs, I personally have no problem. -- Bastien
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. PS: This is similar to my plan of creating org-contrib.git as a spin off from org-mode.git. There would be two repositories and contrib/ would still be packaged in Org tarballs. org-mode.git would contain the bare Org, the one similar to the one in GNU ELPA, for later distribution within Emacs tarballs. -- Bastien
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. I don't know that I'd go so far as to include all of CC-mode, but more than once I've missed some of the stuff not included in core XEmacs. The bootstrapped Emacs should be a fully functional editor, hopefully with some features useful for editing Emacs' own sources.
[O] RFC: Creating a new org-contrib.git repository
Hi all, the idea has been surfacing here and there on the list, time to get your feedback on the idea and your help on its technical aspects. I plan to extract org-contrib.git from org-mode.git. The org-*tar.gz/zip packages would distribute the contrib/ directory as they do now, so there would be no change for users installing from these archives. For users would use Org from git, they would just need to update a git submodule, then all files would be in contrib/ as they are now. So on the overall, this change would only affect developers: those who contribute to Org's core would push commits to org-mode.git and those who contribute to contrib/ would push commits to org-contrib.git. The advantage is (1) to separate Org's core logs (the one that are further merged into Emacs) from the org-contrib.git logs, and (2) to open org-contrib.git more widely, i.e., make it safe for anyone to push commits there with no fear of doing something wrong in Org's main repository. Also, remember that org-contrib.git would be open for contributors without signing FSF papers first. Does anyone think this is a very bad idea? Why? On the technical side: does anyone know what incantations needs to be done for this? I use git filter-branch (and its --tree-filter option) from time to time but I'm definitely not an expert. What we want at the end is: org-mode.git: with no contrib/ directory with no commits affecting the contrib/ directory only. with the maint and master branches org-contrib.git/ with all files from contrib/ with all commits affecting the contrib/ directory. with just a master branch Does anyone feel confident enough about this to provide a recipe? This will be the last structural move before releasing 8.0. Thanks in advance for your help! -- Bastien
Re: [O] [RFC] Org syntax (draft)
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. Thanks Nicolas -- yep, that's really *great*! -- Bastien
Re: [O] org-export raises stringp nil error
From: joa...@verona.se Date: Fri, 08 Mar 2013 10:15:07 +0100 Cc: b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, Leo Liu sdl@gmail.com, emacs-de...@gnu.org - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. It also has at least one demerits: people who track the trunk will not necessarily use the revisions of packages from elpa that will be included in Emacs tarballs. That will probably mean longer and more painful pretests, and some of the advantages of having a publicly accessible development trunk will be lost.
Re: [O] org-export raises stringp nil error
From: Dmitry Gutov dgu...@yandex.ru Cc: Eli Zaretskii e...@gnu.org, b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, Leo Liu sdl@gmail.com, emacs-de...@gnu.org Date: Fri, 08 Mar 2013 13:25:16 +0400 joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). That would certainly mean more problems for users to set them up with a particular version of Emacs, because there's no longer a clear way of getting the version of package X that correspond to Emacs version N.M.
Re: [O] [BUG] attr_latex in new exporter
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I think this behavior was introduced in the last week or so.
This in the Org file:
#+attr_latex: :height 2in
[[file:saa-fig/wet-dry.jpeg]]
yields this in LaTeX output:
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth,height=2in]{saa-fig/wet-dry.jpeg}
\end{figure}
I think when :height is set, then the default :width should not be
set.
I think it should be fixed. Could you confirm it?
Thank you for reporting it.
Regards,
--
Nicolas Goaziou
[O] was: [RFC] Org syntax (draft)
[ ... ] ╭ │ STARS KEYWORD PRIORITY TITLE TAGS ╰ Hi, my thanks too. BTW does that mean, stars are hard-coded in a way, they can't be replaced by another car? If yes, what about to keep the core more abstract? Best, Andreas
Re: [O] (no subject)
Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: BTW does that mean, stars are hard-coded in a way, they can't be replaced by another car? Yes, this is the case. If yes, what about to keep the core more abstract? This is a hard problem and I personally don't think it's worth tackling it. But I don't want to decourage anyone, of course :) -- Bastien
[O] latex italics in list, with quotation marks
Hi, Just wondering if there is a better way to italicise across more than two lines for a list item, currently this is the only way that works for me: - on the assumption of equilibrium: /``even if there is equilibrium at the pore sale, the upscaling, in this/ /if there is equilibrium at blah the equilibrium/'' Thanks, Myles
Re: [O] (no subject)
Am 08.03.2013 11:46, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: BTW does that mean, stars are hard-coded in a way, they can't be replaced by another car? Yes, this is the case. If yes, what about to keep the core more abstract? This is a hard problem Hi Bastien, can it be more difficult than related use of comment-start? [ ... ] Cheers, Andreas
Re: [O] (no subject)
Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: can it be more difficult than related use of comment-start? Yes -- check this FAQ: http://orgmode.org/worg/org-faq.html#sec-8-12 HTH, -- Bastien
Re: [O] (no subject)
Am 08.03.2013 12:05, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: can it be more difficult than related use of comment-start? Yes -- check this FAQ: http://orgmode.org/worg/org-faq.html#sec-8-12 HTH, Thanks, still non-believing :) (defcustom outline-regexp [*\^L]+ Regular expression to match the beginning of a heading. Any line whose beginning matches this regexp is considered to start a heading. Note that Outline mode only checks this regexp at the start of a line, so the regexp need not (and usually does not) start with `^'. The recommended way to set this is with a Local Variables: list in the file it applies to. See also `outline-heading-end-regexp'. :type 'regexp :group 'outlines) IMHO remains to make that buffer-local and use outline-regexp from inside org-mode. Andreas
Re: [O] (no subject)
Andreas Röhler andreas.roeh...@easy-emacs.de writes: IMHO remains to make that buffer-local and use outline-regexp from inside org-mode. Have a go and let us know :) -- Bastien
Re: [O] [new exporter] blank html page with org-info.js
Hi Henry, henry atting s...@online.de writes: But the file is not displayed, as mentioned before only in text browsers. Older .html files, created before the last pull still work properly. When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Thanks! -- Bastien
Re: [O] [new exporter] blank html page with org-info.js
Bastien b...@altern.org writes: Hi Henry, henry atting s...@online.de writes: But the file is not displayed, as mentioned before only in text browsers. Older .html files, created before the last pull still work properly. When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Org-mode version 8.0-pre (release_8.0-pre-5-ga646a2) Thanks! -- henry atts, web: http://literaturlatenight.de
Re: [O] (no subject)
Am 08.03.2013 12:23, schrieb Bastien: Andreas Röhler andreas.roeh...@easy-emacs.de writes: IMHO remains to make that buffer-local and use outline-regexp from inside org-mode. Have a go and let us know :) That should work already - to start with. commit 8cf6bc6faeb2a3b3fec0780e56a04ef0e13c3c62 Author: Andreas Roehler andreas.roeh...@online.de Date: Fri Mar 8 13:58:13 2013 +0100 Enable different heading chars, not just `*' Use variable `org-heading-char', customizable later on, instead of hard-coded `*' TINYCHANGE diff --git a/lisp/org.el b/lisp/org.el index 811506a..2db63ae 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -90,13 +90,17 @@ ;; `org-outline-regexp'. The only function still directly relying on ;; `outline-regexp' is `org-overview' so that `org-cycle' can do its ;; job when `orgstruct-mode' is active. +(defvar org-heading-char *) + (defvar org-outline-regexp \\*+ Regexp to match Org headlines.) +(setq org-outline-regexp (concat (regexp-quote org-heading-char) + )) (defvar org-outline-regexp-bol ^\\*+ Regexp to match Org headlines. This is similar to `org-outline-regexp' but additionally makes sure that we are at the beginning of the line.) +(setq org-outline-regexp-bol (concat ^ (regexp-quote org-heading-char) + )) (defvar org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$ Matches a headline, putting stars and text into groups.
Re: [O] (no subject)
Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 08.03.2013 12:23, schrieb Bastien: Andreas Röhler andreas.roeh...@easy-emacs.de writes: IMHO remains to make that buffer-local and use outline-regexp from inside org-mode. Have a go and let us know :) That should work already - to start with. Sorry, I should not let you go into that direction without a warning that I won't commit anything related to this myself. Btw, did you read the thread as the FAQ suggests? One reason why the stars are hardcoded (like the comment characters and other syntactic elements) is that Org files are used outside Emacs and allowing users to use something else here is calling for trouble. So -- just to let you know that it's fine playing with the idea and providing proof-of-concept patches, but there are many reasons why this cannot be considered. Also, we are trying to focus on 8.0 right now... help welcome! -- Bastien
Re: [O] [RFC] Org syntax (draft)
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. Fantastique! :-) I'm preciously saving this! François
[O] Tests failing
Hello, I just tried to upgrade org (master) to test a small bug, and I saw that two tests were failing: Test test-org-export/define-derived-backend backtrace: signal(ert-test-failed (((should (equal (quote ((:headline . test) ( ert-fail(((should (equal (quote ((:headline . test) (:headline . par (if (unwind-protect (setq value-5240 (apply fn-5238 args-5239)) (set (let (form-description-5242) (if (unwind-protect (setq value-5240 (a (let ((value-5240 (quote ert-form-evaluation-aborted-5241))) (let (f (let ((fn-5238 (function equal)) (args-5239 (list (quote ((:headline (lambda nil (let ((value-5234 (ert--gensym ert-form-evaluation-abor byte-code(\306\307!q\210\310\216\311 \312\216\313\314\315\316\3 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc byte-code(\306\307!\211\211r\310\311!q\210\312 d\313\223)L\210)\3 ert-run-test([cl-struct-ert-test test-org-export/define-derived-back ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st ert-run-tests(\\(org\\|ob\\) #[(event-type rest event-args) \306 ert-run-tests-batch(\\(org\\|ob\\)) ert-run-tests-batch-and-exit(\\(org\\|ob\\)) (let ((org-id-track-globally t) (org-id-locations-file (convert-stan org-test-run-batch-tests() call-interactively(org-test-run-batch-tests nil nil) command-execute(org-test-run-batch-tests) command-line-1((--eval (add-to-list 'load-path \./lisp\) --ev command-line() normal-top-level() Test test-org-export/define-derived-backend condition: (ert-test-failed ((should (equal '... (let ... ... ... ...))) :form (equal ((:headline . test) (:headline . parent)) ((:headline . test))) :value nil :explanation (proper-lists-of-different-length 2 1 ((:headline . test) (:headline . parent)) ((:headline . test)) first-mismatch-at 1))) FAILED 273/413 test-org-export/define-derived-backend Test test-org-export/derived-backend-p backtrace: signal(error (Unknown \test2\ back-end: Aborting export)) error(Unknown \%s\ back-end: Aborting export test2) org-export-barf-if-invalid-backend(test2) (progn (org-export-barf-if-invalid-backend (quote test2)) (let ((reg (let (org-export-registered-backends) (progn (let ((registeredp (ass (setq value-5254 (let (org-export-registered-backends) (progn (let ( (unwind-protect (setq value-5254 (let (org-export-registered-backend (if (unwind-protect (setq value-5254 (let (org-export-registered-bac (let (form-description-5255) (if (unwind-protect (setq value-5254 (l (let ((value-5254 (ert--gensym ert-form-evaluation-aborted-))) (le (lambda nil (let ((value-5248 (ert--gensym ert-form-evaluation-abor byte-code(\306\307!q\210\310\216\311 \312\216\313\314\315\316\3 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc byte-code(\306\307!\211\211r\310\311!q\210\312 d\313\223)L\210)\3 ert-run-test([cl-struct-ert-test test-org-export/derived-backend-p ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st ert-run-tests(\\(org\\|ob\\) #[(event-type rest event-args) \306 ert-run-tests-batch(\\(org\\|ob\\)) ert-run-tests-batch-and-exit(\\(org\\|ob\\)) (let ((org-id-track-globally t) (org-id-locations-file (convert-stan org-test-run-batch-tests() call-interactively(org-test-run-batch-tests nil nil) command-execute(org-test-run-batch-tests) command-line-1((--eval (add-to-list 'load-path \./lisp\) --ev command-line() normal-top-level() Test test-org-export/derived-backend-p condition: (error Unknown \test2\ back-end: Aborting export) FAILED 274/413 test-org-export/derived-backend-p Alan
[O] S-M-right problem in orgstruct-mode
Hello, I'm using a recently pulled orgmode from master. I have the following in an emacs-lisp buffer: #+BEGIN_SRC emacs-lisp ;; Local Variables: ;; eval: (orgstruct-mode 1) ;; orgstruct-heading-prefix-regexp: ;;; ;; End: #+END_SRC With such local variables, if I start with: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ;;; * Test2 #+END_SRC and do a shift-meta-right on the second line, I get: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ** Test2 #+END_SRC I also see the following appear in the *Messages* folder: #+BEGIN_SRC emacs-lisp org-get-tags-string: Not on a heading #+END_SRC Is this a (known) bug? Thanks, Alan
[O] S-M-right problem in orgstruct-mode
Hello, I'm using a recently pulled orgmode from master. I have the following in an emacs-lisp buffer: #+BEGIN_SRC emacs-lisp ;; Local Variables: ;; eval: (orgstruct-mode 1) ;; orgstruct-heading-prefix-regexp: ;;; ;; End: #+END_SRC With such local variables, if I start with: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ;;; * Test2 #+END_SRC and do a shift-meta-right on the second line, I get: #+BEGIN_SRC emacs-lisp ;;; * Test 1 ** Test2 #+END_SRC I also see the following appear in the *Messages* folder: #+BEGIN_SRC emacs-lisp org-get-tags-string: Not on a heading #+END_SRC Is this a (known) bug? Thanks, Alan
[O] Link colours in new Worg style
Hi Bastien and others, The new Worg style is amazing; the text is very clear and much more readable now. However I have a major complaint about the links. It seems the new style overrides my browser's colour setting for unvisited and visited links. I think this is extremely confusing. As per my setting, I have blue for unvisited links and purple for visited links. The new style overrides this to red for unvisited and blue for visited. Obviously you can see how this leads to a confusion. I would really appreciate it if this was left to the user and not determined by the webpage. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] org-export raises stringp nil error
From: Dmitry Gutov dgu...@yandex.ru Cc: l...@metapensiero.it, joa...@verona.se, emacs-de...@gnu.org, b...@gnu.org, emacs-orgmode@gnu.org, sdl@gmail.com Date: Fri, 08 Mar 2013 15:18:19 +0400 I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). That would certainly mean more problems for users to set them up with a particular version of Emacs, because there's no longer a clear way of getting the version of package X that correspond to Emacs version N.M. There won't be such correspondence. And therein lies the problem. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. When I install a package, I usually want its latest *stable* version that is compatible with the Emacs version I run. As great as compatibility stuff is, I trust testing more, as I need to do something each day that doesn't involve debugging Emacs and my other tools. Also think about various package managers for GNU/Linux distros, which need to specify on what version of Emacs package X depends.
Re: [O] org-export raises stringp nil error
On Fri, 08 Mar 2013 10:15:07 +0100 joa...@verona.se wrote: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. And there is also another way: Add a command line argument named `--slim', it can invoke Emacs with only the bare-minimum Emacs Lisp libraries needed for quick editing. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] (no subject)
Am 08.03.2013 14:12, schrieb Bastien: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Am 08.03.2013 12:23, schrieb Bastien: Andreas Röhler andreas.roeh...@easy-emacs.de writes: IMHO remains to make that buffer-local and use outline-regexp from inside org-mode. Have a go and let us know :) That should work already - to start with. Sorry, I should not let you go into that direction without a warning that I won't commit anything related to this myself. Hi Bastien, don't worry, didn't expect that for now or soon. Btw, did you read the thread as the FAQ suggests? Nothing different resp. new so far. Let's stress that solution in mind also would be quite simple. See the example patch. No-one would be compelled to change the default BTW, it would just open the possibility. One reason why the stars are hardcoded (like the comment characters and other syntactic elements) is that Org files are used outside Emacs and allowing users to use something else here is calling for trouble. Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred-- org-file while the default is active. But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the stars where expected. [ ... ]
Re: [O] [RFC] Org syntax (draft)
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. 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 : 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) 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 suggest adding : The number of stars defines the level of the headline. 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. 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 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. 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.] A section contains directly any greater element or element. Only a headline can contain a section. As an exception, text before the first headline in the document also belongs to a section. In a quoted headline contains a section, the latter will be considered as a “quote section”. s/In/If/ unsure: s/quote section/quoted section/ ? As an example, consider the following document: snip, useful example BACKEND is a string constituted of alpha-numeric characters, hyphens or underscores. I suggest: BACKEND is a string which is an element of (mapcar 'car org-export-registered-backends). OPTIONAL and VALUE can contain any character but a new line. Only keywords in `org-element-dual-keywords' can have an optional value. I guess OPTIONAL cannot contain a closing square bracket ] An affiliated keyword can appear on multiple lines if KEY belongs to `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND: VALUE”. I suggest s/on multiple lines/more than once/ PARAMETERS can contain any character, and can be omitted. any other than new line, I guess. CONTENTS can contain any element, but another greater block of the same type. What is the type of a greater block ? the /name/ ? I did have a quick look at the rest of your mail, and it is very nice to have all of it written down explicitly, so again a big thanks for all of this (and the rest of your) work. Unfortunately I don't have much time right now to read it thoroughtfully, so just one single comment : Even the LaTeX community suggests to use `\(...\)' over `$...$'. — ngz AFAIK that's not for technical reasons and also I would be curious to know who does that in real documents : '$' is so much more convenient. But one might think of rebinding $ to a command which would insert \( and \) appropriately within org-mode (see below). (OTOH, there are technical reasons for avoiding $$ and $$.) Here some elisp for the above behaviour : (defun
Re: [O] (no subject)
Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred-- org-file while the default is active. ... or if someone shares a file online using non-star character as the prefix for headlines: this file won't be processed by Org tools like org-ruby and the like. But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the stars where expected. Org files are not just for Emacs, that's were the problem lies... -- Bastien
Re: [O] org-export raises stringp nil error
Hi Xue, Xue Fuqiao xfq.f...@gmail.com writes: Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. Well, that's more an argument for switching to hg or git for Emacs repo, not really for trimming out packages from Emacs core. And there is also another way: Add a command line argument named `--slim', it can invoke Emacs with only the bare-minimum Emacs Lisp libraries needed for quick editing. That's what the require mechanism is for: libraries are not loaded until you require/load them. -- Bastien
Re: [O] [new exporter] blank html page with org-info.js
Hi Henry, henry atting s...@online.de writes: When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Org-mode version 8.0-pre (release_8.0-pre-5-ga646a2) This is now fixed, thanks! -- Bastien
Re: [O] [new exporter] blank html page with org-info.js
Hi Bastien, Bastien b...@altern.org writes: Hi Henry, henry atting s...@online.de writes: When was the last pull exactly? I fixed some issues recently in this area, the first versions of ox-html.el were not compatible with org-info.js. So what is M-x org-version RET exactly? Org-mode version 8.0-pre (release_8.0-pre-5-ga646a2) This is now fixed, thanks! Great! For me personally the switch to the new exporter is kind of hard but on the other hand it is not to difficult to imagine that it might be a lot harder for you; so... many thanks. -- henry atts, web: http://literaturlatenight.de
[O] [PATCH 1/3] Taskjuggler export: Fix a reference to a defcustom
* contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-task): Fix the reference to the target-version defcustom --- contrib/lisp/ox-taskjuggler.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 8db45e9..88641b8 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -721,7 +721,7 @@ a unique id will be associated to it. (and allocate (format purge %s\n allocate %s\n ;; Compatibility for previous TaskJuggler versions. - (if (= org-export-taskjuggler-target-version 3.0) allocate + (if (= org-taskjuggler-target-version 3.0) allocate allocations) allocate)) (and complete (format complete %s\n comptete)) -- 1.7.10.4 -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland - Die neue Online-Bibliothek der SBS: Mit wenigen Klicks zum Buch unter http://online.sbs.ch
[O] [PATCH 2/3] Taskjuggler export: Only create a milestone if node has no children
* contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-task): Fix the check whether a node has no children A milestone should only (automatically) be inserted if a node has no children and no duration defined. --- contrib/lisp/ox-taskjuggler.el | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 88641b8..9146dfd 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -696,14 +696,14 @@ a unique id will be associated to it. (effort (org-element-property :EFFORT task)) (milestone (or (org-element-property :MILESTONE task) - (and (org-element-map (org-element-contents task) 'headline - 'identity info t) ; Has task any child? - (not (or effort -(org-element-property :LENGTH task) -(org-element-property :DURATION task) -(and (org-taskjuggler-get-start task) - (org-taskjuggler-get-end task)) -(org-element-property :PERIOD task)) + (not (or (org-element-map (org-element-contents task) 'headline +'identity info t) ; Has task any child? + effort + (org-element-property :LENGTH task) + (org-element-property :DURATION task) + (and (org-taskjuggler-get-start task) + (org-taskjuggler-get-end task)) + (org-element-property :PERIOD task) (priority (let ((pri (org-element-property :priority task))) (and pri -- 1.7.10.4 -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland - Die neue Online-Bibliothek der SBS: Mit wenigen Klicks zum Buch unter http://online.sbs.ch
[O] [PATCH 3/3] Taskjuggler export: Target tj3 by default
* contrib/lisp/ox-taskjuggler.el (org-taskjuggler-target-version): The default target is now tj3 Since taskjuggler is not developed anymore and hardly any distributions carry it anymore we ought to target tj3 by default now. --- contrib/lisp/ox-taskjuggler.el |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el index 9146dfd..295fad1 100644 --- a/contrib/lisp/ox-taskjuggler.el +++ b/contrib/lisp/ox-taskjuggler.el @@ -182,7 +182,7 @@ the project. :group 'org-export-taskjuggler :type 'string) -(defcustom org-taskjuggler-target-version 2.4 +(defcustom org-taskjuggler-target-version 3.0 Which version of TaskJuggler the exporter is targeting. :group 'org-export-taskjuggler :type 'number) -- 1.7.10.4 -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland - Die neue Online-Bibliothek der SBS: Mit wenigen Klicks zum Buch unter http://online.sbs.ch
Re: [O] org-export raises stringp nil error
Bastien b...@altern.org wrote: Hi Xue, Xue Fuqiao xfq.f...@gmail.com writes: Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. Well, that's more an argument for switching to hg or git for Emacs repo, not really for trimming out packages from Emacs core. There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. I've been using it with no problems (afaict) for some years now. It may not have today's updates until tomorrow, but if you upgrade emacs every couple of months as I do, it should serve well. Nick
Re: [O] org-export raises stringp nil error
Nick Dokos nicholas.do...@hp.com writes: There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. This one is from savannah http://git.savannah.gnu.org/cgit/emacs.git --
Re: [O] org-export raises stringp nil error
Hi Nick, Nick Dokos nicholas.do...@hp.com writes: Bastien b...@altern.org wrote: Hi Xue, Xue Fuqiao xfq.f...@gmail.com writes: Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. Well, that's more an argument for switching to hg or git for Emacs repo, not really for trimming out packages from Emacs core. There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. FWIW, here is the one I'm using, from the Savannah server: http://git.savannah.gnu.org/cgit/emacs.git/ -- Bastien
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Bastien writes: Bastien, I think it would make sense to clear up this confusion by tagging 8dd2bfc291 with version 7.9.9 or 8.0-pre or something like that (must be an annotated tag, of course). That'll help to easier determine who's using the new and the old exporter. I used 8.0-pre -- thanks for the suggestion! Thanks, but you tagged a different commit. The commit I named is the one that moved the new exporter into core which I consider an important milestone. I suggest to add two extra annotated tags to account correctly (in the way version-to-list numbers things) for the history leading up to the 8.0 release: 8dd2bfc291 release_8.0-alpha (move the new exporter into core) ee3b3eb421 release_8.0-beta (remove /contrib/oldexp/) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] [BUG] attr_latex in new exporter
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I think this behavior was introduced in the last week or so.
This in the Org file:
#+attr_latex: :height 2in
[[file:saa-fig/wet-dry.jpeg]]
yields this in LaTeX output:
\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth,height=2in]{saa-fig/wet-dry.jpeg}
\end{figure}
I think when :height is set, then the default :width should not be
set.
I think it should be fixed. Could you confirm it?
There is a change, but not a fix.
Now I get this:
\begin{figure}[htb]
\centering
\includegraphics[width=0.7\textwidth,height=2in]{saa-fig/wet-dry.jpeg}
\end{figure}
I'm expecting this:
\begin{figure}[htb]
\centering
\includegraphics[height=2in]{saa-fig/wet-dry.jpeg}
\end{figure}
In other words, I'm looking to preserve the aspect ratio of the source
image.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] org-export raises stringp nil error
Jambunathan K kjambunat...@gmail.com writes: Nick Dokos nicholas.do...@hp.com writes: There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. This one is from savannah http://git.savannah.gnu.org/cgit/emacs.git Great minds think alike!! :) -- Bastien
Re: [O] [PATCH 1/3] Taskjuggler export: Fix a reference to a defcustom
Hi Christian, Christian Egli christian.e...@sbs.ch writes: * contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-task): Fix the reference to the target-version defcustom * contrib/lisp/ox-taskjuggler.el (org-taskjuggler--build-task): Fix the check whether a node has no children * contrib/lisp/ox-taskjuggler.el (org-taskjuggler-target-version): The default target is now tj3 Applied, thanks a lot for taking care of this! -- Bastien
Re: [O] Link colours in new Worg style
Hi Suvayu,
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
The new Worg style is amazing; the text is very clear and much more
readable now. However I have a major complaint about the links. It
seems the new style overrides my browser's colour setting for unvisited
and visited links. I think this is extremely confusing. As per my
setting, I have blue for unvisited links and purple for visited links.
The new style overrides this to red for unvisited and blue for visited.
Obviously you can see how this leads to a confusion. I would really
appreciate it if this was left to the user and not determined by the
webpage.
The previous stylesheet already used non-default colors for
non-visited and visited links. I just changed the colors.
Here is the setting you saw:
a {text-decoration: none; color: #FF; font-weight: 400;}
a:visited {text-decoration: none; color: #0066CC; font-weight: 400;}
a:hover {text-decoration: underline; color: #FF}
But you're right this is confusing, as this is the exact opposite
of... most browsers default settings. I swaped the color, let me
know if this looks better.
PS: The Unicorn-on-steroid logo will change, I'm waiting for my
friend to submit a new one. Perhaps the colors will change a bit
too.
--
Bastien
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
Hi Achim, Achim Gratz strom...@nexgo.de writes: Thanks, but you tagged a different commit. The commit I named is the one that moved the new exporter into core which I consider an important milestone. I suggest to add two extra annotated tags to account correctly (in the way version-to-list numbers things) for the history leading up to the 8.0 release: 8dd2bfc291 release_8.0-alpha (move the new exporter into core) ee3b3eb421 release_8.0-beta (remove /contrib/oldexp/) Okay, please go ahead. Thanks, -- Bastien
[O] Quotes not being converted correctly for LaTeX export
Hi,
It seems double and single quotes are not being exported properly for
LaTeX export. In a minimal Org instance, the following
* Test
Orange box
'Orange box'
is exported as
\section[Testing]{Testing}
\label{sec-1}
Orange box
'Orange box'
whereas I would expect the following
\section[Testing]{Testing}
\label{sec-1}
``Orange box''
`Orange box'
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] [PATCH] * lisp/org-src.el (org-edit-src-exit): disable undo.
Hi Aaron, Aaron Ecay aarone...@gmail.com writes: Currently, this function modifies the buffer-undo-list, which it should not. One can reproduce the undesirable behavior by creating a new org buffer and manually typing in the following text: #+begin_src emacs-lisp foo bar #+end_src Then press C-c ' twice to enter and exit the edit-src. Then press C-/ to undo: the cursor moves to the beginning of the source block. Further presses of C-/ undo the original text entry (as expected). Applied, thanks! -- Bastien
Re: [O] Quotes not being converted correctly for LaTeX export
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
Hi,
It seems double and single quotes are not being exported properly for
LaTeX export. In a minimal Org instance, the following
* Test
Orange box
'Orange box'
is exported as
\section[Testing]{Testing}
\label{sec-1}
Orange box
'Orange box'
whereas I would expect the following
\section[Testing]{Testing}
\label{sec-1}
``Orange box''
`Orange box'
#+OPTIONS: ':t
,[ C-h v org-export-with-smart-quotes RET ]
| org-export-with-smart-quotes is a variable defined in `ox.el'.
| Its value is nil
|
| Documentation:
| Non-nil means activate smart quotes during export.
| This option can also be set with the #+OPTIONS: line,
| e.g. ':t.
|
| You can customize this variable.
|
| This variable was introduced, or its default value was changed, in
| version 24.4 of Emacs.
`
Hope this helps,
--
Re: [O] org-exp-bibtex missing in git?
Aloha Rasmus, Rasmus ras...@gmx.us writes: t...@tsdye.com (Thomas S. Dye) writes: Indeed, but perhaps there is a better possible syntax. With Reftex the the link-way is OK, but I still think that we should think about whether there is a Better Wayᵀᴹ if Org was to add it officially. There are some recent projects adding citation support for higher level languages such as: 1. https://github.com/cboettig/knitcitations 2. http://wordpress.org/extend/plugins/kcite/ Thanks for these pointers--very interesting. It is certainly seductive to think about pointing to a location such as a DOI and coming away with a useful citation. In my experience, there is typically a fairly wide gap between the publisher's citation style and the information available digitally, even in standard MARC records from a library. I bridge this gap by hand with lots of changes to a Bib(La)TeX entry taken off the Web. It would certainly be a feat if this could be done automatically. Part of the problem is publisher's citation styles. BibLaTeX tries to canvas that field, and the result is pretty complex. The data needs for a fully catholic BibLaTeX database are impractically large. I'm not trying to throw cold water on a prospective project and would be an avid user of a working Better Way. 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] [BUG] attr_latex in new exporter
Hi Thomas, I think the following patch (on top of current master) will fix the problem: -cut-here- diff --git c/lisp/ox-latex.el w/lisp/ox-latex.el index d17dd60..eefb272 100644 --- c/lisp/ox-latex.el +++ w/lisp/ox-latex.el @@ -1811,9 +1811,9 @@ used as a communication channel. ;; It is possible to specify width and height in the ;; ATTR_LATEX line, and also via default variables. (width (format %s (cond ((plist-get attr :width)) - ((eq float 'figure) 0.7\\textwidth) + ((plist-get attr :height) ) + ((eq float 'figure) 0.7\\textwidth) ((eq float 'wrap) 0.48\\textwidth) - ((plist-get attr :height) ) (t org-latex-image-default-width (height (format %s (cond ((plist-get attr :height)) ((or (plist-get attr :width) -cut-here- Nicolas, I’m not sure I understand the logic behind (memq float '(figure wrap)) in the cond for setting height. I think that it would be very rare for someone to set the default height to something other than , but in the event that the user does so I don’t see why it shoudl make a difference whether the image is floating or not. -- Aaron Ecay
Re: [O] org-export raises stringp nil error
Bastien b...@gnu.org wrote: Jambunathan K kjambunat...@gmail.com writes: Nick Dokos nicholas.do...@hp.com writes: There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. This one is from savannah http://git.savannah.gnu.org/cgit/emacs.git Great minds think alike!! :) -- Bastien Thanks to both for pointing it out: I think I knew about it at some point in the past and had some problems with it. So I just tried changing my git config to pull from there (I should point out that I tried the git:// version of the URL) - I'm getting $ git pull fatal: The remote end hung up unexpectedly So two questions: o is the savannah repo http only? o and if so, it used to be the case that http was much slower than git - is that still the case? Thanks, Nick
Re: [O] Quotes not being converted correctly for LaTeX export
Hi Jambunathan and others,
On Fri, Mar 08, 2013 at 11:03:39PM +0530, Jambunathan K wrote:
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
It seems double and single quotes are not being exported properly for
LaTeX export. In a minimal Org instance, the following
* Test
Orange box
'Orange box'
is exported as
\section[Testing]{Testing}
\label{sec-1}
Orange box
'Orange box'
whereas I would expect the following
\section[Testing]{Testing}
\label{sec-1}
``Orange box''
`Orange box'
#+OPTIONS: ':t
,[ C-h v org-export-with-smart-quotes RET ]
[...]
Thanks for pointing this out, but I still think this is a bug for LaTeX
export. Quoting as .. produces incorrect output in LaTeX, the correct
forms are `..' or ``..''. This is even more important if you are
writing in a language that uses umlauts, and the situation can get
confusing as the character is used to specify umlauts.
This is worth a thought since the old exporter did it right without any
special settings.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Quotes not being converted correctly for LaTeX export
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
Hi Jambunathan and others,
On Fri, Mar 08, 2013 at 11:03:39PM +0530, Jambunathan K wrote:
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
It seems double and single quotes are not being exported properly for
LaTeX export. In a minimal Org instance, the following
* Test
Orange box
'Orange box'
is exported as
\section[Testing]{Testing}
\label{sec-1}
Orange box
'Orange box'
whereas I would expect the following
\section[Testing]{Testing}
\label{sec-1}
``Orange box''
`Orange box'
#+OPTIONS: ':t
,[ C-h v org-export-with-smart-quotes RET ]
[...]
Thanks for pointing this out, but I still think this is a bug for LaTeX
export. Quoting as .. produces incorrect output in LaTeX, the correct
forms are `..' or ``..''. This is even more important if you are
writing in a language that uses umlauts, and the situation can get
confusing as the character is used to specify umlauts.
This is worth a thought since the old exporter did it right without any
special settings.
I get GRAVE ACCENT and APOSTROPHE. You are requesting the exact same
chars. I am copy pasting from my latex buffer here.
``Orange box''
`Orange box'
Re: [O] org-export raises stringp nil error
Nick Dokos nicholas.do...@hp.com writes: Bastien b...@gnu.org wrote: Jambunathan K kjambunat...@gmail.com writes: Nick Dokos nicholas.do...@hp.com writes: There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. This one is from savannah http://git.savannah.gnu.org/cgit/emacs.git Great minds think alike!! :) -- Bastien Thanks to both for pointing it out: I think I knew about it at some point in the past and had some problems with it. So I just tried changing my git config to pull from there (I should point out that I tried the git:// version of the URL) - I'm getting $ git pull fatal: The remote end hung up unexpectedly So two questions: o is the savannah repo http only? o and if so, it used to be the case that http was much slower than git - is that still the case? Bzr user here. May be try one of these? , https://savannah.gnu.org/git/?group=emacs | Anonymous checkout: | | git clone git://git.savannah.gnu.org/emacs.git ` , http://savannah.gnu.org/maintenance/UsingGit | URL-s summary: | | git://git.sv.gnu.org/myproject.git - git lightweight protocol (read-only access) | ssh://git.sv.gnu.org/srv/git/myproject.git - developer access using SSH | http://git.sv.gnu.org/r/myproject.git - slow dumb protocol, http-based, for use behind fascist firewalls | | Web browser: http://git.sv.gnu.org/gitweb/ | | If you use ssh-based access, please verify the host keys first at | SshAccess (git.sv.gnu.org is the same host as cvs.sv.gnu.org). | | Note: there is at most a 1/2h delay between Git activation in the web | front-end, and its creation on the system. Basic commands | | Checkout: | | git clone git://git.sv.gnu.org/project.git | | Firewall checkout: if you're behind a outgoing-traffic-filtering firewall, you can use Git's dumb protocol via HTTP - note that this is SLOWER, both for you and Savannah. Avoid if possible, and please tell your local sysadmin to allow outgoing git traffic (port 9418): | | git clone http://git.savannah.gnu.org/r/project.git | | Note: we enabled git-http-backend (a CGI script) to speed up HTTP cloning, but this is still not the recommended protocol. | | Project member checkout: if you want to be able to push your changes back into the repository on savannah: | | git clone lo...@git.sv.gnu.org:/srv/git/project.git | ` Thanks, Nick --
Re: [O] Quotes not being converted correctly for LaTeX export
Hi, On Fri, Mar 08, 2013 at 11:25:25PM +0530, Jambunathan K wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Fri, Mar 08, 2013 at 11:03:39PM +0530, Jambunathan K wrote: [...] #+OPTIONS: ':t ,[ C-h v org-export-with-smart-quotes RET ] [...] Thanks for pointing this out, but I still think this is a bug for LaTeX export. Quoting as .. produces incorrect output in LaTeX, the correct forms are `..' or ``..''. This is even more important if you are writing in a language that uses umlauts, and the situation can get confusing as the character is used to specify umlauts. This is worth a thought since the old exporter did it right without any special settings. I get GRAVE ACCENT and APOSTROPHE. You are requesting the exact same chars. I am copy pasting from my latex buffer here. ``Orange box'' `Orange box' Sorry I think you misunderstood me. What I meant was following your suggestion fixes the issue for me. However I'm raising the question if having to explicitly set the ':t option to get ``..'' as output is a reasonable expectation for LaTeX export since the default is actually incorrect LaTeX. I hope I was clear this time around. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Link colours in new Worg style
Hi Bastien,
On Fri, Mar 08, 2013 at 06:24:12PM +0100, Bastien wrote:
Hi Suvayu,
Suvayu Ali fatkasuvayu+li...@gmail.com writes:
The new Worg style is amazing; the text is very clear and much more
readable now. However I have a major complaint about the links. It
seems the new style overrides my browser's colour setting for unvisited
and visited links. I think this is extremely confusing. As per my
setting, I have blue for unvisited links and purple for visited links.
The new style overrides this to red for unvisited and blue for visited.
Obviously you can see how this leads to a confusion. I would really
appreciate it if this was left to the user and not determined by the
webpage.
The previous stylesheet already used non-default colors for
non-visited and visited links. I just changed the colors.
Here is the setting you saw:
a {text-decoration: none; color: #FF; font-weight: 400;}
a:visited {text-decoration: none; color: #0066CC; font-weight: 400;}
a:hover {text-decoration: underline; color: #FF}
But you're right this is confusing, as this is the exact opposite
of... most browsers default settings. I swaped the color, let me
know if this looks better.
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.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] org-export raises stringp nil error
Jambunathan K kjambunat...@gmail.com wrote: So two questions: o is the savannah repo http only? o and if so, it used to be the case that http was much slower than git - is that still the case? Bzr user here. May be try one of these? , https://savannah.gnu.org/git/?group=emacs | Anonymous checkout: | | git clone git://git.savannah.gnu.org/emacs.git ` This seems to work. Thanks! Nick
Re: [O] Quotes not being converted correctly for LaTeX export
Suvayu Ali fatkasuvayu+li...@gmail.com writes: Hi, On Fri, Mar 08, 2013 at 11:25:25PM +0530, Jambunathan K wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Fri, Mar 08, 2013 at 11:03:39PM +0530, Jambunathan K wrote: [...] #+OPTIONS: ':t ,[ C-h v org-export-with-smart-quotes RET ] [...] Thanks for pointing this out, but I still think this is a bug for LaTeX export. Quoting as .. produces incorrect output in LaTeX, the correct forms are `..' or ``..''. This is even more important if you are writing in a language that uses umlauts, and the situation can get confusing as the character is used to specify umlauts. This is worth a thought since the old exporter did it right without any special settings. I get GRAVE ACCENT and APOSTROPHE. You are requesting the exact same chars. I am copy pasting from my latex buffer here. ``Orange box'' `Orange box' Sorry I think you misunderstood me. What I meant was following your suggestion fixes the issue for me. However I'm raising the question if having to explicitly set the ':t option to get ``..'' as output is a reasonable expectation for LaTeX export since the default is actually incorrect LaTeX. You should have simply stated. It works. Can we have the default setting changed? instead of Thanks ... but which I parse as Thanks ... but it doesn't work. Install a filter function for options (add-to-list 'org-export-filter-options-functions 'org-latex-options-function) (defun org-latex-options-function (info backend) (when (eq backend 'latex) (plist-put info :with-smart-quotes t))) If the above snippet doesn't work you can search the mailing list for Nicolas recipe. I hope I was clear this time around. Cheers,
Re: [O] Quotes not being converted correctly for LaTeX export
There is still something wrong here: if french users use
(setq org-export-smart-quotes-alist t) and do not use
\usepackage[french]{babel}, the quotes will not be very
smart, they will disappear.
I suggest having an option for the babel package: when
a string (equal org-latex-use-package-babel french), it
will trigger the insertion of \usepackage[french]{babel}
in the header. When an alist, it will trigger the insertion
of \usepackage... depending on the current language.
I think {babel} is common enough to deserve its own option,
but maybe I'm overrating its use.
Nicolas, what do you think?
--
Bastien
Re: [O] Quotes not being converted correctly for LaTeX export
Bastien b...@altern.org writes:
There is still something wrong here: if french users use
(setq org-export-smart-quotes-alist t) and do not use
\usepackage[french]{babel}, the quotes will not be very
smart, they will disappear.
I suggest having an option for the babel package: when
a string (equal org-latex-use-package-babel french), it
will trigger the insertion of \usepackage[french]{babel}
in the header. When an alist, it will trigger the insertion
of \usepackage... depending on the current language.
I think {babel} is common enough to deserve its own option,
but maybe I'm overrating its use.
Nicolas, what do you think?
Use #+LANGUAGE
Re: [O] Quotes not being converted correctly for LaTeX export
Bastien b...@altern.org writes:
Jambunathan K kjambunat...@gmail.com writes:
Use #+LANGUAGE
How does it solve the problem I'm pointing?
So you didn't want this?
\og Orange box\fg{}
\og Orange box\fg{}
Re: [O] org-agenda-write taking very long (probably because of babel)
Hi Achim! Sorry, I was away from Org a couple of days. * Achim Gratz strom...@nexgo.de wrote: Karl Voit writes: I guess this relates to ... org-babel-exp processing... [25 times] ... which also pops up some babel result graphics which did not happen before. Was there a change in the default settings or is this a bug? Yes there was, sorry for that. I missed something that was going on in an otherwise inconspicously named function and that unintentionally changed the conditions for when source blocks are eligible for evaluation. Since your setup was affected, may I ask you to apply this patch after the next update (which should include 302d3780ec) and report if this fixes the issue you had? I updated to 50226db65d5cb176f3f5e027d668ef5de4937bde and tried to apply your patch. Either because I never applied patch files before (or I don't remember) or the code changed in between, I could not apply it without getting errors. So I tried to do the patch manually and I hope, I did not break something. You can find the ob-core.el I generated on [1]. Org mode compiled and Emacs started without any error message. When I exported my agenda, I got: org-babel-exp processing... [24 times] org-babel-execute-src-block: Symbol's function definition is void: cache-p The pop-up window with generated bar charts did not appear this time. But some test.png from one gnuplot (of three) was re-generated. HTH Please reply if I can check something else for you. 1. https://gist.github.com/novoid/6bace66e0e8c6a4d2a7f -- Karl Voit
Re: [O] org-exp-bibtex missing in git?
Hello Bastien (et al), 2013ko martxoak 7an, Bastien-ek idatzi zuen: Hi Nicolas, I like Aaron's idea (maybe others proposed this too) of having parameters in links: [[file:my.bib::keyprenote=my prenotepostnote=my postnote]] [[http://perdu.comtitle=You're lost?]] This is orthogonal to my proposal of extending #+LINK to be able to define new protocols (by allowing to add a follow and an export functions); and this is orthogonal to whether link abbrevs can have more than one formatting string %s. We would just need to pass the parameters as keywords to the export function, either the default one, either the defined by the protocol. E.g., the first link would be represented by the parser like this: (:type file :path my.bib :raw-link file:orgmode.org::test2 :application nil :search-option test2 :parameters '(:title You're lost) :begin 63 :end 97 :contents-begin 90 :contents-end 95 :post-blank 0 :parent #3) 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. To Nicolas: 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] Alternatively, the lookup-type and display-type could just be made properties, as long as there is a clear notion of what the default for these should be. From 69e7a98a2f8044362597de31789b43b955e1fc7a Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Fri, 8 Mar 2013 13:31:38 -0500 Subject: [PATCH 1/3] Add support for link properties MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-element.el (org-element-link-parser): include :properties in plist of parsed link * lisp/org.el (org-make-link-string): don’t escape properties * lisp/ox-html.el (org-html-link) lisp/ox-latex.el (org-latex-link): pass link properties to org-link-protocols functions The properties of a link are appended to the link path, separated by the string “”. Each property should have the form key=val. No escaping is applied to key or val, and they must not contain an “=” character. The properties of a link are passed as the optional fourth argument to export functions defined by org-add-link-type and org-link-protocols. (Currently only for the HTML and LaTeX backends). --- lisp/org-element.el | 18 ++ lisp/org.el | 15 +-- lisp/ox-html.el | 3 ++- lisp/ox-latex.el| 3 ++- 4 files changed, 27 insertions(+), 12 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 6810b98..b944ffd 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2982,7 +2982,7 @@ Assume point is at the beginning of the link. (save-excursion (let ((begin (point)) end contents-begin contents-end link-end post-blank path type - raw-link link search-option application) + raw-link link search-option application properties) (cond ;; Type 1: Text targeted from a radio target. ((and org-target-link-regexp (looking-at org-target-link-regexp)) @@ -2998,9 +2998,18 @@ Assume point is at the beginning of the link. ;; abbreviation in it. raw-link (org-translate-link (org-link-expand-abbrev - (org-match-string-no-properties 1))) - link (org-link-unescape raw-link)) - ;; Determine TYPE of link and set PATH accordingly. + (org-match-string-no-properties 1 + (when (string-match raw-link) + (let ((components (split-string raw-link )) + p) + (setq raw-link (nth 0 components)) + (dolist (prop (cdr components)) + (setq p (split-string prop =)) + (setq properties (plist-put properties + (intern (concat : (nth 0 p))) + (nth 1 p)) +(setq link (org-link-unescape raw-link)) +;; Determine TYPE of link and set PATH accordingly. (cond ;; File type. ((or (file-name-absolute-p link) (string-match ^\\.\\.?/ link)) @@ -3058,6 +3067,7 @@ Assume point is at the beginning of the link. :raw-link (or raw-link path) :application application :search-option search-option + :properties properties :begin begin :end end :contents-begin contents-begin diff --git
Re: [O] org-exp-bibtex missing in git?
Hi Rasmus,
2013ko martxoak 7an, Rasmus Pank Roulund-ek idatzi zuen:
In my book it would seem 'natural' to strive towards the following:
1. It should be Bibtex-based. I.e. Bibtex should be the 'database'
or storage for citation information. It may be stored in
Org-Bibtex-whatever, but Bibtex should be the natural base.
2. Citation selection should be possible via Reftex.
In principle this is true, but I think RefTeX is deeply intertwined with
the assumption that it is running in a LaTeX buffer. Going through its
code and making it major-mode-agnostic is a worthy project all of its
own. But it might take less effort and be more long-run maintainable to
just wire up the bibtex.el bundled with emacs, CompletionUI
(http://www.emacswiki.org/CompletionUI) and YAsnippet
(http://emacswiki.org/emacs/Yasnippet).
3. It should look nice in the buffer. For instance, with the
current link hacks I am shown the pre or post notes in place of
the citation. Ideally, it should be able to specify a
reftex-cite-format string on how to display stuff in the buffer.
Notes should be viewable in an non-disturbing way.
Ideally, I would want to see something like:
(POSTFIX, Jensen, 1906, SUFFIX)
or
Jensen (POSTFIX, 1906, SUFFIX)
(If my memory serves me correctly this is how BibLatex places
notes).
One could do this with font-lock and the new citation syntax I proposed
in my other email. We would need two alists. One would pair citation
lookup types with functions to resolve them to a location, and to get
their properties. The other would pair display types with two
functions: one to return a format string that would be displayed by
font-lock instead of the citation markup, and one to return the code to
export the citation.
So, a citation like [cite:doi:parens:some-doi:key=valkey2=val2] would be
displayed by:
1. call (org-lookup-cite-doi some-doi) - (:author Foo :title bar ...)
2. call (org-display-cite-parens '(:author Foo :title bar ...)) -
(Foo 2000)
3. (font-lock puts an overlay over the citation markup, with the
returned string)
If you click on the citation, org would open the location (URL or local
file) returned by (org-resolve-cite-doi some-doi)
A citation could exported by calling (org-export-cite-parens 'doi
some-doi (:author foo :title bar) current-backend). This function
could just return \parencite{foo} if exporting to latex and the citation
was already in a bibtex file. But it could also just return “Foo 2000”
as a static string for dumb backends like ASCII, or write the
information to a temporary bibtex file (so that latex can atomatically
use the bibliographic info looked up from a DOI citation).
In any event, this is a big, complicated project. Step zero for me (and
many people, I guess) is to get a slightly less hackish way to export
Bibtex-based citations to latex, and the other pieces can be built on
top of that.
--
Aaron Ecay
Re: [O] trouble exporting just one subtree while using babel and R code blocks--spoke too soon
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. 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] org-export raises stringp nil error
From: Achim Gratz strom...@nexgo.de Date: Fri, 08 Mar 2013 17:34:42 +0100 Cc: emacs-orgmode@gnu.org In any case, doing the built-in packages this way (or something similar) takes a lot of unecessary churn and merges out of the release process and I would think that would be a clear advantage to everyone involved. I see that we have come a full circle, what with all this new blood pouring into Emacs development, and we are finally ready to repeat the failed experiment with dividing Emacs into core and all the rest. Good luck (you will need it)!
Re: [O] org-exp-bibtex missing in git?
Aaron,
2. Citation selection should be possible via Reftex.
In principle this is true, but I think RefTeX is deeply intertwined with
the assumption that it is running in a LaTeX buffer. Going through its
code and making it major-mode-agnostic is a worthy project all of its
own. But it might take less effort and be more long-run maintainable to
just wire up the bibtex.el bundled with emacs, CompletionUI
(http://www.emacswiki.org/CompletionUI) and YAsnippet
(http://emacswiki.org/emacs/Yasnippet).
These are not shipped with Emacs. Reftex is. I don't know how big of
a project it would be to adapt Reftex.
This is what I use for selecting entries. Admittedly, it's 'hackish'.
#+BEGIN_SRC emacs-lisp
(defun org-mode-reftex-setup ()
(load-library reftex)
(and (buffer-file-name)
(file-exists-p (buffer-file-name))
(reftex-parse-all))
(make-local-variable 'reftex-cite-format)
(setq reftex-cite-format 'org)
(define-key org-mode-map (kbd C-c )) 'reftex-citation))
(add-hook 'org-mode-hook 'org-mode-reftex-setup)
(eval-after-load 'reftex-vars
'(progn
(add-to-list 'reftex-cite-format-builtin
'(org Org-mode citation
((?\C-m . [[cite:%l]])
(?t . [[textcite:%l]])
(?p . [[parencite:%l]])
(?s . [[citepos:%l]])
(?a . [[citeauthor:%l]])
(?y . [[citeyear:%l]])
(?n . %l)
;; the following depends on
org-link-search-must-match-exact-headline
(?o . [[file:~/documents/literature/lit.org::*%t][%2a
(%y). %T]]))
#+END_SRC
3. It should look nice in the buffer. [...]
One could do this with font-lock and the new citation syntax I proposed
in my other email. We would need two alists. One would pair citation
lookup types with functions to resolve them to a location, and to get
their properties. The other would pair display types with two
functions: one to return a format string that would be displayed by
font-lock instead of the citation markup, and one to return the code to
export the citation.
So, a citation like [cite:doi:parens:some-doi:key=valkey2=val2] would be
displayed by:
1. call (org-lookup-cite-doi some-doi) - (:author Foo :title bar ...)
2. call (org-display-cite-parens '(:author Foo :title bar ...)) -
(Foo 2000)
3. (font-lock puts an overlay over the citation markup, with the
returned string)
Looks nice.
If you click on the citation, org would open the location (URL or local
file) returned by (org-resolve-cite-doi some-doi)
Yeah, I that aspect of url'ing is nice, I agree.
A citation could exported by calling (org-export-cite-parens 'doi
some-doi (:author foo :title bar) current-backend). This function
could just return \parencite{foo} if exporting to latex and the citation
was already in a bibtex file. But it could also just return “Foo 2000”
as a static string for dumb backends like ASCII, or write the
information to a temporary bibtex file (so that latex can atomatically
use the bibliographic info looked up from a DOI citation).
That also sounds nice. Reftex provide many ways to format strings
which could be useful for ASCII backend, say, but perhaps it's too
tied to LaTeX, as you suggest above.
In any event, this is a big, complicated project. Step zero for me (and
many people, I guess) is to get a slightly less hackish way to export
Bibtex-based citations to latex, and the other pieces can be built on
top of that.
If such a project is undertaken it should, however, be done right, I
am sure we would agree. Making citation first class citizens would
be a first step IMO.
Cheers,
Rasmus
--
If you can mix business and politics wonderful things can happen!
Re: [O] (no subject)
Hello, Bastien b...@altern.org writes: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred-- org-file while the default is active. ... or if someone shares a file online using non-star character as the prefix for headlines: this file won't be processed by Org tools like org-ruby and the like. But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the stars where expected. Org files are not just for Emacs, that's were the problem lies... I don't understand this heavy-handed approach. Plain text is great because I can do whatever I want. What I come up with might not work correctly in other tools (or anything at all), but I have the freedom to do interesting things, and to have my files look just the way I want them to. Emacs is great because it allows me the freedom of near-infinite customization. It has sensible defaults, but it allows me to break things however I want. Org, on the other hand, seems to be moving away from that in many ways. Headlines must start with stars because I might someday post something on the web and it wouldn't work for someone else? Other tools might not recognize my file correctly? A developer of some other tool might someday have a problem? These are not good reasons for limiting what I can do with my own Org files. I don't need or want supervision in how I create my files. I want freedom. If I wanted supervision, I wouldn't be using Emacs. Have you seen the lisp posted to the web? Somehow, Emacs and I survive that. Org started as a great tool that let me do cool things with my text files. I don't want to see it change to a rigid format for me to force my files into, where my only options are conform or leave. Org should err on the side of user freedom. IMHO, Terry -- T.F. Torrey
Re: [O] (no subject)
Hello, tftor...@tftorrey.com (T.F. Torrey) writes: Hello, Bastien b...@altern.org writes: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred-- org-file while the default is active. ... or if someone shares a file online using non-star character as the prefix for headlines: this file won't be processed by Org tools like org-ruby and the like. But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the stars where expected. Org files are not just for Emacs, that's were the problem lies... I don't understand this heavy-handed approach. Plain text is great because I can do whatever I want. What I come up with might not work correctly in other tools (or anything at all), but I have the freedom to do interesting things, and to have my files look just the way I want them to. Emacs is great because it allows me the freedom of near-infinite customization. It has sensible defaults, but it allows me to break things however I want. Org, on the other hand, seems to be moving away from that in many ways. Headlines must start with stars because I might someday post something on the web and it wouldn't work for someone else? Other tools might not recognize my file correctly? A developer of some other tool might someday have a problem? These are not good reasons for limiting what I can do with my own Org files. I don't need or want supervision in how I create my files. I want freedom. If I wanted supervision, I wouldn't be using Emacs. Have you seen the lisp posted to the web? Somehow, Emacs and I survive that. Org started as a great tool that let me do cool things with my text files. I don't want to see it change to a rigid format for me to force my files into, where my only options are conform or leave. I disagree. Org is a plain text format. Like any format, plain-text or not, it needs a proper definition. At least, it helps users and developers to agree on what they are talking about. As for myself, I cannot play any game if I don't know its rules. My point of view is the following: Org (as a format) definition shouldn't depend on Emacs. It should be totally parseable by any language (which is not the case actually, since syntax relies on variables defined in Emacs). IOW, we should work to make it a real plain-text markup format. Org should err on the side of user freedom. You still have the freedom to choose what you write down in Org format. You have the freedom use, or to not use Org. You have the freedom to modify Org code to bend it to your will. IMO, freedom is totally unrelated to this subject. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
On Tue, Mar 5, 2013 at 11:07 PM, Aaron Ecay aarone...@gmail.com wrote: In order for the cache feature to work, the hash of a finished computation must be inserted. But, this is not currently done for src blocks which have the option :results none. Thus, we should insert a dummy empty result for these blocks, which will hold the hash. --- lisp/ob-core.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 3b7c463..eabfc05 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -576,7 +576,10 @@ block. (if (member none result-params) (progn (funcall cmd body params) - (message result silenced)) + (message result silenced) + (when cachep The above should be cache-p (with hyphen). + (org-babel-insert-result + result-params info new-hash indent lang))) (setq result ((lambda (result) (if (and (eq (cdr (assoc :result-type params)) 'value) -- 1.8.1.5
Re: [O] Quotes not being converted correctly for LaTeX export
Hello,
Bastien b...@altern.org writes:
There is still something wrong here: if french users use
(setq org-export-smart-quotes-alist t) and do not use
\usepackage[french]{babel}, the quotes will not be very
smart, they will disappear.
I suggest having an option for the babel package: when
a string (equal org-latex-use-package-babel french), it
will trigger the insertion of \usepackage[french]{babel}
in the header. When an alist, it will trigger the insertion
of \usepackage... depending on the current language.
I think {babel} is common enough to deserve its own option,
but maybe I'm overrating its use.
Nicolas, what do you think?
Latex back-end already takes care of setting the correct Babel language
according to LANGUAGE keyword.
The only problem is when user doesn't load Babel at all, but still wants
to use smart quotes. Is it meaningful? Even if it is, I suspect it is
quite rare. So, dropping a note in `org-export-with-smart-quotes'
docstring would be enough.
As you probably know, I'm not a big fan of package autoloading.
Regards,
--
Nicolas Goaziou
Re: [O] [BUG] attr_latex in new exporter
Hello, aarone...@gmail.com writes: I think the following patch (on top of current master) will fix the problem: [...] It does. Thank you. Nicolas, I’m not sure I understand the logic behind (memq float '(figure wrap)) in the cond for setting height. I think that it would be very rare for someone to set the default height to something other than , but in the event that the user does so I don’t see why it shoudl make a difference whether the image is floating or not. figure and wrap float provide their own default width. A default height would probably break image ratio in that case. So it is only used when no width (implicit or explicit) is given. Regards, -- Nicolas Goaziou
Re: [O] org-export raises stringp nil error
joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. If distribution tarballs include code from elpa, then I imagine code freeze rules would also apply to elpa branch. So I don't see how this would be an improvement.
Re: [O] org-export raises stringp nil error
Eli Zaretskii e...@gnu.org writes: From: Dmitry Gutov dgu...@yandex.ru Cc: Eli Zaretskii e...@gnu.org, b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, Leo Liu sdl@gmail.com, emacs-de...@gnu.org Date: Fri, 08 Mar 2013 13:25:16 +0400 joa...@verona.se writes: Just a small reminder of the idea Stefan sometimes drops in these discussions: - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). That would certainly mean more problems for users to set them up with a particular version of Emacs, because there's no longer a clear way of getting the version of package X that correspond to Emacs version N.M. There won't be such correspondence. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. And if some do, package.el allows to specify the minimal Emacs version in the Package-Requires header. It just might use some improvement in the error message when this dependency is not satisfied. So, users of all versions of Emacs would use the same latest stable Gnus, Org and CEDET, as long as the packages maintain backward compatibility. That would create some pressure to upgrade old Emacs versions, though (as long as ELPA repositories only contain the latest versions of packages), but that's not necessarily a bad thing.
Re: [O] org-export raises stringp nil error
Eli Zaretskii e...@gnu.org writes: From: joa...@verona.se Date: Fri, 08 Mar 2013 10:15:07 +0100 Cc: b...@gnu.org, l...@metapensiero.it, emacs-orgmode@gnu.org, Leo Liu sdl@gmail.com, emacs-de...@gnu.org - Emacs trunk could be stripped of all but the bare essentials to achieve bootstrap. - distribution tarballs could be made from trunk+elpa. Since I dont do releases for Emacs I dont get to have an opinion on the matter, but if pressed, I would say this idea has considerable merit. It also has at least one demerits: people who track the trunk will not necessarily use the revisions of packages from elpa that will be included in Emacs tarballs. That will probably mean longer and more painful pretests, and some of the advantages of having a publicly accessible development trunk will be lost. On the other hand, people using older-but-still-supported versions of Emacs will be able to help test the new versions of packages in ELPA. Considering the total Emacs userbase is huge, this could be a great benefit, and hey, if a problem in org-mode is found just before Emacs release, it would either be completely org-mode team's problem (if it's not bundled with Emacs), or Emacs could bundle the last stable version without the regression. As long as Org is in the same tree, doing this kind of trick is much harder.
Re: [O] org-export raises stringp nil error
Eli Zaretskii writes: Not even that: the release candidate already reports its version as 24.3, so all is needed is to rename the tarball and upload to ftp.gnu.org. I stand corrected.
Re: [O] org-export raises stringp nil error
On 08.03.2013 18:06, Eli Zaretskii wrote: From: Dmitry Gutov dgu...@yandex.ru Cc: l...@metapensiero.it, joa...@verona.se, emacs-de...@gnu.org, b...@gnu.org, emacs-orgmode@gnu.org, sdl@gmail.com Date: Fri, 08 Mar 2013 15:18:19 +0400 I like the idea of stripping big bundled packages (like org, gnus, cedet, maybe even tramp, if that's possible). That would certainly mean more problems for users to set them up with a particular version of Emacs, because there's no longer a clear way of getting the version of package X that correspond to Emacs version N.M. There won't be such correspondence. And therein lies the problem. AFAIK, all 4 packages I mentioned above maintain backward compatible codebases, so it's not like they depend on the latest Emacs. When I install a package, I usually want its latest *stable* version that is compatible with the Emacs version I run. As great as Well, you're not getting it now. If you're using Emacs 23, you get the old version of Org that was bundled with it, and not some newer one that is still compatible with it (that would be the current stable release, I imagine). compatibility stuff is, I trust testing more, as I need to do something each day that doesn't involve debugging Emacs and my other tools. Easier access to newer versions for users means a bigger testing pool. Yes, the combination of latest org + latest Emacs may end up getting tested less, but that might be an acceptable tradeoff. Also, since org-mode or gnus won't update without explicit action from you, working with/on Emacs trunk may become more stable, because it will mean less moving parts. Also think about various package managers for GNU/Linux distros, which need to specify on what version of Emacs package X depends. They already do, at least for some packages: http://packages.ubuntu.com/quantal/gnus http://packages.ubuntu.com/quantal/org-mode
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Aaron Ecay writes: In order for the cache feature to work, the hash of a finished computation must be inserted. But, this is not currently done for src blocks which have the option :results none. Thus, we should insert a dummy empty result for these blocks, which will hold the hash. Getting a results block when specifying :results none feels a bit strange. Since it is not the results that are hashed, but the effective parameters of the invocation, wouldn't it make more sense to store the parameter hash with the source block or call rather than the result? That would free up the current place to hash the actual result to check if the results have been tampered with. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] (no subject)
Hi, On Fri, Mar 08, 2013 at 10:19:56PM +0100, Nicolas Goaziou wrote: tftor...@tftorrey.com (T.F. Torrey) writes: Org, on the other hand, seems to be moving away from that in many ways. Headlines must start with stars because I might someday post something on the web and it wouldn't work for someone else? Other tools might not recognize my file correctly? A developer of some other tool might someday have a problem? These are not good reasons for limiting what I can do with my own Org files. [...] My point of view is the following: Org (as a format) definition shouldn't depend on Emacs. It should be totally parseable by any language (which is not the case actually, since syntax relies on variables defined in Emacs). IOW, we should work to make it a real plain-text markup format. This discussion comes up again and again over the years. Every time the conclusion has been, there are many who want to use other characters instead of a star but the rational is always cosmetic. And in the end people end up agreeing it is not worth the pain. To give you an example of breakage, after long whining github started supporting org file formatting for READMEs via org-ruby (even source blocks I think!). Do you expect we can have similar support if something as fundamental as the headline is not well defined? Other possible breakages could be in org-merge-driver, VimOrganizer, org-sync, some of the collaborative editing projects that have been spawning, and the list goes on ... FWIW, assuming that the rational behind this feature request is cosmetic, there was a proposal to implement this as overlays. So the file still uses *-s but a user can customise how they are displayed. I think this addresses almost all requests in this category (majority being I want really cool UTF characters instead of boring old asterisk). If someone is interested in implementing this, I'm pretty sure the maintainers would give that a serious consideration for inclusion. Changing the file format on the other hand is a no go amongst many of the users (myself included) and developers alike. Hope my 2¢ shed some light on the implications of a change like this. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [RFC] Org syntax (draft)
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.] Only a section can contain another section is wrong. It should be removed. A section contains directly any greater element or element. Only a headline can contain a section. As an exception, text before the first headline in the document also belongs to a section. In a quoted headline contains a section, the latter will be considered as a “quote section”. s/In/If/ Yes. unsure: s/quote section/quoted section/ ? No, it is quote section. BACKEND is a string constituted of alpha-numeric characters, hyphens or underscores. I suggest: BACKEND is a string which is an element of (mapcar 'car org-export-registered-backends). Not really. Parser can understand #+attr_foo even if foo is not registered as a valid back-end. OPTIONAL and VALUE can contain any character but a new line. Only keywords in `org-element-dual-keywords' can have an optional value. I guess OPTIONAL cannot contain a closing square bracket ] It can. An affiliated keyword can appear on multiple lines if KEY belongs to `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Achim Gratz strom...@nexgo.de writes: Aaron Ecay writes: In order for the cache feature to work, the hash of a finished computation must be inserted. But, this is not currently done for src blocks which have the option :results none. Thus, we should insert a dummy empty result for these blocks, which will hold the hash. Getting a results block when specifying :results none feels a bit strange. I would agree. I don't believe *any* changes should take place in the buffer when a code block is executed with :results none. Since it is not the results that are hashed, but the effective parameters of the invocation, wouldn't it make more sense to store the parameter hash with the source block or call rather than the result? That would free up the current place to hash the actual result to check if the results have been tampered with. 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 Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Aaron Ecay aarone...@gmail.com writes: On Tue, Mar 5, 2013 at 11:07 PM, Aaron Ecay aarone...@gmail.com wrote: In order for the cache feature to work, the hash of a finished computation must be inserted. But, this is not currently done for src blocks which have the option :results none. Thus, we should insert a dummy empty result for these blocks, which will hold the hash. --- lisp/ob-core.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 3b7c463..eabfc05 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -576,7 +576,10 @@ block. (if (member none result-params) (progn (funcall cmd body params) - (message result silenced)) + (message result silenced) + (when cachep The above should be cache-p (with hyphen). The hyphen should only be required for multi-word functions, e.g., `listp' has no hyphen but `hash-table-p' does have a hyphen. + (org-babel-insert-result + result-params info new-hash indent lang))) (setq result ((lambda (result) (if (and (eq (cdr (assoc :result-type params)) 'value) -- 1.8.1.5 -- Eric Schulte http://cs.unm.edu/~eschulte
[O] interoperability matters Re: (no subject)
Hi T.F., * T.F. Torrey tftor...@tftorrey.com [08. Mar. 2013]: Plain text is great because I can do whatever I want. What I come up with might not work correctly in other tools (or anything at all), but I have the freedom to do interesting things, and to have my files look just the way I want them to. One argument against changing the headlne marker was interoperability: Share org files with others, use other tools to manipulate org files. Interoperability is a product of rules/formats/protocols. Email is a plain text protocol too, but some headers are required for interoperability. It wouldn't make sense for instance for me to use my freedom to create/change headers arbitrary, and to have my emails look just the way I want them to. E.g. to use german words Betreff, Datum, An, Von instead of Subject, Date, To, From, only because I can -- no mail transport agent would handle this plain text file. Regards, Gregor
Re: [O] Quotes not being converted correctly for LaTeX export
Hi Nicolas, On Fri, Mar 08, 2013 at 10:28:17PM +0100, Nicolas Goaziou wrote: The only problem is when user doesn't load Babel at all, but still wants to use smart quotes. Is it meaningful? Even if it is, I suspect it is quite rare. So, dropping a note in `org-export-with-smart-quotes' docstring would be enough. I'm not exactly sure what you mean here. All my documents are in English, so I rarely use babel. But I do want my quotes to look correct. So I use ``..'' instead of ... The old LaTeX exporter used to translate .. to ``..'' by default, which the new one does not do. Since smart quote for LaTeX is usually a necessity rather than a preference, would it make sense to have it enabled by default for the LaTeX backend and all other backends that derive from it? Of course if that is not reasonable, I can always get use the filter suggested by Jambunathan earlier in the thread. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
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? 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 In this case, the code block shouldn’t be marked :cache. Unless the desired (and odd, IMO) behavior is to have a datestamp that is only updated when the user forcibly re-evaluates the block (with C-u C-c C-c). Also, with regard to: 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. -- Aaron Ecay
Re: [O] org-export raises stringp nil error
On Fri, 08 Mar 2013 11:29:23 -0500 Nick Dokos nicholas.do...@hp.com wrote: Bastien b...@altern.org wrote: Xue Fuqiao xfq.f...@gmail.com writes: Sounds fine to me, because my Internet connection is very slow (especially to Savannah). It is often a pain for me to perform a `bzr pull', since it takes a long time. Well, that's more an argument for switching to hg or git for Emacs repo, not really for trimming out packages from Emacs core. There *is* a git mirror for emacs: git://repo.or.cz/emacs.git. But Emacs Dev don't have access to this repository or the repository on Savannah. I think what Bastien meant is switching the main repository. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao
Re: [O] Quotes not being converted correctly for LaTeX export
Hello, Suvayu Ali fatkasuvayu+li...@gmail.com writes: I'm not exactly sure what you mean here. All my documents are in English, so I rarely use babel. But I do want my quotes to look correct. So I use ``..'' instead of ... The old LaTeX exporter used to translate .. to ``..'' by default, which the new one does not do. Since smart quote for LaTeX is usually a necessity rather than a preference, would it make sense to have it enabled by default for the LaTeX backend and all other backends that derive from it? It makes sense indeed. latex back-end will use, by default, smart quotes. Regards, -- Nicolas Goaziou
Re: [O] Better way to customize daily/weekly agenda?
Hi Piotr, Piotr Isajew wrote: - daily agenda having grid mode on, and displaying entries from all categories - weekly agenda having grid mode off and filtering out entries from one specific category With regard to the time grid you might want to check out the variable org-agenda-time-grid. I have it set thusly: #+BEGIN_SRC emacs-lisp (setq org-agenda-time-grid '((daily today required-time) (600 1200 1800 2400))) #+END_SRC The first part of the variable shows the time grid in the day agenda, but not in the weekly agenda, except for today's date. Cheers, Viktor
[O] [New Exporter] Parameterized wrapper elements
(cc'ing list) Nicolas- The patch Jambunathan sent didn't really make much sense to me, as it didn't provide any added functionality over simply subclassing (deriving) from the current html exporter. Anyway, attached is a patch which parameterizes the html exporter in a way which is useful (for me :) in deriving new backends. It also make the exporter more capable of generating HTML5 compatible output instead of just XHTML. If you agree with it, i would be happy to apply it (or you can :). rick From 01640c5a9f0d4957a0289a9dfc0497f5b7d42bd9 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 | 76 ++--- 1 file changed, 57 insertions(+), 19 deletions(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 829fe28..a971440 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 in +the exported html file. 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. (?v . ,html-validation-link) (when (org-string-nw-p postamble-contents) (concat - (format div id=\%s\\n (nth 2 org-html-divs)) + (format %s id=\%s\\n + (nth 1 (nth 2 org-html-divs)) + (nth 0 (nth 2 org-html-divs)))
[O] [RFC] Simplify attributes syntax
Hello,
The following patch simplifies syntax for attributes.
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)
If there's no major problem with it, I'll apply it before Monday.
Though, I think ox-odt needs double-checking.
Regards,
--
Nicolas Goaziou
From e3a89f40f497297fd7c0ffe9273ede724684b4b9 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Sat, 9 Mar 2013 00:58:31 +0100
Subject: [PATCH 1/2] ox: Simplify syntax for attributes
* lisp/ox.el (org-export-read-attribute): Do not use `read' to read
attributes. Instead, extract keywords and values from it, which
means each value will be a string when non-nil.
* contrib/lisp/ox-groff.el (org-groff-link--inline-image): Use new
attribute syntax. Small refactoring.
* lisp/ox-ascii.el (org-ascii-horizontal-rule): Use new attribute
syntax.
* lisp/ox-beamer.el (org-beamer-plain-list): Use new attribute syntax.
* lisp/ox-html.el (org-html--textarea-block): Use new attribute
syntax.
* lisp/ox-latex.el (org-latex--inline-image, org-latex--org-table,
org-latex--math-table): Use new attribute syntax.
* lisp/ox-man.el (org-man-table--org-table): Use new attribute syntax.
Small refactoring.
* lisp/ox-odt.el (org-odt-link--inline-image, org-odt-table-cell): Use
new attribute syntax.
* testing/lisp/test-ox.el: Add tests.
This patch introduces two changes. To begin with, it removes the need
for quoting and escaping characters. Also, all non-nil values are
stored as strings. As an exception nil is stored as nil.
---
contrib/lisp/ox-groff.el | 45 ++---
lisp/ox-ascii.el | 4 +++-
lisp/ox-beamer.el| 6 +++---
lisp/ox-html.el | 6 +++---
lisp/ox-latex.el | 47 +++
lisp/ox-man.el | 30 --
lisp/ox-odt.el | 22 +++---
lisp/ox.el | 19 ---
testing/lisp/test-ox.el | 25 +++--
9 files changed, 108 insertions(+), 96 deletions(-)
diff --git a/contrib/lisp/ox-groff.el b/contrib/lisp/ox-groff.el
index 96a688a..5e64023 100644
--- a/contrib/lisp/ox-groff.el
+++ b/contrib/lisp/ox-groff.el
@@ -1209,11 +1209,11 @@ used as a communication channel.
(expand-file-name raw-path
(attr (org-export-read-attribute :attr_groff link))
(placement
- (case (plist-get attr :position)
-('center )
-('left -L)
-('right -R)
-(t )))
+ (let ((pos (plist-get attr :position)))
+ (cond ((string= pos 'center) )
+ ((string= pos 'left) -L)
+ ((string= pos 'right) -R)
+ (t
(width (or (plist-get attr :width) ))
(height (or (plist-get attr :height) ))
(caption (and (not (plist-get attr :disable-caption))
@@ -1223,7 +1223,7 @@ used as a communication channel.
(concat
(cond
((and org-groff-raster-to-ps
-(or (string-match .\.png$ path)
+(or (string-match .\.png$ path)
(string-match .\.jpg$ path)))
(let ((eps-path (concat path .eps)))
(shell-command (format org-groff-raster-to-ps path eps-path))
@@ -1658,37 +1658,20 @@ This function assumes TABLE has `org' as its `:type' attribute.
(lines (org-split-string contents \n))
(attr-list
- (let (result-list)
-(dolist (attr-item
- (list
- (if (plist-get attr :expand)
- expand nil)
-
- (case (plist-get attr :placement)
-('center center)
-('left nil)
-(t
- (if org-groff-tables-centered
- center )))
-
- (case (plist-get attr :boxtype)
-('box box)
-('doublebox doublebox)
-('allbox allbox)
-('none nil)
-(t box
-
- (if (not (null attr-item))
- (add-to-list 'result-list attr-item)))
-result-list))
+ (delq nil
+ (list (and (plist-get attr :expand) expand)
+ (let ((placement (plist-get attr :placement)))
+ (cond ((string= placement 'center) center)
+ ((string= placement 'left) nil)
+ (t (if org-groff-tables-centered center
+ (or (plist-get attr :boxtype) box
(title-line (plist-get attr :title-line))
(long-cells (plist-get attr :long-cells))
(table-format
Re: [O] [RFC] Simplify attributes syntax
Aloha Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, The following patch simplifies syntax for attributes. 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 user POV +1. Tom -- Thomas S. Dye http://www.tsdye.com
