release_notes_2_1_1
Release Notes for EPIC5-2.1.1 (Released: 2019-02-24)
*** News 02/24/2019 -- EPIC5-2.1.1 released here (Abulia) (Commit id: 1899)
*** 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.
release_notes_2_1_1.txt · Last modified: 2021/09/22 02:40 by 127.0.0.1