[EMAIL PROTECTED] (Tuomo Valkonen) writes: > 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. I see what your intention is here, but I was thinking the user would define his own meters in cfg_statusbar.lua. It appears that you are trying with many of the changes in ion version 3 to better support a less programming audience, whereas I am more interested in a programming interface. > 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.). Sure, it probably would be better for the status bar to be implemented in a separate program, but since the WM can do it reasonably well, it doesn't seem to be a problem right now. Note that if the it is user that defines all of the meters (the ones included in cfg_statusbar.lua would be considered examples), then the possibility that a proc file is missing is not an issue. > [snip] >> 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. I suppose it is true that you use that pattern consistently throughout ion, and it is really just a matter of preference. I am just more fond of letting the user define the structure and naming of his own configuration files, particularly since in this case, the configuration file is what is actually invoking the library (ext_statusbar.create). >> 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. Okay -- in the sense that they are designed to function like comments, I think they are useful (although a standard comment would be just as suitable). I figured given the syntax used that they were designed to be read by some future built-in help feature or configuration utility -- the issue is that as a user, I don't generally want to bother having to add or otherwise manage the documentation strings, but nonetheless find documentation strings to be useful. >> 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. I believe that the problem of needing separate bindable commands can be avoided. Right now, I believe that most of the standard key bindings are single function calls -- a builtin help feature could check the bindings, and if it is a simple function call, it could display the documentation for the function being called. -- Jeremy Maitin-Shepard
pgpFfF56ZexJo.pgp
Description: PGP signature
