Re: Zle patch - termok change

[gwing@xxxxxxxxxxxxxxx]

Bart Schaefer wrote:
:On Mar 7,  6:23pm, gwing@xxxxxxxxxxxxxxx wrote:
:} Subject: Zle patch - termok change
:} termok  now is flag based, not value based.
:} termok == 0 indicates a `normal' working terminal - this is *opposite* to
:}  the previous situation.
:In that case, you should never use the form (!termok) because it reads as
:if you mean the terminal is not OK.  Use (termok == 0) or make a new macro
:#define nosetflag(X)	((X) == 0)
:and then write (nosetflag(termok)).

Point taken, though I probably shouldn't be using !termok where I have, but
isanysetflag(termok, TERM_BAD | TERM_UNKNOWN | TERM_NOUP | TERM_SHORT)

:} Flags for termok are defined and explained in zsh.h - currently TERM_NARROW
:} is unused.
:It looks like it is used in zlevarsetfn() ... you mean nobody explicitly
:tests for it, but it is used in the sense that it makes termok != 0 ...

Yes, I meant explicitly, but also if I change as above, then it won't be
used yet.

:} If a terminal is evaluated as TERM_BAD then that status shouldn't go until
:} $TERM is changed.
:So that means that init_term() looks for TERM_BAD and doesn't change it?
:Or what?

Have no idea what I meant, but:
Until $TERM is changed, init_term() is not going to get called.  So your
terminal is TERM_BAD for one combination of $TERM/$TERMCAP/TERMCAP-file.
Yep, I don't know where I was going with this.  Don't worry about it.

:} I can't see why lines/columns should be any way connected to init_term() .
:They don't need to be as long as init_term() doesn't reset TERM_SHORT or
:TERM_NARROW.  If I do
:
:TERM=vt100
:LINES=3
:COLUMNS=3
:TERM=xterm
:
:Then what happens to termok?  Am I going to get a crash because init_term()
:has reset termok to zero?

No, init_term() doesn't touch TERM_SHORT or TERM_NARROW.  termok is flag
based and only set explicitly in  setupvals()

:BTW:
:#define issetflag(X, Y)		((X & (Y)) == Y)
:#define isanysetflag(X, Y)	(X & (Y))
:Is it really necessary for these to be different?  Why risk evaluating Y
:twice in issetflag?

There's no risk I can see or I would have put everything in parentheses.
You can't use the first form if you do something like my example above,
and the first form always evaluates to 1.  Hmmm,  you're right, I should
probably change it to:

#define issetflag(X, Y)		((X & (Y)) != 0)

And replace all isanysetflag()s with issetflag().  Good thinking.

-- 
Geoff Wing [mason@xxxxxxxxxxxxxxx]   Technical Manager
  Phone    : +61-3-9818 2977         PrimeNet - Internet Consultancy
  Facsimile: +61-3-9819 3788         Web : <URL:http://www.primenet.com.au/>
  Mobile   : 0412 162 441