Someone suggested entering 'empty' into the dictionary. Try it. You get 30-40 entries, with 'empty' as a property, and one with it as a constant, and two with it as an option on commands. One of these may or may not tell you how to set a variable to empty.
This is a bit like setting out to make spaghetti carbonara, and discovering that you can look up spaghetti in the manual. There are lots of entries for the diferent sorts of spaghetti, thick, thin, fresh, wholewheat... You look up bacon. Lots of entries, back, streaky, smoked, pancetta..... What you need is a book organised by Things You Want to Make. Carbonara, Bolognese, Cheese. Broccoli and achovies, Putanesca... I am getting hungry thinking about it. So similarly what Rev needs is a book which does not, when you look up 'empty' have all those 40-50 entries. Instead it has some along the lines of 'How to empty a variable, field.....'. Carla's book is a model. Here is her table of contents http://oreilly.com/catalog/9780596006402/toc.html?CMP=ILL-4GV796923290 And here is an excerpt to show exactly how it works: Problem You need to know what files are installed on your system when you install a program from source code, so that you can find and remove all of them if you decide you don't want them anymore. Some program authors thoughtfully include a "make uninstall" target to perform a clean uninstall, but many do not. Solution You can use standard Linux utilities to generate a pre-installation list of all files on your system. Then generate a post-installation list, and diff the two lists to make a list of newly-installed files. This example uses JOE: Joe's Own Editor: # find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-preinstall.list Compile and install your new program, then generate the post-installation list: # find / | grep -v -e ^/proc/ -e ^/tmp/ -e ^/dev/ > joe-postinstall.list Then create a list of files installed by Joe by diffing the two lists: $ diff joe-preinstall.list joe-postinstall.list > joe-installed.list There are a few more examples here: http://www.linuxdevcenter.com/pub/a/linux/excerpt/lnxckbk_1/index.html Its all organized along the lines of, you are engaged in doing something and find you would like to do X, This is how to do it. Sometimes (as in this case) there is a discussion (here omitted) afterwards about how it works and what to be careful of. You can see, its a dictionary, but organized by problems which in turn are all grouped under tasks. You need both kinds. I am not criticizing the Rev materials, which are (a) much improved and (b) excellent as what they are. But you do need both. Especially for those starting out with it. My own example was a problem which Jim Ault was kind enough to show me how to manage, using 'filter'. Filter was there in the dictionary all the time, I'd just not realized that this was what you used or how you used it to solve my problem. But had there been an entry on the lines of, how to eliminate dupes, or some ways of doing lookups and matches, it would have been in there. It would be natural to get contributions in the form of a wiki, and then have someone edit them into a structure. Most of the material is probably around somewhere, just not organized like this. -- View this message in context: http://www.nabble.com/Why-Rev-needs-a-cookbook-%28newb-questions%29-tp23457871p23470257.html Sent from the Revolution - User mailing list archive at Nabble.com. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
