On Thu, Feb 19, 2004 at 10:24:03AM +0000, Yves Rutschle wrote:
> Also, I switched to ion2 recently, and this would be my
> biggest gripe: there is a definite lack of _introductory_
> documentation (I must say there is plenty of detailed
> documentation, which is nice). I had to read pages and pages
> to find that I just needed to unncomment one line somewhere
> to get the dock module.
The configuration files are partly self-documenting, and e.g. the dock
should be self-explanatory once you find ion.lua. But indeed an "Ion
for Dummies" guide would be good to have. (I am not going to write it,
and am the wrong person to do that in any case.) The man page lists
the default bindings and explains some basic concepts, but IMHO that's
all that man pages should be. (And who would want to write tens of
pages of troff?)
> While the man page documents the
> basic bindings, I think it should also document the basics
> of the configuration (what files are used).
These are explained in the configuration manual
> I know I found
> ion1 much easier to configure and get accointed with than
> ion2 (which makes sense as ion2 seems much more powerful).
Ion3 may be easier or harder to configure than Ion2. For example,
floatws.lua looks as follows at the moment (all rights reserved to
change the format at any time :)
defbindings("WFloatWS", {
kpress(MOD1.."Tab", "WFloatWS.circulate_and_raise(_)"),
submap(MOD1.."K", {
kpress("AnyModifier+Tab", "WFloatWS.backcirculate_and_raise(_)"),
}),
kpress(MOD1.."P", "WRegion.lower(_sub)", "_sub:non-nil"),
kpress(MOD1.."N", "WRegion.raise(_sub)", "_sub:non-nil"),
})
defbindings("WFloatFrame", {
mdblclick("[EMAIL PROTECTED]", "WFloatFrame.toggle_shade(_)"),
mpress("[EMAIL PROTECTED]", "WFloatFrame.raise(_)"),
mpress("[EMAIL PROTECTED]", "WFloatFrame.raise(_)"),
mclick(MOD1.."Button1", "WFloatFrame.raise(_)"),
mclick(MOD1.."Button3", "WFloatFrame.lower(_)"),
mdrag("[EMAIL PROTECTED]", "WFloatFrame.p_move(_)"),
mdrag(MOD1.."Button1", "WFloatFrame.p_move(_)"),
kpress(MOD1.."M", "menulib.menu(_, _sub, 'ctxmenu-floatframe')"),
mpress("[EMAIL PROTECTED]", "menulib.pmenu(_, _sub, 'ctxmenu-floatframe')"),
})
The strings might be a little easier for people to grasp than directly
passing functions around that has seems to confuse a lot of people.
They're always calling the functions. *sigh* How hard can it be...
However, now there will be even more completely broken configuration files
because people will be confused with all the parentheses and quotes.
And there are these strange _ and _sub variables that need to be passed
around without the help of the 'make_*' convenience (and confusion?)
functions.
On the positive side, you can enter exactly the same strings in the
Mod1+F3 query. In principle one could use "_:raise()" etc. above, but
I decided that fully qualified names might be easier to grasp.
External configuration programs should have a little easier time with
this scheme: all they have to do is define a couple of Lua functions to
parse the files in a somewhat usable form. But as the strings aren't
just simple commands, some extra parsing needs to be done there. At least
the result isn't just some random function reference.
So why not just simple commands? After all, it'd be a lot easier for
newbies and external programs.
Simple commands are not usable for scripting if you must work with
multiple objects in scripts (instead of e.g. a single buffer), and it
is a lot of work to maintain two separate sets of functions. If first
thought of a scheme that would know how to call most functions given
just their name and the extra arguments, but then I decided to clean up
the namespace, and I have this idea of a much higher-level semantic
structure configuration/ui building system...
--
Tuomo
