[R] cat(), Rgui, and support for carriage return \r...

[Philippe Grosjean]

Prof Brian Ripley wrote:
> On Tue, 28 Mar 2006, Duncan Murdoch wrote:
> 
> 
>>On 3/28/2006 11:00 AM, Prof Brian Ripley wrote:
>>
>>>Rgui now supports \r in the same way as rterm.
>>
>>I notice that there's a slight change to the colour scheme:  now the prompt 
>>">" is in foreground colour, rather than user colour.  This might make sense 
>>(it's printed by the system, after all), but it looks a little strange at 
>>first.
> 
> 
> Yes, it was intentional.  The problem is that you can now do
> 
> 
>>cat("abcde\rf")
> 
> 
> and then the next line will be
> 
> f> de

Actually, there is an interest to do so with GUIs, like R Commander or 
SciViews-R (although R commander uses its own in/out window by default). 
The idea is to work with commands constructed by the GUI, and report the 
corresponding command to the console, but to flag them with a "special" 
prompt, telling it is different from what the user actually entered. 
Something like:
 > cat("\rGUI") # Tcl-triggered instruction
would give the following prompt:
GUI>
which is nice if there is a way to append a command in user color just 
after it, for instance:
 > cat("ls()\n") # Also triggered by Tcl code
giving:
GUI> ls()
with GUI> in foreground colour and ls() in user color.
Perhaps is it not possible, or even, not desirable to get this result 
for other situations.
Best,

philippe Grosjean

> with the cursor on the 'd'.  There is no longer a left-right divide 
> between system output and user input, as you can have output to the right 
> of user input.  The previous behaviour was to mark as system output all 
> the columns up to the 'e' here, so when you started entering new input it 
> looked very odd indeed, changing colour in mid-word.
> 
> I can change to making the prompt be explicitly regarded as user input, 
> which would be backwards compatible and less odd in cases like this.
> 
> 
>>Duncan Murdoch
>>
>>
>>
>>>On Sun, 19 Mar 2006, Duncan Murdoch wrote:
>>>
>>>
>>>>On 3/18/2006 2:39 PM, Duncan Murdoch wrote:
>>>>
>>>>>On 3/17/2006 9:44 AM, Jeffrey Racine wrote:
>>>>>
>>>>>>Hi, and thanks in advance for your time.
>>>>>>
>>>>>>Background - I am working on a package and wish to have a routine's
>>>>>>progress reported. The routine can take some time, and I would like to
>>>>>>inform the user about the routine's progress. I have scoured the
>>>>>>archives but to no avail, so would like to solicit input from this list.
>>>>>>
>>>>>>I am successfully using
>>>>>>
>>>>>>cat("\rBootstrap replication ", i, " of ", boot.num,)
>>>>>>flush.console() # To flush stdout on windows systems
>>>>>>
>>>>>>which works as expected on *NIX systems and using Rterm under windows.
>>>>>>However, under Rgui the carriage return \r is ignored, and I certainly
>>>>>>don't want to use the newline escape sequence \n. Under Rgui it appears
>>>>>>as
>>>>>>
>>>>>>Bootstrap replication 1 of 399Bootstrap replication 2 of 399Bootstrap...
>>>>>>
>>>>>>but I want it to function properly if at all possible.
>>>>>>
>>>>>>My question is simply whether there is a portable way to implement this
>>>>>>so that it works regardless of the R platform the user may be working
>>>>>>on?
>>>>>>
>>>>>>Many thanks for any/all suggestions.
>>>>>
>>>>>I've just been looking at the source code for this.  I think it will be
>>>>>relatively easy to make \r in Rgui do a destructive CR (i.e. it will
>>>>>return to the start of the line, but clear any existing characters).
>>>>>I'll play around a bit and then do that for R-devel.
>>>>
>>>>Oops, this was a bad idea.  I did commit the change for a while, but
>>>>have reverted it now.
>>>>
>>>>It seems that the help system displays help pages by writing CR LF at
>>>>the end of each line; the CR is \r, and my change above caused it to
>>>>wipe out the line it had just written.  The help pages ended up
>>>>completely blank.
>>>>
>>>>I may look into supporting \r as a non-destructive CR, but that's
>>>>harder, because it means low-level changes to the console display.
>>>>Right now it only writes to the end of the text buffer; this would mean
>>>>it would sometimes write to a spot before the end.  I don't think it
>>>>would be impossible to do, but it will take more time than I have right 
>>>>now.
>>>>
>>>>Duncan Murdoch
>>>>
>>>>______________________________________________
>>>>R-help at stat.math.ethz.ch mailing list
>>>>https://stat.ethz.ch/mailman/listinfo/r-help
>>>>PLEASE do read the posting guide! 
>>>>http://www.R-project.org/posting-guide.html
>>>>
>>>
>>
>