Summary: | Make R console compatible with 'cli' R package | ||
---|---|---|---|
Product: | [Applications] rkward | Reporter: | flyos |
Component: | general | Assignee: | RKWard Team <rkward-devel> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | thomas.friedrichsmeier |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
flyos
2022-12-22 16:23:47 UTC
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. |