Re: [O] Regression in #+include behavior [master]
On Mon, Mar 19, 2018 at 6:52 PM Nicolas Goaziou wrote: > > Fixed. Thank you. > Hello, Thank you for quickly fixing this. Though I didn't understand why it failed when exporting from the large file, but not when moving the relevant subtrees (where the #+include was called, and the included) to a separate file.. I am just including content from one subtree to another in the same file.. What that the corner/pathological case?[1]. Sorry, I didn't quite understand the test in the commit. [1]: https://code.orgmode.org/bzg/org-mode/commit/beeb4bf23fd2b2339c2354457840d52c52d6dff5 -- Kaushal Modi
[O] org-mode R using xtable produces strange output
I am using xtable to produce summary tables of linear models, specifying the output as latex. If I just run the code in R, I get the correct output. However, the latex output in the org document contains a lot of “|”s. I think this is because the header of the table contains some code to make “p > |t|”, where the vertical lines are to indicate “absolute value of t”. My guess is that when the output is written to the results section, org interprets the “|” signs as an org-table and tries to be helpful by adding more of them to make up the correct number of columns. If I switch off the latex output, and write the xtable to a small .tex file, using xtable.print and then include the file after the code block, the table appears correctly. I’m using emacs 25.2. Here’s an example: Best wishes, Brian xtableeg.org Description: Binary data
Re: [O] [PATCH v2 0/3] org-sbe fixes
Hello, Vladimir Panteleev writes: > OK, here is v2 with table-based tests. > > Vladimir Panteleev (3): > ob-table: Fix org-sbe's handling of quotes in cell values > ob-table: Fix org-sbe's handling of list arguments > ob-table: Mention passing ranges as lists in org-sbe's documentation Applied. Thank you! Regards, -- Nicolas Goaziou
Re: [O] Regression in #+include behavior [master]
Hello, Kaushal Modi writes: > I believe a regression was introduced in > https://code.orgmode.org/bzg/org-mode/commit/d81a1d088c74e605c99e90a2835c55df5144f43e > > I am unable to come with a minimal example, but I can link to the actual > Org file that causes the failure. If I try to move that subtree along with > the "included" subtrees into a separate Org file, the export works fine. > > - Download > https://raw.githubusercontent.com/kaushalmodi/ox-hugo/master/test/site/content-org/all-posts.org > (you can wget or curl that file using that URL). > - Ensure that point is in the "* Alert Shortcode Lookalike" heading (around > line 3416). > - Do C-c C-e C-s h h > > You should get an error like this: > > Debugger entered--Lisp error: (wrong-type-argument stringp nil) > looking-at(nil) > org-element-context() Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] does this pandoc error look familiar to anybody?
On 3/19/18, Eric S Fraga wrote: > has a limit on the number of levels, both headings and items. If you > have an org document (assuming you started with org to generate the > HTML) which has >8 levels, you are likely to run into this problem. thanks everybody for your contributions, including muphry. i will have to try this, but can i assume [i do hope] that org->html->pandoc->pdf does not count clean view as approximately doubling the number of levels? and that it does not count levels above the subtree that i am exporting? i.e. the olpath a/b/c/d/e/f/g/h/i/i am exporting this/2/3/4 would be ok?
Re: [O] Regression in #+include behavior [master]
On Mon, Mar 19, 2018 at 4:00 PM Kaushal Modi wrote: > Hello, > > I believe a regression was introduced in > https://code.orgmode.org/bzg/org-mode/commit/d81a1d088c74e605c99e90a2835c55df5144f43e > Actually the commit before that would have been the breaking commit as I was able to "fix" this locally by reverting to 594b2dbae85dca118253fa35b0681c66362587ee and re-evalling ox.el. -- Kaushal Modi
[O] Regression in #+include behavior [master]
Hello, I believe a regression was introduced in https://code.orgmode.org/bzg/org-mode/commit/d81a1d088c74e605c99e90a2835c55df5144f43e I am unable to come with a minimal example, but I can link to the actual Org file that causes the failure. If I try to move that subtree along with the "included" subtrees into a separate Org file, the export works fine. - Download https://raw.githubusercontent.com/kaushalmodi/ox-hugo/master/test/site/content-org/all-posts.org (you can wget or curl that file using that URL). - Ensure that point is in the "* Alert Shortcode Lookalike" heading (around line 3416). - Do C-c C-e C-s h h You should get an error like this: Debugger entered--Lisp error: (wrong-type-argument stringp nil) looking-at(nil) org-element-context() org-export--prepare-file-contents("/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/test/site/content-org/ all-posts.org" "3311-3358" 0 5 1 # "/home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/ox-hugo/test/site/content-org/ all-posts.org") org-export-expand-include-keyword() org-export-as(html t nil nil (:output-file "alert-short-code-lookalike.html")) org-export-to-file(html "alert-short-code-lookalike.html" nil t nil nil nil) org-html-export-to-html(nil t nil nil) org-export-dispatch(nil) funcall-interactively(org-export-dispatch nil) call-interactively(org-export-dispatch nil nil) command-execute(org-export-dispatch) Let me know if this error can be reproduced by the above steps -- Kaushal Modi
Re: [O] Defining the export height of a babel-generated image
On Monday, 19 Mar 2018 at 14:14, Karl Voit wrote: [...] > Hehe. Simple as that. sometimes, but only sometimes... :-) -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d signature.asc Description: PGP signature
Re: [O] [PATCH] org-global-tags-completion-table does not include tags from buffers
Attached is a patch that fixes the issue. Best, Matt Matt Lundin writes: > If org-tags-alist is customized by the user, the value returned by > org-global-tags-completion-table does not include any tags from agenda > buffers and files. > > This behavior contradicts the docstring of > org-global-tags-completion-table, which claims to return the list of all > tags in all agenda buffer/files. > > I believe this bug was introduced with commit > 4743d43dd8e448b6c440b1e4988bcd353de60cc7 in April 2016. Before that > commit, Org mode appended tags in org-tags-alist to tags gathered from > the buffer. After the commit, Org mode no longer gathers buffer tags if > org-tags-alist is defined. > > Line 13731 is the key line: > > (or org-current-tag-alist (org-get-buffer-tags))) > > AFAICT, org-current-tag-alist only includes tags defined in > org-tag-alist and org-tag-persistent-alist. So if these are defined, the > function will never gather the buffer tags. > > As an aside, this bug makes filtering the agenda by filetags or tags in > org buffers impossible due to commit > 404ac42ee51f0ac0d9cfb8fbefaefbbe96c61017, which requires a match for tag > completion when hitting "/ [TAB]" in the agenda. Since > org-global-tags-completion-table does not actually return the tags in > buffers, it is impossible to filter by them. > > I can reproduce this with emacs -Q (emacs 25.3 and Org mode from git). > > Best, > Matt >From fc09bce2c9efe72a340132a499510658cd03bec2 Mon Sep 17 00:00:00 2001 From: Matt Lundin Date: Mon, 19 Mar 2018 09:53:15 -0500 Subject: [PATCH] Include buffer tags in global tags completion * lisp/org.el: (org-global-tags-completion-table): Return all tags, including tags in the buffer. This fixes a bug that caused buffer tags to be excluded if user configured tags either via org-tag-alist or the #+TAGS keyword. --- lisp/org.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 73ab32aa0..44b57a60d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13724,10 +13724,11 @@ instead of the agenda files." (mapcar (lambda (file) (set-buffer (find-file-noselect file)) - (mapcar (lambda (x) - (and (stringp (car-safe x)) -(list (car-safe x - (or org-current-tag-alist (org-get-buffer-tags + (append (org-get-buffer-tags) + (mapcar (lambda (x) + (and (stringp (car-safe x)) + (list (car-safe x + org-current-tag-alist))) (if (car-safe files) files (org-agenda-files -- 2.16.2
Re: [O] does this pandoc error look familiar to anybody?
On Mon, 19 Mar 2018 08:30:13 -0400, Colin Baxter wrote: Adonay Felipe Nogueira writes: snip > Good academic and writting practice tells that headings shouldn't > be more than four levels deep. In LaTeX (which is used for PDF > export), and its default `article' class, you can have > `section{}', `subsection{}', `subsubsection{}' and --- if I'm not > mistaken --- `subsubsubsection{}'. There's also part{}. Indeed, if your writing is to be read by other people, not just yourself, you should try to stay to no more than two levels. If you feel you need levels deeper than two, perhaps your should refactor your writing. When I say "two" do I mean * and **, or do I mean ** and ***? Well, I guess that depends upon what the value of two is. Moreover, as we can already see in this discussion, any attempt to correct errors of style, grammar or spelling will itself contain additional errors. This phenomenon is sometimes called Muphry's Law. Yes, Muphry, not Murphy. https://en.wikipedia.org/wiki/Muphry%27s_law
Re: [O] Defining the export height of a babel-generated image
* Eric S Fraga wrote: > > On Sunday, 18 Mar 2018 at 15:35, Karl Voit wrote: >> Hi! >> >> Some babel blocks generate image files as output. Orgmode does link >> them so that exporting the corresponding heading also includes the >> image. >> >> For example: >> >> #+BEGIN_SRC plantuml :file "foobar.svg" >> (*) --> "step1" >> --> "step2" >> --> (*) >> #+END_SRC >> >> #+RESULTS: >> [[foobar.svg]] >> >> Is is possible to define a height attribute for the result file >> which is used for LaTeX/PDF export? > > Sure: put the desired #+attr_latex: line just before the #+results line. Hehe. Simple as that. I thought this might get replaced on babel block execution. I was wrong. I now have two working solutions: ** Solution 1: https://orgmode.org/manual/post.html#post #+name: attr_wrap #+begin_src sh :var data="" :var width="\\textwidth" :results output echo "#+ATTR_LATEX: :width $width" echo "$data" #+end_src #+BEGIN_SRC plantuml :post attr_wrap(width="1cm", data=*this*) :results drawer :file (make-temp-file "export-example-1-" nil ".png") (*) --> "step1" --> "step2" --> (*) #+END_SRC #+RESULTS: :RESULTS: #+ATTR_LATEX: :width 1cm [[file:c:/Users/KARL~1.VOI/AppData/Local/Temp/export-example-1-tXDZCj.svg]] :END: ** Solution 2: "put the desired #+attr_latex: line just before the #+results line." #+BEGIN_SRC plantuml :file (make-temp-file "export-example-2-" nil ".png") (*) --> "step1" --> "step2" --> (*) #+END_SRC #+ATTR_LATEX: :width 2cm #+RESULTS: [[file:c:/Users/KARL~1.VOI/AppData/Local/Temp/export-example-2-nvoWbD.svg]] -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [O] Creating mu4e-like screens for org-mode
On 2018-03-19, at 12:25, Roland Everaert wrote: > Hi, > > I would like to create a set of screens for dealing with org-mode like mu > and notmuch does with maildir. > > So I am searching good resources, like guidelines, that explain how to > build that can of features. > > I could look directly into the code of those projects or the agenda view, > but I would prefer something more structured than trial-and-error. You might be interested in the widget.el library (it has its own info docs). Not the easiest to use, but quite powerful. Another approach would be to write a major mode with suitable bindings, probably derived from special-mode. I suspect this is what mu4e does. A lightweight approach would be a hydra. Coincidentally, I blogged about my Org-mode-related hydra a few days ago: http://mbork.pl/2018-03-18_My_Org-mode_hydra I might need a similar thing (a menu-driven application on top of Emacs), so I might be tempted to write a blog post about such a thing. Would you be interested? I'm wondering what Org-mode features are you going to interfce to this way. Hth, -- Marcin Borkowski http://mbork.pl
Re: [O] does this pandoc error look familiar to anybody?
> Adonay Felipe Nogueira writes: snip > Good academic and writting practice tells that headings shouldn't > be more than four levels deep. In LaTeX (which is used for PDF > export), and its default `article' class, you can have > `section{}', `subsection{}', `subsubsection{}' and --- if I'm not > mistaken --- `subsubsubsection{}'. There's also part{}. Best wishes,
Re: [O] does this pandoc error look familiar to anybody?
> ! LaTeX Error: Too deeply nested. I guess that it's due to excessive subsections, or --- in Org mode documents --- this can also happen if you have headings such as "***" or similar exagerated structure. The heading "***" by default is exported as an item list (`itemize' environment), or as an enumerated list (`enumerate' environment), depending on the heading level. Good academic and writting practice tells that headings shouldn't be more than four levels deep. In LaTeX (which is used for PDF export), and its default `article' class, you can have `section{}', `subsection{}', `subsubsection{}' and --- if I'm not mistaken --- `subsubsubsection{}'. At least for the LaTeX `book' class, before `section{}', there is `\chapter{}'. In all cases, those headings that are deeper than four are exported as lists by Org mode when converting to LaTeX and to PDF. -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar instantaneamente comigo no endereço abaixo. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM.
[O] Creating mu4e-like screens for org-mode
Hi, I would like to create a set of screens for dealing with org-mode like mu and notmuch does with maildir. So I am searching good resources, like guidelines, that explain how to build that can of features. I could look directly into the code of those projects or the agenda view, but I would prefer something more structured than trial-and-error. Regards, Roland.
Re: [O] Defining the export height of a babel-generated image
On Sunday, 18 Mar 2018 at 15:35, Karl Voit wrote: > Hi! > > Some babel blocks generate image files as output. Orgmode does link > them so that exporting the corresponding heading also includes the > image. > > For example: > > #+BEGIN_SRC plantuml :file "foobar.svg" > (*) --> "step1" > --> "step2" > --> (*) > #+END_SRC > > #+RESULTS: > [[foobar.svg]] > > Is is possible to define a height attribute for the result file > which is used for LaTeX/PDF export? Sure: put the desired #+attr_latex: line just before the #+results line. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d signature.asc Description: PGP signature
Re: [O] does this pandoc error look familiar to anybody?
On Sunday, 18 Mar 2018 at 21:43, Samuel Wales wrote: > exporting to html, then converting to pdf errors. it worked ok > before. just wondering if anybody has seen this before and can guess > if i did something wrong at the org level? hard to know without seeing the actual input file but, if this happens to be related to your other posting regarding exporting to PDF, LaTeX has a limit on the number of levels, both headings and items. If you have an org document (assuming you started with org to generate the HTML) which has >8 levels, you are likely to run into this problem. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d signature.asc Description: PGP signature
Re: [O] what settings would make original export to pdf as good as pandoc conversion?
On Sunday, 18 Mar 2018 at 21:41, Samuel Wales wrote: > On 3/13/18, Eric S Fraga wrote: >> Could you post a minimal example that illustrates this? > > here is the minimal example. [btw, it turns out that pandoc erros > now, so i have to either get your direct export code to work, or fix > pandoc's export.] Couple of things: 1. Start your document with a top level heading, i.e. single * heading. 2. Remove any whitespace before the \[...] entries in your org-latex-classes setting. For instance, this seems to work fine for me although obviously with no real content it is difficult to see the settings taking effect: * NEXTKA fixing pdf to have better paragraphs SCHEDULED: <2018-03-21 Wed> #+begin_src emacs-lisp (add-to-list 'org-latex-classes '("article" " \\documentclass{scrartcl} \[DEFAULT-PACKAGES] \[PACKAGES] \[EXTRA] \\setlength{\\parindent}{0pt} \\setlength{\\parskip}{6pt} " ("\\section{%s}" . "\\section*{%s}") ("\\subsection{%s}" . "\\subsection*{%s}") ("\\subsubsection{%s}" . "\\subsubsection*{%s}") ("\\paragraph{%s}" . "\\paragraph*{%s}") ("\\subparagraph{%s}" . "\\subparagraph*{%s}"))) #+end_src -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.7-475-g3ffc7d signature.asc Description: PGP signature
[O] org-latex-export-to-pdf error
Hi, This morning, I've received an error message that I do not understand. Perheaps you can help me. If a try to export a file to pdf typing "C-c C-e l p", I receive the error message below (that I do not understand.) if, for the same file, I type "M-x org-latex-export-to-pdf", the pdf file is produced without any error. I suspect (but you can perheaps confirm that) that there is a conflict between "my" org configuration and "my" yasnippet configuration. Thank you in advance for your advice kind regards claude ;; error message == Debugger entered: ("`yas--original-auto-fill-function' unexpectedly nil! Please report this backtrace (hit `c' to continue)") (progn (debug nil "`yas--original-auto-fill-function' unexpectedly nil! Please report this backtrace (hit `c' to continue)")) (if (and (null newval) (eq auto-fill-function 'yas--auto-fill) (fboundp 'backtrace-frames) (not (and (eq op 'makunbound) (not (eq (default-value 'auto-fill-function) 'yas--auto-fill)) (cl-member 'kill-all-local-variables (backtrace-frames 'yas--watch-auto-fill) :key (function (lambda (frame) (nth 1 frame))) (progn (debug nil "`yas--original-auto-fill-function' unexpectedly nil! Please report this backtrace (hit `c' to continue)"))) yas--watch-auto-fill(yas--original-auto-fill-function nil set #) make-local-variable(yas--original-auto-fill-function) #f(compiled-function () #)() funcall(#f(compiled-function () #)) org-element-parse-secondary-string("13 novembre 2017" (bold code entity export-snippet inline-babel-call inline-src-block italic line-break latex-fragment link macro radio-target statistics-cookie strike-through subscript superscript target timestamp underline verbatim)) org-macro-initialize-templates() org-export-as(latex nil nil nil (:output-file "cprog.tex")) org-export-to-file(latex "cprog.tex" nil nil nil nil nil #f(compiled-function (file) #)) org-latex-export-to-pdf(nil nil nil nil) org-export-dispatch(nil) funcall-interactively(org-export-dispatch nil) #(org-export-dispatch nil nil) apply(# org-export-dispatch (nil nil)) call-interactively@ido-cr+-record-current-command(#call-interactively> org-export-dispatch nil nil) apply(call-interactively@ido-cr+-record-current-command #call-interactively> (org-export-dispatch nil nil)) call-interactively(org-export-dispatch nil nil) command-execute(org-export-dispatch)