Re: [O] [BUG] in last org in indentation of source blocks - confirmed with emacs -Q
Just confirmed this bug with the following setup: Just load --8---cut here---start-8--- emacs -Q --8---cut here---end---8--- #+begin_src emacs-lisp (add-to-list 'load-path ~/.emacs.d/org-mode/lisp) (add-to-list 'load-path ~/.emacs.d/org-mode/contrib/lisp) (require 'org) (setq org-src-preserve-indentation nil) #+end_src Proper indentation of any source block #+begin_src emacs-lisp (setq org-src-preserve-indentation t) #+end_src runaway indentation #+begin_src emacs-lisp (setq org-src-preserve-indentation t) #+end_src , | | Org-mode version 8.3beta (release_8.3beta-1178-g317886 @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) | GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, Carbon Version 157 AppKit 1347.57) of 2015-04-13 on Rainers-MacBook-Pro.local ` Cheers, Rainer Rainer M Krug rai...@krugs.de writes: I reralised this morning that there eems to be a bug introduced in one of the last commits which causes repeted editing of source blocks to indent more each time the are edited (C-'). Original: , | #+begin_src sh | echo 2 | #+end_src ` After C-' and back again , | #+begin_src sh | echo 2 | #+end_src ` After second C-' and back , | #+begin_src sh | echo 2 | #+end_src ` When C-', the indirect buffer has the same indentation as the source block, but when switching back, two more spaces are added. Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] org-preview-latex-fragment ignores \includes in the LATEX_HEADER
On Wednesday, 27 May 2015 at 15:02, Stefan Otte wrote:
[...]
The pdf export works flawlessly, however `org-preview-latex-fragment`
seems to ignore \include{commands}, i.e., equations that use
commands that are defined in commands.tex are rendered as blank/empty
image.
Is it the intended behavior that `org-preview-latex-fragment` ignores
\include, is it a bug, or is there a better way to do it?
Maybe create a style file and then use
,[ C-h v org-latex-packages-alist RET ]
| org-latex-packages-alist is a variable defined in `org.el'.
|
| Documentation:
| Alist of packages to be inserted in every LaTeX header.
|
| These will be inserted after `org-latex-default-packages-alist'.
| Each element is either a cell or a string.
|
| A cell is of the format:
|
| (options package SNIPPET-FLAG)
|
| SNIPPET-FLAG, when non-nil, indicates that this package is also
| needed when turning LaTeX snippets into images for inclusion into
| non-LaTeX output.
|
| A string will be inserted as-is in the header of the document.
|
| Make sure that you only list packages here which:
|
| - you want in every file;
| - do not conflict with the setup in `org-format-latex-header';
| - do not conflict with the default packages in
| `org-latex-default-packages-alist'.
|
| You can customize this variable.
`
Note bit about LaTeX snippets.
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
Re: [O] Confusing creation of frames and windows
On Thursday, 28 May 2015 at 18:08, M wrote: I'm not sure where exactly my problem comes from, but I find it quite confusing how Emacs / org-mode creates new frames or does show something in the existing frame or window. Is there a tutorial or a best-practice setup to get it easy and intuitive? Not that I am aware of. Usually, the behaviour will be controlled by some variable. For instance, in org, when asking for an agenda view (org-agenda), the following variable controls what it does in terms of frames and windows within frames: ,[ C-h v org-agenda-window-setup RET ] | org-agenda-window-setup is a variable defined in `org-agenda.el'. | Its value is current-window | Original value was reorganize-frame | | Documentation: | How the agenda buffer should be displayed. | Possible values for this option are: | | current-windowShow agenda in the current window, keeping all other windows. | other-window Use `switch-to-buffer-other-window' to display agenda. | only-window Show agenda, deleting all other windows. | reorganize-frame Show only two windows on the current frame, the current | window and the agenda. | other-frame Use `switch-to-buffer-other-frame' to display agenda. | Also, when exiting the agenda, kill that frame. | See also the variable `org-agenda-restore-windows-after-quit'. | | You can customize this variable. | | [back] ` Usually, these variables are described in the info manuals. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1136-g0e7062
Re: [O] [BUG] in last org in indentation of source blocks
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Rainer M Krug rai...@krugs.de writes: I reralised this morning that there eems to be a bug introduced in one of the last commits which causes repeted editing of source blocks to indent more each time the are edited (C-'). Original: , | #+begin_src sh | echo 2 | #+end_src ` After C-' and back again , | #+begin_src sh | echo 2 | #+end_src ` After second C-' and back , | #+begin_src sh | echo 2 | #+end_src ` When C-', the indirect buffer has the same indentation as the source block, but when switching back, two more spaces are added. This should be fixed in a33acf61917d8c72369297289031d8745e08e320. Thank you. Thanks Nicolas, Rainer Regards, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] ob-sed
Bjarte Johansen bjarte.johan...@infomedia.uib.no writes: I think I have addressed all your comments in the attached patch. Thank you. Some more comments follow. Subject: [PATCH] Org Babel now supports sed scripts You should add something like the following to your commit message: * doc/org.texi: Signal new Babel language * lisp/ob-sed.el: * testing/examples/ob-sed-test.org: * testing/lisp/test-ob-sed.el: New files. -@item GNU Screen @tab screen @tab shell @tab sh -@item SQL @tab sql @tab SQLite @tab sqlite +@item GNU Screen @tab screen Sed @tab sed +@item @tab shell @tab sh @item SQL @tab sql +@item @tab SQLite @tab sqlite @tab @tab This looks wrong. I think it should be: @item GNU Screen @tab screen @tab Sed @tab sed @item shell @tab sh @tab SQL @tab sql @item SQLite @tab sqlite @tab @tab +;;; Usage: + +;; Add to your Emacs config: + +;; (org-babel-do-load-languages +;; 'org-babel-load-languages +;; '((sed . t))) You may want to introduce usage for :cmd-line and :in-file arguments in Usage section. +(defconst org-babel-header-args:sed + '((:cmd-line :any + :in-file :any)) + Sed specific header arguments.) It should be '((:cmd-line . :any) (:in-file . :any)) See, for example `org-babel-header-args:R' +(defun org-babel-execute:sed (body params) + Execute a block of sed code with Org Babel. +BODY is the source inside a sed source block and PARAMS is an +association list over the source block configurations. This ^^^ two spaces Regards,
Re: [O] [BUG] in last org in indentation of source blocks
Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-28 Thu 04:49, Rainer M Krug wrote: I reralised this morning that there eems to be a bug introduced in one of the last commits which causes repeted editing of source blocks to indent more each time the are edited (C-'). Original: , | #+begin_src sh | echo 2 | #+end_src ` After C-' and back again , | #+begin_src sh | echo 2 | #+end_src ` After second C-' and back , | #+begin_src sh | echo 2 | #+end_src ` When C-', the indirect buffer has the same indentation as the source block, but when switching back, two more spaces are added. I can’t reproduce the second indent but I think it’s a bug that there is any indentation at all. I just checked again, and the incremental indentation is there if I set ~org-src-preserve-indentation~ to non-nil. Rainer The documentation of `org-edit-special' (C-x ') says: Call a special editor for the element at point. … No mention of indentation or other reformatting of my code. The same goes for `org-edit-src-exit' (C-c C-c) which says: Kill current sub-editing buffer and return to source buffer. The edit-in-buffer feature should not touch the indentation. If the syntax of the language is sensitive to indentation (e.g. Python) this can break the code. Example: #+BEGIN_SRC python :results output print test #+END_SRC is invalid Python syntax. Also having one function perform two very different actions (edit code in separate buffer *and* reformat the code) is poor design. At least in this special case. When I open the code in a separate buffer but then decide not to change it (C-c C-c), I'll end up with extra indentation and this will create unnecessary changes when I commit the file in git. Titus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
[O] ox-texinfo: Xref are not typeset properly
Nicolas, (Delayed) Thanks for your (other) fixes. I will respond to
those separately. Meanwhile...
This mail comes in two parts
a) A bug
b) A request
Bug
===
ox-texinfo: Xref are not typeset properly
See attached files.
Request
===
(May be?) Put *Org INFO Texinfo Output* in `compilation-mode'.
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename ./emacsprimer.info
@settitle
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title
@end titlepage
@ifnottex
@node Top
@top
@end ifnottex
@menu
* Figure::
* Link to Figure::
@end menu
@node Figure
@unnumbered Figure
@image{./images/emacs-24.5.1-startup-screen-annotatedpng}
@node Link to Figure
@unnumbered Link to Figure
@ref{orgparagraph1,,1}
@bye
emacsprimer.org
Description: Lotus Organizer
;;; -*- mode: compilation; -*-
~/src/emacsprimer/emacsprimer.texi:16: warning: Must specify a title with least
one of @settitle or @top.
~/src/emacsprimer/emacsprimer.texi:32: Cross reference to nonexistent node
`orgparagraph1' (perhaps incorrect sectioning?).
makeinfo: Removing output file `./emacsprimer/index.html' due to errors; use
--force to preserve.
Re: [O] [BUG] Radio Targets and double quotes
Hello, thomas tho...@friendlyvillagers.com writes: I have Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ /home/thomas/.emacs.d/elpa/org-20150504/) You may want to switch to development version. It should be fixed there. Regards, -- Nicolas Goaziou
Re: [O] [BUG] in last org in indentation of source blocks
t...@tsdye.com (Thomas S. Dye) writes: Titus von der Malsburg malsb...@posteo.de writes: I can’t reproduce the second indent but I think it’s a bug that there is any indentation at all. The documentation of `org-edit-special' (C-x ') says: Call a special editor for the element at point. … No mention of indentation or other reformatting of my code. The same goes for `org-edit-src-exit' (C-c C-c) which says: Kill current sub-editing buffer and return to source buffer. The edit-in-buffer feature should not touch the indentation. If the syntax of the language is sensitive to indentation (e.g. Python) this can break the code. Example: #+BEGIN_SRC python :results output print test #+END_SRC is invalid Python syntax. Also having one function perform two very different actions (edit code in separate buffer *and* reformat the code) is poor design. At least in this special case. When I open the code in a separate buffer but then decide not to change it (C-c C-c), I'll end up with extra indentation and this will create unnecessary changes when I commit the file in git. Does the variable org-src-preserve-indentation get the behavior you're after? If I set it to nil, I don't have the runway indentation, if I set it to non-nil, I have the runaway indentation. But I can't use nil, as I need the indentation for tangling of some files. Rainer hth, Tom -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [BUG] in last org in indentation of source blocks
Hello, Rainer M Krug rai...@krugs.de writes: I reralised this morning that there eems to be a bug introduced in one of the last commits which causes repeted editing of source blocks to indent more each time the are edited (C-'). Original: , | #+begin_src sh | echo 2 | #+end_src ` After C-' and back again , | #+begin_src sh | echo 2 | #+end_src ` After second C-' and back , | #+begin_src sh | echo 2 | #+end_src ` When C-', the indirect buffer has the same indentation as the source block, but when switching back, two more spaces are added. This should be fixed in a33acf61917d8c72369297289031d8745e08e320. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [BUG] Radio Targets and double quotes
Hi Nicolas, I have Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ /home/thomas/.emacs.d/elpa/org-20150504/) org-export-with-smart-quotes is set to t. The error goes away when org-export-with-smart-quotes is not true. M-x org-reload (sorry, I do not know how C-u org-reload could work) reveals: [type q key info org-export-smart-quotes-alist encoding eql apostrophe open ' ...] 6], 1 Thank you. Thomas On 29.05.2015 01:08, Nicolas Goaziou wrote: Hello thomas tho...@friendlyvillagers.com writes: a radio target reference followed by another radio target in double quotes breaks html-export. The following minimal throws an error: === Keyword1 keyword2 Keyword1 keyword2 === Error Message: org-export-activate-smart-quotes: Wrong number of arguments: #[(q type) ÆÇ\ I cannot reproduce it. What Org version are you using? (after that comes a number of weird symbols that I cannot even copy into the email...) You should use Org uncompiled (C-u org-reload) to get a better backtrace. Regards, -- Nicolas Goaziou
[O] ox-texinfo: Link to dedicated to target doesn't work
ox-texinfo: Link to dedicated to target doesn't work
See the attached .org and .texi file.
bug-texinfo.org
Description: Lotus Organizer
\input texinfo@c -*- texinfo -*-
@c %**start of header
@setfilename ./bug-texinfo.info
@settitle bug-texinfo
@documentencoding UTF-8
@documentlanguage en
@c %**end of header
@finalout
@titlepage
@title bug-texinfo
@end titlepage
@ifnottex
@node Top
@top bug-texinfo
@end ifnottex
@menu
* Heading 1::
@end menu
@node Heading 1
@unnumbered Heading 1
@anchor{orgtarget1}Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim
ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
Jump to .
@bye
Re: [O] ox-texinfo: Xref are not typeset properly
Thanks for the fixes. I am test driving the ox-texinfo exporter. So the list is likely to get more bug reports from me. On Friday 29 May 2015 03:03 PM, Nicolas Goaziou wrote: Hello, Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: Bug === ox-texinfo: Xref are not typeset properly See attached files. Fixed in 0ed99a4c8cccde1d7f5e190feda54558c1ff4188. Thank you. Request === (May be?) Put *Org INFO Texinfo Output* in `compilation-mode'. Done in 1bd26e2d81933a05c3f97ff0d3c8cc53dd51dd3a. Regards,
[O] org-use-property-inheritance not working?
Consider this example: I enable property inheritance with (setq org-use-property-inheritance t) --8---cut here---start-8--- #+PROPERTY: header-args :tangle-mode (identity #o444) #+PROPERTY: header-args+ :eval no-export #+PROPERTY: header-args:R :session *R.EnergyBalance* * Without properties #+begin_src 13 #+end_src Result from (org-babel-view-src-block-info): , | Properties: | :header-args:tangle-mode (identity #o444) :eval no-export | :header-args:nilnil | Switches: | Header Arguments: | :cache no | :eval no-export | :exportscode | :hlines no | :noweb no | :resultsreplace | :sessionnone | :tangle no | :tangle-mode292 ` This is as expected. * First Level :PROPERTIES: :header-args+: :tangle ./output/scripts/analysisCode.do.not.source.R :header-args+: :output-dir ./output :END: #+begin_src R 13 #+end_src Result from (org-babel-view-src-block-info): , | Lang: R | Properties: | :header-args:tangle-mode (identity #o444) :eval no-export :tangle ./output/scripts/analysisCode.do.not.source.R :output-dir ./output | :header-args:R :session *R.EnergyBalance* | Header Arguments: | :cache no | :eval no-export | :exportscode | :hlines no | :noweb no | :output-dir ./output | :resultsreplace | :session*R.EnergyBalance* | :tangle ./output/scripts/analysisCode.do.not.source.R | :tangle-mode292 ` Also as expected, the header arguments are appended ** Second level :PROPERTIES: :header-args:R: :session *R.Results.Simp* :header-args+: :tangle ./output/scripts/graphs.SimplificationOfWindProfileFits.R :END: Now the problem comes: #+begin_src R 13 #+end_src Result from (org-babel-view-src-block-info): , | Lang: R | Properties: | :header-args:tangle-mode (identity #o444) :eval no-export :tangle ./output/scripts/graphs.SimplificationOfWindProfileFits.R | :header-args:R :session *R.Results.Simp* | Header Arguments: | :cache no | :eval no-export | :exportscode | :hlines no | :noweb no | :resultsreplace | :session*R.Results.Simp* | :tangle ./output/scripts/graphs.SimplificationOfWindProfileFits.R | :tangle-mode292 ` The header arguments from Level One (:output-dir and :tangle) are not there anymore and only the ones from the Second Level are used. I would have expected the Level Two header arguments to be added to the ones from Level One and the File wide? --8---cut here---end---8--- Is this to be expected? I always thought, that the properties are hierarchical, and that the ones from the lower levels / headers are used as well? Is this not the case, or id this a bug? With property inheritance I would have expected the inheritance, but it does not seem to make a difference? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] ox-latex: includegraphics should quote filenames
On Tuesday 26 May 2015 02:32 PM, Andreas Leha wrote:
Hi Vaidheeswaran,
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:
In:
[[./emacs-24.5.1-startup-screen-annotated.png]]
Buggy Out:
\includegraphics[width=.9\linewidth]{./emacs-24.5.1-startup-screen-annotated.png}
Desired: Out:
\includegraphics[width=.9\linewidth]{{./emacs-24.5.1-startup-screen-annotated}.png}
Source:
http://tex.stackexchange.com/questions/10574/includegraphics-dots-in-filename
I agree. Although I do not actually experience this, as my custom LaTeX
classes all \use[ the ]package{grffile} (also in your Reference) by now.
I have not experienced any problem with that package and it appears to
handle more cases (especially spaces) than 'quoting'. So, it might be
an alternative to use grffile by default?
ox-latex export must work out of the box (when it can)! Currently
inline images (that have dots in their names) are not exporting
correctly.
If someone fixes this bug (one way or the other), I will be most
grateful!
Re: [O] ox-latex: includegraphics should quote filenames
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: ox-latex export must work out of the box (when it can)! Currently inline images (that have dots in their names) are not exporting correctly. No it musen't. There's explicit cases where you have to add configuration. The most horrendous example is a local toc. If someone fixes this bug (one way or the other), I will be most grateful! Unless this is SUPER urgent for you, I will fix it on Monday. Let me know if this is not early enough. Rasmus -- m-mm-mmm- bacon!
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). AFAICT, the x comes from R, not Org. It could also come from the way Org calls R, but I don't know enough of the latter to tell. Regards,
Re: [O] ox-texinfo: Xref are not typeset properly
Hello, Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: Bug === ox-texinfo: Xref are not typeset properly See attached files. Fixed in 0ed99a4c8cccde1d7f5e190feda54558c1ff4188. Thank you. Request === (May be?) Put *Org INFO Texinfo Output* in `compilation-mode'. Done in 1bd26e2d81933a05c3f97ff0d3c8cc53dd51dd3a. Regards, -- Nicolas Goaziou
Re: [O] ox-latex: includegraphics should quote filenames
On Friday 29 May 2015 03:39 PM, Rasmus wrote: Okay, I'm adding grffile as it also support spaces in filenames. Now this example works: Thanks. Works for me.
Re: [O] ox-latex: includegraphics should quote filenames
Rasmus ras...@gmx.us writes: Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: ox-latex export must work out of the box (when it can)! Currently inline images (that have dots in their names) are not exporting correctly. If someone fixes this bug (one way or the other), I will be most grateful! Actually, does it work if you add grffile to your latex package alist? It should. Since it's part of latex-base I'm tempted to add this package to the default packages. Okay, I'm adding grffile as it also support spaces in filenames. Now this example works: * test [[file:nasty dir/Screenshot. from 2015-03-05 19:05:00.png]] Rasmus -- Hooray!
Re: [O] ox-latex: includegraphics should quote filenames
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: ox-latex export must work out of the box (when it can)! Currently inline images (that have dots in their names) are not exporting correctly. If someone fixes this bug (one way or the other), I will be most grateful! Actually, does it work if you add grffile to your latex package alist? It should. Since it's part of latex-base I'm tempted to add this package to the default packages. Rasmus -- ⠠⠵
Re: [O] ob-sed
I think I have addressed all of your comments except I didn’t understand the comment about the spaces. Are there two spaces extra or do you want me to introduce two spaces somewhere? I have attached the updated patch. Regards, Bjarte 0001-Org-Babel-now-supports-sed-scripts.patch Description: Binary data On 29 May 2015, at 11:00, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Bjarte Johansen bjarte.johan...@infomedia.uib.no writes: I think I have addressed all your comments in the attached patch. Thank you. Some more comments follow. Subject: [PATCH] Org Babel now supports sed scripts You should add something like the following to your commit message: * doc/org.texi: Signal new Babel language * lisp/ob-sed.el: * testing/examples/ob-sed-test.org: * testing/lisp/test-ob-sed.el: New files. -@item GNU Screen @tab screen @tab shell @tab sh -@item SQL @tab sql @tab SQLite @tab sqlite +@item GNU Screen @tab screen Sed @tab sed +@item @tab shell @tab sh @item SQL @tab sql +@item @tab SQLite @tab sqlite @tab @tab This looks wrong. I think it should be: @item GNU Screen @tab screen @tab Sed @tab sed @item shell @tab sh @tab SQL @tab sql @item SQLite @tab sqlite @tab @tab +;;; Usage: + +;; Add to your Emacs config: + +;; (org-babel-do-load-languages +;; 'org-babel-load-languages +;; '((sed . t))) You may want to introduce usage for :cmd-line and :in-file arguments in Usage section. +(defconst org-babel-header-args:sed + '((:cmd-line :any + :in-file :any)) + Sed specific header arguments.) It should be '((:cmd-line . :any) (:in-file . :any)) See, for example `org-babel-header-args:R' +(defun org-babel-execute:sed (body params) + Execute a block of sed code with Org Babel. +BODY is the source inside a sed source block and PARAMS is an +association list over the source block configurations. This ^^^ two spaces Regards,
Re: [O] [BUG] Radio Targets and double quotes
Nicolas, thank you. - thomas On 29.05.2015 09:31, Nicolas Goaziou wrote: Hello, thomas tho...@friendlyvillagers.com writes: I have Org-mode version 8.2.10 (8.2.10-40-gc763fa-elpa @ /home/thomas/.emacs.d/elpa/org-20150504/) You may want to switch to development version. It should be fixed there. Regards,
Re: [O] ox-texinfo: Link to dedicated to target doesn't work
Hello, Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes: ox-texinfo: Link to dedicated to target doesn't work The behaviour is correct here. You are inserting a link to a target without a description. As in any export back-end, Org tries to associate it to a number, in this case, headline's number. However, you explicitly asked to have unnumbered headlines. As a consequence Org simply bails out. Regards, -- Nicolas Goaziou
[O] Add #+subtitle to org-document-info-keyword?
Hi, Would it be OK to add #+subtitle to org-document-info-keyword? To get the same face as other keywords in that list. Recall that it's a keyword that only exists in a subset of the export backends. Thanks, Rasmus -- One thing that is clear: it's all down hill from here
Re: [O] Add #+subtitle to org-document-info-keyword?
Hello, Rasmus ras...@gmx.us writes: Would it be OK to add #+subtitle to org-document-info-keyword? To get the same face as other keywords in that list. That variable doesn't exist anymore. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On Fri, 29 May 2015, Nicolas Goaziou wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). AFAICT, the x comes from R, not Org. It could also come from the way Org calls R, but I don't know enough of the latter to tell. In particular, `org-babel-R-write-object-command' contains an R function that processes the object for `:results value'. The guts of it is a call to write.table(). Here is an example: #+NAME: show write.table #+BEGIN_SRC R :results output write.table(c(a,b)) #+END_SRC #+RESULTS: show write.table : x : 1 a : 2 b The difficulty is that write.table() coerces its first argument to a `data.frame', whence the odd seeming row/column labels. Making the R code in `org-babel-R-write-object-command' smart enough to do what the OP wants without breaking stuff might be possible if anyone wants to do the work. However, IMO `:results output' is the way to go for such cases. There are plenty of tools in R for formatting output and the user will have better control over what is produced. Chuck
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-29 Fri 11:09, Charles C. Berry wrote: On Fri, 29 May 2015, Nicolas Goaziou wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). AFAICT, the x comes from R, not Org. It could also come from the way Org calls R, but I don't know enough of the latter to tell. In particular, `org-babel-R-write-object-command' contains an R function that processes the object for `:results value'. The guts of it is a call to write.table(). Here is an example: #+NAME: show write.table #+BEGIN_SRC R :results output write.table(c(a,b)) #+END_SRC #+RESULTS: show write.table : x : 1 a : 2 b The difficulty is that write.table() coerces its first argument to a `data.frame', whence the odd seeming row/column labels. Making the R code in `org-babel-R-write-object-command' smart enough to do what the OP wants without breaking stuff might be possible if anyone wants to do the work. Thanks for the pointer, Charles. If this is standard behaviour in R, I’m actually fine with it. It just wasn’t clear that write.table is used for making tables. I would add a note about this in the documentation but, correct me if I’m wrong, the whole “:results table“-thing isn’t yet described in the documentation. Is that correct? Titus However, IMO `:results output' is the way to go for such cases. There are plenty of tools in R for formatting output and the user will have better control over what is produced. signature.asc Description: PGP signature
Re: [O] ob-sed
Hi Bjarte, On Fri, May 29, 2015 at 03:32:51PM +0200, Bjarte Johansen wrote: +(defun org-babel-execute:sed (body params) + Execute a block of sed code with Org Babel. +BODY is the source inside a sed source block and PARAMS is an +association list over the source block configurations. This ^^^ two spaces I think Nicolas means there should be two spaces after the period after configurations. Something like this: configurations. This It is probably clearer to see, once you read his email in a fixed width font. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). AFAICT, the x comes from R, not Org. It could also come from the way Org calls R, but I don't know enough of the latter to tell. The thread colnames with a list of columns does not work (see https://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00589.html) shouldn't be forgotten, as it contains an (un?)applied patch -- can't verify now. Best regards, Seb -- Sebastien Vauban
Re: [O] Help needed on delegating some maintainance tasks (was: Org maintainance)
If you send out this email again next year when I have graduated from university, I'd be down with helping out with things ^_^. - Original Message - From: Robert Klein rokl...@roklein.de To: Bastien b...@gnu.org Cc: emacs-orgmode@gnu.org Sent: Saturday, May 23, 2015 2:56:32 PM Subject: Re: [O] Help needed on delegating some maintainance tasks (was: Org maintainance) On Sat, 23 May 2015 10:47:49 +0200 Bastien b...@gnu.org wrote: Hi all, I need help on these maintainance tasks : 1. Watching the emacs-diffs mailing list and backport changes on Org in the local Org repository (2 hours per month). 2. Adding public keys on the orgmode.org server for org-mode and worg contributers (1 hour per month). 3. Maintaining the orgmode.org server and taking care of errors when updating Worg (1 hour per month). 4. Merging the last stable release into Emacs repository. (1 hour every release). 5. Releasing Org (.5 hour every release). I'd like to help with 3 but would need an introduction. Best regards Robert -- Leo Ufimtsev | Intern Software Engineer @ Eclipse Team
Re: [O] Bug: Non buffer-local org-not-done-heading-regexp breaks TODO dependencies under certain circumstances [8.3beta (release_8.3beta-1178-g317886 @ /opt/local/share/emacs/site-lisp/org/)]
Hello, Alexander Borkowski ale...@opus-b.com writes: I did some tracking down and I think this comes from the fact that variable org-not-done-heading-regexp is not buffer-local. It probably should be as both lines 4800 and 4803 in org.el are: (make-variable-buffer-local 'org-not-done-regexp) Good catch. That's a typo. Fixed in d00dcd09ca64f8d653241c1462b4e0d05ca92c73. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-use-property-inheritance not working?
Hello, Charles C. Berry ccbe...@ucsd.edu writes: On Fri, 29 May 2015, Rainer M Krug wrote: Is this to be expected? I always thought, that the properties are hierarchical, and that the ones from the lower levels / headers are used as well? I would have thought this, too. Property inheritance doesn't work that way. It only means that it will look higher in the hierarchy if current entry doesn't have the property you want. This is explained in `org-entry-get-with-inheritance' docstring: Get PROPERTY of entry or content at point, search higher levels if needed. The search will stop at the first ancestor which has the property defined. Here, current entry has the property, so it ignores the one above. Regards, -- Nicolas Goaziou
[O] [Bug] ~Verbatim~ in headlines breaks LaTeX
#+BEGIN_EXAMPLE
* The variable ~JAVA_HOME~
…
#+END_EXAMPLE
Exporting this to LaTeX and then compiling to PDF, produces the
following error:
! Missing $ inserted.
inserted text
$
l.35 \section{The variable \verb~JAVA_HOME~}
Apparently, \verb is not allow in command arguments:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin
One solution is uses \cprotect:
\cprotect\section{The variable \verb~JAVA_HOME~}
I don’t know how the exporter works but I wouldn’t be surprised if it
wasn’t entirely trivial to implement this.
The problem also exists in other situations where ~verbatim~ is used in
embedded contexts, for example when used in link descriptions:
[[https://encrypted.google.com/search?q=JAVA_HOME][Google
~JAVA_HOME~]]
Is there anything that speaks against using \texttt for ~verbatim~? The
HTML exporter uses the code tag for ~verbatim~ and =code=.
Titus
signature.asc
Description: PGP signature
Re: [O] ox-texinfo: Link to dedicated to target doesn't work
On Friday 29 May 2015 09:26 PM, Nicolas Goaziou wrote:
Hello,
Vaidheeswaran C vaidheeswaran.chinnar...@gmail.com writes:
ox-texinfo: Link to dedicated to target doesn't work
The behaviour is correct here.
You are inserting a link to a target without a description. As in any
export back-end, Org tries to associate it to a number, in this case,
headline's number.
A canonical DESCRIPTION is NOT available. (YET) The ANCHOR should
still get through to the `texi' file, right?
This is the output I see in other backends (that support anchors).
HTML:
p
Jump to a href=#orgtarget1No description for this link/a.
/p
LaTeX:
Jump to \ref{orgtarget1}.
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
Titus von der Malsburg malsb...@posteo.de writes:
#+BEGIN_EXAMPLE
* The variable ~JAVA_HOME~
#+END_EXAMPLE
Exporting this to LaTeX and then compiling to PDF, produces the
following error:
! Missing $ inserted.
inserted text
$
l.35 \section{The variable \verb~JAVA_HOME~}
Apparently, \verb is not allow in command arguments:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin
One solution is uses \cprotect:
\cprotect\section{The variable \verb~JAVA_HOME~}
I don’t know how the exporter works but I wouldn’t be surprised if it
wasn’t entirely trivial to implement this.
The problem also exists in other situations where ~verbatim~ is used in
embedded contexts, for example when used in link descriptions:
[[https://encrypted.google.com/search?q=JAVA_HOME][Google
~JAVA_HOME~]]
Is there anything that speaks against using \texttt for ~verbatim~? The
HTML exporter uses the code tag for ~verbatim~ and =code=.
Titus
I don't know what \cprotect does but there was a discussion of this a
long time ago:
http://thread.gmane.org/gmane.emacs.orgmode/14256/focus=14257
and back then, Carsten changed it so that verbatim in headlines used
\texttt - but that was the old latex exporter: I take it things are
different now?
Nick
Re: [O] [Bug] ~Verbatim~ in headlines breaks LaTeX
On 2015-05-29 Fri 21:32, Nick Dokos wrote:
Titus von der Malsburg malsb...@posteo.de writes:
#+BEGIN_EXAMPLE
* The variable ~JAVA_HOME~
#+END_EXAMPLE
Exporting this to LaTeX and then compiling to PDF, produces the
following error:
! Missing $ inserted.
inserted text
$
l.35 \section{The variable \verb~JAVA_HOME~}
Apparently, \verb is not allow in command arguments:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin
One solution is uses \cprotect:
\cprotect\section{The variable \verb~JAVA_HOME~}
I don’t know how the exporter works but I wouldn’t be surprised if it
wasn’t entirely trivial to implement this.
The problem also exists in other situations where ~verbatim~ is used in
embedded contexts, for example when used in link descriptions:
[[https://encrypted.google.com/search?q=JAVA_HOME][Google
~JAVA_HOME~]]
Is there anything that speaks against using \texttt for ~verbatim~? The
HTML exporter uses the code tag for ~verbatim~ and =code=.
Titus
I don't know what \cprotect does but there was a discussion of this a
long time ago:
http://thread.gmane.org/gmane.emacs.orgmode/14256/focus=14257
and back then, Carsten changed it so that verbatim in headlines used
\texttt - but that was the old latex exporter: I take it things are
different now?
Yes, I saw this thread after sending the previous email. According to
`org-latex-text-markup-alist', protectedtexttt should be used, which
seems like a good-enough solution for this problem. But for some reason
that doesn’t happen.
BTW, I used the latest development versions of Emacs (-Q) and Org-mode
to test this.
Titus
signature.asc
Description: PGP signature
[O] org-preview-latex-fragment on Retina display?
Recently, I upgraded to a macbook pro with retina display, and now all my latex previews in org-mode are... fuzzy. These are generated with org-preview-latex-fragment command, using dvipng. Is there a setting I can change to up-res these? Maybe something in org.el? Thanks, -Adam
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Titus von der Malsburg malsb...@posteo.de writes: I would add a note about this in the documentation but, correct me if I’m wrong, the whole “:results table“-thing isn’t yet described in the documentation. Is that correct? Not sure what you mean by :results table thing. The header argument :results table is described in the Org mode manual. I don't think the R-specific :results table behavior is described in ob-doc-R.org. If you'd like to remedy that, then the place to start might be the section Header Arguments under Org Mode Features for R Source Blocks. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-use-property-inheritance not working?
On Fri, 29 May 2015, Rainer M Krug wrote: Consider this example: I enable property inheritance with (setq org-use-property-inheritance t) But it does not matter. See the docstring for `org-entry-get'. The setting used in `org-babel-view-src-block-info' for INHERIT is `t'. I believe there is a problem with `org-entry-get'. Here is an ECM: --8---cut here---start-8--- #+PROPERTY: aprop one #+BEGIN_SRC emacs-lisp (org-entry-get (point) aprop t) #+END_SRC #+RESULTS: : one * x :PROPERTIES: :aprop+: two :END: #+BEGIN_SRC emacs-lisp (org-entry-get (point) aprop t) #+END_SRC #+RESULTS: : one two ** y :PROPERTIES: :aprop+: three :END: #+BEGIN_SRC emacs-lisp (org-entry-get (point) aprop t) #+END_SRC #+RESULTS: : one three I expected 'one two three' --8---cut here---end---8--- [much deleted] Is this to be expected? I always thought, that the properties are hierarchical, and that the ones from the lower levels / headers are used as well? I would have thought this, too. [rest deleted] Chuck
Re: [O] org-preview-latex-fragment on Retina display?
Adam Sneller a...@earth2adam.com writes: Recently, I upgraded to a macbook pro with retina display, and now all my latex previews in org-mode are... fuzzy. These are generated with org-preview-latex-fragment command, using dvipng. What happens if you produce a PDF document from LaTeX? Is it fuzzy? What happens if you use ImageMagick instead of dvipng? Is there a setting I can change to up-res these? Maybe something in org.el? Nick
[O] ReadTheOrg HTML theme
Hello, Just for your information, I've now allowed up to 3 levels in the TOC (left sidebar) instead of 2. See https://github.com/fniessen/org-html-themes for more information on how to use the ReadTheOrg CSS theme in your exports. Best regards, Fabrice PS- I'll give a 1:30 course on Org mode 8 (aimed to PDF LaTeX) during the Stage LaTeX de Dunkerque (yes, LaTeX?!) held on July, 1st. See http://stage-latex-gte.univ-littoral.fr/ to subscribe for free to any of the LaTeX events. -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
[O] Bug: Non buffer-local org-not-done-heading-regexp breaks TODO dependencies under certain circumstances [8.3beta (release_8.3beta-1178-g317886 @ /opt/local/share/emacs/site-lisp/org/)]
Hi all, I experimented a bit with per-file TODO keywords and noticed that under certain circumstances TODO dependencies are broken. A minimal example to reproduce the problem I encountered (under emacs -q) would be as follows: - Enable TODO dependencies, i.e. eval (setq org-enforce-todo-dependencies t) in *scratch*. - Create one file (e.g. ~/test-local.org) with these contents: #+TODO: LOCALTODO | LOCALDONE * Local Parent :PROPERTIES: :ORDERED: t :END: ** LOCALTODO First ** LOCALTODO Second Then add it to the end of agenda-files (with C-u C-c [) and close the buffer. - Create another file (e.g. ~/test-global.org) with these contents: * Global Parent :PROPERTIES: :ORDERED: t :END: ** TODO First ** TODO Second Then also add it to the end of agenda-files (with C-u C-c [) and close the buffer. - Now view the global TODO list (M-x org-todo-list) and notice that the second TODO from the local file is not dimmed and it is possible to change its TODO state (using the t key) as it is not blocked, but should be. I did some tracking down and I think this comes from the fact that variable org-not-done-heading-regexp is not buffer-local. It probably should be as both lines 4800 and 4803 in org.el are: (make-variable-buffer-local 'org-not-done-regexp) When I re-open emacs and eval (what I suspect line 4803 should be) (make-variable-buffer-local 'org-not-done-heading-regexp) in *scratch* before re-runing the above steps everything works as expected. Regards, Alex B. Emacs : GNU Emacs 24.5.1 (x86_64-apple-darwin11.4.2) of 2015-04-14 on tenseven-slave.macports.org Package: Org-mode version 8.3beta (release_8.3beta-1178-g317886 @ /opt/local/share/emacs/site-lisp/org/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-shell-link-function 'yes-or-no-p org-after-todo-state-change-hook '(org-clock-out-if-current) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-archive-hook '(org-attach-archive-delete-maybe) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-enforce-todo-dependencies t org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent) org-agenda-files '(~/test-local.org ~/test-global.org) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) )
