EPIC5-3.0.3

*** News 2/27/2025 -- EPIC5-3.0.3 (2157 - Obturation) released here
	The third bugfix release for EPIC5-3.0

*** News 2/27/2025 -- ^X{#RRGGBB} support, $rgb()
	The $rgb() function outputs a ^X RGB code.  However, if it is
	immediately followed by a comma, such as:
		/echo $rgb(FF00FF),01 more text
	then the ",01" would be interpreted as part of the color code.
	To address this, ^X RGB codes can be surrouned by curly braces,
	which makes the syntax unambiguous.  This only works for RGB
	color codes, not for 256-color codes.

	The $rgb() function now uses this feature to fix the problem.

EPIC5-3.0.2

*** News 12/02/2024 -- EPIC5-3.0.2 (2154 - Peregrination) released here
	The second bugfix release for EPIC5-3.0

*** News 11/27/2024 -- Easier way to specify SSL server (port prefix)
	In a server desc, you have specified that a server does ssl 
	by using :type=irc-ssl: but that's a hassle.  Other clients 
	permit you to prefix the port with a + sign to indicate this,
	and so i figured, as long as i'm playing santa claus...
		/server irc.host.com:+6697

*** News 11/27/2024 -- Auto-detection of SSL servers [experimental]
	If you try to connect to an irc server's SSL port, it closes
	the socket without sending any data back.  The client now
	detects this, and if a non-ssl server closes the socket without
	sending any data back, the server's "type" will be unconditionally
	changed to "IRC-SSL" and then will try again.  I am 50% sure I am
	going to regret this, but carpe diem, i suppose.

*** News 11/26/2024 -- New flag, /EXEC -EXIT {code} (rb fusion)
	Although there is already /EXEC -END {code} and /WAIT -CMD to 
	run callbacks after a process ends, neither of those interact
	with /ON EXEC_EXIT or /SET NOTIFY_ON_TERMINATION.

	Fusion asked if there was a way to defeat the "process exited"
	message of /SET NOTIFY_ON_TERMINATION on an /exec-by-/exec 
	basis.  So the flag /EXEC -EXIT {...} was added.  I will admit
	that having two ways to run code seems confusing, so I will just
	say that this callback is run *instead of* /on exec_exit or 
	/set notify_on_termination handling.  So you should only use it
	to format messages about the process exiting.

	You can do  /exec -exit {#} ls   to (eg) suppress all that

*** News 11/26/2024 -- /AWAY restatement
	When you do /AWAY <message> you tell the client you are away.
	The client then tells the server you are /AWAY.  Later on, you
	do /AWAY and the client tells the server you are no longer away.

	But the notion of "am i away?" is a client-side thing, and it is
	triggered on whether you have set an away message, and not whether
	the server has acknowledged your away-ness.

	So $serverctl(GET x AWAY) returns your away message, and $isaway()
	is triggered based on whether you have an away message.  Fusion
	pointed out there was no way to know whether the server thought you
	were away or not, since the client has never tracked the 305/306
	numerics.

	So now the client tracks the 305/306 numerics which tell us whether
	the server thinks we're away or not.   This is available via
	$serverctl(GET x AWAY_STATUS)

	For backwards compatability reasons, _absolutely nothing_ that changes
	its behavior if you are "away" is changing here.  That continues to
	be controlled only on whether you have set an away message (or not)

*** News 09/05/2024 -- EPIC5-3.0 (2139 - Brigadoon) released here
	This is the third production release of EPIC5

*** News 08/23/2024 -- EPIC5-2.6 (2137 - Sedulous) released here
	This is the third release candidate for EPIC5-3.0

*** News 08/20/2024 -- EPIC5-2.4 (2136 - Sedulous) released here
	This is the second release candidate for EPIC5-3.0

*** News 08/18/2024 -- EPIC5-2.2 (2135 - Sedulous) released here
	This is the first release candidate for EPIC5-3.0

*** News 08/18/2024 -- /SET RANDOM_SOURCE now has no effect
	EPIC has traditionally had 4 random number generators:
	They have been replaced with just using OpenSSL's BYTES_random().
	Using /set random_source now has no effect.

*** News 08/18/2024 -- SOCKS support retired
	SOCKS4 and SOCKS5 support has been sunset.  It was 28 years old.

*** News 08/18/2024 -- Flood control support retired
	Flood control is a historical ircII feature that solved
	a problem we used to have with pre RFC1459 servers.
	Flood detection, as a concept, hasn't been relevant in
	30 years.  The /on flood and /set flood_* variables have
	been retired.

*** News 06/14/2024 -- EPIC5-2.1.13 (2125 - Sockdolager released here
	People like to see releases occasionally!

*** News 06/12/2024 -- I didn't document stuff for a long time
	You'll notice a lot of things documented on this date.  That's my fault.
	I've been making changes but not updating this file with the docs.
	These changes were not all made on this day, but in the past year. ;-) 
	I included the commit id in case that is useful.

*** News 06/12/2024 -- Restatement of $rgb() behavior  (commit 2123)
	Whatever it was I said about $rgb(), i take it back, now that proper
	RGB/24-bit color is now supported.  This is how it works now:

	$rgb() takes two, space-seperated colors -- a fg color, and bg color.
	A color can be one of these:
		- 		The color is omitted (it won't be changed)
		1,2,3		The color as three decimal numbers (0-255)
		1 2 3		The color as three space-separated decimal 
				numbers (0-255)
		#AABBCC		The color as a hash and 6 hex digits 

	The return value is a full properly formatted ^X code that you can 
	/echo or whatever to set the color.

	The fg and bg colors can be in any of the above formats, and you can
	mix and match them.

	If you pass it a syntax error, it will return an empty string.

	The JSON arguments are now:
		current:	r	g	b	attr
		added:		bg_r	bg_g	bg_b

	You can see some useful examples in the 'regress/color256' script.

*** News 06/12/2024 -- RGB/24 bit color support (rb everybody) (commit 2123)
	EPIC now supports RGB/24-bit colors natively.
	Specify a RGB color with ^X#, as in:
		^X#AABBCC		set the fg only
		^X#AABBCC,		you can use comma, bg is optional
		^X#AABBCC,DDEEFF	you can specify both at the same time
		^X#,DDEEFF		set the bg only (note the leading comma)
	EPIC will also parse ^[[28m and ^[[38m RGB codes and convert them to
	the above formats.

	EPIC no longer approximates RGB colors into the 256-color space.  
	RGB colors are output as RGB colors.  So your terminal emulator needs
	to support that, or you'll have a bad time.  Let me know if this is a
	problem for you.

	None of this supplants 256 colors, which are still supported exactly as 
	they have always been.  However, because every terminal emulator supports
	256 colors, and because colors 0-15 are the same between "basic" colors
	and 256 colors, "basic" colors map to 256 colors now.  Let me know if your
	terminal emulator doesn't support 256 colors!

*** News 06/12/2024 -- status sub-expandos now protect from expansion (2106,2123)
	Some status bar expandos use "sub-expandos".  The primary expando
	is controlled by (eg) /set status_mode, which is used by %+.
	Usually this is set to " +%+ ", so the sub-expando value (the
	channel's mode) is substituted in the %+.  But what happens if
	you have /set status_does_expandos on, and someone does something
	that causes your status bar to include rogue data?

	Example:
		/mode #chan +k $exec(rm -rf ~)
	You wouldn't want that expanded!  So all subexpandos now get 
	"quoted" so that doesn't happen.  

	The above is a bad example, because /set status_mode has always
	done this protection.  I was asked to extend this protection to
	every status subexpando.

*** News 06/12/2024 -- Add $hex(<digits> <number>) (commit 2114)
	Convert a decimal number into a hex number without fuss.
	Also ensures correct zero-padding.  Useful for converting
	decimal numbers to RGB portions!

	Example:
		$hex(255 2)	returns "FF"
		$hex(10 2)	returns "0A"
		$hex({"value": 10, "digits": 2}) 	returns "0A"

*** News 06/12/2024 -- Improvements to 'reconnect' script (commit 2112)
	The 'reconnect' script now supports these new /set's:
	  * /set auto_reconnect_delay_method [ON|OFF]
	  * /set auto_reconnect_join_delay <seconds>

	When /set auto_reconnect_delay_method OFF (default behavior)
	- All chnanels are rejoined at once as soon as you are connected.

	When /set auto_reconnect_delay_method ON 
	- Channels will be joined one-at-a-time, one-per-second,
	  starting after /set auto_reconnect_join_delay seconds, 

*** News 06/12/2024 -- Add /WINDOW LISTER "refnum [refnum]" (commit 2111)
	Given a double-quoted space-separated list of words, do what 
	/WINDOW LIST would do, but only for those windows.  This allows 
	you to sort the window listing order.

*** News 06/12/2024 -- Add $windowctl(GET x CURRENT_CHANNEL) (commit 2109)
	This tells you what the current channel is for a window.
	How did it take so long for me to add this?

*** News 06/12/2024 -- autoconf, make uninstall (commit 2106)
	EPIC's configure script now works with autoconf-2.71, and the
	Makefile now includes 'make uninstall' which does its best.

*** News 06/12/2024 -- /set blank_line_indicator (rb harzelien) (commit 2105)
	The default value of this is "unset" which is the historical behavior.
	Traditionally, a window starts off its life empty, and from time to 
	time parts of it might be empty (ie, after a clear).  If you want to see
	that a line is explicitly "missing" rather than blank, this set will be
	used for each blank line

	Example:
	  /set blank_line_indicator ~
	       makes missing lines ~, like vi does

*** News 06/12/2024 -- Add $symbolctl(GET <var> 0 BUILTIN_VARIABLE ORIG_DATA) (commit 2105)
	Builtin variables (ie, /SET) are initialized when the client starts.
	You can later change the value.  But if you want to reset the value
	to the "initial" value, you can fetch that value here.
	
	Example:
	  /set banner $symbolctl(GET banner 0 BUILTIN_VARIABLE ORIG_DATA)

*** News 07/17/2023 -- New /ON, /ON PING (rb skered)
       The /ON PING will be thrown when the server sends you a PING
       after you've been idle for some time.   Yes, you can suppress
       the default handling, which will probably result in you being
       disconnected.  Whatever floats your boat.

               $0    - The server that sent you the PING
               $1-   - The ping message itself.  
                       Do /QUOTE PONG $1- to respond

*** News 10/26/2022 -- Basic CAP support, /load capctl (zlonix)
	The /load capctl script, written by zlonix, provides
	the /CAPCTL command, which permits you to register CAPs
	that you wish the client to activate on your behave when
	you connect to a particular server.  

	Turning on arbitrary CAPs results in unspecified behavior
	(ie, if it breaks things, that's not a bug)
	Turning on 'account-tag' or 'multi-prefix' should be safe.

*** News 10/26/2022 -- New built in function, $tags() for CAP tags (zlonix)
	If you turn on the CAP 'account-tag', some servers (which 
	includes ZNC) will start sending you CAP tags, which you can 
	fetch with $tags().  How to parse and/or use them is left for
	future expansion.  Stay tuned.

*** News 10/26/2022 -- New server description field "cert" (client certs)
	Some servers support "client certificates" for their SSL connections.
	Client certificates are similar to server certificates -- they verify
	your identity to the server.  Some networks use this for authentication
	with servers.

	You create a *.pem cert, using the same instructions as for every other
	client, and then provide that file in the "cert" field:

		/server irc.network.com:6697:type=irc-ssl:\
			cert=/home/user/.certs/network.pem

	"cert" does not support tildes in filenames.  Use $realpath() for that.

*** News 08/11/2022 -- New concept to the /CLEAR command
	When you /CLEAR a window, it's empty, right?  But quite a few
	operations can result in a window getting bigger.  You can 
	/WINDOW GROW or /WINDOW CLEARLEVEL or you can resize the screen.
	Usually when everything in a window fits in the new size, but
	does not take up all of the room, EPIC has to decide what to do
	with the new space.  Does it redisplay info that was previously
	scrolled off? ("pinning the bottom")  Does it display blank lines
	at the bottom of the window? ("pinning the top").

	People disagree on this point, and that's part of why the 
	/WINDOW SCROLLADJ feature exists.  But it's clear that a second
	signal is important -- the /CLEAR command.

	Each time you /CLEAR (or /WINDOW CLEAR) it will set the window's
	"clear point".  When EPIC adjusts a window's scrollback to fill
	in blank lines, the top of the window can never go before the 
	"clear point", and so that's how it will decide whether you 
	want to redisplay old stuff, or keep blank lines on the bottom.

	The /UNCLEAR command unconditionally "pins the bottom", and for
	backwards compatability, it ignores the "clear point".  However, 
	if you want it to honor the clear point, use /UNCLEAR -NOFORCE

*** News 07/24/2022 -- New commands, /CTCP_CLOAK and /CTCP_UNCLOAK
	These are implemented by the /LOAD ctcp script, which is 
	part of the default experience

	"Cloaking" a CTCP means to treat a built-in CTCP as though
	it were not a built-in CTCP.
	   1. It will not show up in CTCP CLIENTINFO
	   2. Built-in handlers will NOT be called, but it will be
	      treated like any ordinary unrecognized CTCP 
	      (with /on ctcp_request and /on ctcp)

	Usage:
		/ctcp_cloak		List all cloaked CTCPs
		/ctcp_uncloak		List all uncloaked CTCPs
		/ctcp_cloak name	Cloak CTCP "name" 
		/ctcp_uncloak name	Uncloak CTCP "name"

	Zlonix wanted to do this:
		/ctcp_cloak FINGER

*** News 07/24/2022 -- $ctcpctl(SET x ACTIVE 0|1) and $ctcpctl([IN]ACTIVE)
	There are some new $ctcpctl() facilities:

	  $ctcpctl(SET x ACTIVE 0)	- Make a CTCP inactive (cloaked)
	  $ctcpctl(SET x ACTIVE 1)	- Make a CTCP active (uncloaked)
	  $ctcpctl(ACTIVE)		- Return all active CTCPs
	  $ctcpctl(INACTIVE)		- Return all inactive CTCPs

	All CTCPs start their life off as ACTIVE automatically.
	The user can then inactivate them later.
	These facilities are used for /ctcp_cloak and /ctcp_uncloak (above)

*** News 06/15/2022 -- EPIC5-2.1.12 (2078 - Secondment) released here
	This release improves build behavior for openbsd and others.

*** News 06/05/2022 -- EPIC5-2.1.11 (2071 - Adynaton) released here
	This release is entirely quality improvements, focused on 
	removing (rather than handling) type punning, and signed-
	pointer issues where c99 behaves differently from c90.

*** News 05/22/2022 -- EPIC5-2.1.10 (2059 - Casuistry) released here
	This release is entirely quality improvements now that we've 
	to C99 -- addressing undefined behavior, etc.

*** News 05/09/2022 -- EPIC5-2.1.9 (2053 - Decoupage) released here
*** News 05/09/2022 -- EPIC5-2.1.8 (2052 - Decoupage) released here
	I screwed up the release of 2.1.8 so I redid it as 2.1.9

*** News 05/09/2022 -- EPIC is now a C99 program
	As of this release, EPIC is now expected to be a well-defined C99
	program.  This release has eliminated all type punning/aliasing 
	shenanigans (or at least given the compiler fair warning about it)
	Type-punning pointer casts are done through unions, as C99 requires.
	Consequently, EPIC is now compiled with -O2, which I hope I don't come
	to regret.

*** News 05/02/2022 -- New $info() values, $info(Z:*)
	$info(Z:configure_args)		returns what you passed to 'configure'
	$info(Z:compiler_version)	returns "$CC -v" that was used
	$info(Z:final_link)		returns the command used to link epic5
	$info(Z:cflags)			returns the CFLAGS used during build
	$info(Z:libs)			returns the libs used during build
	$info(Z)			returns all the above in a json dict

*** News 04/10/2022 -- Window /LOGs now don't require logged window to exist
	There is a question -- do logs log _a particular window instance_
	or do they log _any window matching a descirption_?  Previously you
	could not /log add a window that didn't exist because the window 
	lookup failed.  

	Starting now, you can /log add any window you want even if the window
	does not exist -- you can /log add a refnum, a name, or a uuid, and
	any window that ends up using that refnum, name, or uuid, will log
	to the log; not just the window that existed when the log was created.

	On the flip side of this, if you are logging a window refnum and then
	you change a window's refnum, it might stop logging -- so if you want
	to log _a particular window_, log its uuid, for example:
		/log add $windowctl(GET 5 UUID)

*** News 04/08/2022 -- Restatement of /WINDOW QUERY
	The behavior of /WINDOW QUERY, /WINDOW ADD, and /WINDOW REMOVE 
	was unified some time ago, but the behavior was inconsistent
	and unclear.  So the code has been harmonized and now has the
	following behavior:

	/WINDOW QUERY nick
		Add 'nick' to target list and make current target (query)
	/WINDOW QUERY nick1,nick2
		Add 'nick1' and 'nick2' to target list and make the last
		target (nick2) the current target (query)
	/WINDOW QUERY
		Remove the current target (query) from the target list.
		If there are other targets in the target list, then the 
		previous query will become the new current target (query)
	/WINDOW -QUERY
		Remove all targets from the window's target list.
		There will be no query.

	/WINDOW ADD nick
		Add 'nick' to target list, but not as the current target
	/WINDOW REMOVE nick
		Remove 'nick' from the target list.  If you REMOVE the
		current target (query) then another target will become
		the new current target (query)

	Don't forget the SWITCH_QUERY keybinding, to cycle between the
	targets in a window.

*** News 04/06/2022 -- New functtions $pledge() and $unveil()
	These functions call the OpenBSD syscalls, if you're running on 
	OpenBSD.

	$PLEDGE()
	======================
	Simple Example:
		/@pledge(stdio rpath inet dns tty proc)
	Read the man page for more information.
	Returns:
		empty string - pledge(2) is not supported
		anything else - the return value of pledge(2)

	Complex examples:
		/@pledge({"test": true})
			Return 1 if $pledge() is supported, and 0 if not.

		/@pledge({"promises": "...", "execpromises": "..."})
			Pass these values to the 'promises' and 'execpromises'
			parameters of pledge(2)


	$UNVEIL()
	====================
	Simple Example:
		/@unveil(/path/to/directory r)
		/@unveil(/path/to/another/directory wc)
		/@unveil()
	Read the man page for more information
	Returns:
		empty string - unveil(2) is not supported
		anything else - the reteurn value of unveil(2)

	Complex examples:
		/@unveil({"test": true})
			Return 1 if $unveil() is supported, and 0 if not.

		/@unveil({"path": "/path/to/directory", "permissions": "r"})
		/@unveil({"path": "/path/to/another/directory", "permissions": "wc"})
		/@unveil({"close": true})
			Does the same thing as the simple example

*** News 04/04/2022 -- TCL support removed
	TCL support passed away quietly this afternoon.  It was 19 years old

*** News 04/04/2022 -- Install target de-cruftified
	EPIC has been doing lots of strange stuff when you 'make install'
	since its earliest days.  But in these modern worlds with silicon
	chips and whatnots, it makes little sense to compile our own version
	of test and ship a weird version of 'bsdinstall'.  Make install
	is now optimized for how package maintainers actually use it, so
	hopefully they'll not have to patch the heck out of epic to make 
	it behave like all the other programs

*** News 03/28/2022 -- New /SET, /SET AUTOMARGIN_OVERRIDE (default OFF)
	Previously, automargin support was conditionally built into 
	the client at compile time.  The default was to include it.
	The support is now always included.

	Traditionally, the use of the last column depended on whether the 
	client was convinced your terminal emulator safely supported it.
	At the request of skered, this /SET was added that allows you
	to force it, even if the client doesn't know how to safely turn
	it on.  Therefore, using this /SET may cause display corruption
	if the final column is used -- and this would not be considered
	a bug in the client.

	/SET AUTOMARGIN_OVERRIDE ON
		Try to use the final column, even if you aren't sure if
		it can be done safely -- (at your own risk -- if you have
		screen corruption, this is "normal")
	/SET AUTOMARGIN_OVERRIDE OFF
		Use (or don't use) the final column based on whether the
		client is sure (or isn't sure) if it's safe.

*** News 03/27/2022 -- EPIC5-2.1.7 (2011 - Cinereous) released here

*** News 03/21/2022 -- New built in function $rgb()
	There are three ways to call the $rgb() function:
	   1. As three numbers
		$rgb(255 0 255)
	   2. As a string
		$rgb(#FF00FF)
	   3. As kwargs
		$rgb({"r":255, "g":0, "b":255, "attr":true})

	This will return a string that will change to the indicated color.
	(ie, it is of the form ^Xab, where "ab" are two hex digits)
	The kwarg version is the only way to prevent prefixing with ^X
	(ie, to get the color number).   The 'attr' flag is optional.

*** News 03/06/2022 -- New serverctl(DONT_CONNECT), sets the -s CLI
	The -s command line option ("dont connect to a server") can now
	be set by your ~/.epicrc with 
		@serverctl(DONT_CONNECT 1)
	Obviously this only matters at client startup.  Setting it at
	any other time is pointless

*** News 03/06/2022 -- New math operator: "??" -- Coalesce
	The coalesce operator is a binary operator that returns the left
	value if the left value is true-y, otherwise returns the right
	value.  Therefore, "x ?? y" is shorthand for "x ? x : y"
	The operator precedence is the same as "||".

*** News 03/06/2022 -- New /set BROKEN_AIXTERM
	Some terminal emulators are silly and don't/can't/won't support
	bold and color at the same time, instead insisting that you send
	proprietary/non-standard ansi codes that were pioneered by a
	vendor that also couldn't get its terminal emulator to properly
	emulate real terminals.

	If you are using such an emulator, you can /set broken_aixterm
	and bold colors will send aixterm codes instead of standard codes.

*** News 02/06/2022 -- What is $serverctl(GET x OPEN)?
	Zlonix asked me to document "what does OPEN mean for a server?"

	A server is "open" when it has a file descriptor open.  
	This is entirely different from whether it is connected to IRC.
	(for that, use $serverctl(GET x CONNECTED))

	When a server is "open" then it is under the active management
	of the client.  When a server is "closed" then the client has 
	stopped paying attention to it and nothing further will happen
	with it until the user (or script) does something.

	During the course of a connection, several *different*
	file descriptors get used by a server as it goes through the
	server states:

	Server State	Is "Open"?	What is fd used for?
	-------------	-------------	----------------------------
	CREATED		No
	RECONNECT	No
	DNS		Yes*		DNS helper subprocess
	CONNECTING	Yes*		socket that is not yet connect()ed
	SSL_CONNECTING	Yes*		connected socket not yet ssl'd
	REGISTERING	Yes		socket that is trying to get on irc
	SYNCING		Yes		socket that is on irc
	ACTIVE		Yes		socket that is on irc
	EOF		Yes*		socket that has seen an end-of-file
	ERROR		Yes*		socket that has fatal error
	CLOSING		Yes*		socket that is shutting down
	CLOSED		No		
	DELETED		No		

	* - Just because a server is "open" does not mean that it is useful
	    for IRC purposes.  It only means that the fd has not yet been
	    closed at the OS level.  These states still have an 'fd that 
	    has not been close(2)d', but don't represent useful states

*** News 02/05/2022 -- New $serverctl(GET x NEXT_SERVER_IN_GROUP)
	This will return the server that /server + will connect to

*** News 11/11/2021 -- $json_implode() takes kwargs, adds "compact mode"
	The standard behavior of $json_implode() is to take a single word 
	as an argument, the root of a assign tree to convert into a json 
	object.
		$json_implode(q)	# Collapse $q.* into json object

	The standard behavior of $json_implode() is to return a "human-
	formatted" string, with newlines and indentation.  This is nice 
	for looking at, but isn't appropriate for every situation.

	So $json_implode() is our pilot test for json object argument lists.
	It now supports the following two arguments:
		root	  string    The root of the assign tree (required)
		compact	  boolean   false - return human readable (default)
				    true - return one line

	Example:
		@ q.one = [val1]
		@ q.two = [val2]
	then,
		$json_implode({"root": "q", "compact": true})
	would return
		{"one":"val1","two","val2"}

	
*** News 11/18/2021 -- New concept -- json object as argument list ("kwargs")
	You'll start noticing something new happening more and more.
	The idea of "json object as an argument list" is being introduced,
	to allow passing of parameters in a more deterministic way.

	JSON objects (also known as "dicts") are a collection of key-value pairs.
		{ "field1", "val1", "field2", "val2"}
	You already operate on these with $json_implode() and $json_explode().
	Most RESTful APIs in the world send and receive them.  

	For backwards compatability reasons, of course, this feature will be
	rolled out on a case-by-case basis whenever it seems appropriate.
	But, occasionally, a new feature might be available only through json
	object arguments because it makes sense.

*** News 10/06/2021 -- EPIC5-2.1.6 (1981 - Impignorate) released Here

*** News 09/21/2021 -- Another round of clang static analysis
	Somewhere around here we did another round of static analysis
	with clang's analyzer, and fixed whatever it recommended.

*** News 09/19/2021 -- "reconnect" script has been reimplemented
	The reconnect script has been renamed to "reconnect.orig".
	If you want the original behavior, just /load reconnect.orig
	The new script is based on improvements we've made in epic5
	to make reconnection logic more reliable and dependable.

*** News 09/11/2021 -- New option,  $serverctl(GET x PADDR)
	The $serverctl(GET x PADDR) returns the server's presentation
	address.  This is "1.2.3.4" for ipv4, or "2600::1" for ipv6.
	This represents the IP address we're connected to.

*** News 09/11/2021 -- New /window operation, /WINDOW CLEARREGEX <regex>
	This was requested by Zlonix.

	The /WINDOW CLEARREGEX <regex> operation removes all items from
	the window's lastlog whose text (what you see on the screen) 
	matches the <regex>.  Removing them from the lastlog removes
	them from the scrollback and your screen as well.  This is useful
	for making conversations with annoying bots go away retroactively.
	Example:	/window clearregex annoybot

*** News 09/11/2021 -- New /ON, /ON RECONNECT_REQUIRED 
	The /ON RECONNECT_REQUIRED hook is thrown by the client when it
	feels that a reconnection intervention is appropriate.  
	We are going to start this small, and build in more use cases
	as we go forward.

	  1. When server is in ACTIVE state and the socket dies
	  2. When a write to the server fails

	In these situations, your script should take whatever measures
	are necessary to save the state of windows, channels, etc,
	in preparation for the upcoming disconnection.

	This /ON is thrown while the server is in a state of chaos.
	The internal state of the system is wrong, and you must assume
	that the connection to the server has already been lost.  

	YOU MUST _*_*_NOT_*_*_ try to do anything clever in this /on.
	If you have this idea of moving windows or servers or channels,
	please don't!  I recommend setting up /timer's and /defer's so
	you can do those sorts of changes away from the blast radius.

	YOU MUST _*_*_NEVER_*_*_ attempt to do any direct intervention
	in this /on -- instead, you should save information and create 
	a timer to deal with the problem later.  YOU HAVE BEEN WARNED.

	/ON RECONNECT_REQUIRED currently provides this information
		$0 	The server that unexpected failed on us.
			Reconnection will be required.  Remember,
			you cannot do reconnection in the /on, you
			have to schedule it to happen "later"

*** News 09/08/2021 -- New /window operation, /WINDOW CLEARLEVEL [levels]
	This was requested by Zlonix.

	The /WINDOW CLEARLEVEL [levels] operation removes all items from
	the window's lastlog of the levels you specify.  Removing them
	from your lastlog removes them from your screen as well.  This is
	useful for making noise go away retroactively
	Example:	/window clearlevel joins,parts,quits,kicks

*** News 09/08/2021 -- New statement type: block-with-arglist
	The ircII syntax now supports a new statement type, which I'm 
	calling a "block with arglist"

		(arglist) {block}

	You could also think of this as an "inline anonymous function".
	For the purposes of the statement, $* is modified by (arglist)
	and then {block} is run.

	Please note there are several caveats to this:
	  1. Arglist is not magic, it is syntactic sugar.  So it creates real 
	     local variables, and those local variables have their ordinary 
	     scope.  So they will persist after the end of the statement.
	  2. The statement only modifies $* during the statement itself.
	     So after {block} is run, $* goes back to what it was originally.
	  3. Note that this is a *statement* and not a *block* so if you are
	     working with something that expects a block, wrap it in {}s to
	     create a block.
		if (# == 3) {(arg0, arg1, arg2) {... code ...}}
	  4. Arglist processing isn't "free" so doing it in a tight loop will
	     be slower than doing it outside of the loop

*** News 09/07/2021 -- Pass window refnum in /ON CHANNEL_LOST
	The /ON CHANNEL_LOST hook now provides the window that a channel
	was in as $2
		$0 - The server refnum of a channel
		$1 - The name of a channel
		$2 - The window refnum of a channel

*** News 09/06/2021 -- Functions for JSON document handling
	Some time ago some new functions appeared for handling
	JSON documents, but they were not documented.  So now
	I am going to document them!

	CONVERTING JSON DOCS TO /ASSIGNS
	--------------------------------
	Syntax:    $json_explode(varbase json-document)

	An example is worth a thousand words:

	    $json_explode(e {"one": 1, "two": { "sub1", "hi", "sub2", "bye" })
	will result in three new assigns
		$e[one]		-> 1
		$e[two][sub1]	-> hi
		$e[two][sub2]	-> bye

	CONVERTING ASSIGNS TO JSON DOCS
	-------------------------------
	Syntax:	   $json_implode(varbase)

	This converts everything under $varbase[*] into a JSON doc.

	HANDLING ERRORS
	--------------
	If there is an error, $json_error() will tell you about it.

*** News 09/06/2021 -- SSL handling improvements (take 2)
	The other day I posted some info on how the SSL handling has been 
	improved.  But then things got revamped again, so I delete the old 
	info and am replacing it with this info.

	1) Step one - You connect to an SSL server
	 You connect to an irc server doing something like
		/SERVER irc.example.com:6697:type=irc-ssl
	 This goes through connect()ing to the server, and then doing an 
	 SSL_connect() to set up the certificate exchange and TLS negotiation.

	2) Step two - The SSL handshake is completed
	 After the SSL_connect() step has completed, we now have a fully 
	 functioning TLS socket with an SSL certificate.  Before we use the 
	 TLS socket, we're supposed to verify we trust the SSL certificate, 
	 to ensure we're talking to who we think we are.

	3) Step three - The client watches the certificate verification
	 OpenSSL "verifies" the certificate and the client provides
	 a C function to tag along for the ride.  The callback function
	 is called every time:
	   (1) An error is discovered, or
	   (2) There are no (further) errors in a certificate.
	 Thus, if a certificate is trusted, it will only report 
	 "no problems" for each link in the chain.

	 This permits the client to trap and categorize every error that
	 happens - some certificates have multiple problems!  There are
	 three buckets the client uses:
		(1) Self-signed certificates
		(2) Incorrect-hostname certificates
		(3) Any other (serious) error
	 The client tracks the "most serious error" (if there is one),
	 using the above priorities.

	4) Step four - The cliet offers you /ON SSL_SERVER_CERT
	  The client sets $serverctl(SET <refnum> SSL_ACCEPT_CERT -1)
	  and then throws /ON SSL_SERVER_CERT.   The use of -1 is on
	  purpose so the client can determine whether your /ON handler
	  sets it to 0 or 1.  

	  If your handler does a $serverctl(SET <retval> SSL_ACCEPT_CERT 0|1)
	  then that is taken as the final disposition of the handling, and 
	  nothing further occurs. (ie, it skips the rest of the steps)

	  Parameters of /ON SSL_SERVER_CERT
		$0  The fd of the socket
		    (Use $serverctl(FROM_SERVER) to get the server refnum)
		$1  Certificate Subject, url-encoded
		$2  Certificate Issuer, url-encoded
		$3  Bits used in the public key 
		$4  OpenSSL error code of the "most serious error"
			(18 is "Self-signed certificate",
			 62 is "Hostname mismatch",
			 everything else is irregular/bad)
		$5  The SSL regime being used (ie, TLSv1.2)
		$6  The Certificate Hash
		$7  Was there a hostname mismatch?  0 = no error, 1 = error
		$8  Was there a self-signed error?  0 = no error, 1 = error
		$9  Was there another (serious) error?  
			0 = no other error 1 = other error
		$10 Was there any error of any kind?  
			0 = no errors of any kind, 1 = some kind of error

	5) Step five - The client makes a provisional decision
	  Next, the client looks at the errors and decides whether
	  it thinks the cert is ok.  
	    * Cert has no errors 		   -> ACCEPT
	    * Cert has "self signed" or "wrong hostname" error
	      and /SET ACCEPT_INVALID_SSL_CERT ON  -> ACCEPT
	    * Cert has "self signed" or "wrong hostname" error
	      and /SET ACCEPT_INVALID_SSL_CERT OFF -> REJECT
	    * Cert has any serious error	   -> REJECT
	  The client sets this provisional value with 
		$serverctl(SET <refnum> SSL_ACCEPT_CERT 0|1)

	6) Step six - The client offers you /ON SERVER_SSL_EVAL
	  Then, the client hooks /ON SERVER_SSL_EVAL.  At this point,
	  all of the information your script needs to make a fully 
	  informed decision to accept or overrule the client's choice
	  is available.  Your handler is not obligated to make any
	  change, but it certainly can if it wants to 

	  Parameters of /ON SERVER_SSL_EVAL
		$0  The server refnum
		$1  The "ourname" of the server (what you /server'd to)
		$2  Was there any error at all? 
			0 = no errors of any kind   1 = some kind of error
		$3  Was there a hostname mismatch?  0 = no error, 1 = error
		$4  Was there a self-signed error?  0 = no error, 1 = error
		$5  Was there another (serious) error?
			0 = no other error, 1 = other error
		$6  What does the client suggest?
			0 = reject certificate, 1 = accept certificate

	  Using $serverctl() to get info about the certificate
	  Use $serverctl(GET <refnum> <item>) where <item> is:
		SSL_CIPHER		The encryption cipher being used
		SSL_PEM			The certificate (in PEM format)
		SSL_CERT_HASH		The certificate's hash
		SSL_PKEY_BITS		The bits in the public key
		SSL_SUBJECT		Who the cert was issued to
		SSL_SUBJECT_URL		Who the cert was issued to (url-encoded)
		SSL_ISSUER		Who issued the cert
		SSL_ISSUER_URL		Who issued the cert (url-encoded)
		SSL_VERSION		What version of SSL being used (ie, TLSv1.2)
		SSL_SANS		Subject Alternate Names in the cert
		SSL_CHECKHOST_ERROR	Hostname Mismatch error - 0 (no) 1 (yes)
		SSL_SELF_SIGNED_ERROR	Self-signed error - 0 (no) 1 (yes)
		SSL_OTHER_ERROR	        Any other (serious) error - 0 (no) 1 (yes)
		SSL_MOST_SERIOUS_ERROR	The OpenSSL error code of the most serious error
					18 (self-signed) and 62 (hostname mismatch)
					are considered non-serious (routine) errors
		SSL_VERIFY_ERROR	Any error at all - 0 (no) 1 (yes)
		SSL_ACCEPT_CERT		Is this cert headed for acceptance?  0 (no) 1 (yes)

	   Use $serverctl(SET <refnum> SSL_ACCEPT_CERT 0) to reject the cert
	   Use $serverctl(SET <refnum> SSL_ACCEPT_CERT 1) to accept the cert
	   If you don't do anything, the client will do the most reasonable thing

	7) Step seven - The client moves forward
	  Finally, everyone has had a chance to weigh in.  
	  Whatever the value of $serverctl(GET <refnum> SSL_ACCEPT_CERT) 
	  is after all this, is used to accept or reject the SSL connection.

*** News 09/02/2021 -- Configuring SSL Ciphers
	Now, if you know what you are doing, you can set
	the SSL Ciphersuites that the client will use for
	SSL connections, via
		/SET SSL_CIPHERS <stuff>
	If you don't know what you're doing, don't touch.
	The default value is "unset", which means we let
	openssl choose the ciphers for us.

*** News 09/02/2021 -- SSL Handling improvements
	[replaced -- see above]

*** News 08/30/2021 -- New server description field "ssl-strict"
	[this feature was removed]

*** News 05/29/2021 -- EPIC5-2.1.5 released here (Fecund) (Commit id: 1945)

*** News 05/25/2021 -- Updated configure to autoconf-2.69
	We upgraded configure from autoconf-2.13 to 2.69 here.
	Along the way, we fixed the support for python3.8+

*** News 05/20/2021 -- Windows have UUIDs ($windowctl(GET x UUID))
	Every window now receives an immutable UUID when it is 
	created.  This UUID is globally unique and cannot be changed.

	Although the UUID is not user-facing (as in /window list),
	you can get it with $windowctl(GET refnum UUID).

	The UUID is an lval (that is, it does not contain hyphens),
	so you can use it as part of a variable name if you wish.

*** News 05/20/2021 -- New concept, "claiming channels"
	When EPIC receives a protocol JOIN message for a channel, 
	it has to decide what window to put the channel in.  
	A common request has been the opportunity to let scripts 
	decide where new channels should go, rather than it being 
	hardcoded.

	So now when a JOIN is received, an /ON will be thrown 
	(see below) which is an invitiation for your script to do
	whatever preparatory work for the channel you see fit.

	One thing in particular is /WINDOW CLAIM (see below), which
	tells EPIC which window the channel should be put into.
	As part of this process, EPIC will suggest a window the 
	channel should go into, unless you choose to overrule that.

	*** NONE OF THIS APPLIES TO /JOIN or /WINDOW CHANNEL
	    when the user is deliberately moving a channel they are
	    already on between windows.  You can't stop that.

*** News 05/20/2021 -- New /ON, /ON CHANNEL_CLAIM 
	The /ON CHANNEL_CLAIM is thrown when a JOIN is received,
	but before the client has assigned the channel to a window.
		$0 - The server refnum 
		$1 - The channel being joined
		$2 - The window refnum epic proposes to put the
		     window into.

	If your handler does /WINDOW CLAIM in any particular window,
	then the channel will go to that window that you specify.

	At this time, you can only do /WINDOW CLAIM in a window that
	is connected to the server in $0. In the future, this will
	probably change.  But for now, a /WINDOW BIND in a "window
	connected to the wrong server" is treated as invalid.

	If you do not do a valid /WINDOW CLAIM, then the channel will
	go into the window proposed by EPIC.

*** News 05/20/2021 -- New /WINDOW operation. /WINDOW CLAIM #channel
	During the handling of an /ON CHANNEL_CLAIM, you may perform
	the /WINDOW CLAIM operation to direct EPIC to put the new
	channel into a particular window.

	You must pass the name of the channel as a paraemter.
	It is available as $1 in the /on.

	You may only claim the channel in a window that is connected
	to the correct server (from $0).  Attempting to claim a 
	channel in a window connected to the wrong server is invalid
	and has no effect.   This will change in the future.

*** News 05/20/2021 -- $uuid4() can now return lvals (NODASHES)
	You can now get a uuid4 that is valid as an lval if you
	supply NODASHES as the only argument
		@ a.$uuid4(NODASHES) = [whatever]

	ALL ARGUMENTS TO THIS FUNCTION ARE RESERVED FOR FUTURE EXPANSION.
	There are now two defined behaviors:
		$uuid4()	 - UUID4 with dashes
		$uuid4(NODASHES) - UUID4 without dashes
	EVERYTHING ELSE IS UNDEFINED BEHAVIOR (ie, other arguments may 
	do something today, but forwards compatability is not guaranteed)

*** News 03/26/2021 -- EPIC5-2.1.4 released here (Redound) (Commit id: 1927)

*** 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()
	Harzilein 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'
