zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh-Workers <zsh-workers@sunsite.dk>
Subject: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?
Date: Fri, 18 Aug 2006 11:03:51 -0700	[thread overview]
Message-ID: <060818110351.ZM24330@torch.brasslantern.com> (raw)
In-Reply-To: <20060818102602.GA24702@finlandia.home.infodrom.org>
In-Reply-To: <20060818130849.GD15840@fsst.voodoo.lan>

On Aug 18, 12:26pm, Matthias Kopfermann wrote:
}
} For _prompts_ i have to surround every variable with %{ %} which
} does not , aehem, look too nice.

The colors function is meant to be entirely separable from prompts, so
it avoids reference to any prompt formatting strings.

} what do you think? would it be fine to have that with
} wrapped around %{ %} , too so that not everybody has to put
} these around the keys or roll a prompt_colors_array on his
} own?

Another reason I resisted this is that it leads to PS1 values that
contain lots more %{ %} pairs than are often necessary.  E.g., for a
two-line prompt, you can often put the entire first line in a single
pair of %{ ... %}.

On Aug 18,  3:08pm, Frank Terbeck wrote:
}
} I just think that the colors function would load quite a lot of
} redundant information, if these are added as well.

That, too.

} [snip]
} for i in ${(k)fg} ; do pfg[$i]="%{$fg[$i]%}" ; done
} [snap]
} 
} to your .zshrc, but I guess a loadable function would be easier for
} new users.

Perhaps a candidate for adding to the zsh-newuser-install function?

} Maybe it would be helpful to add this to the colors function:
} 
} [snip]
} blink_color="$lc${color[blink]}$rc"
} [snap]

Hrm.  That would imply we ought to have $fg_blink and $fg_no_blink as
associative arrays as well, etc. ... this doesn't scale.  What's really
needed is a function that takes a set of attributes and turns them on
or off, but then you have to use $(...) which is ugly.  Of course even
then you have to maintain your own idea of the screen state, because
what you send to the terminal is "set the attributes to this" not
"change the attributes in this additive/subtractive way".

This seems like something to revisit when we have discipline functions
attached to parameter expansions.


  reply	other threads:[~2006-08-18 18:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-18 10:26 Matthias Kopfermann
2006-08-18 13:08 ` Frank Terbeck
2006-08-18 18:03   ` Bart Schaefer [this message]
2006-08-19  6:43     ` readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?) Matthias Kopfermann
2006-08-19 18:39       ` Bart Schaefer
2006-08-20  6:56         ` Matthias Kopfermann
2006-08-20 17:33           ` Bart Schaefer
2006-08-20 18:47             ` Matthias Kopfermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=060818110351.ZM24330@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).