Duncan Murdoch
2022-May-15 17:24 UTC
[Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher
On 15/05/2022 1:09 p.m., Paulo Barata wrote:> > Following Mr. Murdoch's suggestion, I installed R Studio (2022.02.2 > build 485) on my Windows 10 Professional. > > When opening R Studio, it showed R 4.2.0 patched, the most recent > version of R I had installed here. As it happens with the standalone R > 4.2.0, Dasher did not work with R Studio with that version of R -- > please see below what happened.That's too bad. Still, there are other front ends: - Running Rterm in a command window. - R in Visual Studio Code - ESS in Emacs - Others whose names I don't remember; not sure how active any of them are these days. And finally, if you are really desperate, I believe dasher runs on other platforms besides Windows, i.e. Linux and MacOS. Duncan Murdoch> > I unistalled R 4.2.0 patched and also R 4.2.0, so then my latest version > of R was R 4.1.3 patched. This was now the version of R that R Studio > used. Dasher also did not work in R Studio with R 4.1.3 patched -- > please see below what happened. Please note that the standalone R 4.1.3 > patched does work perfectly well with Dasher. > > What happens in R Studio with both R 4.2.0 patched and R 4.1.3 patched: > when I open R studio and start writing with Dasher, the first character > that I write is now the character that always appears on the R Studio > console, no matter what other characters I am commanding with Dasher. > For R Studio, strangely, Dasher seems to be stuck in the first character. > > For example, if I wish to write a plot command in R Studio, the first > Dasher "p" is accepted by R Studio, but the next "lot" appears on the R > Studio console as "ppp". This is is contrast with what happens with > Dasher on R 4.2.0, where, except for the "Enter" character, no other > character is accepted by R 4.2.0, the R 4.2.0 screen just does not > respond to Dasher. > > Both in R 4.2.0 and in R Studio, the "Enter" character of Dasher work > well, it makes the R prompt to jump to the next line. > > So, Dasher does not work with R Studio either, but in a different way > than it happens with R 4.2.0. > > Regards, > > Paulo Barata > > ---------------------------------------------------------- > Paulo Barata > Rua Almirante Alexandrino 1808 apt. 102 > Santa Teresa > 20241-263 Rio de Janeiro - RJ > > Paulo Barata > Sub-S?ndico - Condom?nio do Edif?cio Dois Irm?os > Rua Almirante Alexandrino 1808 - Santa Teresa > > E-mail: pb at infolink.com.br > ---------------------------------------------------------- > > On 15/05/2022 13:27, Duncan Murdoch wrote: >> On 15/05/2022 10:58 a.m., Ivan Krylov wrote: >>> On Sun, 15 May 2022 11:10:49 -0300 >>> Paulo Barata <pb at infolink.com.br> wrote: >>> >>>> I noticed today that R 4.2.0 responds to the "Enter" character of >>>> Dasher version 5.0.0 beta in "Direct Entry" mode. An "Enter" in >>>> Dasher causes the R prompt to jump to the next line, as an "Enter" >>>> should do. >>>> >>>> No other characters (letters, digits, special characters like + = & ~ >>>> | # $) are accepted by R 4.2.0 through Dasher. >>> >>> This seems to be very similar to the problem discussed here: >>> https://stat.ethz.ch/pipermail/r-devel/2022-May/081683.html >>> >>> For the record, here's the part of Dasher responsible for "Direct >>> Entry" on Windows: >>> https://github.com/dasher-project/dasher/blob/0ec7d646dbaadf06b8eebfc11b784738a20e75af/Src/Win32/Widgets/Edit.cpp#L302 >>> >>> >>> MSDN says: >>> >>>>> If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or >>>>> WM_KEYUP message to the foreground thread's message queue with >>>>> wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains >>>>> this message, passing the message to TranslateMessage posts a >>>>> WM_CHAR message with the Unicode character originally specified by >>>>> wScan. >>> >>> <https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput> >>> >> >> As far as I can see, Graphapp never looks for VK_PACKET. >> >>> >>> Previously, Tomas Kalibera has mentioned: >>> >>>> For Unicode Windows, GraphApp uses WM_IME_COMPOSITION messages to >>>> read the keys instead of WM_CHAR, which it uses for non-Unicode >>>> windows. >>> >>> I think that for a combination of R >= 4.2 and Dasher, this means an >>> impasse. Either Dasher should be taught to send WM_IME_COMPOSITION >>> messages to R (?), or R should learn to understand WM_CHAR messages in >>> its Unicode windows in addition to WM_IME_COMPOSITION it currently uses. >>> >> >> Another possible solution for Paulo is to use R via some other front end >> besides RGui, e.g. RStudio, but there are other possibilities too. >> >> Duncan Murdoch
Paulo Barata
2022-May-15 18:28 UTC
[Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher
Mr. Murdoch, Yes, following your suggestion, I see that I can use Dasher with R 4.2.0 patched in Visual Studio Code. Dasher works well that way, Visual Studio Code does accept Dasher, so I can use Dasher with R in an interactive mode. I will have to understand better the workings of Visual Studio Code. As an alternative, I will keep here two different versions of R: R 4.1.3 for interactive use through Dasher, and R 4.2.0 for running programs (written by means of a text editor). Anyway, I hope that some technical way can be found so that Dasher can be used regularly on the R console in R versions following R 4.2.0. For your information, Dasher can be used on Windows and Linux, but currently not on Macs. Best regards, Paulo Barata ---------------------------------------------------------- On 15/05/2022 14:24, Duncan Murdoch wrote:> On 15/05/2022 1:09 p.m., Paulo Barata wrote: >> >> Following Mr. Murdoch's suggestion, I installed R Studio (2022.02.2 >> build 485) on my Windows 10 Professional. >> >> When opening R Studio, it showed R 4.2.0 patched, the most recent >> version of R I had installed here. As it happens with the standalone R >> 4.2.0, Dasher did not work with R Studio with that version of R -- >> please see below what happened. > > That's too bad.? Still, there are other front ends: > > - Running Rterm in a command window. > > - R in Visual Studio Code > > - ESS in Emacs > > - Others whose names I don't remember; not sure how active any of them > are these days. > > And finally, if you are really desperate, I believe dasher runs on other > platforms besides Windows, i.e. Linux and MacOS. > > Duncan Murdoch > > >> >> I unistalled R 4.2.0 patched and also R 4.2.0, so then my latest version >> of R was R 4.1.3 patched. This was now the version of R that R Studio >> used. Dasher also did not work in R Studio with R 4.1.3 patched -- >> please see below what happened. Please note that the standalone R 4.1.3 >> patched does work perfectly well with Dasher. >> >> What happens in R Studio with both R 4.2.0 patched and R 4.1.3 patched: >> when I open R studio and start writing with Dasher, the first character >> that I write is now the character that always appears on the R Studio >> console, no matter what other characters I am commanding with Dasher. >> For R Studio, strangely, Dasher seems to be stuck in the first character. >> >> For example, if I wish to write a plot command in R Studio, the first >> Dasher "p" is accepted by R Studio, but the next "lot" appears on the R >> Studio console as "ppp". This is is contrast with what happens with >> Dasher on R 4.2.0, where, except for the "Enter" character, no other >> character is accepted by R 4.2.0, the R 4.2.0 screen just does not >> respond to Dasher. >> >> Both in R 4.2.0 and in R Studio, the "Enter" character of Dasher work >> well, it makes the R prompt to jump to the next line. >> >> So, Dasher does not work with R Studio either, but in a different way >> than it happens with R 4.2.0. >> >> Regards, >> >> Paulo Barata >> >> ---------------------------------------------------------- >> >> On 15/05/2022 13:27, Duncan Murdoch wrote: >>> On 15/05/2022 10:58 a.m., Ivan Krylov wrote: >>>> On Sun, 15 May 2022 11:10:49 -0300 >>>> Paulo Barata <pb at infolink.com.br> wrote: >>>> >>>>> I noticed today that R 4.2.0 responds to the "Enter" character of >>>>> Dasher version 5.0.0 beta in "Direct Entry" mode. An "Enter" in >>>>> Dasher causes the R prompt to jump to the next line, as an "Enter" >>>>> should do. >>>>> >>>>> No other characters (letters, digits, special characters like + = & ~ >>>>> | # $) are accepted by R 4.2.0 through Dasher. >>>> >>>> This seems to be very similar to the problem discussed here: >>>> https://stat.ethz.ch/pipermail/r-devel/2022-May/081683.html >>>> >>>> For the record, here's the part of Dasher responsible for "Direct >>>> Entry" on Windows: >>>> https://github.com/dasher-project/dasher/blob/0ec7d646dbaadf06b8eebfc11b784738a20e75af/Src/Win32/Widgets/Edit.cpp#L302 >>>> >>>> >>>> >>>> MSDN says: >>>> >>>>>> If KEYEVENTF_UNICODE is specified, SendInput sends a WM_KEYDOWN or >>>>>> WM_KEYUP message to the foreground thread's message queue with >>>>>> wParam equal to VK_PACKET. Once GetMessage or PeekMessage obtains >>>>>> this message, passing the message to TranslateMessage posts a >>>>>> WM_CHAR message with the Unicode character originally specified by >>>>>> wScan. >>>> >>>> <https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-keybdinput> >>>> >>>> >>> >>> As far as I can see, Graphapp never looks for VK_PACKET. >>> >>>> >>>> Previously, Tomas Kalibera has mentioned: >>>> >>>>> For Unicode Windows, GraphApp uses WM_IME_COMPOSITION messages to >>>>> read the keys instead of WM_CHAR, which it uses for non-Unicode >>>>> windows. >>>> >>>> I think that for a combination of R >= 4.2 and Dasher, this means an >>>> impasse. Either Dasher should be taught to send WM_IME_COMPOSITION >>>> messages to R (?), or R should learn to understand WM_CHAR messages in >>>> its Unicode windows in addition to WM_IME_COMPOSITION it currently >>>> uses. >>>> >>> >>> Another possible solution for Paulo is to use R via some other front end >>> besides RGui, e.g. RStudio, but there are other possibilities too. >>> >>> Duncan Murdoch >