EPIC5-2.2

*** News 02/13/2021 -- /UNLOAD now supports /TIMERs
	If you create a /TIMER in a script you /LOAD with /PACKAGE
	the timer will be tagged just like any aliases or assigns
	or ons or whatever.

	Note that /TIMERs are _not_ tagged if they are created 
	after /load time.  This includes but is not limited to 
	timers created by aliases that are tagged; as well as
	timers that create new versions of themselves (but it 
	will catch timers that run forever)

*** News 02/10/2021 -- New /WINDOW operation, /WINDOW UNCLEAR
	There was already an /UNCLEAR command, and a /CLEAR and
	/WINDOW CLEAR command, but there was no /WINDOW UNCLEAR.
	WHy not? Anyways...

*** News 02/07/2021 -- Low level operations on cutbuffer - $inputctl()
	Harzelein asked if there was a way to manipulate the cutbuffer
	without having to put something in the input line.  As it happens,
	that has never been requested before.  So here we go!

	$inputctl(GET cutbuffer)
		This returns the cut buffer.  This is the same as $U

	$inputctl(SET cutbuffer ... new value ...)
		This sets the cut buffer.  This would be effectively
		the same as:
		 * Saving the input line (with $L)
		 * Erasing the input line (parsekey ERASE_LINE)
		 * /TYPEing what you want into the cut buffer
		 * Erasing the input line (to put it into the cut buffer)
		 * /TYPEing the origial input line
		But this doesn't require you to disrupt the input line.

		Please remember that there is only one cut buffer,
		and a large number of operations replace it -- so 
		whatever you put in the cut buffer, use it quickly,
		or the user might clobber it.

*** News 02/05/2021 -- /ON SERVER_STATUS changed to /ON SERVER_STATE
	Some expressed some confusion about whather "SERVER STATUS"
	and "SERVER STATE" were the same thing, and what the states
	were and what they meant.  To reduce this confusion, there
	will be only one term, "SERVER STATE". However, much code
	already uses "SERVER STATUS".  So we have to support both.

	For now, /ON SERVER_STATUS and /ON SERVER_STATE will both 
	exist side by side.   However, I recommend you use 
	/ON SERVER_STATE for new code, and think about migrating
	your old code.   There will come a day when /ON SERVER_STATUS
	will beoome an alias for /ON SERVER_STATE.

	To be unambiguous, using /ON SERVER_STATUS will never break.
	But you should know the official name is going to be 
	SERVER_STATE.

	The stock scripts have been updated.  You can get the changes
	by making sure to do a 'make install'

*** News 02/05/2021 -- $serverctl(GET x STATUS) changed to STATE
	As per the above, both $serverctl(GET x STATUS) and 
	$serverctl(GET x STATE) will return the server's state.
	However, you are encouraged to start using "STATE", since
	that is now the official term for it.

	The stock scripts have been updated.  You can get the changes
	by making sure to do a 'make install'

*** News 07/03/2020 -- New /WINDOW operation, /WINDOW DELETE_KILL
	Harzilein pointed out:
	  1) You cannot delete the last window on a screen
	  2) Deleting a screen does not kill a window
	  3) Therefore, deleting a screen necessarily orphans a window
	But what if you don't want to orphan a window when you kill a
	screeN?  

	The /WINDOW DELETE_KILL operation does a /WINDOW DELETE and
	then does a /WINDOW KILL on the window that was the current
	window.  There are several caveats to this *which i reserve
	the right to change in the future*
	
	Caveat 1) Only the "current window" gets killed.  So if you 
	    DELETE_KILL a screen with multiple windows, other windows
	    will be orphaned in the ordinary way.  I reserve the right
 	    to change this behavior (it will be documented)
	Caveat 2) If you cannot kill the window for other reasons, 
	    such as /window killable off, then the attempt to kill the
	    window will fail, and it will be orphaned.


*** News 05/09/2020 -- New built in function $execctl()
	You can now program the /EXEC command with this low level function

	--- warning ---
	Many of the things you can set here are not sanity checked.
	If you feed it garbage in, you will get garbage out.
	If you need safety rails, use the /EXEC command.
	--- warning ---

	Usage:
	------
	$execctl(REFNUMS)
		Get all refnums in the entire system (as integers)
	$execctl(REFNUM <description>)
		Convert a description (like %3 or %myproc) into a refnum integer

	$execctl(NEW <commands>)
		Create a new /exec process (does not run it!)
	$execctl(LAUNCH <refnum>)
		Run an /exec process that hasn't been started yet
	$execctl(CLOSEIN <refnum>)
		Close the STDIN to the process (this means you can't send any
		more data to the program.  This is useful for programs
		that wait until they've got an EOF from stdin to do their 
		thing)
	$execctl(CLOSEOUT <refnum>)
		Close the STDOUT and STDERR from the process (this means 
		we won't receive any more output from the program.  This is
		useful if we don't want any more output from the program.
		Many programs will die from SIGPIPE if stdout is closed)
	$execctl(SIGNAL <signal> <refnum>)
		KILL (send a signal) to a process.  The <signal> may either
		be an integer (like $execctl(SIGNAL 9 3) or it may
		be a short name (like $execctlSIGNAL HUP 3) to kill 
		process 3.

	$execctl(GET <refnum> [FIELD])
	$execctl(SET <refnum> [FIELD] [VALUE])
		You can GET all the fields of the object, and SET some of them.
		Some fields cannot be changed after the process is launched.

	Field		Set?	Notes
	-------------	------	-----------------------------------
	REFNUM		No	The integer refnum - never repeated.
	REFNUM_DESC	No	The "target" version (ie, %3)
	LOGICAL		Yes	The user-supplied name - must be unique
	LOGICAL_DESC	No	The "target" version (ie, %myproc)
				-- This will change if you SET LOGICAL
	COMMANDS	Yes	The commands to run (**)
	DIRECT		Yes	Whether to use a shell (**)
	REDIRECT	Yes	Either PRIVMSG or NOTICE
	WHO		Yes	The target to send output to
				-- Output from the process is redirected verbatim
	WINDOW_REFNUM	Yes	The window this exec runs in context of
				-- Undefined behavior if window does not exist
	SERVER_REFNUM	Yes	The server this exec runs in context of
				-- This is for redirects and code callbacks
	LINES_LIMIT	Yes	How many lines to receive before CLOSEOUT
				-- 0 means "no limit"
	STDOUTC		Yes	ircII code for every complete line of stdout
	STDOUTPC	Yes	ircII code for every partial line of stdout
	STDERRC		Yes	ircII code for every complete line of stderr
	STDERRPC	Yes	ircII code for every partial line of stderr

	PID		No	The process id of the process (after launch)
				-- This is -1 before launch
	STARTED_AT	No	When the process was created or launched
				-- It is first set when creation happens
				-- It is last set when launched
	P_STDIN		No	File descriptor to talk to process's STDIN
	P_STDOUT	No	File descriptor to read from process's STDOUT
	P_STDERR	No	File descriptor to read form process's STDERR
				-- There is nothing you can do with these.
				-- Don't try.
	LINES_RECVD	No	How many lines of output the process has sent
	LINES_SENT	No	How many lines we sent to the process
	EXITED		No	0 if process has exited yet -- 1 if it has
	TERMSIG		No	The signal that killed the process
				-- It is -1 if the process has not died
				-- It is -1 if the process exited normally
	RETCODE		No	The exit code of the process
				-- It is -1 if the process has not died
				-- It is -1 if the process was killed
	DUMB		No	Reserved for future/internal use
	DISOWNED	No	Reserved for future/internal use
	(Note: ** - Cannot be SET after launch)

*** News 05/08/2020 -- New flag to /EXEC, /EXEC -NOLAUNCH
	The /EXEC -NOLAUNCH flag directs the /EXEC command not to launch 
	a process that has not already launched.  You can launch it later 
	merely by referencing it with its name or refnum.

		/EXEC -nolaunch -name myproc ls -l
		/EXEC -nolaunch -limit 5 %myproc
		/EXEC %myproc

	Many /EXEC operations do not work on an unlaunched process.

*** News 05/07/2020 -- New function, $uuid4()
	This function returns a random UUID4 string.  If you know what that is,
	you might know why it's handy to be able to have one.

	ALL ARGUMENTS TO THIS FUNCTION ARE RESERVED FOR FUTURE EXPANSION.
	To get the default behavior, pass no arguments to this function.
	Forwards compatability is not guaranteed if you pass undefined args

*** News 05/07/2020 -- New /ON, /ON SEND_EXEC
	Whenever text is being sent to an /EXEC process, either through /EXEC -IN
	or /MSG %proc or a /QUERY or whatever, it is displayed to your screen.
	The /ON SEND_EXEC process will let you adorn how this text is displayed,
	instead of it just being displayed blankly as it has always done.

*** News 05/07/2020 -- The /EXEC command
	The /EXEC command has always been part of ircII, but it hasn't
	changed much during EPIC's lifetime.  There were some rough edges
	related to querying exec'd processes, things not always going
	to the windows people expected, some flags not being able to be
	used with other flags, etc.

	So the /EXEC command has been substantially revamped, with an intention
	of everything being "do what i expect".  If you find things that are 
	weirdly behaving, please let me know!

	Instead of describing the changes, let's just level-set the behavior:

	Every /EXEC command can create or modify one process

	[The most general explanation of the syntax]
	Modify an existing running exec:
		/EXEC [options] %refnum [extra arguments]
		/EXEC [options] %logical-name [extra arguments]

	Create a new exec:
		/EXEC [options] commands to run
		/EXEC [options] (commands to run) [extra-arguments]

	OPTIONS to /EXEC

	   [ Options related to sending data to/from the process ]
		-CLOSE
			Close the process's STDIN, STDOUT, and STDERR
		-CLOSEIN
			Close the process's STDIN
		-CLOSEOUT
			Close the process's STDOUT and STDERR
		-IN [extra arguments]
			Send data to a process

	   [ Options related to how the process integrates with ircII ]
		-NAME
			Change the logical name of a process
		-OUT
			Send all output from the process to the now-current 
			channel in the now-current window.
		-WINDOW
			Display all output from or related to the process to the 
			now-current window.
		-WINTARGET <windesc>
			Display all output from or related to the process to the 
			specified window
		-MSG [target]
			Send all output from the process to the target.
			The target can be an irc, dcc chat, or other exec,
			or anything you can send a message to.
			Messages sent over IRC are sent as PRIVMSGs
		-NOTICE
			Send all output from the process to the target.
			Messages sent over IRC are sent as NOTICEs.

	    [ Options related to scripting with processes ]
		-LINE {code}
			Run {code} for each full line of output from stdout of the process.
			$* will be the line of output
		-LINEPART {code}
			Run {code} for each incomplete line of output from stdout of the process.
			$* will be the incomplete line of output
		-ERROR {code}
			Run {code} for each full line of output from stderr of the process.
			$* will be the incomplete line of output
		-ERRORPART {code}
			Run {code} for each incomplete line of output from stderr of the process.
			$* will be the incomplete line of output
		-END {code}
			Run {code} when the process has completed.  This means when the process
			has exited and all of its output has been processed.  (Sometimes this 
			lags the actual exit)
				$0 is the logical process name or its refnum
				$1 is the signal that killed it (if it was killed)
				$2 is the exit code (if it exited)

	    [ Options that don't fit in the other categories ]
		-DIRECT
			Run the program directly -- do not use a shell.  
			Advantages:  The command you give is literally executed
			Disadvantages: If you depend on filename globbing or aliases, well, tough
		-LIMIT <number>
			Read <number> lines from the process and then -CLOSE it.

	    [ Options related to sending a signal to the process ]
		-<signal_number>
			Send the signal to the process, similar to kill -<signal_number> <pid>
		-<signal_name>
			Send the signal to the process, similar to kill -<signal_name> <pid>

	Additionally, %<procref> or %<procname> are full blown message targets that you can 
	/msg or /query or whatever you want, just like all other targets.

	[Examples of how this works]


*** News 04/26/2020 -- New python script, 'shortener'
	You can load this script with
		pyload shortener
	This script provides an in-client URL shortening service.
	Whenever someone provides a URL in a message, the service
	will create a short URL that will be served by an http
	redirection server that runs in client

	Example:
	--------
	<nick> hey, please visit www.frobnitz.com/really-long-and-wraps
        +onto-the-next-line-so-you-can-tpaste-it
	*** http://127.0.0.1:8080/1

	Then you can visit http://127.0.0.1:8080/1 and it will
	redirect you to the original url.

*** News 02/24/2019 -- EPIC5-2.1.1 (Abulia) was released here
	Even though not everything is done, I think I've probably
	dragged my feet long enough

*** News 11/28/2018 -- /EXEC -WINTARGET outsputs to a window by name (caf)
	The normal behavior of /EXEC is to send the output of a command
	to the current window (or is it the OTHER window?  I forget)
	Before this, you couldn't ordinarily send it to just any old
	random window you wanted.  

	You can use /EXEC -WINTARGET to send it to any window you want:
	Example:
		/exec -wintarget msgwin ls

*** News 02/05/2018 -- CTCP UTC now implemented as script
	Given the below feature, CTCP PING support has been 
	rewritten, and CTCP UTC is now scripted.

*** News 02/13/2018 -- New flag for $ctcpctl(), "REPLACE_ARGS"
	There are actually two kinds of CTCPs that replace things

	* CTCP PING replaces its argument(s), but is otherwise
	  handled "normally"
		NOTICE nick :\001PING <sec> <usec>\001
	  becomes
		NOTICE nick :\001PING <sec> seconds\001

	* CTCP UTC replaces itself entirely:
		PRIVMSG nick :\001UTC 1518582810\001
	  becomes
		PRIVMSG nick :Tue Feb 13 22:33:30 2018

	So it's not enough to say that "a CTCP handler can replace 
	itself by returning a string", you need to be able to say
	whether this CTCP replaces its arguments only, or whether
	it replaces itself entirely.

	  * $ctcpctl(SET <ctcp-name> REPLACE_ARGS 1)
	  * $ctcpctl(SET <ctcp-name> REPLACE_ARGS 0)
		Select whether or not a CTCP handler that returns a 
		string replaces its arguments (like CTCP PING) or 
		replaces itself entirely (like CTCP UTC).  
		The default is 0 (replace entirely)

*** News 02/05/2018 -- Some CTCPs are now implemented as scripts
	YOU NEED TO START DOING /LOAD ctcp  IN YOUR STARTUP SCRIPTS.

	One of the larger projects in EPIC5 was to move as many
	hard coded things into scripts as was feasible, so you,
	the user (or the script you're using) can have as complete
	control over them.  We've moved a lot of functionality out
	into scripts.

	Traditionally those users who don't have startup scripts 
	(~/.epicrc or ~/.ircrc) get /load global as their startup
	script.  One of the things /load global does is /load builtins
	which brings in the scripted features.  

	Now /load builtins will /load ctcp, which implements these 
	core CTCP functions entirely in ircII, so you are welcome 
	to modify or remove them, as _you_ choose.

		VERSION		PING		ECHO
		CLIENTINFO	USERINFO	ERRMSG
		FINGER		TIME

	Maybe more will be migrated in the future.  But this is a good
	start for now.  This is also a great example of how to 
	build your own first-class ctcp handlers!

*** News 02/04/2018 -- User-defined CTCP handlers with $ctcpctl()
	You can now create your own first-class user-defined CTCP handlers.

	A CTCP handler is a block of code that takes four arguments:
	  $0  - The person making the request
	  $1  - The target of the request (you, or a channel you're on)
	  $2  - The CTCP that was sent 
	  $3- - Arguments (if any) to the CTCP

	A CTCP request handler is a CTCP handler that handles incoming 	
	requests (over PRIVMSG).  A CTCP request handler can either 
	   (1) generate a response or 
	   (2) substitute something.  
	A response can be generated with:
	      /CTCP $0 $2 Your Response Here
	A substitute string is /return'ed by your handler, and replaces
	the CTCP in the original message.

	A CTCP response handler is a CTCP handler that handles incoming 
	responses (over NOTICE).  A CTCP request handler can either
	   (1) Output the response in a special way or
	   (2) substitute something
	CTCP response handlers are unusual, because the ordinary handling
	of CTCP responses is the expected behavior.

	Syntax:
	  * $ctcpctl(SET <ctcp-name> REQUEST {<code>})
		Register <code> as a CTCP handler for <ctcp-name> requests.

	  * $ctcpctl(SET <ctcp-name> RESPONSE {<code>})
		Register <code> as a CTCP handler for <ctcp-name> responses.
		(Note -- handling responses is unusual.  Normally you just
		 let the client output responses in the ordinary way)

	  * $ctcpctl(SET <ctcp-name> DESCRIPTION <string>)
		SET <string> as the CLIENTINFO for <ctcp-name>.  That is,
		when someone does /CTCP CLIENTINFO <ctcp-name>, <string> 
		will be returned as the description for this CTCP.

	  * $ctcpctl(SET <ctcp-name> SPECIAL 1)
	  * $ctcpctl(SET <ctcp-name> SPECIAL 0)
		Enable/Disable a CTCP as being "Special".  A "Special" CTCP
		is a remote function call, and handles everything itself.
		There are only two "special" CTCPs -- ACTION (/me) and DCC.
		I'm not sure if anyone will create a "special" user-defined CTCP

	   * $ctcpctl(SET <ctcp-name> RAW 1)
	   * $ctcpctl(SET <ctcp-name> RAW 0)
		Enable/Disable a CTCP has requiring the "raw data".
		Ordinary CTCPs transport strings, and they have to be recoded
		according to /encode-ing rules.  But some CTCPs transport 
		binary data, and so the handler needs access to the raw binary
		data.  Ordinarily, the raw/binary data is CTCP encoded, which
		mens you can pass it to $xform("-CTCP") to recover the raw
		bytes (although it might not be a C string, so you can't 
		assign it to a variable.)

	   There are corresponding GET operations for the above

	You can get all the registered CTCPs with
	   * $ctcpctl(ALL)

	Very soon, quite a few CTCP types will be migrated out to a script that
	will be /load'ed from /load global, and you may have to add it to your
	own start scripts if you do not /load global.

	I need to write much better examples for all this.  To look at this you'd
	scratch your head and wonder why you care.  But being able to add new 
	CTCPs instead of requiring them to be written in C in a new version of
	epic is expected to help a lot of people.


*** News 01/16/2018 -- New status expando %{1}P ("status prefix") and variables
	The %{1}P value will expand to a "when window current" or "when window
	not current" value.  The idea is to put this at the start of your 
	/set status_format or /window status_format type variables.

	When a window is current, %{1}P will expand to either
		/window status_prefix_when_current
	or
		/set status_prefix_when_current

	When a window is not current, %{1}P will expand to either
		/window status_prefix_when_not_current
	or
		/set status_prefix_when_not_current

	You can use this all in your ~/.epicrc, like so:
		set status_format %{1}P%T [%R] %*%=%@%N%#%S%{1}H%H%B%Q%A%C%+%I%O%M%F%L %D %U %W
		set status_prefix_when_current ^C37,40
		set status_prefix_when_not_current ^C37,44
	which will make your status bar white-on-black when current,
	and white-on-blue when not current.


EPIC5-2.0
EPIC5-1.8

*** News 01/30/2016 -- /WINDOW LOGFILE and /SET LOGFILE more like /LOG FILNAME
	Historically, changing a logfile name (with /WINDOW LOGFILE and
	/SET LOGFILE) does not affect the log status.  This leads to 
	unexpected behavior if you do /WINDOW LOG ON LOGFILE foo.txt
	because /WINDOW LOGFILE only changes the filename the *next* time
	you open the log, not affecting the currently open log.

	The behavior of /LOG FILENAME is more in line with what people 
	said they expected.  If you change /LOG FILENAME while the 
	log is ON, then it will 1) close the existing log, 2) change
	the filename, and 3) re-open the log under the new name.

	The behavior of /WINDOW LOGFILE and /SET LOGFILE have been changed
	to match the behavior of /LOG FILENAME -- changing the logfile name
	while it is open will close the existing log and open a new one.

EPIC5-1.6

*** News 01/08/2016 -- Per-server vhosts now restrict protocol (ipv4/ipv6)
	Historically, the client tries to connect to the server using the
	addresses as they are returned in order.  (This is a great thing 
	for round-robin or geographic-aware dns resolvers.)

	However, if you have a per-server vhost, you probably intend that
	epic use that vhost to connect to the server.  But what happens if
	your vhost is ipv4 only or ipv6 only, and the first address to the
	server is to the other protocol?  Historically, epic will just go 
	ahead and connect without your vhost.

	You've been able to correct this behavior by specifying explicitly
	the protocol family:
		/server irc.foo.com:proto=v6:vhost=irc.leet6.com
	Some folks said it violated POLA, so here's a new rule:

	"If you set a per-server vhost, then that server can only be 
	 connected to if the vhost can be used.  If ths means that no
	 addresses can be used, then you will not be able to connect 
	 to the server until you clear the vhost."

	This rule does not apply to you if you're using /HOSTNAME but
	only if you are doing something like 
		/server irc.foo.com:vhost=irc.leet6.com

*** News 01/01/2016 -- Can now /query an exec process that doesn't exist
	Previously, you were forbidden from setting up a /query to an 
	/EXEC process that didn't exist.  That set up a race condition
	between running an /EXEC process and being able to corral its 
	output into a window via the query.  

	So now you can /query an exec process before you start it.  

	If you try to send a message to it before you do fire it up, 
	the user will see a diagnostic telling them that the message 
	could not be sent to a non-existing exec process.

*** News 01/01/2016 -- New /window operation, /window log_mangle
	This allows you to overrule /SET MANGLE_LOGFILES for logs that
	you create with /WINDOW LOG ON (only!)
	Example:
		window logfile "my.windowlog" mangle NORMALIZE,COLOR log on

*** News 01/01/2016 -- New /window operation, /window log_rewrite
	This allows you to overrule /SET LOG_REWRITE for logs that
	you create with /WINDOW LOG ON (only!)
	Example:
		window logfile "my.windowlog" rewrite "HOOBOO $1-" log on

*** News 01/01/2016 -- Refinement to $pad(), $[len]var, and $leftpc()
	These functions do not behave graciously since our conversion
	to UTF-8, since they count code points rather than columns.
	It just seems sensible to redefine the behavior of these 
	functions based on columns, which is what everybody probably
	expects them to do.

	Function: $pad(len char string)
	Summary: Extend, but do not truncate, do not justify 'string'
	Definition: 
		Return 'string' so that it takes up at least 'len' columns.
		If it is too short, it will be padded with 'char's until
			it is 'len' columns wide.
		If it is too long, it is NOT truncated.

	Function: $leftpc(len string)
	Summary: Truncate, but do not extend, do not justify 'string'
	Definition:
		Return the first 'len' columns of 'string'.  
		If it is too short, it will NOT be padded.
		If it is too long, it will be truncated on the right end.

	Function: $[len]var
	Summary: Extend, truncate, and justify $var
	Definition:
		Return $var so that it takes up EXACTLY 'len' columns.
		If it is too short, it will be padded with /set pad_char
			until it is 'len' columns wide.
		If it is too long, it is truncated.
		If 'len' is > 0, then the string is left justified, and
			padding (or truncation) happens on the right end.
		If 'len' is < 0, then the string is right justified, and
			padding (or truncation) happens on the left end.

	Function: $fix_width(len justify pad string)
	Summary: Extend, truncate, and justify 'string'
	Definition:
		Return 'string' so it takes up EXACTLY 'len' columns.
		If it is too short, it will be padded with 'pad'
			until it is 'len' columns wide.
		If it is too long, it is truncated.
		If 'justify' is "l" then the string is left justified,
			and padding (or truncation) happens at the right
		If 'justify' is "c" then the string is centered, and 
			padding (or truncation) happens equally at both
			ends.
		If 'justify' is "r" then the string is right justified,
			and padding (or truncation) happens at the left.

*** News 09/15/2015 -- New /ON, /ON RAW_IRC_BYTES
	This new /ON, /ON RAW_IRC_BYTES is the same as /ON RAW_IRC, 
	except $* is the _raw unmodified bytes_ received from IRC.
	Specifically, $* is not guaranteed to be a UTF-8 string, so 
	functions that expect a UTF-8 string won't work.  You should
	not try to /ECHO the $* from this /ON.

	Just like /on raw_irc, if you catch this hook, you will 
	suppress normal handling of the event:
		/on ^raw_irc_bytes * {echo nothing further happens}

EPIC5-1.4

*** News 08/25/2015 -- Improved automargin support 
	You can now use automargins to get better wrapping of long urls.

	1. Use a terminal emulator that supports automargins
	   (they pretty much all do)
	2. Set your TERM env variable to something that supports automargins
		export TERM=vt102am        
	   should do the job
	3. Restart EPIC after you've updated the TERM.  It's not enough 
	   to just change the TERM and re-attach screen.  It's a good 
	   idea to check this when you're upgrading.
	4. /SET -CONTINUED_LINE	
		to get rid of the + thingee
	5. /SET FIRST_LINE >   
		or something if you don't use /set output_rewrite 
		to prefix every line
	6. /SET WORD_BREAK<space><space><enter>
		URLs contain commas and dots and semicolons, and you 
		don't want epic to word break on anything other than 
		a space.

	That should do it!  Your display will now use the final column
	on the display, and urls should be unmangled when you copy them

	If you "forget" to /SET -CONTINUED_LINE or /SET WORD_BREAK and want 
	to rebreak your windows in order to take advantage of this after 
	the fact, you can always just do /window rebreak_scrollback.  

	*** IMPORTANT! ***
	Note that you _must_ be running with a TERM supporting 
	automargins or this will not change things!

	You can check this by doing /eval echo $getcap(TERM enter_am_mode)
	If it returns blank, then your TERM does not support automargins.
	*** IMPORTANT! ***

*** News 08/25/2015 -- New /SET, /SET FIRST_LINE
	For those of you who use /SET OUTPUT_REWRITE to prefix every line
	of output with something (like a timestamp), you can ignore this.

	If you /SET FIRST_LINE, the string will be prefixed before every
	logical line of output.  This is great if you /SET -CONTINUED_LINE
	so you can continue to tell what lines are what.

EPIC5-1.2 
EPIC5-1.1.11

*** News 07/20/2015 -- New operation: @serverctl(SET refnum UMODE ...)
	You've never been able to SET your UMODE, becuase that never
	made much sense.  But it was pointed out that the UMODE is used
	when you reconnect to establish your initial usermode, and they
	wanted to be able to control that.

	So now, when the server is disconnected, you can change its umode,
	which will be used when you next connect.  Try something like this:
		on server_lost * {defer @serverctl(SET $0 UMODE i)}

*** News 07/09/2015 -- Don't do /redirect @W<refnum> <command>
	You can /msg @W4 <stuff> for example to do an /xecho -w 4 <stuff>.
	But you can't use this with /REDIRECT because the redirection 
	itself causes another redirect, and it just gets stuck in an 
	infinite loop.  The client can't protect you from doing this
	without a rewrite, so, don't do this. ;-)

*** News 07/09/2015 -- New flag to /ENCRYPT: /ENCRYPT -REMOVE
	It was confusing to remove /encrypt's before -- you had to specify
	all the arguments but not the password:
		/ENCRYPT hop -blowfish
	And if you had a PROG crypto, you couldn't remove it at all!
		/ENCRYPT hop password program...
	(How do you not specify the password in this case?)

	Anyways, there is now /ENCRYPT -REMOVE which lets you unambiguously
	remove an encrypt for a target
		/ENCRYPT -REMOVE hop

*** News 07/09/2015 -- Only one /ENCRYPT per target now.
	Traditionally, ircII has only had one cipher type for /ENCRYPT.
	EPIC added more cipher types along the way, and it was possible
	to set up multiple /ENCRYPT sessions for the same person.
	However, as I reflect upon this, this isn't a reasonable thing to
	do, because if you do
		/ENCRYPT hop -blowfish password1
		/ENCRYPT hop -aessha password2
	And then you /msg hop, which one should it use?

	So I've changed it so when you change the encryption type (such as
	in the 2nd line above), it will REPLACE the first one -- you will 
	only be able to have one cipher session per target.

	If this is a problem -- if I broke something for you, please let me
	know so we can address your needs.  

*** News 04/14/2015 -- New function, $chankey(servref #channel)
	The $chankey() function returns the channel for a specified channel.
	I created this because $key() doesn't allow you to specify
	'servref' but rather uses from_server, which means you have to
	wrap it in an /xeval -s to use a non-default server. ick.

	Arguments:
	 $0	- A server refnum
	 $1	- A channel name 

	Return Value:
	 empty string - Either 1.) 'servref' not provided, or 
			       2.) '#channel' not provided, or
			       3.) You're not on '#channel' on servref, or
			       4.) #channel doesn't have a key
	 anything else - The mode +k key for #channel on servref.

*** News 04/14/2015 -- SSL info available via $serverctl(GET refnum SSL*)
	You can now get information about live SSL connections:

	$serverctl(GET refnum SSL_CIPHER)
		The encryption being used, something like "DHE-RSA-AES256-SHA"

	$serverctl(GET refnum SSL_VERIFY_RESULT)
		0 if the certificate was verified successfully.
		Any other value if it did not.  
		These values match up to the verify(1) man page.
		Most notable, error code 20 means that OpenSSL could not find
		your local CA file (see /SET SSL_ROOT_CERTS_LOCATION below)

	$serverctl(GET refnum SSL_PEM)
		This is the PEM (base64) format of the server's certificate.
		You could save this to see if it's changed. ;-)

	$serverctl(GET refnum SSL_CERT_HASH)
		This is the SHA1 digest of the server's certificate.
		It is converted into a byte string like AB:CD:EF:01:02:...

	$serverctl(GET refnum SSL_PKEY_BITS)
		This is the number of bits that the server's certificate
		said that the server's public key uses.

	$serverctl(GET refnum SSL_SUBJECT)
		This is the hostname of the subject of the certificate.
		In theory, this is supposed to be the server's hostname.
		This could be a wildcard string.

	$serverctl(GET refnum SSL_SUBJECT_URL)
		This is the SSL_SUBJECT, but passed through URL encoding.
		It's useful because the SSL_SUBJECT will have spaces, and
		this results in just one word.  

	$serverctl(GET refnum SSL_ISSUER)
		This is the Certificate Authority (CA) that issued the 
		server's certificate.

	$serverctl(GET refnum SSL_ISSUER_URL)
		This is the SSL_ISSUER, but passed through URL encoding.
		It's useful because the SSL_ISSUER will have spaces, and
		this results in just one word.

	$serverctl(GET refnum SSL_VERSION)
		This is the version of SSL you're using.  
		It should either be TLSv1 (good) or SSLv3 (bad).

	With all of the above information, I hope someone scripts a nice
	SSL executive script that caches the certificate information, 
	tells you whether the connection should be trusted, decides whether
	the ssl version is ok, the public key bits are ok, all that stuff.

*** News 04/10/2015 -- New /TIMER argument, /TIMER -SNAP
	A "snappable" timer fires off at the "top of the interval".
	That means it runs every time ($time() % <interval> == 0)
	If you snap to 60, it will run at the top of every minute,
	just like mail checking, clock updating, etc.  If you snap 
	to 3600, it will run at the top of every hour.

	Example:
		/timer -snap -repeat -1 -refnum hourly 3600 {
			echo I run at the top of every hour
		}

*** News 04/10/2015 -- New script, /LOAD find_ssl_root_certs
	This script is loaded by /load global, and you should load it 
	too, if you're not using /load global; or you should implement
	a similar functionality to get /SET SSL_ROOT_CERTS_LOCATION pointing
	to the right place for you.  Otherwise, your SSL certificates
	won't authenticate, and $4 in /on ssl_server_cert will always 
	be 0, even if the cert is actually legitimate.  Or maybe all
	of what I just said doesn't matter to you.

*** News 04/10/2015 -- New /SET, /SET SSL_ROOT_CERTS_LOCATION
	In order for SSL to verify certificates, it needs to have a copy
	of the root certificate authorities.  This is usually a file
	named "ca.bundle" or "ca-root-nss.crt".  You need to /set this
	variable to wherever your openssl compatable root ca authority
	certificates are.  It would help if I understood what I'm talking
	about more.  Anyways, the script /load find_ssl_root_certs
	tries to help you with this.

*** News 04/10/2015 -- Enhancements to /ON SSL_SERVER_CERT
	Apparently I've never documented /on SSL_SERVER_CERT.
	
	The /ON SSL_SERVER_CERT hook is thrown every time a successful
	connection to an SSL server is made.  For now, the only SSL 
	connections are to IRC servers, but some day I hope to support
	DCC as well.  For now, this refers only to server connections.

	  $0 - File Descriptor (need a way to convert to server refnum)
	  $1 - The "subject" of the certificate  -- the server name
	  $2 - The "issuer" of the certificate
	  $3 - How many bits are used by the certificate's public key
	  $4 - Did the certificate validate?
		0 = pass, anything else = fail.
		(For now, this the result of X509_get_verify_result())
		(This depends on /SET SSL_ROOT_CERTS_LOCATION (above))
	  $5 - What SSL type are we using? (TLSv1 or SSLv3)
	  $6 - What is the digest of the SSL Certificate?

	The idea is you could use $1 to cache the metadata about a 
	server, and use $2, $3, $4, $5, and $6 to see if anything
	changes from one connection to the next.

	Probably more additions will come later.  I'm especially interested
	in passing in the complete plain text certificate +url'd up.

*** News 04/10/2015 -- More robust certificate verification for SSL
	Based on a paper written by Roca He, who is doing a research
	project on improper use of OpenSSL API by open source software,
	the OpenSSL code in epic was reviewed and enhanced.  One point
	of interest was certificate verification -- epic wasn't doing
	any of that.  But now it is.  This requires OpenSSL to know
	where your root/trusted certificate authorities are, and there
	are more notes above about how to handle that.  The results of
	this verification are reflected in /on ssl_server_cert above.

*** News 04/10/2015 -- You can now /encode to /EXEC processes 
	The /EXEC system is now UTF-8 aware, and you can use the 
	/encoding command to recode between %procs targets now. yay!

	Example:
		/encoding %nonutf8prog iso-8859-15
		/exec -name nonutf8prog myprog
		<output from 'myprog' treated as iso-8859-15, 
		 converted to utf8 for epic's use>

*** News 04/10/2015 -- New scripts: /load sasl_auth, userlist, tmux_away
	Zlonix wrote these scripts.  I need to write blurbs about each.
	Until that time, read the scripts, they're well documented!

*** News 07/24/2014 -- New feature $windowctl(REFNUMS_ON_SCREEN <winref>)
	The $windowctl(REFNUMS_ON_SCREEN <winref>) will return all of the
	refnums on the screen that contains window <winref>.  They are
	returned in SCREEN ORDER, ie, from top to bottom.  

	This was because someone wanted to make the bottom window ONLY 
	double status bar, so he needed to know which one was on bottom 
	and which ones weren't.

	If <winref> is a hidden window, then it will return all of the 
	invisible windows, but in no guaranteed order.

	If <winref> is 0, then it will return the screen for the current
	window, of course.

	You MUST specify a window refnum of some sort, even if it's just 0.

*** News 04/19/2014 -- Support for tmux for /WINDOW CREATE
	If you run EPIC under tmux, you can now use /window create and it
	will create new screens running under other tmux screens, just like
	it does for gnu screen.  There is also /set tmux_options, but I did
	not really test that.  What EPIC does is run this command:

	  tmux new-window "<wserv_path> <tmux_options> localhost [port]"

*** News 04/17/2014 -- /SET TRANSLATION now retired
	The /SET TRANSLATION feature which has served us well for many
	years is now superceded by /ENCODING, and has been retired.

EPIC5-1.1.10
EPIC5-1.1.9

*** News 04/16/2014 -- $fix_width() now fully works, and UTF-8 aware.
	The $fix_width() function takes the following arguments:
		cols      $0    Number of display columns
		justify   $1    Justification ("l" left, "c" center, "r" right)
		fillchar  $2    Fill character (can be utf8 cchar)
		text      $3-   
	This fully supports UTF-8, so the result is a string that will
	take up "cols" columns, even if "fillchar" takes multiple columns.


*** News 04/16/2014 -- Many functions are now UTF8 aware
	These functions are now fully UTF8 aware.  This means that 
	their unit of operation is a unicode character, and not a byte.

		after		before		center		chop		
		chrq		curpos		fix_width	index		
		indextoword	insert		left		maxlen
		mid		msar		pad		pass
		rest		reverse		right		rindex
		rsubstr		sar		split		strip
		strlen		substr		toupper		tolower
		tr		wordtoindex	

	These things are also UTF-8 aware:
		/XTYPE -L
		$[num]VAR		(pad/truncate $var to num places)
		/FEC

	Additionally, case sensitivity is UTF8 aware, for all languages,
	not just English. (at least as far as I tested)


*** News 04/11/2014 -- New function, $encodingctl()
	The $encodingctl() gives you a lower level interface to the 
	encoding system.  

	The behavior of $encodingctl() is ugly and I regret several of
	the decisions I've made already, but that's the way it goes...

	As with other $*ctl() functions, if there was not information in
	the argument list to decide what you wanted to do, it will return
	the empty string.

	- $encodingctl(REFNUMS)
	Return all recode rule refnums.

	- $encodingctl(MATCH servref sender receiver)
	Decide which recode rule would be used for a message sent by
		"sender" to 'receiver' over the server 'servref'.
	If you are the sender, use $servernick().
	Return value:
	 empty_string - an argument is missing, or servref is not an integer
	 anything else - the rule that would be used.

	- $encodingctl(GET refnum <OPERATION>)
	Get an attribute of a recode rule:
	  -> Returns empty string if <refnum> is not a valid recode rule
	  -> Returns empty string if no <operation> specified.

	  - $encodingctl(GET refnum TARGET)
	  Return the complete "target" part of the rule; this is whatever
	  you passed to the /encoding command.

	  - $encodingctl(GET refnum ENCODING)
	  Return the complete "encoding" part of the rule; this is whatever
	  you passed to the /encoding command.

	  - $encodingctl(GET refnum SERVER_PART)
	  Return the 'server part' of the target.  This is the part before
	  the slash, or the empty string if there is no server part.

	  - $encodingctl(GET refnum TARGET_PART)
	  Return the 'target part' of the target.  This is the part after
	  the slash, or the empty string if there is no target part.

	  - $encodingctl(GET refnum SERVER_PART_DESC)
	  This returns nothing for now.  Maybe someday it will return a
	  server description (ie, host:port:...)

	  - $encodingctl(GET refnum MAGIC)
	   1 if this rule is a "system rule" and cannot be deleted.
	   0 if this is a user rule, and can be deleted.

	  - $encodingctl(GET refnum SOURCE)
	   1 - Set at boot-up by using your locale (CODESET)
	   2 - Set at boot-up from hardcoded defaults
	   3 - Set by the user

	- $encodingctl(SET refnum <OPERATION>)
	Change an attribute of a recode rule
	  -> Returns empty string if <refnum> is not a valid recode rule.
	  -> Returns empty string if no <operation> specified.

	  - $encodingctl(SET refnum ENCODING new-encoding)
	    Empty String - New-encoding was not specified
	    0 - Changed: The new encoding was set successfully
	   -1 - Not changed: The new encoding does not exist on your system
	   -2 - Not changed: The new encoding does not convert to UTF-8
	   -3 - Changed: The new encoding PARTIALLY converts to UTF-8

	- $encodingctl(DELETE refnum)
	Delete a recoding rule:
	 Empty String - <refnum> was not a valid recode rule.
	 0 - <refnum> is a magic rule and may not be deleted
	 1 - <refnum> was successfully deleted.

	- $encodingctl(CHECK encoding)
	Determine whether or not <encoding> could be used in recoding rules:
	  Empty String - <encoding> was not specified.
