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@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 >>>> >>> >> > ______________________________________________ R-help@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