Re: In an export transcoder, when should I use org-element-property to get values vs. the contents parameter
"Rohit Patnaik" writes: > My question is, why does org-md-verbatim use org-element-property to retrieve > the text to be transcoded, when org-md-bold and org-md-italic use the contents > parameter. In other words, couldn't the function be simplified to something > like > this: You can't because the contents of verbatim element is always nil. Verbatim cannot contain other objects inside. All the objects that can contain other objects are listed in org-element-object-containers. > The broader context for my question is that I'm writing my own org exporter, > and > I'd like some more clarity on what the distinction is between getting the > value > of the element with org-element-property and relying on the export framework > to > pass the value to the transcoder via the contents parameter. Any Org element is structured as (type properties contents). However, not all the Org elements have contents (as I mentioned above). Elements without contents generally store their text in one of the PROPERTIES. You may find it useful to examine org-element-interpret-TYPE functions to see how the element text can be recovered from its PROPERTIES and CONTENTS. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [BUG] Markdown export of description list with nested list [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
"Rohit Patnaik" writes: > As I understand it, the bug is in `org-md-item'. It formats the tag portion > of the > description with **%s**, and then simply concatenates the content. This is > fine > when the content is a simple string, but when the content includes line breaks > (i.e. when content is itself a list), it doesn't realize that it needs to > include a line break between the tag and the content. > > ox-html handles this case correctly because ox-html distinguishes between > plain > list types, using for ordered and unordered lists and & for > description lists. > > I think this issue can be fixed by prefixing `contents' with a newline if > `tag' > is present and `contents' itself contains multiple lines. However, this feels > like a hack, and I'd be open to better approaches. > > -- Rohit I think the real issue here is that the particular version of markdown used by org-mode (see http://daringfireball.net/projects/markdown/) does not include support for description lists - it simply isn't part of the supported syntax. I"m not convinced adding support is a good idea as I suspect it will create other complications and only reveal other syntax limitations - it will be like pulling on a thread and could result in just unravelling everything. As it says in the version of markdown syntax used - | For any markup that is not covered by Markdown’s syntax, you simply use | HTML itself. There’s no need to preface it or delimit it to indicate | that you’re switching from Markdown to HTML; you just use the tags.
Re: [BUG] Markdown export of description list with nested list [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
As I understand it, the bug is in `org-md-item'. It formats the tag portion of the description with **%s**, and then simply concatenates the content. This is fine when the content is a simple string, but when the content includes line breaks (i.e. when content is itself a list), it doesn't realize that it needs to include a line break between the tag and the content. ox-html handles this case correctly because ox-html distinguishes between plain list types, using for ordered and unordered lists and & for description lists. I think this issue can be fixed by prefixing `contents' with a newline if `tag' is present and `contents' itself contains multiple lines. However, this feels like a hack, and I'd be open to better approaches. -- Rohit
Re: Babel C-mode corrupts double-quoted strings in output
This fix in ob-C.el passes all unit tests, as well as Martin's example, and some other examples. If someone get a regression, please tell me! In a few days, I will commit. The fix: in ob-C.el line 185, change: (org-babel-read results t) to: results Have fun Le 02/09/2022 à 13:02, tbanelwebmin a écrit : This looks like a bug in ob-C.el Around line 196 we should replace (org-babel-read results t) with results In this way, ob-C.el will look more like ob-shell.el Let me see what are the consequences with such a fix. Thanks Martin for investigating deep in the sources! Regards Le 31/08/2022 à 18:35, Martin Jerabek a écrit : Hi! I recently started to use Org Babel for C++ programs. One of the programs outputs several lines with double-quoted strings, similar to this: #+NAME: doublequotes_cpp #+begin_src cpp :includes :results output verbatim raw std::cout << "\"line 1\"\n"; std::cout << "\"line 2\"\n"; std::cout << "\"line 3\"\n"; #+end_src #+RESULTS: doublequotes_cpp line 1 As you can see, only the first line is copied to the RESULTS block, and it is stripped of the double quotes. I tracked down the problem to org-babel-read (in ob-core.el). org-babel-C-execute (in ob-C.el) calls this function with the output of the C++ program. The problem is the following line: ((eq (string-to-char cell) ?\") (read cell)) i.e. if the output of the program starts with a double quote, it is passed to read which reads only the first string and also removes the double quotes, resulting in the observed output. The original version of this piece of code was added with the following commit: commit 60a8ba556d682849eafb0f84e689967cd2965549 Author: Eric Schulte Date: Wed Mar 2 07:55:39 2011 -0700 ob: read string variable values wrapped in double quotes, removing the quotes * lisp/ob.el (org-babel-read): Read string variable values wrapped in double quotes, removing the quotes. AFAICT this modification was done in response to the email thread "[Orgmode] org-babel-read should have option NOT to interpret as elisp" started on 2011-02-27, more specifically the email on "Wed, 02 Mar 2011 07:56:45 -0700" from Eric Schulte. This was obviously done for parsing variables in the header line, not for the program output, but the Babel C mode uses org-babel-read also for the output. I assumed that ":results output verbatim raw" would prevent any postprocessing of the output but this is not the case for C mode. I am not sure how to fix this without breaking backward compatibility. I assume it should be fixed directly in org-babel-C-execute, not in a central function like org-babel-read to minimize the impact. Surprisingly (for me) the equivalent shell script works as expected: #+NAME: doublequotes #+begin_src shell :results output verbatim raw echo '"line 1"' echo '"line 2"' echo '"line 3"' #+end_src #+RESULTS: doublequotes "line 1" "line 2" "line 3" because org-babel-execute:shell does not process the output with org-babel-read. I do not know if languages other than the C family (C, C++, D) are affected. At the very least, the documentation of org-babel-read should be expanded to document the fact that if the CELL parameter starts with a double quote, it is processed by the read function. Best regards Martin Jerabek
[BUG] Markdown export of description list with nested list [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. The following example is not exported correctly to markdown. - description item 1 :: + list 1 + list 2 - description item 2 :: + list 3 + list 4 The example consists of a description list, where each item is described by a list. There is no text following ::. Calling org-md-export-as-markdown gives me - **description item 1:** - list 1 - list 2 - **description item 2:** - list 3 - list 4 when instead should give - **description item 1:** - list 1 - list 2 - **description item 2:** - list 3 - list 4 The example is exported to html correctly. Emacs : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2022-04-09 Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)
In an export transcoder, when should I use org-element-property to get values vs. the contents parameter
I'm looking at function that handles transcoding inline code and verbatim text in ox-md: (defun org-md-verbatim (verbatim _contents _info) "Transcode VERBATIM object into Markdown format. CONTENTS is nil. INFO is a plist used as a communication channel." (let ((value (org-element-property :value verbatim))) (format (cond ((not (string-match "`" value)) "`%s`") ((or (string-prefix-p "`" value) (string-suffix-p "`" value)) "`` %s ``") (t "``%s``")) value))) My question is, why does org-md-verbatim use org-element-property to retrieve the text to be transcoded, when org-md-bold and org-md-italic use the contents parameter. In other words, couldn't the function be simplified to something like this: (defun org-md-verbatim (_verbatim contents _info) "Transcode VERBATIM object into Markdown format. CONTENTS is nil. INFO is a plist used as a communication channel." (format (cond ((not (string-match "`" contents)) "`%s`") ((or (string-prefix-p "`" contents) (string-suffix-p "`" contents)) "`` %s ``") (t "``%s``")) contents)) The broader context for my question is that I'm writing my own org exporter, and I'd like some more clarity on what the distinction is between getting the value of the element with org-element-property and relying on the export framework to pass the value to the transcoder via the contents parameter. Thanks, Rohit
Re: [PATCH] org.el: Fix percent substitutions in `org-open-file'
On 02/09/2022 19:08, Ihor Radchenko wrote: Max Nikulin writes: Subject: [PATCH] org.el: Fix percent substitutions in `org-open-file' +(defun org--open-file-format-command +(mailcap-command file link match-data) + "Format MAILCAP-COMMAND to launch viewer for FILE. + ... +For example, to specify particular location withing a PDF file, +`org-file-apps' list may have the following entries (order is important): + +;; Page and search string, +;; e.g. . +(\".pdf::([0-9]+)::(.+)\\='\" +. \"okular --page %1 --find %2 %s\") +;; Internal anchor and search string, +;; e.g. . In the meanwhile I have realized that it should be To allow just search as +(\".pdf::(.+)::(.+)\\='\" +. \"okular --find %2 file://%s#%1\") +;; Page number, e.g. . +(\".pdf::([0-9]+)\\='\" . \"okular --page %1 %s\") +;; Internal reference, e.g. . And As a side effect it should dramatically reduce number of backslashes since hash symbol becomes a part of %1 substitution. +(\".pdf::(.+)\\='\" . \"okular file://%s#%1\") +;; No location within the file, optionally followed by \"::\", +;; e.g. . +(\".pdf(?:::)?\\='\" . \"okular %s\") This is a nice set of examples, but it probably does not belong to this docstring. I'd rather see this in `org-file-apps' docstring or even in the manual. I thought on this and I do not think it should be added to the manual. Instead a set of hooks should be defined for popular PDF viewers: evince, zathura, xpdf, firefox, chromium & Co, etc. Such hook injects a number of supported `org-file-apps' records and users may add suitable hook to e.g. (with-eval-after-load 'org (push ...)). It may be implemented as a dedicated package org-pdf-viewers.el. The only problems is that adding entries programmatically breaks easy customization interface for `org-file-apps'. Currently there is the same issue with `org-link-parameters' that is a defcustom variables with entries added by various org extensions. I added the example with hope to better explain the purpose of this function.
Re: Support for tagging (special) blocks
Ihor Radchenko writes: > Sébastien Miquel writes: > >> Ihor Radchenko writes: >> > They do not. Tags are only considered inside headlines. Trying to allow >> > tags outside headlines will require major changes across the whole Org >> > codebase and will still make things incompatible with third party >> > packages, like org-ql. Not to mention the whole new concept for block >> > syntax. >> >> Tags on block do not need to have the same support as headlines tags. >> I'm not suggesting they should interact with the agenda or whatnot. >> Support could be behind a user option, and consist only of say easy >> tag edition, and `#+exclude_tags:` support. With that scope, the >> implementation should be fairly simple. As for third party packages, >> it is up to them whether to extend their features to tagged blocks ; >> in some case it might not make sense. > > We already have ":exports none" header argument. For src block yes, but not for special blocks. To explain where I'm coming from : I write mathematical content categorized using special blocks, such as theorems, exercices, proofs, personnal notes, etc. Then from a single org file, I export several pdf files, filtering the content according to the types and tags of special blocks : for example, to exclude some proofs, or exercices that are too hard. > >> > If one wants to add "tags" or other keywords associated with blocks or >> > other Org elements, the right tool to use is affiliated keywords. But >> > note that Org search infrastructure is tailored towards searching >> > headlines. >> >> Two inconvenients with using affiliated keywords. >>1. There would be no uniform treatment with headline tags. In my use, >> I have the same tags on headline and blocks, and I filter the >> export according to them with #+exclude_tags. > > Affiliated keywords are indeed not uniform with headlines. But they are > uniform with everything else. Paragraphs can have affiliated keywords. > Or other blocks. Or lists. Or tables... That's indeed a good point. In fact, I had been wondering recently how I could tag a single list item, but I guess affiliated keywords still can't do that. > >>2. They waste too much space. Say I have some 20 short exercices >> (represented by special blocks). Since I dot not display the >> #+end_ line, each of them takes 2 or 3 lines in my screen. If I >> want to tag those using affiliated keywords that makes for a 50% >> or 33% size increase, with very poor readability. > >> On a slightly related note, I find it quite unfortunate that one >> presently cannot make use of the #+begin_ line of special blocks to >> set some kind of optional title instead of using #+name or >> #+attr_latex. That's a lot of wasted real estate. > > Yes, but we do not want to overcomplicate Org syntax. Affiliated > keywords are universal across multiple element types. Adding a > specialized syntax for src blocks will make things complex technically > and create duplicate code. > > We can alter the fontification to compact the screen space though. Will > it suffice? > I don't see any possible compactification that doesn't hinder readability. From my perspective, it is important that the type of the special block, its title, and its tags are readable. One thing that org can do in that regard is hide the #+end_ line. For special blocks, a requirement is that the org-block face should apply to them too, to see where the block ends. -- Sébastien Miquel
Re: org-time-stamp-custom-formats with out the name of the day of the week
Uwe Brauer writes: > I see, the question simply is this: > > How can I achieve that org-time-stamp inserts the date *without* the day > name?! This cannot currently be customized. However, you can change org-time-stamp-formats constant. Removing the %a should be safe. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: org-time-stamp-custom-formats with out the name of the day of the week
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>>> Timestamp format is hard-coded in Org syntax. See
>>> https://orgmode.org/worg/dev/org-syntax.html#Timestamps
>>
>> I see, but I just learned that also
>>
>> <2022-09-01>
>>
>> Is interpreted as a timestamp not only
>>
>> <2022-09-01 Thu>
> Yes. Day name is optional.
>> However although I have set
>>
>> (setq org-time-stamp-custom-formats '(" %d.%m.%Y " . " %d.%m.%Y")
>>
>> The day of the week gets always inserted.
>>
>> That is a bit inconsistent I would say.
> I am not sure what you are referring to.
> org-time-stamp-custom-formats is not changing the actual text. Just the
> way timestamps are displayed when org-display-custom-times is non-nil.
I see, the question simply is this:
How can I achieve that org-time-stamp inserts the date *without* the day
name?!
--
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
smime.p7s
Description: S/MIME cryptographic signature
Re: Support for tagging (special) blocks
Sébastien Miquel writes: > Ihor Radchenko writes: > > They do not. Tags are only considered inside headlines. Trying to allow > > tags outside headlines will require major changes across the whole Org > > codebase and will still make things incompatible with third party > > packages, like org-ql. Not to mention the whole new concept for block > > syntax. > > Tags on block do not need to have the same support as headlines tags. > I'm not suggesting they should interact with the agenda or whatnot. > Support could be behind a user option, and consist only of say easy > tag edition, and `#+exclude_tags:` support. With that scope, the > implementation should be fairly simple. As for third party packages, > it is up to them whether to extend their features to tagged blocks ; > in some case it might not make sense. We already have ":exports none" header argument. > > If one wants to add "tags" or other keywords associated with blocks or > > other Org elements, the right tool to use is affiliated keywords. But > > note that Org search infrastructure is tailored towards searching > > headlines. > > Two inconvenients with using affiliated keywords. > 1. There would be no uniform treatment with headline tags. In my use, > I have the same tags on headline and blocks, and I filter the > export according to them with #+exclude_tags. Affiliated keywords are indeed not uniform with headlines. But they are uniform with everything else. Paragraphs can have affiliated keywords. Or other blocks. Or lists. Or tables... > 2. They waste too much space. Say I have some 20 short exercices > (represented by special blocks). Since I dot not display the > #+end_ line, each of them takes 2 or 3 lines in my screen. If I > want to tag those using affiliated keywords that makes for a 50% > or 33% size increase, with very poor readability. > On a slightly related note, I find it quite unfortunate that one > presently cannot make use of the #+begin_ line of special blocks to > set some kind of optional title instead of using #+name or > #+attr_latex. That's a lot of wasted real estate. Yes, but we do not want to overcomplicate Org syntax. Affiliated keywords are universal across multiple element types. Adding a specialized syntax for src blocks will make things complex technically and create duplicate code. We can alter the fontification to compact the screen space though. Will it suffice? -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: org-time-stamp-custom-formats with out the name of the day of the week
Uwe Brauer writes:
>> Timestamp format is hard-coded in Org syntax. See
>> https://orgmode.org/worg/dev/org-syntax.html#Timestamps
>
> I see, but I just learned that also
>
> <2022-09-01>
>
> Is interpreted as a timestamp not only
>
> <2022-09-01 Thu>
Yes. Day name is optional.
> However although I have set
>
> (setq org-time-stamp-custom-formats '(" %d.%m.%Y " . " %d.%m.%Y")
>
> The day of the week gets always inserted.
>
> That is a bit inconsistent I would say.
I am not sure what you are referring to.
org-time-stamp-custom-formats is not changing the actual text. Just the
way timestamps are displayed when org-display-custom-times is non-nil.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
Re: Manual Ordering and Dynamic Priority
Eduardo Suarez writes: > I have lots of tasks (todos) and I would like to create a long backlog based > on > my perceived priority. > > I was thinking to deal with them in the following way: > > - divide them in groups (categories or similar), > - manually sort priority for every group, > - mergesort groups, that is, start merging groups in pairs, and manually sort > for every step the union group until I have a large sorted backlog. > > For this to be practical, I would need an easy way to sort manually a group of > tasks and get them assigned automatically a priority (or any other hack) so > that priority ordering matches manual ordering. > > Any idea about how to get this done? It sounds like you just want to have a list of active projects and select one top-priority task at a time from each project. The projects can be simply a headline with all the tasks listed as children. I do not recommend assigning priority as a number. From my experience, it is much easier to order the tasks manually inside a project. You will need to re-order things as the project progresses anyway. Fiddling with numbers will quickly become unmanageable. I also do not recommend listing _all_ the tasks. It is much more productive (again, from experience) to list the one top-priority task for each project and nothing more until you finish the current task batch. In GTD, this is usually done by assigning NEXT todo keyword to the top-priority task, while all others are assigned as TODO. You may also leverage org-edna package to flip TODO->NEXT once you complete the current NEXT task. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Have all the tags of a heading, with a tag hierarchy
Ok thanks a lot for your answers, I made the function, if ever it can interest someone one day (defun org-get-tags-with-hierarchy-at-point() "Return the list of tag WITH the sub-tags if they exist at point" (interactive) (let ((tags-heading (org-get-tags)) (tags-result '())) (dolist (tag tags-heading) (dolist (tag-to-add (org-tags-expand tag t)) (push tag-to-add tags-result) ) ) (delete-dups tags-result) ) ) Do not hesitate to change the "tags-heading" variable to select a different heading Thanks again for your answers ! Le jeu. 1 sept. 2022 à 09:03, Ihor Radchenko a écrit : > Cletip Cletip writes: > > > Just one last clarification to be sure: there is no native function in > > org-mode to have the list of tags with a hierarchy? I have to write my > > function with the two functions > > org-get-tags and org-tags-expand > > to get the result I want : a list of tags that takes into account the > > hierarchy defined by the "org-tag-alist" variable > > AFAIK, we have no such function. > > -- > Ihor Radchenko, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > Support Org development at https://liberapay.com/org-mode, > or support my work at https://liberapay.com/yantar92 >
Re: Improve the docstring for 'org-html-mathjax-options'
Rudolf Adamkovič writes: > Subject: [PATCH 1/2] Fix incorrectly documented auto-numbering of MathJax > equations > Subject: [PATCH 2/2] Fix under-documented MathJax indentation option Thanks! Applied onto main via 710b6ca70 and 74d1a8c75. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=74d1a8c75814519f23fde077d91067b1be61d5eb https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=710b6ca70e1e6d1f9ddc285315543cc361d888d1 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Syntax of footnote-definition: can we allow double empty lines inside? (was: Suspected bug: example block in a footnote doesn't fold if starts with 2 blank lines)
alain.coch...@unistra.fr writes:
> Ihor Radchenko writes on Wed 31 Aug 2022 09:57:
>
> > This is not a bug. Just unintuitive syntax:
> > [...]
> > The important part is: It ends at the next footnote definition,
> > headline, or after two consecutive empty lines.
> >
> > So, your example is
> >
> > foo[fn:1]
> >
> > [fn:1] bar
> > #+begin_example ;; <- this is not considered an example block because no
> > major org elements can be inside a footnote definition.
> >
> >
> >
> > x
> > #+end_example
> >
>
> Thanks a lot for answering.
>
> Is there an official definition for "major org element" ? (I could not
> find anything relevant in the manual.)
Sorry, I actually confused things in attempt to make things more clear.
The official Org syntax defines 2 types of syntax structures:
elements and objects. Elements can be: (1) headings, (2) sections, (3)
greater elements, (4) lesser elements.
Each Org document is a sequence of elements with no gaps in-between.
Objects (e.g. markup) may be separated by plain text and must always be
inside an existing element.
Headings, sections, and greater elements can contain other elements
inside, while lesser elements cannot.
By "major element" I was actually referring to lesser element
(non-object). Not only I was wrong (footnote-definition is a greater
element), but also used a confusing terminology.
You can refer to https://orgmode.org/worg/dev/org-syntax.html for more
detailed info.
> I guess a headline would qualify (and it would not have occurred to me
> to use a headline within a footnote; the manual is clear in that
> respect anyway).
>
> But then a list item would probably qualify as well? But, as far as I
> can see, lists and footnotes work perfectly well together... (because
> 2 consecutive empty lines also mark the end of a list item?)
>
> Furthermore, as long as there is not more than one empty line in a
> row, blocks also appear to me to work just fine within footnotes,
> including upon latex export, and I use things like the following all
> the time:
>
>#+LATEX_HEADER: \usepackage{fancyvrb}
>#+LATEX_HEADER: \VerbatimFootnotes
>foot[fn:1]
>
>[fn:1] note
>#+begin_src fortran
>print*,"foo"
>#+end_src
>
> I simply never had to use 2 consecutive empty lines in blocks up to
> now...
>
> So I guess I'll turn my "suspected bug" into a feature request: that
> #+BEGIN ... #+END blocks behave the same way whether they are within a
> footnote or not.
You are right, there is currently no way to have double blank lines
_inside_ footnote definition. This is because Org syntax prohibits
elements inside a greater element to influence the parent boundaries.
Once Org parser encounters ^[fn:...] right after previously parsed
element, it immediately looks forward for (1) next footnote definition
^[fn:...]; (2) headline ^\*+ ; (3) double blank lines; and sets the
footnote definition boundaries accordingly. Unconditionally. No
backtracking is allowed for the performance reasons.
The consequence is inability to have source blocks containing double
blank lines inside a footnote definition.
This is not an easy problem because we need to ensure backwards
compatibility and avoid doing major changes to Org syntax. The best I
can think of is allowing to escape blank lines like #+ and * lines
inside the code blocks with ",". See 12.6 Literal Examples section of
the manual, for example:
#+BEGIN_EXAMPLE
,* I am no real headline
#+END_EXAMPLE
We may add the same for double blank lines
#+BEGIN_EXAMPLE
,* I am no real headline
,
#+END_EXAMPLE
The downside is overly verbose ordinary code blocks. Double blank lines
may not be uncommon in the wild; sprinkling commas around many source
blocks will be ugly.
Alternative ideas are welcome.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
Re: [PATCH] org.el: Fix percent substitutions in `org-open-file'
Max Nikulin writes: > It's pity that this issue has not fix yet. I have tried to implement > another helper function. It is hardly usable outside of `org-open-file' > (perhaps it is still suitable to make mailcap commands), but separate > function makes the code testable. I hope, the attached patch fixes the > problems with multiple regexp groups and with percent characters in > replacement string. Notice that "\%", not "%%" is used to escape percent > in mailcap, anyway neither variant was supported before. > From 2f2850dcdc0cba8cfc6c0e21fc893c4e664d575c Mon Sep 17 00:00:00 2001 > From: Max Nikulin > Date: Sat, 27 Aug 2022 23:51:24 +0700 > Subject: [PATCH] org.el: Fix percent substitutions in `org-open-file' Thanks! LGTM, except one comment. > +(defun org--open-file-format-command > +(mailcap-command file link match-data) > + "Format MAILCAP-COMMAND to launch viewer for FILE. > + > ... > +For example, to specify particular location withing a PDF file, > +`org-file-apps' list may have the following entries (order is important): > + > +;; Page and search string, > +;; e.g. redirections>. > +(\".pdf::([0-9]+)::(.+)\\='\" > +. \"okular --page %1 --find %2 %s\") > +;; Internal anchor and search string, > +;; e.g. a file>. > +(\".pdf::(.+)::(.+)\\='\" > +. \"okular --find %2 file://%s#%1\") > +;; Page number, e.g. . > +(\".pdf::([0-9]+)\\='\" . \"okular --page %1 %s\") > +;; Internal reference, e.g. > . > +(\".pdf::(.+)\\='\" . \"okular file://%s#%1\") > +;; No location within the file, optionally followed by \"::\", > +;; e.g. . > +(\".pdf(?:::)?\\='\" . \"okular %s\") This is a nice set of examples, but it probably does not belong to this docstring. I'd rather see this in `org-file-apps' docstring or even in the manual. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Babel C-mode corrupts double-quoted strings in output
This looks like a bug in ob-C.el Around line 196 we should replace (org-babel-read results t) with results In this way, ob-C.el will look more like ob-shell.el Let me see what are the consequences with such a fix. Thanks Martin for investigating deep in the sources! Regards Le 31/08/2022 à 18:35, Martin Jerabek a écrit : Hi! I recently started to use Org Babel for C++ programs. One of the programs outputs several lines with double-quoted strings, similar to this: #+NAME: doublequotes_cpp #+begin_src cpp :includes :results output verbatim raw std::cout << "\"line 1\"\n"; std::cout << "\"line 2\"\n"; std::cout << "\"line 3\"\n"; #+end_src #+RESULTS: doublequotes_cpp line 1 As you can see, only the first line is copied to the RESULTS block, and it is stripped of the double quotes. I tracked down the problem to org-babel-read (in ob-core.el). org-babel-C-execute (in ob-C.el) calls this function with the output of the C++ program. The problem is the following line: ((eq (string-to-char cell) ?\") (read cell)) i.e. if the output of the program starts with a double quote, it is passed to read which reads only the first string and also removes the double quotes, resulting in the observed output. The original version of this piece of code was added with the following commit: commit 60a8ba556d682849eafb0f84e689967cd2965549 Author: Eric Schulte Date: Wed Mar 2 07:55:39 2011 -0700 ob: read string variable values wrapped in double quotes, removing the quotes * lisp/ob.el (org-babel-read): Read string variable values wrapped in double quotes, removing the quotes. AFAICT this modification was done in response to the email thread "[Orgmode] org-babel-read should have option NOT to interpret as elisp" started on 2011-02-27, more specifically the email on "Wed, 02 Mar 2011 07:56:45 -0700" from Eric Schulte. This was obviously done for parsing variables in the header line, not for the program output, but the Babel C mode uses org-babel-read also for the output. I assumed that ":results output verbatim raw" would prevent any postprocessing of the output but this is not the case for C mode. I am not sure how to fix this without breaking backward compatibility. I assume it should be fixed directly in org-babel-C-execute, not in a central function like org-babel-read to minimize the impact. Surprisingly (for me) the equivalent shell script works as expected: #+NAME: doublequotes #+begin_src shell :results output verbatim raw echo '"line 1"' echo '"line 2"' echo '"line 3"' #+end_src #+RESULTS: doublequotes "line 1" "line 2" "line 3" because org-babel-execute:shell does not process the output with org-babel-read. I do not know if languages other than the C family (C, C++, D) are affected. At the very least, the documentation of org-babel-read should be expanded to document the fact that if the CELL parameter starts with a double quote, it is processed by the read function. Best regards Martin Jerabek
