Re: [Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher

2022-05-15 Thread Ivan Krylov
On Sun, 15 May 2022 11:10:49 -0300
Paulo Barata  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.



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.

-- 
Best regards,
Ivan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher

2022-05-15 Thread Paulo Barata



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


 





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




__
R-devel@r-project.org maili

Re: [Rd] Writing in R // R 4.2.0 on Windows doesn't work with Dasher

2022-05-15 Thread Ben Bolker
 VScode is sorta-kinda open source 
https://opensource.com/article/20/6/open-source-alternatives-vs-code 
(that is, the default downloadable binaries are non-freely licensed). 
Presumably the open builds also work.


  On the other hand, it's also developed by Microsoft, so it's not much 
of a surprise that it works better on Windows than some of the alternatives.


On 2022-05-15 5:48 p.m., Duncan Murdoch wrote:

On 15/05/2022 5:01 p.m., Kasper Daniel Hansen wrote:
It is interesting that Paulo reports Rgui to behave differently from 
many (all?) other applications. However, I have no insight into Windows.


It's not a big surprise.  Rgui uses a UI library (Graphapp) that was 
written a very long time ago, and it hasn't adopted their updates in at 
least 15 years.  Additionally, Rgui hasn't really had any Windows users 
giving it the attention it needs.


And not nearly "all".  RStudio has different problems, which means 
everyone using the same UI library they use probably has them too.  I 
didn't see any open source projects in the list of things that work.


Duncan Murdoch



Best,
Kasper

On Sun, May 15, 2022 at 3:32 PM Duncan Murdoch 
mailto:murdoch.dun...@gmail.com>> wrote:


    On 15/05/2022 2:44 p.m., Ben Bolker wrote:
 >     I don't know if there's a good up-to-date list anywhere of
 > editors/IDEs that handle R nicely, but it would include at least:
 >
 >     Atom
 >     Sublime Text
 >     VS Code
 >     RStudio
 >     Jupyter notebooks
 >     vim
 >     emacs
 >     Tinn-R
 >
 >     It's worth being able to choose from such a list both for 
general
 > aesthetic preferences, and for those with accessibility 
challenges.


    One more that I should have mentioned:  StatET, a plug-in for the
    Eclipse IDE.

 >
 >    I do agree that it would be nice if there were a way to make 
the R

 > console work well with Dasher under Windows, but the technical
    details
 > are completely beyond me.

    A long time ago I used to know some of this stuff, but now I find
    working in Windows quite difficult.  I never knew it well enough to
    know
    the advantages and disadvantages of the approach RGui uses versus the
    one that dasher seems to be expecting.

    On the hopeful side, accessibility has always had a relatively high
    priority in the R Project, and there seems to be a recent push in 
that

    direction.  Perhaps there will be an opportunity for someone to
    bring up
    this issue at useR! 2022 (https://user2022.r-project.org
    ).

    Duncan Murdoch

    __
    R-devel@r-project.org  mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
    



--
Best,
Kasper




--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel