* Is this an orthodox use of zstyle? @ 2003-10-14 16:00 DervishD 2003-10-14 16:42 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: DervishD @ 2003-10-14 16:00 UTC (permalink / raw) To: Zsh Users Hi all :) 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 or is it more like using mozilla for opening my /etc/hostname just because I can do it? 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 one, and I think that the contexts and styles are very useful here. Just guessing if I'm trying to kill flies using a bazooka... (sorry, can't find a better translation of this spanish expression...) Thanks a lot in advance :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-14 16:00 Is this an orthodox use of zstyle? DervishD @ 2003-10-14 16:42 ` Bart Schaefer 2003-10-14 17:17 ` DervishD 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2003-10-14 16:42 UTC (permalink / raw) To: Zsh Users On Oct 14, 6:00pm, DervishD wrote: } } 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). 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. } 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 } one 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. For example, look at the set of parameters used by the zftp functions to maintain state. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-14 16:42 ` Bart Schaefer @ 2003-10-14 17:17 ` DervishD 2003-10-15 6:21 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: DervishD @ 2003-10-14 17:17 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-14 17:17 ` DervishD @ 2003-10-15 6:21 ` Bart Schaefer 2003-10-15 9:54 ` DervishD 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2003-10-15 6:21 UTC (permalink / raw) To: Zsh Users On Oct 14, 7:17pm, DervishD wrote: } } 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. That's a good argument for looking up configuration options with styles, but not for storing transient state with zstyle. Ask yourself whether you'll ever be looking up the state with a more-specific context than that under which you stored it. If the answer is that you always know the precise context for both storage and retrieval (even if there may be more than one such context), then parameters are probably the better way to go. However, if you've got some really creative way to use "zstyle -e" or some such, go for it. } [...] 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? True, styles don't pollute the parameter namespace, but they do pollute the zstyle namespace. In either case all you need is a convention for your names that isn't likely to collide with someone else's convention. Drawbacks of using zstyle for transient data: Styles are looked up by matching a series of pattern keys against the probe, rather than by matching a single pattern probe against a series of keys. It's therefore more expensive to look up a style than a parameter. (It's like using ${assoc[(k)probe]} when ${assoc[probe]} would suffice.) To use styles as arrays or associative arrays, you have to assign them to a parameter with "zstyle -g", then reset the style from the value of the parameter again to save the state. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-15 6:21 ` Bart Schaefer @ 2003-10-15 9:54 ` DervishD 2003-10-15 15:15 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: DervishD @ 2003-10-15 9:54 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh Users Hi Bart :) * Bart Schaefer <schaefer@brasslantern.com> dixit: > Ask yourself whether you'll ever be looking up the state with a > more-specific context than that under which you stored it. I know what you mean... The power of zstyle is not in precise contexts... Most of the time I will know the exact context the style is in, and right now I cannot think of a case where loose context will be needed (except for configuration) in my widgets... > However, if you've got some really creative way to use "zstyle -e" or > some such, go for it. That's the point: I have a couple of places where this would be useful, to discriminate behaviour. That can be done with parameters too, at least in my case, but will be a good point to learn. > } [...] 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? > True, styles don't pollute the parameter namespace, but they do pollute > the zstyle namespace. In either case all you need is a convention for > your names that isn't likely to collide with someone else's convention. You're right, although I prefer to pollute zstyle namespace rather than parameter namespace. I feel more comfortable adding a :myname: context than using myname_whatever for each and every parameter. But this is not a reason, of course. > Styles are looked up by matching a series of pattern keys against the > probe, rather than by matching a single pattern probe against a series > of keys. Speed is not an issue (well, to a certain extent), nor notation. It's more a desire to learn and practice styles. Moreover, what I consider more important is the possible need of styles in future widgets I write. I think that introducing the style mechanism right now, from the beginning, is a better idea. > To use styles as arrays or associative arrays, you have to assign them > to a parameter with "zstyle -g", then reset the style from the value > of the parameter again to save the state. This is another cause for my original question. The retrieval of style information in an array-like fashion has not a comfortable notation. Parameters are better suitable for this. I think that styles are a very attractive way of storing contextual information, although not always needed, since you can store contextual information using parameters, for example. In this sense, zstyle may be abused, or misused. But the fact is that if you want to store state information, or configuration options, for a simple function or script, you can do with parameters. But if you start to make more complex functions, interrelated ones, entire systems, etc... you will surely need zstyle, since the contexts are sometimes incomplete or unknown; then it is better IMHO that styles are introduced from the beginning. A last point: maybe I'm missing something, but I think that the entire zstyle thing can be done with parameters (with exception of the -e option, maybe). Excuse me if that sounds stupid or clueless, but I haven seen many uses of zstyle (I haven't read all the completion code... by now...). Thanks again Bart. Remember that dinner if you come to Spain ;) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-15 9:54 ` DervishD @ 2003-10-15 15:15 ` Bart Schaefer 2003-10-15 19:00 ` DervishD 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 2003-10-15 15:15 UTC (permalink / raw) To: zsh-users On Oct 15, 11:54am, DervishD wrote: } } A last point: maybe I'm missing something, but I think that the } entire zstyle thing can be done with parameters (with exception of } the -e option, maybe). Yes, you could write "zstyle" as a shell function. There are a number of parts of the completion system that could be written as functions, but that were coded (or re-coded) in C for speed. I think the caching utility (_store_cache, etc.) would be the next candidate for that sort of conversion ... there's something else you could use to store state, by the way. Even slower than styles, but sharable across multiple shells. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-15 15:15 ` Bart Schaefer @ 2003-10-15 19:00 ` DervishD 2003-10-16 14:40 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: DervishD @ 2003-10-15 19:00 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users Hi Bart :) * Bart Schaefer <schaefer@brasslantern.com> dixit: > } A last point: maybe I'm missing something, but I think that the > } entire zstyle thing can be done with parameters (with exception of > } the -e option, maybe). > Yes, you could write "zstyle" as a shell function. There are a number > of parts of the completion system that could be written as functions, > but that were coded (or re-coded) in C for speed. I'm not going to do that, anyway ;)) I was just guessing. The fact is that although you can implement a bunch of builtins as shell code, it's usually faster, safer, etc... to write them in C. > there's something else you could use to store state, by the way. > Even slower than styles, but sharable across multiple shells. What's that? ;)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is this an orthodox use of zstyle? 2003-10-15 19:00 ` DervishD @ 2003-10-16 14:40 ` Bart Schaefer 0 siblings, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2003-10-16 14:40 UTC (permalink / raw) To: zsh-users On Oct 15, 9:00pm, DervishD wrote: } } > there's something else you could use to store state, by the way. } } What's that? ;)) I was referring to the _store_cache/_retrieve_cache mechanism ... but on closer inspection it has :completion: style contexts hardwired, so it'd need some tweaking. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-10-16 14:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-14 16:00 Is this an orthodox use of zstyle? DervishD 2003-10-14 16:42 ` Bart Schaefer 2003-10-14 17:17 ` DervishD 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
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).