Sorry to confuse the threading, but I wanted to bring this back up given Ihor and Suhail Singh talking about this change in R behaviour.
I agree it seems best to revert to the earlier was of handling data tables in R until, if possible, there is a nice way to clean up all the languages at once. The whole situation may be confusing, since there's a mix of how languages handle them, but it doesn't break anything. It seems like a small thing to break a lot of R code over. I don't know if this bug will matter after that, but I wanted to make sure it got noted just in case. Thanks, Bill -- William Denton https://www.miskatonic.org/ Librarian, artist and licensed private investigator. Toronto, Canada On Friday, November 15th, 2024 at 09:23, William Denton <will...@williamdenton.org> wrote: > On Friday, November 15th, 2024 at 06:59, Rens Oliemans ha...@rensoliemans.nl > wrote: > > > According to git bisect, the first bad commit is: > > [e0924db3c55a44c8aa8d126fbb9b42cfc54f104c] orgtbl-to-generic: Retain > > special rows in code block table output > > > Aha! Thank you. I wasn't looking at tables generally. I see now that ORG-NEWS > has a "~orgtbl-to-generic~ retains special rows when exporting to Org" entry. > It says, "To retain the old behaviour, add ~:with-special-rows nil~ to PARAMS > argument." But: > > #+name: test_table > | Date | Weather | > | <10> | <50> | > > |------------+----------------------| > | 2024-11-01 | Warm | > | 2024-11-02 | Warm | > | 2024-11-03 | Still strangely warm | > > #+begin_src R :var t=test_table :colnames yes :with-special-rows nil > t > #+end_src > > #+RESULTS: > | Date | Weather | > |------------+----------------------| > | <10> | <50> | > > | 2024-11-01 | Warm | > | 2024-11-02 | Warm | > | 2024-11-03 | Still strangely warm | > > If I (setq org-org-with-special-rows nil) then this stops, but shouldn't the > parameter work?
