Site Tools

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
                NOTICE nick :\001PING <sec> seconds\001

        * CTCP UTC replaces itself entirely:
                PRIVMSG nick :\001UTC 1518582810\001
                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

        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.

          * $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
                /set status_prefix_when_current

        When a window is not current, %{1}P will expand to either
                /window status_prefix_when_not_current
                /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