auto_mkindex is one of several commands documented at http://www.purl.org/tcl/home/man/tcl8.4/TclCmd/library.htm
MSW 2003-09-03: What does auto_mkindex buy us over auto_mkindex_old (which I prefer), given that auto_mkindex_old has a clear rule how to exclude procs from loading, and auto_mkindex doesn't ?
Imagine e.g. you have a library of tcl stuff, with different (Gui or not) frontends all having a common init procedure which they cannot auto_load (yet) because they did not setup load pathes (auto_path). Now if you e.g. start in a non-gui case, calling an init function (let's call it xxx_init) which you put in an init.tcl, it's absolutely random which file ends up being loaded (or the last alphabetically sorted), which often is not the right thing - that last file could be using xxx_init to set up things, but when it's sourced could call it with some parameters which apply for the GUI case only.
Checking against the argv0 won't help, as this same thing can also be in a subwindow / own toplevel when started from another (GUI) script in the bundle...
So if someone has some insight to share on what the new auto_mkindex really buys us, I'm curious.
RS 2003-09-03: auto_mkindex_old does not exclude procs from loading - only they are not indexed. If the file is sourced because of another proc, all the ;procs will be loaded too. But with unique names (namespaces), conflicts should not occur. Also consider the package mechanism for more modular (and versioned) code management.
MSW 2003-09-03: Uh, sorry. I meant not being indexed. Yet not being indexed means you know which file will be loaded. Of course I can add a plethora of bookhandling code, too. And until package require <pkg> <arg> doesn't accept anything as arg, it's pretty useless for variable behaviour, while you keep developing your packages. That was not the question either, I asked why abandon an easily controllable interface towards one where you either have to dig deeper, add more code or more complexity.
file init-proc.tcl:
proc xxx_init {{do_this 0} {do_that 0} {do_gui 0}} {
# do something shared
# do something according to params
}
file 1.tcl (executable, gui):
> ; proc xxx_init ... > standalone usage: 1.tcl: xxx_init 1 0 1 > loaded: we need that init stuff, too ( as of the options )
file 2.tcl (executable, gui):
> as 1.tcl
file 3.tcl (executable, !gui):
> ; proc xxx_init ... > standalone usage: 3.tcl: xxx_init
file 4.tcl (executable, gui):
> as 1.tcl
5 (statically compiled c program with tcl interpreter)
> in Tcl_AppInit, call xxx_init. With new auto_mkindex > ran, 4.tcl will be loaded (has gui -> Bang!) > with old, init-proc.tcl will be loaded
alternative to get old behaviour: source full/path/init-proc.tcl.
rephrase alternative in other ways: abandon autoloading (in my case of course). uh huh. So that's what auto_mkindex(_new) buys me ?
RS: This seems more like a discipline problem to me - I've learnt (the hard way) that, when using autoloading, one should clearly divide one's files into two classes:
A compromise is however possible, if you must have lib and app functionality in the same file. I often use this for demo or self-test, to have the last part of the file like this:
if {[info exists argv0] && [file tail [info script]]==[file tail $argv0]} {
... ;# demo UI, or tests that report to [stdout], etc.
}Tcl syntax help - Arts and crafts of Tcl-Tk programming - Category Command