[Rd] Unexpected behavior with \r in Rgui 2.12.0

[Henrik Bengtsson]

This is now working. ...almost.  There seem to be some "memory"
remaining of where to put the point ("cursor") - a memory that is
related to the number of characters moving back.  Hard to explain, but
try this in Rgui (I've added the cursor):

> cat("1234\r6789")
6789> |
>     |
>     |
>     |

> cat("12345\r67890")
67890> |
>      |
>      |
>      |

> cat("\r")
> |
> |
> |

Also, maybe a wanted feature or not, but cut'n'paste contains the
complete string sent:

[BEGIN CUT'N'PASTE]
> cat("1234\r6789")
1234
6789>
> cat("12345\r67890")
12345
67890>

> for (kk in 1:10) { cat(sprintf("%02d\r", kk)) }; cat("\n");
01
02
03
04
05
06
07
08
09
10

>
[END CUT'N'PASTE]

> sessionInfo()
R version 2.13.0 Under development (unstable) (2010-11-26 r53672)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

/Henrik

(Just wanted to share these observations; not really using this feature myself).





On Thu, Nov 25, 2010 at 10:12 AM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:
> On Thu, Nov 25, 2010 at 10:02 AM, Henrik Bengtsson <hb at biostat.ucsf.edu> wrote:
>> FYI, this topic was discussed in R-help thread 'cat(), Rgui, and
>> support for carriage return \r...' on March 17-29, 2006:
>>
>>  https://stat.ethz.ch/pipermail/r-help/2006-March/101863.html
>>
>> Some modifications to Rgui's behavior was brought up and (I think)
>> implemented at the time.
>>
>> As far as I remember, after that discussion ASCII carriage return did
>> indeed *move* the point/cursor to the beginning of the current line. I
>> remember trying it at the time, but I admit I haven't verified it in
>> several years now.
>
> [scrap]
>> However, I believe that that was before Unicode
>> character support was introduced, and my best guess is that support
>> for the latter may have changed the expected behavior of carriage
>> return.
> [/scrap]
>
> Remove that last guess of mine; know I re-read Ripley's message and
> see that the displaying of odd characters was due to a bug, which was
> just fixed.  It will take a couple of days before binaries of that
> patched version are available on CRAN.
>
> /Henrik
>
>>
>> My $.02 on the history
>>
>> /Henrik
>>
>>
>> On Thu, Nov 25, 2010 at 7:49 AM, Russell Pierce <rpier001 at ucr.edu> wrote:
>>> Prof. Ripley & Joris,
>>>
>>> I concur with Joris, the behavior persists in R version 2.12.0 Patched
>>> (2010-11-24 r53655) and  under Windows XP.  The current development build
>>> for Windows did not have an RGui at the time I wrote this.
>>>
>>> I did not realize that the functionality of "\r" to return to
>>> the beginning of the line in Windows was undocumented/unsupported.  ?Quotes
>>> lists \r as carriage return without any warning that it is unsupported in
>>> RGui, perhaps a notice should be put in?
>>>
>>> Since "\r" is not supported, I would like to express a desire that it at
>>> least do something predictable.  Certainly, it seems doubtful that
>>> these "strange characters" (with the copying characteristics described) is
>>> what a user expects.  If "\r" is not usable under RGui perhaps it would be
>>> better to ignore it entirely than to parse it and return the odd output that
>>> I am seeing?
>>>
>>> In the RGui for Windows prior to this version "\r" returned to
>>> the beginning of the line without deleting the already written content.
>>>  Thus cat(70,"\r") and cat("\r",70) only differed in terms of where the
>>> cursor was left.
>>>
>>> I started using "\r" because I had seen it in the code for txtProgressBar.
>>>  The help for txtProgressBar does note that it "uses \r to return to the
>>> left margin – the interpretation of carriage return is up to the terminal or
>>> console in which *R* is running". For Jorris' reference, in a windows
>>> environment there are several methods to produce keep track of progress:
>>> tcltk::tkProgressBar, utils::txtProgressBar , and utils::winProgressBar.
>>>  None of them are as "user friendly" as cat and "\r" because you have to
>>> create the progress bar, increment it, then destroy it.  If you want to
>>> output debugging information as well as increment a counter you need to
>>> tweak the title attribute as you go.
>>>
>>> Best,
>>>
>>> Russell S. Pierce
>>>
>>>        [[alternative HTML version deleted]]
>>>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>