Wanted: readline-no-echo

• To: jmorrill@BBN.COM
• Subject: Wanted: readline-no-echo
• From: Steve Haflich <smh@franz.com>
• Date: Wed, 6 May 92 16:35:24 PDT
• Cc: SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM
• In-Reply-To: Jeff Morrill's message of Wed, 06 May 92 18:35:55 -0400 <2136.705191755@bbn.com>

   From: Jeff Morrill <jmorrill@BBN.COM>
   ...
   I can see a potential problem with XJ313's specification for
   echo streams here.  Presumably a frame pane is (or will be)
   an echo stream, and yet there are times when you want to read
   a string from a frame pane without echoing (e.g. passwords).
   There might be a reason to add a new reader control variable,
   *read-echo*, for this case.

X3J13 actually specifies accessors for the components of an echo
stream: ECHO-STREAM-INPUT-STREAM and ECHO-STREAM-OUTPUT-STREAM.  They
are new, so not all implementations provide them yet.

I really don't want to get sucked too deep into the issue whether a
frame pane actually would be implemented as an echo stream, but in
fact it seems unlikely.  The original STREAM-DEFINITION-BY-USER
proposal by David Gray pointed out that the compound stream of the
original CLtL specification (echo-, broadcast-, two-way-, and
concatentated-) are antithetical to the architecture of subclassable
closified stream types.  For instance, a generic function that needs
to descriminate on stream class has an intractible problem with an
echo stream.  There is no automatic way for the gf to discriminate on
either the input stream or output stream -- only the echo stream is
available to the gf discrimination mechanism.

• Re: Wanted: readline-no-echo
• From: Jeff Morrill <jmorrill@BBN.COM>

• Prev: Re: Wanted: readline-no-echo
• Next: (not so) silly presentation question
• Index: CLIM Mailing list (1-Jan-92 to 31-Aug-92)
• Thread: CLIM Mailing list Index (1-Jan-92 to 31-Aug-92)