EPIC4pre1

*** News 06/18/97 -- New feature, "CPU SAVER"
	Some of you have asked me for a way to make ircII use less CPU
	especially when you are idling and detached.  Every minute ircII
	sends out your notify list, parses the replies, checks the clock,
	updates your status line, and other various housekeeping duties.

	But when youre detached, you dont really care if your notifies
	dont get processed promptly every 60 seconds, you dont care if
	the clock is accurate every moment, and you would prefer that
	the client not go to the trouble of wasting CPU time just to
	keep track.   This wont help if youre on busy channels, or
	logging wallops, only if the only traffic youre getting are
	the pings from the server.

	There are several new sets:
	/set CPU_SAVER_AFTER -	If you havent typed anything after
				this many minutes, CPU saver mode activates.
	/set CPU_SAVER_EVERY -	If cpu saver mode is on, the client will
				only do housekeeping every this many minutes.
	If either of these two are 0, then cpu saver mode cannot be
	activated, and the "traditional" behavior will apply.

	If youre interested in seeing when the client is in cpu saver
	mode, there is a new status line expando, "%L".  There is also
	a new /set, /SET STATUS_CPU_SAVER which determines how the %L
	expando will look when it is activated (just like STATUS_MAIL)

	There is also a new keybinding, "CPU_SAVER", which if bound to
	a key will activate cpu saver mode without having to wait.

	I did this on a whim, mostly because i havent done any features
	in a long time that have required this many changes, and I wanted
	to have some fun, so i just let loose with this and went berzerk
	If i forgot some obscure feature with this, let me know! ;-)


*** News 05/31/97 -- New environment variable honored, ``IRC_SERVERS_FILE''
	Someone had suggested something close to this -- they wanted a 
	way to specify a SERVERS_FILE as an absolute path rather than
	having it in their irclib directory.  So you can now set this
	environment variable to an absolute path where you would like the
	client to get your server list from.  This overrides any
	built in SERVERS_FILE setting, if appropriate.

*** News 05/31/97 -- Semantic clarification for /TOPIC
	Due to the confusion between the very common ``topic'' alias
	and the built in TOPIC command syntax, I have expanded the
	built in TOPIC command to do everything that everyone expects
	TOPIC to do, towit:

		/topic This is a topic		(set current channel topic)
		/topic * This is a topic	(same thing)
		/topic				(see topic on current chan)
		/topic *			(same thing.)
		/topic #chan This is atopic	(set topic on #chan)

	I strongly advise you to throw away your /topic alias unless it
	does something up and beyond this.  If it does, let me know, and
	I can include its semantics in the client, if its reasonable.

*** News 05/19/97 -- All new syntax for /IF
	As if ircII wasnt becoming PERLish enough, ive modified the
	/IF command to be more perl-like:  You may now use the 
	"elsif" modifier to indicate a blocked if command, eg:

		if (....) {
			....
		} elsif (...) {
			....
		} elsif (...) {
			....
		} else {
			....
		}

	(The final "else" is optional.)  Note that the placement of
	the "elsif" and "else" modifiers is critical:  They MUST be
	on the same line as the closing } to which they modify, or the
	/LOAD parser will get totaly confused and munge the whole
	thing up.  This is a limitation that applies only to how
	scripts are loaded -- sorry.

*** News 05/09/97 -- New function added, $findw(word ...text ...)
	This addresses the two most common complaints people have
	about $[r]match():

	1) This function returns the WORD NUMBER of the word
	   in text, such that $word($findw(word .text.)  .text.)
	   returns "word".  It returns -1 if word is not found.
	2) This function does not do anything screwy about quoting
	   or unquoting your input.  It just looks for the word,
	   thats it.  No pattern matching, no frills, and its fast.

*** News 05/09/97 -- Semantic weakness closed
	There was a semantic weakness with respect to the word count
	and strlen modifiers ($#var and $@var) such that if you did 
	not provide a variable to modify, an unuseful value was returned.
	Since this was likely to cause confusion, these cases are now
	defined to implicitly assume $* as the default argument. eg:
		$#   all by itself is now the same as $numwords($*)
		$@   all by itself is now the same as $strlen($*)
	These are *NOT* built in functions.  The # and @ characters
	still are considered to be modifiers.  The weakness was that
	these modifiers did not return meaningful values when a value to
	modify was not provided:  This change stipulates a useful default.

	In a seperate, but related topic, a change was also made to
	the math parser to honor this change in that context.  That
	is to say,   @ foo = #   now assigns to `foo' the number of
	arguments in the current context.  NOTE THAT THIS IS NOT A
	FUNDAMENTAL CHANGE!  We're just saying that the default value
	for the # and @ modifiers is $*.  This is not a "function"!

*** News 05/05/97 -- New flag to /WINDOW,  /WINDOW LASTLOG
	/WINDOW LASTLOG lets you individually tweak the size of a 
	window's lastlog.  This was introduced because this used to
	be the default beahavior of /set lastlog, but now that /set
	lastlog is a global action, we still need a way to do this...

*** News 04/29/97 -- New /set, /SET QUIT_MESSAGE
	This will be your default quit message.  If you do something
	stupid, like unset this completely, the client's version will
	be used as the default.  Of course, any argument you pass to
	/quit or /signoff will override this /set.

*** News 04/29/97 -- New /set, /SET DISPATCH_UNKNOWN_COMMAND
	If you type a command that is not recognized by the client,
	and youre one of those people who /never/ mistype a command,
	then you can /set this to ON, and the client will dispatch any
	otherwise unrecognized commands to the server.  Im sure your
	server admin will love you if you do this.

*** News 04/29/97 -- New built in function, $winchan()
	You give it a channel name, and an optional server name
	or server refnum, and it tells you what window refnum that
	channel belongs to. (Written by IceKarma)

*** News 04/29/97 -- New flag to /lastlog, /lastlog -max
	You can use /LASTLOG -MAX to specify the maximum number
	of matches you want to display, regardless of any other
	flags.  The default is no limit.  This was written by Sheik.

*** News 04/29/97 -- New functionality to /stack,  /stack set
	You can now do /STACK (PUSH|POP|LIST) SET just as you can
	already with ALIAS/ASSIGN/ON.  This was written by Colten.

*** News 04/21/97 -- New set, /SET BANNER
	The /SET BANNER variable now controls what special banner will
	be prepended to informational messages from the client.  Up until
	now, the banner has been three stars ("***"), and many people dont
	like that or want to be able to change it.  Now you can.

*** News 04/21/97 -- New on, /ON SET
	/ON SET is a way to extend the capabilities of the /set command.
	The /ON SET hook is passed two or more arguments, with
		$0  -- is the name of the variable to be set
		$1- -- is the value the variable will be set to.

	The main idea is the ability to offer /set variables that are
	not built into the client, and execute ircII code to handle that
	situation.  The other idea is the ability to suppliment or override 
	a built-in set variable when it is changed.

	If you hook /ON SET with the "SILENT" modifier ('^'), then the
	default action (if any) will not be taken.  This may mean that
	if the variable is not a built in variable, no error will be
	output.  If the variable IS a built in variable, then the variable
	will NOT be set after the fact.

	There are two ways to get around this:  You can either hook the
	/ON SET with the "quiet" modifier ('-'), or you can use the /set
	command inside of the /on set body.  If you attempt to /set a 
	variable that is already being parsed by /on set, you will NOT
	be offered the /on again -- it will directly set the variable:

	Example:
		on ^set "exec_protection off" {
			echo *** You cannot set EXEC_PROTECTION off!
			set exec_protection on
		}

	Or:
		on ^set "auto_rejoin_delay *" {
			echo *** AUTO REJOIN delay set to [$1] seconds.
			@ myscript.autorejoin.delay = [$1]
		}

	Then you could do:
		/set auto_rejoin_delay 4


*** News 04/17/97 -- $X now reflects your ``real'' userhost
	When you connect to a server, the client asks the 
	server what your userhost is, and then that value is
	reflected in the $X variable.  Different server connections
	may have different $X values.

*** News 04/17/97 -- Changed semantics for USERHOST command
	The userhost command will act the same as always, except
	under the following  condition:

	If you do /userhost <nick(s)> -cmd, and *every* nick so 
	specified is on one of the channel(s) you are on (so that 
	the client already has the userhost cached), then the -cmd 
	code will be executed immediately, and the client will *NOT* 
	ask the server for the userhost information.  You are 100% 
	guaranteed still to get accurate information, you will just
	get it without waiting for the server query!  The only caveat
	is that the AWAY and OPER fields will be specified with the
	false value.  If you currently use the /userhost command to
	determine if a person is an operator, keep reading.

	A new flag has been added to the USERHOST command, -direct.
	The -direct flag forces the client to do a server query for
	the specified nicknames, even if all of the nicknames are 
	known to the client beforehand.  This can be used to get
	accurate AWAY and OPER information.  This flag only makes sense
	with the -cmd flag, since userhost caching does not happen
	unless the -cmd flag is specified.

*** News 04/10/97 -- Two new operators =~ and !~
	The two operators are intended to be similar to the perl operators:
	The lhs of the operator is expected to be a plaintext string, and
	The rhs of the operator is expected to be a wildcard expression.
	The operator returns a true value if the pattern matches the text,
	and it returns the false value if it does not.

	This is intended to be a low-cost alternative to the $match() and
	$rmatch() built-in functions when the only thing you need to do is
	see if a string is matched by a pattern.  If you need to select 
	from more than one pattern, use $match() or $rmatch().

*** News 04/07/97 -- Asynchronous code may use local variables
	You may reference local variables in asynchronous code
	provided that you follow the rules that have already been
	laid down.  See the regress/kill script for more info.

	1) You have to use /bless in the asynchronous code in order
	   to have access to the underlying local variables.
	2) You have to use /wait in the synchronous code in order to
	   make sure the local variables dont go away.
	3) Make sure you clean up your own messes.  Asynchronous code
	   lying around, resulting in /bless calls when there is no 
	   context for local variables is not a good thing.

*** News 03/31/97 -- New argument to /WAIT command, ``for''
	Yes, ``for'' without a hyphen.  This command guarantees that
	the code given as the argument is executed synchronously.
	That is to say, if the arguments, when executed, sent something
	to the server, the command will not return until that request
	has been completed (as if a wait had been done.)  But if the
	code does not send a query to the server, no wait is executed,
	and the command returns immediately after the code completes.

	You can also mix and match ``wait for'' with regular ``wait''
	calls and the client will be able to figure out what to do
	without waiting extra more than it needs to.

	And as always, using /wait or /wait for and /redirect at the 
	same tims is a bad thing (tm), so dont do it.  The result is
	undefined behavior (eg, what happens isnt my fault.)

*** News 03/19/97 -- About the new who/ison (and soon userhost) queues.
	The client now keeps a FIFO (queue) of who/ison/userhost queries
	you make.  It is *critically* important that you do not confuse
	these queues (due to the nature of these server queries, there is
	no way to have any reasonable error recovery). 

	The following behaviors are forbidden (but the client wont stop
	you from doing them)

	* Using /ON ^RAW_IRC to wedge the 303, 351, or 315 numerics.
	  If you do this, the queues wont be properly flushed, anyone
	  waiting on a proper reply wont be handled, and any further
	  reqeusts will be thought to be previous queries, and all hell
	  will break loose.
	* Using /QUOTE to launch USERHOST, ISON, or WHO requests..
	  If you do this, the client will whine at you when it gets
	  unexpected replies and will eat the information.  If you launch
	  another query before the invalid one finishes, all hell will
	  break loose.

	*** THERE IS NO WAY TO RECOVER IF YOU DO THESE THINGS ***
	If youre stupid enough to do it, you get what you deserve.

*** News 03/18/97 -- Expanded syntax for $userhost()
	For your convenience, the $userhost() function now takes arguments:
	You may specify one or more nicknames as arguments to the $userhost()
	function, and the corresponding userhost(s) for the nick(s) specified
	will be returned.  The string <UNKNOWN>@<UNKNOWN> will be inserted
	for any nicknames whose userhost is not known.  The nickname(s)
	speified *must* be people who are on channels you are also on for
	the current server!  (See the second caveat)

	* Caveat -- Because it can take time for the WHO query to complete
	after you join a channel, there is no definite way to know if
	$userhost() for a person on your channel will succeed or not.
	You should probably be prepared to launch a /USERHOST query in
	case of failure.  This deficiency may be altered or modified in
	the future to block if an otherwise valid request is made while
	a WHO query is still pending.

	* Caveat -- This function will never be modified to launch a server 
	query.  That means that this function will only ever recognize those 
	nicknames that are common to channels you are on.  If you want to find 
	the userhost for other users, you should use the /userhost command.
	It is expected that the /userhost command will soon be able to
	take advantage of the userhost caching (but it does not yet.)

*** News 03/18/97 -- Expanded syntax for /who
	For your convenience, the /who command now takes two new arguments:

	-line {...}	The code inside the braces will be executed for each
			line returned by the who query.  The arguments are
			exactly the same as for the /on who hook, except that
			this flag is *guaranteed* to override the default
			/on who, and will also *go away* when the current who 
			query is finished.

	-end {...}	The code inside the braces will be executed at the
			end of the who query, when the 315 numeric is parsed.
			The arguments are:
				$0 - server queried
				$1 - body of the query
			This is guaranteed to toverride the default /on 315,
			and will also go away once the current who query is
			completed.

	These command bodies will be executed asynchronously, which means
	that you must assume that the enclosing code scope will complete
	before the code is ever executed (e.g., the same rules as for the
	/userhost -cmd flag.) unless you use /wait.  You are encouraged
	to not use /wait if you can figure a way around it.  Code that is
	not concerned with being stricly backwards compatable with the
	stock client is ***strongly encouraged*** to use these new flags.

	Underlying this change is a new re-entrant WHO queue, which allows
	you to launch more than one WHO query simultaneously.  No longer do
	concurrent WHO requests have to wait for previous queries to complete,
	and no longer (with the above flags) does the caller need to put the
	WHO command in a /stack-/on-/wait wrapper.

*** News 03/17/97 -- /on 312, /on 319 changes
	All of the whois numerics: 311, 312, 313, 314, 317, 318, 319
	now pass $0 as the server name and $1 as the target of the 
	whois query.  All the rest of the arguments are passed as $2-.
	Previously, some of these numerics passed the target as $1,
	but not all of them.  I changed it this way for consistancy.

*** News 03/17/97 -- New: /ON STATUS_UPDATE and $status()
	/ON STATUS_UPDATE is hooked whenever any of the status lines
	for any of the visible windows changes **and you are in dumb mode**:
	   $0  is the refnum for the window whose status line has changed
	   $1  is the status line in that window that has changed
	   $2- is the actual status line for that window.

	$status() can be used to fetch the current status line for any
	visible window.  Invisible windows do not have their status lines
	updated, so they may be inaccurate.  This problem may change in
	the future.  Pass two arguments:
	   $0  is the refnum for a window
	   $1  is the status line

*** News 03/02/97 -- Local variables can now span entire array tree
	The syntax:
		``local x.y.''
	will define all variables in the subarray $x[y][...] to be
	implicitly considered local variables.  That is to say, the
	entire variable tree rooted at $x[y] is local to that scope.
	This was requested by a user for compatability with another
	client.  All local variables that are instantiated in this
	manner have the same scope as the explicit declaration above.

*** News 02/18/97 -- New built in variable, /SET CONNECT_TIMEOUT <seconds>
	Set this to the number of seconds you want your connect()ions to	
	block before they time out.  Note that this doesnt affect
	connect()ions that are already in progress, only those that are
	started after you set it.  The default is 30.

*** News 01/30/97 -- Expanded syntax for /LOCAL, /STUB
	You may now specify more than one name per command:  Each name
	will be treated independantly of all others.  The names must be
	seperated by a comma, and ***must not*** have any spaces between
	the commas and the names (that is, all of the names must form one
	logical word).  To declare both "foo" and "bar" as local vars,
			/local foo,bar

	You can do this to stub more than one alias/assign to the same
	file, as well:
			/stub foo,bar filename

*** News 01/29/97 -- New command /BLESS
	Currently this command ignores its arguments.  This may change
	in the future, so you should not get in the habit of supplying
	arguments to this function, for forwards compatability.

	The ''BLESS'' command is used to allow an asynchronous scope to
	access the local variables of the underlying synchronous context:

		alias foobar {
			local myvar $0
			userhost $1- -cmd {
				bless
				echo $myvar -- $0!$3@$4
			}
			wait
		}

	Note that the use of 'bless' must be paired with an appropriate
	call of ``wait'' in the synchronous context, or this wont work.

*** News 01/27/97 -- New flag for /EXEC, -direct
	Syntax:
		/EXEC -direct <commands>

	This simulates the effect that unsetting the SHELL variable
	causes, that is, the command is executed directly, without
	invoking a subshell.  This is appropriate for those who wish
	to execute a command passing untrusted data as an argument:
	With this flag, there would be no shell to interpret metacharacters,
	thus cutting down on that ability to have an accidental back door.

*** News 01/27/97 -- New command, /SETENV
	Syntax:
		/SETENV <var-name> <new-val>

	Sets the process environment variable <var-name> to the value of
	<new-val>.  This command is not neccesarily useful, nor is it 
	always appropriate, but it is provided for completeness.  There
	are several places in the code that can benefit from the ability
	to change environment variables after startup (eg, TZ).  It also
	allows you to set environment variables for /exec'd processes,
	and it is also possible to really foul things up if you mangle
	important environment variables such as DISPLAY and so on.

*** News 01/24/97 -- New, /ON ODD_SERVER_STUFF
	This is hooked whenever the server sends you something
	that the client doesnt recognize.  This is usually when
	you try to connect to a non ircd server, or you use some
	extension that isnt yet supported.  You are strongly 
	encouraged to use this interface to support new features
	rather than using /on raw_irc because this hook is only
	activated when something unexpected occurs (which is rare),
	rather than for every incoming line, as raw_irc does.

	$0  is the server that sent it to you, '*' if unknown
	$1- is the unrecognized command and its arguments.

*** News 01/22/97 -- /FE, /FOREACH use local variables now
	The "control variables" for the /FE and /FOREACH command
	now are local variables.  They will not disturb global variables,
	but they will destroy any local variables you have by the same
	name.  You dont have to explicitly declare the variables as local,
	it is done automatically for you.  Note that the normal warnings 
	for local variables still apply -- dont use any variable name that
	is the same as a global variable you might want to use later in
	the same alias/on. 

*** News 01/18/97 -- Support for local variables
	You may define a local variable with the following command:

		LOCAL <varname> [<value>]

	It mirrors the ASSIGN command.  Note that local variables act
	in exactly the same way as normal variables, except you cannot
	get rid of them.  You also do not (yet) have any way to get at
	a global variable that has the same name as a local variable, so
	choose wisely.  An example:

		alias foobar
		{
			local b			(declare LOCAL var $b as []) 
			assign a 4		(assigns 4 to GLOBAL $a)
			local a 5		(assigns 5 to LOCAL $a)
			eval echo $a		(outputs '5' -- local)
			@ a = []		(clears LOCAL variable)
			eval echo $a		(outputs '' -- local)
		}

	Restrictions:
	* You cannot have local aliases -- only local variables
	* You cannot save local variables.
	* You cannot (yet) access a global variable with the same name
	  as a local variable.

	This support is EXPERIMENTAL and still has some development to go 
	before it is mature.  


[This file truncated for EPIC4pre1... the rest of it is available via
 ftp at ftp.acronet.net]
