On Sat, Aug 14, 2004 at 08:39:30PM -0400, Jeremy Maitin-Shepard wrote: > I also think that all of the code currently in ext_statusbar.lua for > registering specific meters and the corresponding functions should be > moved to cfg_statusbar.lua.
The register_meter code is supposed to be called by additional meter-implementing scripts possibly loaded from cfg_statusbar.lua. Note that no meter is called that does not appaer in the format string, so there's no need for the user to be concerned with how the meters are registered. Also, ideally this all should be in some ion-statusd; running programs and opening files not known to be on a virtual fs (/proc) not in the background is a bad idea in a WM (NFS etc.). But the ext_statusbar script is just a proof-of-concept and I have more important things to write for now (like getting around to finishing mod_autows). > Finally, I think cfg_statusbar.lua should > load ext_statusbar.lua rather than ext_statusbar.lua loading > cfg_statusbar.lua; I think such organization is more suitable for a > library. The idea is that a library/module/whatever loads its configuration file. > Regarding the recent inclusion of documentation directives for each of > the key bindings, I find this litters the config files will a lot of > unnecessary text I asked about this on IRC before committing the patch, and all the replies agreed that the documentation actually helps reading the configuration files when you don't know what the code in each of the bindings is supposed to do. > if Lua supports it, I would suggest instead that the > documentation strings be bound to the underlying functions rather than > the key bindings -- this is what Emacs does, for example. This would imply separate sets of available bindable _commands_ for which we know how they should be called etc. and _functions_ for scripting. That is far too much stuff to maintain, and an ugly division between scripting and configuration, so it is __not__ going to happen. (Not until Ion runs on top of a Vis-like framework :) -- Tuomo
