The console interface of RKWard is starting to get incompatible with much of the sugar coming from tidyverse packages, especially when it comes to features provided by the 'cli' package. This package is, among other things, responsible for output colouration (in error messages, printing tibbles, etc.) and since very recently, for printing progress bars in e.g. purrr package. Although those features work in R itself and even modified interfaces such a radian, they do not work in RKWard (colours are overridden and, most problematically, purrr's progress bar are not shown at all). This is the crux of the bug here. I know this is not a very easy request, but would there be a way to make RKWard R console closer to pure R console (or to radian, for that matter?), in order to avoid such incompatibilities? (My dream would be to be able to use directly radian as RKWard's console, as it offers very nice features missing from RKWard's R console such history browsing because on completion, multiline input, access to bash terminal and so on, but I know this is not a mere matter of plugin a program into the window of another...)
Git commit f84482ceee07e0af0a1ebb7e04ddd42bd07b993b by Thomas Friedrichsmeier. Committed on 25/12/2022 at 10:31. Pushed by tfry into branch 'master'. Fix handling of carriage returns in R Console window M +2 -1 ChangeLog M +30 -16 rkward/rkconsole.cpp M +2 -0 rkward/rkconsole.h https://invent.kde.org/education/rkward/commit/f84482ceee07e0af0a1ebb7e04ddd42bd07b993b
I can confirm that the progress bar of CLI is shown with this patch, thank you for this. However for your information, when a multiline command is pasted from a script file, the progress bar is displayed by erasing a line of the pasted command. For example: map(1:100, ~ Sys.sleep(0.1), .progress = TRUE) Results in: ****** /progress bar here/ ~ Sys.sleep(0.1), .progress = TRUE)
Git commit aef76e215c70e6e8998952345c3d3bd35f7eda47 by Thomas Friedrichsmeier. Committed on 27/12/2022 at 09:41. Pushed by tfry into branch 'master'. Fix output position in case of pasted multi-line commands. M +1 -0 rkward/rkconsole.cpp https://invent.kde.org/education/rkward/commit/aef76e215c70e6e8998952345c3d3bd35f7eda47
I can confirm this fixes the progress bar issue completely. Shall I consider the part about printing the colours of the output from 'cli' package in RKWard's R console as "won't fix" then? Happy to help in any way I can.
> Shall I consider the part about printing the colours of the output from 'cli' package in RKWard's R console as "won't fix" then? I'm not sure about that, yet. It's definitely lower priority, however, and also more difficult. If you would like to get your hands dirty, RKConsole::newOutput() is the key function to look at (https://invent.kde.org/education/rkward/-/blob/master/rkward/rkconsole.cpp#L555). The console window is based on KTextEditor, and highlighting could be amended using https://api.kde.org/frameworks/ktexteditor/html/classKTextEditor_1_1MovingRange.html (setAttribute).
I am currently toying quite a lot with the syntax highlighting of "R interactive session" (I've sent a PR on invent to fix highlighting of the native pipe by the way), and I've managed to replicate most of the colours of 'cli' package to easily distinguish between errors and warnings and whatnot. I'm actually getting a bit carried away and starting to include highlighting for vector/matrix-indices (it's rather dampening in this case), floats, NA and boolean... I find it quite handy to have, as it helps making sense of a data.frame more easily, but it's not really the matter of this bug report. So I need to ask: would you be open to a PR for syntax highlighting containing all these goodies, or should I rather extract only the parts about cli-colouring at the time of submit? I'll try to use my modifications for something like a month to make sure I get most of the corner cases (at least based on my habits) before submitting anything.
I was skeptical that this could be done based on syntax highlighting definitions, but if so, I'll be quite excited to see your work (and don't wait to long before submitting. You can always mark a merge request as "draft", as long as you are not quite confident). I'm also quite open to having additional highlighting features. But in fact, it's always a good idea to keep independent features separate as much as possible (i.e. two or even more separate merge requests would be preferable).
I was skeptical as well, but it turns out that cli-based formatting is sufficiently well formatted so that the colouring can be "retrieved" by detecting some special characters starting the line. When I realised KTextEditor was responsible for the console, I lost hope it could be possible to retrieve the colours passed by 'cli' since KTextEditor would treat it as plain, non-coloured text whatever we do (or so I think anyway). Catching a colour signal before the R console output is sent to KTextEditor is waaaaaay above my skills! ;) I'll do my best to separate my modifications into several relevant PR.