zsh-users
 help / color / mirror / code / Atom feed
From: DervishD <raul@pleyades.net>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@sunsite.dk>
Subject: Re: Is this an orthodox use of zstyle?
Date: Tue, 14 Oct 2003 19:17:41 +0200	[thread overview]
Message-ID: <20031014171741.GG211@DervishD> (raw)
In-Reply-To: <1031014164250.ZM22562@candle.brasslantern.com>

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     I think I can use styles to carry state information from one
> } widget execution to another, so the widget will behave differently
> } depending on the result of past executions, but: is this an orthodox
> } use of styles [...]?
> Typically functions read styles but don't set them, unless they're a
> special kind of function that's designed to help the user set up his
> environment (e.g., (in 4.1.1) select-word-style).

    That's the cause of my question, I haven't seen this kind of use
in zsh functions (well, I haven't checked all...).
 
> If the same function will behave differently depending on context
> (e.g., it might be called as either a normal widget or a completion
> widget) then styles might be appropriate, but if you don't need to
> save different state in different contexts, parameters are better.

    Well, the first widgets I want to modify using state information
really don't need contexts, but I think that I may need it in the
future, for example if I write any completion widget (I don't use
compsys), so it may be a good thing using styled from the beginning.

> }     I know that I can do this with an environment variable but since
> } the state information can be a bit complex I will need an array, or
> } maybe a couple for separating information, or even an associative
> You presumably don't want to "export" the widget state parameters
> (you can't export styles) so it's fine to use arrays and associative
> arrays for your state.

    Yes, you're true, I don't want nor need to export the state, so
this is not an issue. Anyway, since styles doesn't pollute namespace,
wouldn't be better to directly use them for storing state information
even without contexts?

> For example, look at the set of parameters
> used by the zftp functions to maintain state.

    Yes, I've took that as an example ;)) but then my idea about
using styles arose. I must admit that for simple state information, a
simple array is enough, or maybe one per 'session' (whatever you call
a session), but the power of styles is exciting ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/


  reply	other threads:[~2003-10-14 22:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-14 16:00 DervishD
2003-10-14 16:42 ` Bart Schaefer
2003-10-14 17:17   ` DervishD [this message]
2003-10-15  6:21     ` Bart Schaefer
2003-10-15  9:54       ` DervishD
2003-10-15 15:15         ` Bart Schaefer
2003-10-15 19:00           ` DervishD
2003-10-16 14:40             ` Bart Schaefer

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=20031014171741.GG211@DervishD \
    --to=raul@pleyades.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@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).