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 > >> 40 4.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. > >> >