On 2005-03-15, Zachary Landau <[EMAIL PROTECTED]> wrote: >> (The proper way would of course be to first write Vis :) > > What is Vis? I tried googling for it, but three letter words are not > fun to do a search on.
http://iki.fi/tuomov/vis/ > As far as the explanation view, what is the best way to maintain the > information about what the function does? In theory, the input file > should have a bdoc() call before each function. But what I don't like > about that is there is no direct link between a bdoc and the > corresponding binding. It seems messy to go through the table, seeing > if a bdoc comes right before a kpress/mpress/whatever. > > Another option is to maintain a separate, direct mapping between > bindings and their descriptions. But I think I dislike that option > even worse. > > If anyone has a better idea for how to handle this, please let me know. It depends on how "user-friendly" you want the configuration editor to be. Should the documentation be at the 'bdoc' level? Or are the documentation comments in the code and in the Ion configuration manual simple enough? In the first case, you are probably best off creating a database of descriptions of commonly used "commands". For example: command{ context = "WScreen", call = "WMPlex.switch_nth(_, __n__)", descr = "Switch to __n__:th region within screen.", } You can use ltokens <http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/> to parse the lua code in both bindings and the descriptions and then try to match them. (Note that the the above pattern should match WScreen.switch_nth as well, so you'll have to do some ugly inheritance handling.) An example of ltokens use on the Lua side can be found in ion/build/lxgettext.lua. This database could as well be used to replace the bdoc documentation in manual page generation. In the second case you can improve libextl/libextl-mkexports(.in) in libextl to generate documentation of the format you want. Some kind of matching like above may still be needed :(. Yes, writing this kind of editor would be much easier if Ion provided simple "commands" to call instead of a full scripting interface. But I don't like providing both. -- Tuomo
