Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
On 25/05/18 01:13, Nicolas Goaziou wrote: Hello, Alex Fenton writes: As far I understand it, |:output-dir| and |:file-ext| that were intended to be used in the global document header, applying to all blocks. However, it seems to mean that all blocks regardless of their :results args then emit a file, and put their output as a [file:] link. It's not clear from the docs why this happens. Am I missing something, or does this mean that these arguments are useless unless a document happens only to emit graphics from blocks? At the moment, the blocks (R, as it happens) are meant to sometimes emit scalars, sometimes literal latex, sometimes tables to be formatted by orgs, and sometimes graphics. But all the non-graphics are at the moment being stuffed into (non-working) PDF files. Following a discussion and suggested, but not-working solution at: https://emacs.stackexchange.com/questions/41618/org-modes-output-dir-and-file-ext-arguments-cause-all-output-to-be-saved-to I agree something is cheesy here. According to `org-babel-execute-src-block', if :file is set (it can also be forged from :file-ext and :output-dir according to `org-babel-generate-file-param'), results become the filename. Also, according to `org-babel-merge-params' both :file and :file-ext trump :results value, i.e., they automatically imply "file" in :results. and "results" in :exports. At this point, I'm not sure about :export, but I think it should be the other way for :results. IOW, :file and :file-ext should be taken into consideration only when :results contains "file". WDYT? Regards,
Re: [O] link handling for `file:' fails to stay within Emacs but calls `open file:' with TextEdit
> Nicolas Goaziou writes: > > You may > want to tweak `org-file-apps’. I chose `Default for unrecognized files’, `Visit with Emacs’; but `Default for files in directory’ or use of the hidden file in the directory for setting the mode would be better. Thanks.
Re: [O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
Hello, Alex Fenton writes: > As far I understand it, |:output-dir| and |:file-ext| that were > intended to be used in the global document header, applying to all > blocks. > > However, it seems to mean that all blocks regardless of their :results > args then emit a file, and put their output as a [file:] link. It's > not clear from the docs why this happens. > > Am I missing something, or does this mean that these arguments are > useless unless a document happens only to emit graphics from blocks? > At the moment, the blocks (R, as it happens) are meant to sometimes > emit scalars, sometimes literal latex, sometimes tables to be > formatted by orgs, and sometimes graphics. But all the non-graphics > are at the moment being stuffed into (non-working) PDF files. > > Following a discussion and suggested, but not-working solution at: > https://emacs.stackexchange.com/questions/41618/org-modes-output-dir-and-file-ext-arguments-cause-all-output-to-be-saved-to I agree something is cheesy here. According to `org-babel-execute-src-block', if :file is set (it can also be forged from :file-ext and :output-dir according to `org-babel-generate-file-param'), results become the filename. Also, according to `org-babel-merge-params' both :file and :file-ext trump :results value, i.e., they automatically imply "file" in :results. and "results" in :exports. At this point, I'm not sure about :export, but I think it should be the other way for :results. IOW, :file and :file-ext should be taken into consideration only when :results contains "file". WDYT? Regards, -- Nicolas Goaziou
Re: [O] link handling for `file:' fails to stay within Emacs but calls `open file:' with TextEdit
Hello, Van L writes: > The link handling for org mode behaves unexpectedly where a file sets > org mode according to `Local variables:' at the end of the file. > > In the following, a.org and b.org files work as expected using M-x > org-store-link and M-x org-insert-link for `file:' link. > > Without the .org filename extension, following the link calls > > `open file:' which leads to Org Mode opening the file with TextEdit > > under mac os, Emacs 26.1 rc-1. > > > > > ;; running: Emacs.app/Contents/MacOS/Emacs -Q > ;; problem: This two file arrangment for `Emacs -Q' *fails* to follow the > link. > ;; expect : Emacs to open a link to org file. > ;; unexpected : Emacs calls TextEdit to open org file. > ;; solution : if file a and b are called a.org and b.org then there is no > problem. > > ;; Solution needs org files named without the `.org’ extension > ;; to follow `file:’ links without leaving Emacs. Files are selected by their extension, not by their major mode. You may want to tweak `org-file-apps'. Regards, -- Nicolas Goaziou
Re: [O] set Babel default header argument don't eval when export seems does not work
Hello, stardiviner writes: > I set Babel default header arguments to this: > > , > | (setq-default org-babel-default-header-args > | '((:session . "none") > | (:noweb . "no") (:hlines . "no") > | (:tangle . "no") (:comments . "links") > | (:cache . "yes") > | (:results . "replace") > | ;; for exporting > | (:eval . "never-export") > | (:exports . "both") > | )) > ` > > When I export with org-publish, src blocks still evaluated. Seems > `:eval never-export` does not work? This is rather vague. Could you send an ECM demonstrating the issue? Also, did you try with regular export? Did you try with synchronous publishing? Regards, -- Nicolas Goaziou
[O] Babel - :export-dir and :file-ext arguments cause all blocks to emit files
Hi, As far I understand it, |:output-dir| and |:file-ext| that were intended to be used in the global document header, applying to all blocks. However, it seems to mean that all blocks regardless of their :results args then emit a file, and put their output as a [file:] link. It's not clear from the docs why this happens. Am I missing something, or does this mean that these arguments are useless unless a document happens only to emit graphics from blocks? At the moment, the blocks (R, as it happens) are meant to sometimes emit scalars, sometimes literal latex, sometimes tables to be formatted by orgs, and sometimes graphics. But all the non-graphics are at the moment being stuffed into (non-working) PDF files. Following a discussion and suggested, but not-working solution at: https://emacs.stackexchange.com/questions/41618/org-modes-output-dir-and-file-ext-arguments-cause-all-output-to-be-saved-to Thanks alex
Re: [O] [PATCH] Add new keyword :coding for #+include directive
Hello Nicolas, I'm sorry for the delay, this problem drove me crazy for a few days. So I started again from the beginning and, of course, I am now unable to replicate my original test case. So, I think you could delete the 0001-Manage-the-encoding-of-files-with-include-.patch patch. I am really sorry for the inconvenience. I hope we can go ahead with the other patch to add a ":coding" keyword to the include directive. To resume the goal: The include keyword works well with encodings like cp850 if, and only if, there are some indications of the encoding in the file (as local variables for example). But sometimes, there is no such information and you can not modify the file (for various reasons. ex: the file is generated automatically). Once again, I'm sorry for the disturbance. Regards, Nicolas Goaziou writes: > Hello, > > pierre.techouey...@free.fr (Pierre Téchoueyres) writes: > >> I've used the following command to do the test : >> for emacs 25.3 >> >> #+begin_src sh >> emacs -Q -L lisp -L ~/.emacs.d/elpa-25/htmlize-20180412.1244 -l >> ~/.emacs.d/elpa-25/htmlize-20180412.1244/htmlize-autoloads.el >> testing/examples/test.org >> #+end_src > > With the command above, you're not exporting the file using "ox.el". > What are you testing? Could you use a command that exports the file > (preferably using ASCII (utf-8) export back-end)? > >> TEST WITH DIFFERENT ENCODINGS. >> >> Pierre TÚchoueyres > ^^^ > see > > Regards,
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Aaron, I just went ahead and removed that "---" syntax from ox-hugo. Updated links: 1. https://ox-hugo.scripter.co/doc/details-and-summary/ 2. https://ox-hugo.scripter.co/test/posts/details-and-summary/ (it was easy as I had committed that feature just yesterday.) On Thu, May 24, 2018 at 3:08 PM Aaron Ecay wrote: > > Is it important for open to be a “bare” attribute (not sure of the > official name) like “” as opposed to “ open="open">”? I'm not so sure.. I just followed the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details#Creating_an_open_disclosure_box > The latter form is already supported (in fact the second > “open” can be any string). Just add > > #+attr_html: :open any-string-you-want > I know, but I did not test that.. just thought of doing as in that example in the mozilla documentation. That's why I am using (org-element-property :attr_html special-block) in the code to get the raw values to #+attr_html. > The only thing I know off the top of my head is that CSS can be quite > hairy, Heh, of course :) > so I would not be surprised if this wrapper is sometimes needed. > And indeed, support for it would be missing. > Is it something that is > likely to crop up for other elements as well, such that it would be > desirable to support it in org core? That would be great. I myself wasn't sure if I should bring that up to Org core.. I had just implemented #+attr_css support for ox-hugo. It looks like this: #+attr_html: :class red-text #+attr_css: :color red - Red list item 1 - Red list item 2 Above will generate
Re: [O] Code or Verbatim
Hello, aldo ridhoni writes: > https://orgmode.org/manual/Emphasis-and-monospace.html#Emphasis-and-monospace > > https://orgmode.org/guide/Emphasis-and-monospace.html#Emphasis-and-monospace > > The manual and guide is different in code and verbatim text. Which one is > the right one? The manual is the reference. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, 2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen: > > Yes, the proposal though supports these 2 things specific to details > element: > > 1. Detecting "open" attribute via "#+attr_html: open". Is it important for open to be a “bare” attribute (not sure of the official name) like “” as opposed to “”? The latter form is already supported (in fact the second “open” can be any string). Just add #+attr_html: :open any-string-you-want above the block. > > 2. Adding a wrapper tag around the details portion > following the tag. Useful if user wants to set CSS rules for > "details .details". The only thing I know off the top of my head is that CSS can be quite hairy, so I would not be surprised if this wrapper is sometimes needed. And indeed, support for it would be missing. Is it something that is likely to crop up for other elements as well, such that it would be desirable to support it in org core? (This is at least partly me wondering out loud, no need to specifically answer unless something particularly occurs to you one way or the other.) -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Aaron, On Thu, May 24, 2018 at 2:36 PM Aaron Ecay wrote: > > I wasnʼt thinking about multiparagraph summaries. But actually, I > realize that your suggestion in response would work with only one small > change to a variable in ox-html. Yes, the proposal though supports these 2 things specific to details element: 1. Detecting "open" attribute via "#+attr_html: open". 2. Adding a wrapper tag around the details portion following the tag. Useful if user wants to set CSS rules for "details .details". > Assuming there are no objections, we could make this tweak to > ‘org-html-html5-elements’ in org core. I don't mind adding that to ox-html. Just that the details disclosure implementation will be /slightly/ incomplete, but still very functional. I think “syntactic sugar” like > your original proposal could be implemented as a before-parsing-hook > that transforms the --- into the above syntax. > +1 > PS Once upon a time, I created ox-extras in contrib as a home for little > snippets like this hypothetical before-parsing-hook. It never really > took off, but maybe itʼs just biding its time... > Sure thing :) -- Kaushal Modi
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, 2018ko maiatzak 24an, Kaushal Modi-ek idatzi zuen: > > HTML allows multi-paragraph summaries.. (see my test link above). Expanding > on your idea.. what if we had another Special block with name summary? I wasnʼt thinking about multiparagraph summaries. But actually, I realize that your suggestion in response would work with only one small change to a variable in ox-html. Specifically, the following document already yields the desired behavior with vanilla org (both giving the proper behavior in html5, and having a fallback for earlier versions): = * setup #+begin_src emacs-lisp (add-to-list 'org-html-html5-elements "details") (add-to-list 'org-html-html5-elements "summary") (setq-local org-html-html5-fancy t) (setq-local org-html-doctype "html5") #+end_src * subtree #+begin_details #+begin_summary Open for details More summary. #+end_summary Many details here. #+end_details = Assuming there are no objections, we could make this tweak to ‘org-html-html5-elements’ in org core. I think “syntactic sugar” like your original proposal could be implemented as a before-parsing-hook that transforms the --- into the above syntax. Aaron PS Once upon a time, I created ox-extras in contrib as a home for little snippets like this hypothetical before-parsing-hook. It never really took off, but maybe itʼs just biding its time... -- Aaron Ecay
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hello Aaron,
On Thu, May 24, 2018 at 2:08 PM Kaushal Modi wrote:
> Expanding on your idea.. what if we had another Special block with name
> summary?
>
> #+begin_details
> #+begin_summary
> Open for details
>
> More summary.
> #+end_summary
> Many details here.
> #+end_details
>
>From quick testing, this works (doesn't support the div tags for HTML4).
The good part is that the "summary" Special Block is automatically handled
by ox-html.
((string= block-type "details")
;; Recognize Org Special blocks like:
;; #+begin_details
;; #+begin_summary
;; This is summary.
;; #+end_summary
;; Here are the details.
;; #+end_details
(let* ((is-open (member "open" (org-element-property :attr_html
special-block)))
(str1 (org-blackfriday-special-block special-block contents
nil))
;; Insert a new-line before the closing tag
;; for correct Markdown parsing for cases when the
;; Special Block content ends a code block. Without this
;; inserted newline, the Markdown converted content will
;; look like below, and Blackfriday won't parse it
;; correctly.
;; ```emacs-lisp
;; (message "a code block")
;; ```
;; A closing tag is also added.. the opening
;; tag is later added in the `str2' var if summary is
;; present, else in `str3' var.
(str1 (replace-regexp-in-string "\\'" "\n\\&"
str1))
;; Detect the summary closing tag "".
;; Also add the opening tag with "details" class
;; so that just as CSS rules can be set for summary
;; ("details summary"), they can be set for the details
;; portion following the too, using "details
;; .details".
(str2 (replace-regexp-in-string
"\\(\\(.\\|\n\\)*\\)"
"\\1"
str1)))
;; (message "[DBG details/summary]: is-open:%S `%s' `%s'" is-open
str1 str2)
(if is-open
(replace-regexp-in-string "\\`\\(" "\\1 open>" str2)
str2)))
Also, thinking about HTML4 support, as details and summary tags were added
in HTML5, the "support" would be simply to and the (string= block-type
"details") condition with org-html-html5-fancy or equivalent. So then for
HTML4, details and summary Special Blocks will simply be div tags.
--
Kaushal Modi
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Aaron, Thanks for the feedback. On Thu, May 24, 2018 at 1:42 PM Aaron Ecay wrote: > Hi Kaushal, > > It seems like a good idea. My two comments are: > > - Remember that ox-html can export to HTML4, so the code would need to > detect that case and have a sensible fallback > Yes, I think that would need to be handle just as ox-html does now.. use div tags instead of details and summary tags. > - The approach of looking for “magic” strings in the contents seems > hackish. What if the summary was treated as a caption? > I also feel like that's a hack, but seems quite robust and functional at least in my tests. The main reason to make summary part of details was to no impose a one-paragraph limit on summaries. Here's my pathological test for this feature: https://ox-hugo.scripter.co/test/posts/details-and-summary/ #+caption: Open for details > #+begin_details > Many details here. > #+end_details > > (Admittedly, the mismatch between “caption” and “summary” is not ideal, > but caption is the only suitable keyword that the syntax gives us...). > I agree. caption doesn't go well with details.. looks like making a stew out of whatever's in the fridge. Hope that bad metaphor makes sense :) Another idea would be: > > #+begin_details > #+summary: Open for details. > Many details here. > #+end_details > HTML allows multi-paragraph summaries.. (see my test link above). Expanding on your idea.. what if we had another Special block with name summary? #+begin_details #+begin_summary Open for details More summary. #+end_summary Many details here. #+end_details It doesn't look as pretty as using the magic string "---", but it should work. But still not sure.. > Just food for thought... > I appreciate that. -- Kaushal Modi
Re: [O] RFC: Proposal for an Org Special Block for ox-html
Hi Kaushal, It seems like a good idea. My two comments are: - Remember that ox-html can export to HTML4, so the code would need to detect that case and have a sensible fallback - The approach of looking for “magic” strings in the contents seems hackish. What if the summary was treated as a caption? #+caption: Open for details #+begin_details Many details here. #+end_details (Admittedly, the mismatch between “caption” and “summary” is not ideal, but caption is the only suitable keyword that the syntax gives us...). Another idea would be: #+begin_details #+summary: Open for details. Many details here. #+end_details This approach would require a supporing change to be made to the ‘org-html-keyword’ function. Just food for thought... -- Aaron Ecay
[O] RFC: Proposal for an Org Special Block for ox-html
Hello,
Yesterday, I came up with a way to generate the HTML details disclosure
fairly easily using Org Special Blocks. I implemented that in ox-hugo. But
I believe the same would be useful for ox-html too.
Here's the relevant code snippet:
((string= block-type "details")
;; Recognize Org Special blocks like:
;; #+begin_details
;; summary. This will be wrapped in and
;; ---
;; details
;; #+end_details
(let* ((is-open (member "open" (org-element-property :attr_html
special-block)))
(str1 (org-blackfriday-special-block special-block contents
nil))
;; Insert a new-line before the closing tag
;; for correct Markdown parsing for cases when the
;; Special Block content ends a code block. Without this
;; inserted newline, the Markdown converted content will
;; look like below, and Blackfriday won't parse it
;; correctly.
;; ```emacs-lisp
;; (message "a code block")
;; ```
;; A closing tag is also added.. the opening
;; tag is later added in the `str2' var if summary is
;; present, else in `str3' var.
(str1 (replace-regexp-in-string "\\'" "\n\\&"
str1))
;; Detect the summary divider special string "---". It
;; must begin at the beginning of a line. Also ensure to
;; replace only the first match, if any.
;; Also add the opening tag with "details" class
;; so that just as CSS rules can be set for summary
;; ("details summary"), they can be set for the details
;; portion following the too, using "details
;; .details".
(str2 (replace-regexp-in-string
"^\\(---\\)\n\\(.\\|\n\\)*\\'"
""
str1 nil nil 1))
(has-summary (not (string= str1 str2)))
str3)
;; (message "[DBG details/summary]: is-open:%S `%s' `%s'" is-open
str1 str2)
(setq str3 (if has-summary
(replace-regexp-in-string "\\`"
"\\&" str2)
(replace-regexp-in-string "\\`" "\\&" str2)))
(if is-open
(replace-regexp-in-string "\\`\\(" "\\1 open>" str3)
str3)))
I used "---" as the summary/details divider so that even if someone exports
that Org document to HTML without that support in ox-html, it exports as
Summary — Details.
See this for examples: https://ox-hugo.scripter.co/doc/details-and-summary/
Here is the full org-hugo-special-block:
https://github.com/kaushalmodi/ox-hugo/blob/14533c96195c90e417fcbde9d938650e83a39125/ox-hugo.el#L2239-L2363
If this feature is approved for addition to ox-html, I can make a formal
patch where instead of looking for "---", I look for the appropriate string
based on the value of (plist-get info :with-special-strings).
Thanks!
Kaushal
--
Kaushal Modi
[O] extract a column from a table but but an name on the new table
Hi Thierry Banel one of the authors of orgtbl-aggregate.el Suggested to me the following code, if just want to extract one column of a table. #+TBLNAME: raw-data | 1 | a | 3 | | 2 | b | 4 | | 3 | c | 6 | | 4 | d | 7 | #+BEGIN_SRC elisp :var data=raw-data (mapcar (lambda (line) (list (nth 2 line))) data) #+END_SRC #+RESULTS: | 3 | | 4 | | 6 | | 7 | It works nicely but how could I obtain the result with a table name, like: #+TBLNAME: RESULTS | 3 | | 4 | | 6 | | 7 | Or something like this? Thanks Uwe Brauer
Re: [O] Code or Verbatim
aldo ridhoni writes on Tue 1 May 2018 02:28:
> https://orgmode.org/manual/Emphasis-and-monospace.html#Emphasis-and-monospace
>
> https://orgmode.org/guide/Emphasis-and-monospace.html#Emphasis-and-monospace
>
> The manual and guide is different in code and verbatim text. Which one is
> the right one?
>From the value of variable org-emphasis-alist, I would say that it is
the manual which is correct:
org-emphasis-alist is a variable defined in `org.el'.
Its value is (("*" bold)
("/" italic)
("_" underline)
("=" org-verbatim verbatim)
("~" org-code verbatim)
("+"
(:strike-through t)))
--
EOST (École et Observatoire des Sciences de la Terre)
IPG (Institut de Physique du Globe) | alain.coch...@unistra.fr
5 rue René Descartes [bureau 106] | Phone: +33 (0)3 68 85 50 44
F-67084 Strasbourg Cedex, France| Fax: +33 (0)3 68 85 01 25
