Re: Why is Babel-C trimming its output?
Hi Michael and Ian, I removed the call to `org-trim' which I believe was here for mere cosmetic purpose. Thanks for reporting this, -- Bastien
Re: Why is Babel-C trimming its output?
That's up to the maintainers. If you just want to fix it on your end you could advise/replace `org-babel-C-execute` but unfortunately there's a lot there. On Fri, Jul 17, 2020, 1:31 PM Michaël Cadilhac wrote: > Thanks for the investigation Ian. So, since the tests run just fine > without it, and it offers an inconsistent and at times detrimental > feature, can we consider removing it, and/or adding some options for > that? > > I'd be fine having to flag my src-block with a ":verbatim t" option to > make sure that the output is not mangled. > > Thoughts? > > On Fri, Jul 17, 2020 at 7:30 AM ian martins wrote: > > > > Fortunately the author wrote tests, so we can tie the behavior of the > code to use cases. Unfortunately all the tests pass with the call to > org-trim removed. Also the call is there from the first commit of the file > in git, so there's no commit message to explain. > > > > My guess is that it was added to clean up cases that resulted in extra > trailing whitespace, but I dunno. > > > > > > On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac > wrote: > >> > >> Hello, > >> > >> Quick question here: in ob-C.el, before returning the output of a C > >> file, there's this line: > >> > >> (setq results (org-trim (org-remove-indentation results))) > >> > >> That seems quite arbitrary; is it on purpose? I have a C file that > >> outputs some sort of list of formatted numbers, e.g.: > >> > >> 0 -17.8 > >> 404.4 > >> 80 26.7 > >> 120 48.9 > >> > >> and only the first line gets trimmed, leading to a faulty output. > >> > >> This does not seem to be a universal thing in Babel; for instance: > >> > >> #+begin_src emacs-lisp :exports both :results value raw > >> " 0\n 1\n2\n" > >> #+end_src > >> > >> …results in: > >> > >> #+RESULTS: > >> 0 > >> 1 > >> 2 > >> > >> But the same thing in C: > >> > >> #+begin_src C :exports both :results output raw > >> printf (" 0\n 1\n2\n"); > >> #+end_src > >> > >> …results in: > >> #+RESULTS: > >> 0 > >> 1 > >> 2 > >> > >> Cheers, > >> M. > >> >
Re: Why is Babel-C trimming its output?
Thanks for the investigation Ian. So, since the tests run just fine without it, and it offers an inconsistent and at times detrimental feature, can we consider removing it, and/or adding some options for that? I'd be fine having to flag my src-block with a ":verbatim t" option to make sure that the output is not mangled. Thoughts? On Fri, Jul 17, 2020 at 7:30 AM ian martins wrote: > > Fortunately the author wrote tests, so we can tie the behavior of the code to > use cases. Unfortunately all the tests pass with the call to org-trim > removed. Also the call is there from the first commit of the file in git, so > there's no commit message to explain. > > My guess is that it was added to clean up cases that resulted in extra > trailing whitespace, but I dunno. > > > On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac > wrote: >> >> Hello, >> >> Quick question here: in ob-C.el, before returning the output of a C >> file, there's this line: >> >> (setq results (org-trim (org-remove-indentation results))) >> >> That seems quite arbitrary; is it on purpose? I have a C file that >> outputs some sort of list of formatted numbers, e.g.: >> >> 0 -17.8 >> 404.4 >> 80 26.7 >> 120 48.9 >> >> and only the first line gets trimmed, leading to a faulty output. >> >> This does not seem to be a universal thing in Babel; for instance: >> >> #+begin_src emacs-lisp :exports both :results value raw >> " 0\n 1\n2\n" >> #+end_src >> >> …results in: >> >> #+RESULTS: >> 0 >> 1 >> 2 >> >> But the same thing in C: >> >> #+begin_src C :exports both :results output raw >> printf (" 0\n 1\n2\n"); >> #+end_src >> >> …results in: >> #+RESULTS: >> 0 >> 1 >> 2 >> >> Cheers, >> M. >>
Re: Why is Babel-C trimming its output?
Fortunately the author wrote tests, so we can tie the behavior of the code to use cases. Unfortunately all the tests pass with the call to org-trim removed. Also the call is there from the first commit of the file in git, so there's no commit message to explain. My guess is that it was added to clean up cases that resulted in extra trailing whitespace, but I dunno. On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac wrote: > Hello, > > Quick question here: in ob-C.el, before returning the output of a C > file, there's this line: > > (setq results (org-trim (org-remove-indentation results))) > > That seems quite arbitrary; is it on purpose? I have a C file that > outputs some sort of list of formatted numbers, e.g.: > > 0 -17.8 > 404.4 > 80 26.7 > 120 48.9 > > and only the first line gets trimmed, leading to a faulty output. > > This does not seem to be a universal thing in Babel; for instance: > > #+begin_src emacs-lisp :exports both :results value raw > " 0\n 1\n2\n" > #+end_src > > …results in: > > #+RESULTS: > 0 > 1 > 2 > > But the same thing in C: > > #+begin_src C :exports both :results output raw > printf (" 0\n 1\n2\n"); > #+end_src > > …results in: > #+RESULTS: > 0 > 1 > 2 > > Cheers, > M. > >
Why is Babel-C trimming its output?
Hello, Quick question here: in ob-C.el, before returning the output of a C file, there's this line: (setq results (org-trim (org-remove-indentation results))) That seems quite arbitrary; is it on purpose? I have a C file that outputs some sort of list of formatted numbers, e.g.: 0 -17.8 404.4 80 26.7 120 48.9 and only the first line gets trimmed, leading to a faulty output. This does not seem to be a universal thing in Babel; for instance: #+begin_src emacs-lisp :exports both :results value raw " 0\n 1\n2\n" #+end_src …results in: #+RESULTS: 0 1 2 But the same thing in C: #+begin_src C :exports both :results output raw printf (" 0\n 1\n2\n"); #+end_src …results in: #+RESULTS: 0 1 2 Cheers, M.