EPIC4-2.2

*** News -- 11/09/2004 -- Changes to way spaces are handled *** IMPORTANT ***
	Up until this point, the technical definition of what is a "space"
	(the term used for an Internal Field Separator (IFS), that is, the 
	thing that separates one word from another word)

	EPIC has always had three sets of IFSs
	1) Character 32 only ("space")
	2) Characters 9, 10, 11, 12, 13, and 32 ("my_isspace()")
	3) Whatever your locale says is a space ("isspace")

	In the C locale (the default for unix users), sets #2 and #3 are
	exactly the same.  I don't know about other locales.

	Now we are going to only use set #3.  Changing Set #2 to Set #3 is
	easy, and nobody should notice any difference there.  The one that
	is going to cause pain is Set #1.  Consider this situation:

		One<tab>Two

	Is this one word, or two words?  In some places in epic, it is one
	word, and in other places it is two words.  As a result of this
	change, it will now always be two words every place.

	Here is a list of the places that were using Set #1 that will change
	to use Set #3, and you should be on the lookout for changes!

	*) /AWAY separated the end of its flags with spaces.
	   This means 
		/AWAY -ALL<tab>Hi there!
	   will now work properly.
	*) $pop(....) removes the last word from the argument list.
	   Whereas $pop(one two<tab>three) used to return "two<tab>three"
	   is will now only return "three"
	*) Commands are separated from the argument list by a "space".
	   Whereas 
		/one<tab>two blah blah blah
	   parsed "one<tab>two" as the command, now "one" is the command
	   and "two" is part of the argument list.
	*) In expressions, a variable name may be separated from an
	   operator with a space.  Whereas things like
		@var<tab> =foo
	   might have failed because <tab> is not a valid character in 
	   a variable name, it will now treat <tab> the same as a space.
	*) Places that expect a number did not accept a string that contained
	   a <tab> so that things like
		<tab><tab>9
	   was not accepted as a number.  Now it will be.
	*) The /IGNORE command used to consider a string containing a <tab>
	   to not be empty.  This means that
		/IGNORE <tab>
	   would not list the ignorance list, but rather would try to show
	   the ban value for an ignore matching <tab> which isn't reasonable.
	*) The % wildcard pattern stopped matching only when it saw char 32.
	   Now it will stop whenever it seems a Set 3 type space.  
	   So whereas before "%" matched "one<tab>two" now it won't,
	   because "one<tab>two" is two words, not one word.
	*) In /xdebug extractw mode, tabs before or after double quotes were 
	   not considered to start or end a double quoted word.  So previously 
	   this string:
		one <tab>"two three" four
	   contained four words, because the <tab> before "two nullified
	   the double quoting.  Now that <tab> is treated like any other
	   space, the above word has three words, not four.

	Places that use Set 1 and will NOT be changing to Set 3, because 
	they are parsing IRC protocol data, which stipulates that the IFS
	MUST be a space solely:

	*) CTCP requests and replies are formatted only with spaces
	*) Words in protocol messages are separated only with spaces

*** News -- 11/09/2004 -- You may now mangle ALT_CHAR characters
	And ALT_CHAR mangling is included in ALL.  This was an oversight
	that was fixed in epic5.

*** News -- 11/02/2004 -- Mangling "ALL,-BOLD" no longer mangles "ALL_OFF"
	In general, if you use ANSI (ALL includes ANSI), the mangled string
	has its six attributes (COLOR, REVERSE, UNDERLINE, BOLD, BLINK, 
	ALT_CHAR) rewritten into canonical form.  This will add some ALL_OFFs
	to your string that weren't there originally.  So if you strip all of
	the attributes (as ALL does), then epic will strip ALL_OFF off as well.
	This retains backwards compatability with ALL.

	But if you use ANSI and don't want to strip all 6 of the attributes, 
	then it's important that ALL_OFFs are not removed, otherwise your 
	string will not appear as it should (the ANSInator uses ALL_OFFs to
	turn off attributes).  So EPIC automatically will not strip ALL_OFFs
	if you use ANSI and do not mangle one of the 6 attributes.

	Examples:
	  $stripcrap(ALL this is ^B^_bold underline^_ not bold)
	will strip everything as it has always done.

	  $stripcrap(ALL,-BOLD this is ^B^_bold underline^_^B not bold)
	will strip everything but not bold and all_offs, because if all_offs
	are stripped, then "not bold" will be in bold!

	The entire point of this is to allow /set mangle_logfile ALL to 
	work the way it has always worked, and $stripcrap(ALL,-BOLD ...)
	to work the way it *should* work.

*** News -- 10/06/2004 -- Support for +e and +I numerics from efnet
	EFNet has +e and +I channel modes, which act like +b does.
	These numerics are now handled by epic like +b is.

*** News -- 10/06/2004 -- New status bar expandos, %{2}W and %{3}W
	These two new expandos expand to the same value as %W.  

	%W    	Expands on each input window on each screen that has
		two or more visible windows.

	%{2}W	Expands on all visible windows on all screens.

	%{3}W	Expands on each input window on each screen, even on
		screens that have only one visible window.

*** News -- 10/06/2004 -- Support for ircnet's "numeric nick" feature
	On ircnet, each user is given a unique numeric identifier, which
	is their one true nickname.  In addition to this numeric id, they
	can have a rfc1459 nickname, but they are not required to have one.
	Further, the special numeric id 0 is reserved and refers to the
	user's own numeric id.  EPIC now fully supports all of this, 
	particularly in the following ways:

	/NICK <unique id>
	/NICK 0
		To turn off your rfc1459 nickname.

	$serverctl(GET <refnum> UNIQUE_ID)
	$serverctl(SET <refnum> UNIQUE_ID)
		To retrieve and change your unique nickname.  
		Changing your unique id is probably a bad idea.

	/USERHOST <unique id>
		You may USERHOST unique id's now.

	'epic 0'
		You may now use the nickname 0 on the epic command
		line if you don't want to use an rfc1459 nickname
		on an ircnet server.

	Using unique numeric id's on non-ircnet servers is probably 
	fraught with peril.  Try to avoid that.

*** News -- 10/06/2004 -- /SET INDENT maxes out at 1/3 screen width
	Previously, if you did /set indent on, and the width of the 
	first word on the first line was > 1/3 of the screen's width,
	then the second (and subsequent) lines were not indented at all.
	This was the historical ircII behavior.  It seems more sensible
	to cap the indent level at 1/3 of the screen's width and indent
	it to there.

# End of file
