Dokumentation zu: terminal_colour(E)

HR Image

        varargs string terminal_colour(string str, null|mapping|closure map,
                                       int wrap, int indent)

        If <map> is given as a non-0 value, this efun expands all
        colour-defines of the form "%^KEY%^" (see below for details) from the
        input-string and replaces them by the apropriate values found
        for the color-key specified by <map>.

        If <map> is a mapping, the entries queries have the
        format "KEY" : "value", non-string contents are ignored with one
        exception: if the mapping contains an entry 0:value, it is used
        for all otherwise unrecognized keys. The value in this case can be
        a string, or a closure. If it is a closure, it takes the key as
        argument and has to return the replacement string.

        If <map> is given as a closure, it is called with the KEYs to
        replace, and has to return the replacement string.

        The special keys "%^%^" and "%%^^" are always replaced with the
        literal "%^".

        The parameters wrap and indent are both optional, if only wrap is
        given then the str will be linewrapped at the column given with
        wrap. If indent is given too, then all wrapped lines will be
        indented with the number of blanks specified with indent.

        The wrapper itself ignores the length of the color macros and that
        what they contain, it wraps the string based on the length of the
        other chars inside. Therefore it is color-aware.

        If <map> is given as 0, the efun does no colour-define detection
        and replacement at all, but still does linewrapping and indentation
        if requested. This way terminal_colour() doubles as a simple
        line wrapping function, duplicating the functionality also
        provided by sprintf("%-=s").


        As mentioned above, the special keys "%^%^" and "%%^^" are always
        replaced with the literal "%^" and play no role in the following

        The input string is supposed to follow this syntax:

          text { '%^' colorkey '%^' text } [ '%^' colorkey ]

        or in words: the efun splits up the string at every '%^' it finds
        and then treats every second substring as color key.

        Note that this is different from the way MudOS treats the
        input string. MudOS uses this syntax:

          key_or_text { '%^' key_or_text }

        or in words: the MudOS efun splits the string at every '%^' and
        then tries to treat every substring as color key. One can achieve
        the MudOS behaviour with this LPC function:

          string mudos_terminal_colour(string str, mapping ext, int w, int i) {
            return terminal_colour("%^"+implode(explode(str, "%^")-({""})
                                  , ext, w, i);

        mapping trans;
        string str;

        trans = ([ "GREEN" : "ansi-green", "RED" : "", "BLUE" : 1 ]);

        str = terminal_colour( "%^GREEN%^ and %^RED%^ and %^BLUE%^", trans );

        This will result in str == "ansi-green and  and BLUE"

        %^GREEN%^ is expanded to ansi-green because trans defines that,
        %^RED%^ is stripped because trans defines that as "" and
        %^BLUE%^ gets the %^'s removed because the contents of trans are
        not valid (i.e. no string). The same would happen to %^DEFINES%^
        where the key is not found inside the trans mapping.

        Caveat: to replace adjacent keys, use the efun like this:

            str = terminal_colour( "%^GREEN%^%^RED%^", trans );

        A command like

            str = terminal_colour( "%^GREEN%^RED%^", trans );

        will return the logical but sometimes unexpected "ansi-greenRED".

        Some words about wrapping:

        a string wrapped without indent would look like this:

            "this is the first line\nand this is the second line"

        a string wrapped with indent 3 would look like:

            "this is the first line\n   and this is the indented second one"

        Efun idea and initial implementation taken from MudOS; the key
        recognition strategy (including pure wrapping mode) was straightened
        out in LDMud 3.2.8.
        LDMud 3.2.9/3.3.58 added the use of closures to specify the colour
        LDMud 3.2.9/3.3.102 officialized the "%%^^" replacement pattern for
        better MudOS compatibility.


Die Seite ist auch in Deutsch vorhanden.

Start » Magierhandbuch » Docu » Efun » Terminal_colour Letzte Generierung: 25.04.2021, 01:58
Email an:
Valid HTML 4.01!