Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!tut.cis.ohio-state.edu!bloom-beacon!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Getchar w/wout echo
Message-ID: <6972@haddock.ima.isc.com>
Date: 2 Sep 88 22:10:53 GMT
References: <6589@haddock.ima.isc.com> <319@quintus.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 34

In article <319@quintus.UUCP> ok@quintus.uucp (Richard A. O'Keefe) writes:
>In article <6589@haddock.ima.isc.com> karl@haddock.isc.com (Karl Heuer)
>proposes a   rawenable(), getrawchar(), rawdisable()   interface.
>
>>Let's begin by ignoring the issue of exactly what "raw" means.
>
>Let's not.  The original topic was reading without _echoing_, which is
>not the same thing as reading without line-editing.

Right.  Which is why I didn't define "raw"; I wanted to leave open the
possibility that it could mean "with line editing, but no echo".  Such
variants can be (and are, in my current implementation) handled via arguments
passed to rawenable().  The set of legal feature-combinations is, of course,
implementation-defined.  (It may even be empty, in which case the request
always fails.)

>>If getrawchar() is called from cooked mode, or any stdio function from raw
>>mode, the behavior is undefined.
>
>Does this mean ANY sort of stdio ...?

Good point.  Let's make it "any stdio function which applies to the raw
terminal", or something like that.

In <155@umigw.MIAMI.EDU> and <1276@mcgill-vision.UUCP>, steve and mouse
suggest that rawenable() and rawdisable() should be idempotent instead of
causing undefined behavior on repetition.

But it may be better to allow them to stack, instead.  (E.g. if you want to
call getpass() from within raw mode, and if getpass() is implemented using
rawenable().)  I figured it's better to leave it undefined until the details
are worked out.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint