Re: Something wrong with prompt themes

Re: Something wrong with prompt themes

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Some prompt themes (e.g. elite) explicitly use characters with 8th bit set. This
> looks really ugly here - tested on dtterm and console (AT386 terminal - dunno if
> it specific to SINIX or is in common use) with ISO-8859-1 and ISO-8859-5
> charsets.

Irritating, isn't it? ;-)

But that reminded me... Adam, have you ever thought about extending
your prompt themes stuff to include definitions for the format styles
used by the completion code (so that they look appropriate for the
prompt style used)?

> ...
> 
> Or use style(s) to switch them on/off. Themes may look nicely even without these
> characters - and users may conditionally switch them on/off depending on current
> terminal.

Which brings us back to the idea of using a generic package code, sigh.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Something wrong with prompt themes

[Bart Schaefer]

On Dec 6,  2:19pm, Sven Wischnowsky wrote:
} Subject: Re: Something wrong with prompt themes
}
} Andrej Borsenkow wrote:
} 
} > Some prompt themes (e.g. elite) explicitly use characters with 8th
} > bit set. This looks really ugly here - tested on dtterm and console
} > (AT386 terminal - dunno if it specific to SINIX or is in common use)
} > with ISO-8859-1 and ISO-8859-5 charsets.
} 
} Irritating, isn't it? ;-)

Those characters are just stipple-patterns in a VGA console font; the
faded/shaded themes actually look best on the raw console of an x86-PC
unix system such as Linux (i.e. without X11).

It ought to be possible to use actual colors for the fade from one color
to another, but to do so for an arbitrary pair of colors would require
a ridiculously big lookup table to find the correct ANSI codes.  Maybe
there's some algorithmic way involving an AA that keys the ANSI codes
on their RGB values ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Something wrong with prompt themes

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> Those characters are just stipple-patterns in a VGA console font; the
> faded/shaded themes actually look best on the raw console of an x86-PC
> unix system such as Linux (i.e. without X11).

For an example screenshot of how they're supposed to look:

  http://www.new.ox.ac.uk/~adam/computing/zsh/

> It ought to be possible to use actual colors for the fade from one color
> to another, but to do so for an arbitrary pair of colors would require
> a ridiculously big lookup table to find the correct ANSI codes.  Maybe
> there's some algorithmic way involving an AA that keys the ANSI codes
> on their RGB values ...

Yep, this had already occurred to me, and made me realise for the
first time ever (duh) that in fact the ANSI colour order does directly
follow RGB:

  code | colour  | RGB
 ------+---------+-----
    0  | black   | 000
    1  | red     | 100
    2  | green   | 010
    3  | yellow  | 110
    4  | blue    | 001
    5  | magenta | 101
    6  | cyan    | 011
    7  | white   | 111

Sorry, that was probably almost insultingly obvious to anyone with a
brain (that is, everyone here except me :-)

But then that doesn't usually help determine intermediate colours for
a gradient, because there isn't enough granularity when you're working
at 3-bit colour depth.  So I left it to the user in the end.

Re: Something wrong with prompt themes

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> Andrej Borsenkow wrote:
> > Some prompt themes (e.g. elite) explicitly use characters with 8th
> > bit set. This looks really ugly here - tested on dtterm and
> > console (AT386 terminal - dunno if it specific to SINIX or is in
> > common use) with ISO-8859-1 and ISO-8859-5 charsets.
> 
> Irritating, isn't it? ;-)
> 
> But that reminded me... Adam, have you ever thought about extending
> your prompt themes stuff to include definitions for the format styles
> used by the completion code (so that they look appropriate for the
> prompt style used)?

Eek.  I wasn't really aware that there were any particular conflicts
between completion format styles and prompt themes ... actually that's
not true, since the `adam2' prompt theme, which I use the most, makes
user input bold initially, and I use:

  compstyle '*:descriptions' format "$fg_bold[white]%d$fg_no_bold[white]"

But I suspect I'm missing more significant issues here.  Could you
give a practical example or two where the extension suggested above
would be worthwhile?

> > Or use style(s) to switch them on/off. Themes may look nicely even
> > without these characters - and users may conditionally switch them
> > on/off depending on current terminal.
> 
> Which brings us back to the idea of using a generic package code, sigh.

Yep :-) While I'm not convinced more flexibility is needed in this
(prompt themes) case, there's no denying that a generic customization
system would be very worthwhile.  In my mind, the ideal goal would be
an extension of compstyle for general zsh customization (excepting
options, of course, because they're fine left as is), and then to have
some sort of simple front-end customization program (perhaps something
like the sort of UI the `dialog' program generates?) which harnesses
this in a user-friendly way.  The upshot behind this would be that
someone can download, install and have running very quickly a version
of zsh with all the funky stuff enabled, and actually (roughly)
understand what all the funky bits do, without having to spend hours
uploading the zshcompsys man page to their brain.  That would be
great, IMO.

Back to the topic in hand.  These 8-bit characters seem to be causing
several people to wrinkle up their noses, so I should change something
I guess.  The problem is, I'm not sure what in /every/ case.  In the
`adam2' theme you can already specify `plain' to have 7-bit
replacements for 8-bit characters, so perhaps the default should be
7-bit, and there should be a `solid' option or something which uses
8-bit.  However this approach doesn't always work.  For example, in
the `fade' theme, if you ditch the ability to have stippled
characters, it's difficult to imagine how you could use the theme in a
worthwhile way.  For this reason, I mentioned recommended fonts in the
help texts of all themes which use 8-bit characters.  However, I've
just noticed a bug which prevents most help texts from being displayed
normally: if you haven't used or previewed a particular theme, its
help function won't have been loaded, so `prompt -h foo' won't display
the help.  This problem already cropped up in the previewing code, and
I solved it as following:

      # The next line is a bit ugly.  It (perhaps unnecessarily)
      # runs the prompt theme setup function to ensure that if
      # the theme has a _preview function that it's been autoloaded.
      prompt_${theme_args[1]}_setup

which wasn't too bad, as we needed to run prompt_foo_setup to preview
theme `foo' anyway.  However, it's even messier now I've noticed this
help problem, and so we return to the question, "how best to load an
autoloaded function without actually causing any function within the
autoload file to be run?"  When I last asked this, Bart suggested:

    function loadauto {
        emulate -L zsh
        local f
        f=( $^fpath/$1(N) )
        eval "function $1 {
            $(< $f[1])
        }"
    }

but this won't work, since the files in question are of the autoload
variety which explicitly define the function `foo' (and some other
functions at the same time in fact), and then have a

  foo "$@"

as the last line.  I looked at the autoload -X and +X options, but if
I read the docs and thought about it correctly, they don't help.

Re: Something wrong with prompt themes

[Bart Schaefer]

On Dec 7,  1:44am, Adam Spiers wrote:
} Subject: Re: Something wrong with prompt themes
}
} [...] noticed a bug which prevents most help texts from being displayed
} normally: if you haven't used or previewed a particular theme, its
} help function won't have been loaded, so `prompt -h foo' won't display
} the help.  [...] so we return to the question, "how best to load an
} autoloaded function without actually causing any function within the
} autoload file to be run?"  When I last asked this, Bart suggested:
} 
}     function loadauto {
}         emulate -L zsh
}         local f
}         f=( $^fpath/$1(N) )
}         eval "function $1 {
}             $(< $f[1])
}         }"
}     }
} 
} [...] I looked at the autoload -X and +X options, but if
} I read the docs and thought about it correctly, they don't help.

That "loadauto" function is almost exactly equivalent to "autoload +X".

} but this won't work, since the files in question are of the autoload
} variety which explicitly define the function `foo' (and some other
} functions at the same time in fact), and then have a
} 
}   foo "$@"
} 
} as the last line.

That should be

	[[ -o kshautoload ]] || foo "$@"

or else foo will be executed twice.  I haven't checked whether the prompt
functions have a problem with this.  (Hmm, this points out a problem with
"autoload +X" -- the function *won't* be executed the first time it is
called following "autoload +X" when kshautoload is set, if that particular
trick was used in the function's definition.)

It's presently impossible to cause some second function that's defined
in the same file as an autoloaded function to become loaded without also
executing the autoloaded one.  I can't even think of a way to make this
possible.  You either have to execute the contents of the file, causing
the additional functions therein to become defined; or parse it as the
body of a function (and thereby not execute it).  There isn't any way
to selectively execute the commands, particularly if both ksh-style and
zsh-style autoloads are to be supported at the same time.

An additional but more easily surmounted problem is that those additional
functions are completely unknown to zsh.  There's no mechanism to say that
"file X provides function Y" and thus cause X to be read when Y is run.

The best (non-general) solution I can think of would be for the primary
function to accept a "don't execute now" switch, like so:

    # contents of file "foo" somewhere in $fpath
    foo_helper() { echo I am so helpfoo with "$@" }
    foo() {
	[[ $1 = --no-execute ]] && return 0
	echo I need help with "$@" ; foo_helper "$@"
    }
    [[ -o kshautoload ]] || foo "$@"

Now the commands

    autoload foo
    foo --no-execute

will load foo and foo_helper without running either of them.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Something wrong with prompt themes

[Sven Wischnowsky]

Adam Spiers wrote:

> ...
> 
> Eek.  I wasn't really aware that there were any particular conflicts
> between completion format styles and prompt themes ... actually that's
> not true, since the `adam2' prompt theme, which I use the most, makes
> user input bold initially, and I use:
> 
>   compstyle '*:descriptions' format "$fg_bold[white]%d$fg_no_bold[white]"
> 
> But I suspect I'm missing more significant issues here.  Could you
> give a practical example or two where the extension suggested above
> would be worthwhile?

I didn't mean to say that there are conflicts, I was just wondering if 
thought about including defs for the format styles to make them
look-alike with the prompt themes. Probably resulting in a nicer or
more consistent user interface.

> ...
> 
> Yep :-) While I'm not convinced more flexibility is needed in this
> (prompt themes) case, there's no denying that a generic customization
> system would be very worthwhile.  In my mind, the ideal goal would be
> an extension of compstyle for general zsh customization (excepting
> options, of course, because they're fine left as is), and then to have
> some sort of simple front-end customization program (perhaps something
> like the sort of UI the `dialog' program generates?) which harnesses
> this in a user-friendly way.  The upshot behind this would be that
> someone can download, install and have running very quickly a version
> of zsh with all the funky stuff enabled, and actually (roughly)
> understand what all the funky bits do, without having to spend hours
> uploading the zshcompsys man page to their brain.  That would be
> great, IMO.

Any suggestions about how this should/could/would look like?

> Back to the topic in hand.  These 8-bit characters seem to be causing
> several people to wrinkle up their noses, so I should change something
> I guess.

For me at least: only until I had a look at your screen shots...


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Something wrong with prompt themes

[Andrej Borsenkow]

Some prompt themes (e.g. elite) explicitly use characters with 8th bit set. This
looks really ugly here - tested on dtterm and console (AT386 terminal - dunno if
it specific to SINIX or is in common use) with ISO-8859-1 and ISO-8859-5
charsets.

What are these characters for? I believe, they are for semi-grafic with standard
IBM 437 codepage. Unfortunately, you cannot expect everybody to use it.

May be, 'prompt -p' or even 'prompt -l' should at least print warning if the
theme expects particular character set.

Or use style(s) to switch them on/off. Themes may look nicely even without these
characters - and users may conditionally switch them on/off depending on current
terminal.

/andrej