From: Arnd B. <arn...@we...> - 2004-01-08 08:12:55
|
On Wed, 7 Jan 2004, Ethan Merritt wrote: > The light dawns. Much that was murky becomes clear. That's really good news - below is a text I set up before, parts of it might be obsolete, even though observation D) seems to relate what you wrote on the buffered to unbuffered change [...] > setvbuf(stdin, (char *) 0, _IONBF, 0); > This command changes from buffered to unbuffered input > mode, which would be OK, but..... > The current buffer contents are thrown away, and you lose > all the characters that have not yet been read in and acted upon. Commenting this out explains then (I think) why this contents shows up after a return (see below). > So it isn't really a race. It's just that if we are going to > switch to unbuffered mode we should first make sure the > buffer is empty, or else store it elsewhere for later execution. > > I don't yet see a trivial way of doing this, but it can probably > be done with enough work. OK - I will stay tuned ;-). Alright, and here the "results" of some tests: Hi, thank you all very much for your replies. I tested some of the options: A) ./configure --with-readline=gnu --disable-mouse - copy-and-paste: does work - piping from python works B) ./configure --with-readline=gnu --enable-mouse (default) - copy-and-paste : does not work - piping : has problems - with `gnuplot -noevents -nofeedback` and an unset mouse at the beginning: does not help. C) ./configure --enable-mouse (default) results: as for B) D) ./configure --with-readline=gnu --enable-mouse (default) + commenting out setvbuf() in x11.trm results: same as for B), but - for pasting: after pressing enter at the gnuplot> prompt the "lost" lines appear and are executed! - for piping: sometimes a character at the beginning of a line is lost. I am not sure if the above is helpful ;-) ... For the "moment" it would be good to have the two options a) mouse enabled gnuplot with feedback and all that b) mouse disabled, feedback disabled + pasting works + piping works via command line options. (I wonder if b) should be the default for backwards compatibility?). In the longer run Dan's "tight loop" suggestion sounds very reasonable to me... Regards, Arnd |