From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2840 invoked from network); 7 Dec 1999 01:44:16 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Dec 1999 01:44:16 -0000 Received: (qmail 11091 invoked by alias); 7 Dec 1999 01:44:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8926 Received: (qmail 11084 invoked from network); 7 Dec 1999 01:44:10 -0000 Date: Tue, 7 Dec 1999 01:44:08 +0000 From: Adam Spiers To: zsh-workers@sunsite.auc.dk Subject: Re: Something wrong with prompt themes Message-ID: <19991207014408.B4276@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh-workers@sunsite.auc.dk References: <199912061319.OAA06256@beta.informatik.hu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <199912061319.OAA06256@beta.informatik.hu-berlin.de> X-URL: http://www.new.ox.ac.uk/~adam/ X-OS: Linux 2.2.12 i686 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.