Release Notes for EPIC5-2.1.4 (Released: 2021-03-26)

*** 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'

*** 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.