[O] [PATCH] ob-ocaml: Support for pretty-printed outputs
E.g. the following snippet produces multiple lines of output, due to pretty-printing #+BEGIN_SRC ocaml :exports code :eval no-export :results verbatim (* Note, no need to have parentheses around sqrt, as application binds the tightest *) let rec gamma n = if n = 0 then (1.0 +. sqrt 5.0) /. 2.0 else 1.0 /. (gamma (n-1) -. 1.0) let nums = List.map gamma (List.init 5 (fun x -> x)) #+END_SRC #+NAME: gamma-tbl #+RESULTS[1fd6a3e846afdef51350eb6d7ba15c6844ccc14e]: : val gamma : int -> float = : val nums : float list = : [1.6180339887498949; 1.61803398874989468; 1.61803398874989535; :1.61803398874989357; 1.61803398874989823] (In reality this would have 50 or so outputs, point being mathematically it shouldn't change, but due to floating point errors it does.) The regexp has the following problems: - The "." in group 5 (as-was) doesn't match new-lines, so it only matches the first line, e.g. as a list : - [1.6180339887498949, 1.61803398874989468, 1.61803398874989535, - When using "\\(.\\|\n\\)", it includes the starting indentation of the list, which makes org-babel-script-escape choke (called from org-babel-ocaml-read-list, from org-babel-ocaml-parse-output, from org-babel-execute:ocaml, the code being modified. From 281de8e248fdd70ecfc69237df83a155c9491f2e Mon Sep 17 00:00:00 2001 From: Kovacsics Robert Date: Fri, 4 Oct 2019 17:29:00 +0100 Subject: [PATCH] ob-ocaml: Support for pretty-printed outputs E.g. the following snippet produces multiple lines of output, due to pretty-printing #+BEGIN_SRC ocaml :exports code :eval no-export :results verbatim (* Note, no need to have parentheses around sqrt, as application binds the tightest *) let rec gamma n = if n = 0 then (1.0 +. sqrt 5.0) /. 2.0 else 1.0 /. (gamma (n-1) -. 1.0) let nums = List.map gamma (List.init 5 (fun x -> x)) #+END_SRC #+NAME: gamma-tbl #+RESULTS[1fd6a3e846afdef51350eb6d7ba15c6844ccc14e]: : val gamma : int -> float = : val nums : float list = : [1.6180339887498949; 1.61803398874989468; 1.61803398874989535; :1.61803398874989357; 1.61803398874989823] (In reality this would have 50 or so outputs, point being mathematically it shouldn't change, but due to floating point errors it does.) The regexp has the following problems: - The "." in group 5 (as-was) doesn't match new-lines, so it only matches the first line, e.g. as a list : - [1.6180339887498949, 1.61803398874989468, 1.61803398874989535, - When using "\\(.\\|\n\\)", it includes the starting indentation of the list, which makes org-babel-script-escape choke (called from org-babel-ocaml-read-list, from org-babel-ocaml-parse-output, from org-babel-execute:ocaml, the code being modified. --- lisp/ob-ocaml.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el index 0c0ffe442..54bc49a2f 100644 --- a/lisp/ob-ocaml.el +++ b/lisp/ob-ocaml.el @@ -83,11 +83,11 @@ (raw (org-trim clean)) (result-params (cdr (assq :result-params params (string-match - "\\(\\(.*\n\\)*\\)[^:\n]+ : \\([^=\n]+\\) =\\(\n\\| \\)\\(.+\\)$" + "\\(\\(.*\n\\)*\\)[^:\n]+ : \\([^=\n]+\\) =[[:space:]]+\\(\\(.\\|\n\\)+\\)$" raw) (let ((output (match-string 1 raw)) (type (match-string 3 raw)) - (value (match-string 5 raw))) + (value (match-string 4 raw))) (org-babel-reassemble-table (org-babel-result-cond result-params (cond -- 2.19.2
Re: [O] [RFC] Document level property drawer
Adam Porter writes: > Marco Wahl writes: >> You say the visibility is better for the #+-property keywords. I say >> they can occur _anywhere_ in the file and even in some drawers. See >> above "#+CATEGORY: cat-doc-prop-keyword-2". >> >> Further you say >> > - However, it seems to me that the simplest, most natural protocol would > be for later declarations to override earlier ones. >> >> This means that cat-doc-prop-keyword-2 from the example defines the >> CATEGORY property which at least I find not so natural. And I already >> stated what I find natural. > Org may allow #+KEYWORD: lines to appear anywhere in a file, including > in arbitrary drawers, but that's up to the user. If the user chooses to > hide them in drawers, it's his responsibility. > > AFAICT that's not a common or generally recommended thing to do. Most > Org files have such lines at the top of the file, and some under a > heading at the bottom of the file with other settings. Such lines don't > need to be in drawers, and this proposal wouldn't change that. > > So I think it would be confusing if settings in a drawer at the top of > the file were to absolutely override settings outside of drawers (which > would mean that hidden settings could override plainly visible ones). > The most natural protocol would be like written language: later > declarations override earlier ones. Hi Adam, Just I got the idea that for a good part this discussion is about personal preferences. For me for example it's not a big deal if a property is placed within a drawer or not. I don't care much about the "visibility" of a property setting. Of course I respect other views about this. What I really find irritating is that "Org ... allows #+KEYWORD: lines to appear anywhere in a file" (This sentence is from you) with the meaning that the settings apply to the whole file. I think this interpretation of #+KEYWORD: lines is unnecessary and confusing. BTW I find it completely natural that--let's for simplicity assume an Org file without any drawers--#+KEYWORD: settings that appear later in a file replace earlier settings. Best regards, -- Marco
Re: [O] [RFC] Document level property drawer
Adam Porter writes: > Gustav Wikström writes: > >> I'd argue that precedence already works that way. One has to take >> inheritance into account. With inheritance turned on, tell me which >> value for Property1 is used for the nodes in the following example: >> >> #+begin_src org >> ,* Node 1 >> ,* Node 2 >> :PROPERTIES: >> :Property1: Value1 >> :END: >> >> ,#+PROPERTY: Property1 Value2 >> #+end_src >> >> As you'll see line number already isn't the deciding factor. >> >> With two ways to define properties it makes sense to first think of >> which syntax to promote as "more important" and then to think of >> precedence rules for duplicates within each syntax. >> >> Having the same syntax for node level 0 as for regular nodes makes the >> property functionality easy to understand and congruent. Something I >> think is worth promoting by saying that property blocks on file-level >> has precedence over the keyword syntax. > > I think this example illustrates the issue better. This is how Org > currently works: > > #+BEGIN_SRC org > # Category here is "Alpha" > > ,* Node 1 > > # Category here is "Alpha" > > ,* Node 2 > :PROPERTIES: > :CATEGORY: Beta > :END: > > # Category here is "Beta" > > ,#+CATEGORY: Alpha > #+END_SRC > > > IIUC, your proposal would work like this: > > #+BEGIN_SRC org > :PROPERTIES: > :CATEGORY: Gamma > :END: > > # Category here is "Gamma" > > ,* Node 1 > > # Category here is "Gamma" > > ,* Node 2 > :PROPERTIES: > :CATEGORY: Beta > :END: > > # Category here is "Beta" > > ,#+CATEGORY: Alpha > #+END_SRC > > So the #+CATEGORY: line has no effect because of the first-line property > drawer. > > In Org, some keywords are special, like #+CATEGORY. For many years, > such keywords have had file-wide effects regardless of their placement > in the file. IIUC, your proposal would change that, and that would > still be a major, breaking change. IIUC Org files not using a file level property drawer would not be affected from the change at all. With the proposition the user gets a further option to define a file wide property. >> If you think of the document as an outline, something Org mode is all >> about, it makes sense to also think of things before the first >> headline as "node level 0". And with that way of conceptually thinking >> of the document it makes perfect sense to have a property drawer fixed >> at the top - in the same way as it is required for all other node >> levels. > > What you're proposing is actually a fundamental change to the way Org > documents are interpreted. Org documents are not currently an outline, > just a series of elements which may include an outline. Text and > elements before a first heading are not part of a node, they're just > text and elements in the document. > > If Org were a new project, I think your proposal might be very > suitable. But at this point, it would be a significant, breaking > change, even without the org-element parser changes. > > Consider as well that the Org format has recently been seeing wider use, > with more implementations becoming available in several languages and on > several platforms. Fundamental changes like this would affect more than > just the official Org software, and the costs of breaking software in > the wider Org community should be carefully considered. The proposal is an extension leaving all operations and tools intact for Org files not using the file wide property drawer AFAICS. If a tool depends on a file wide property then it needs to be adapted. Possibly this could be called "breaking" but I think this should not hold back the proposal. One could even think about letting fade out the "#+"-file-wide property definition syntax or at least think about a good place within a file or a subtree for those definitions. (There is at least Sebastian Miele who wants to keep that syntax as he stated in another thread AFAIR.) Personally I think it's a good idea to work for an Org mode where an Org file behaves very much like an Org subtree. Ciao, -- Marco
Re: [O] [ANN] org-sidebar-tree: Sidebar tree-view buffer for outline navigation
Thanks for the clarifications and updates. I'll play some more and will get back to you. -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
