Jeff,
Can an extension be added to tkcon so that the interpreter becomes aware of XOTcl proc, instprocs and associated vars for type ahead capability.
Lazy,
John
John McGlaughlin wrote:
Can an extension be added to tkcon so that the interpreter becomes aware of XOTcl proc, instprocs and associated vars for type ahead capability.
tkcon only does the "first" level of expansion for procs. I assume you are looking for object instrospection that will expand methods and/or vars then?
Lazy,
That I understand well. ;)
Jeff
That's correct Jeff,
I thought perhaps it might be possible but could see how it might be a performance hit cept on the dual opterons it is quite fast.
perhaps if it were to be implemented it could be a switch to enable it?
Though it sounds like there are no cycles for such a feature.
XOTcl is cool and becoming more popular.
Thanks John
Jeff Hobbs wrote:
John McGlaughlin wrote:
Can an extension be added to tkcon so that the interpreter becomes aware of XOTcl proc, instprocs and associated vars for type ahead capability.
tkcon only does the "first" level of expansion for procs. I assume you are looking for object instrospection that will expand methods and/or vars then?
Lazy,
That I understand well. ;)
Jeff
Hi John and Jeff,
Just now i made a quick attempt to handle all kind of methods in tkcon.tcl (i started with the newest version from the cvs repository http://tkcon.sourceforge.net/). The code tgries to be least invasive, there are almost certainly more elegant ways to handle this, however, it seems to work pretty well with procs, instprocs (as well with instprocs from mixins). See the following script, where i have added the lines with the <TAB> keys.
======= (scripts) 4 % package require XOTcl 1.3.6 (scripts) 5 % namespace import ::xotcl::* (scripts) 6 % Class create M -instproc foo {} {puts hi} ::M (scripts) 7 % Object o ::o (scripts) 8 % o set<TAB> self set (scripts) 8 % o set x 1 1 (scripts) 9 % o mixin M foo forward (scripts) 10 % o fo<TAB> =======
just replace ::tkcon::ExpandProcname with the proc below.
Jeff, I am not too happy about the way expandOrder is evaluated, but this might be a misleading impression of a new user. frequently, the expansion of pathnames overrules the proc expansion. how about doing the pathname expansion (optionally) when the path starts with one of "./~"?
all the best -gustaf
===================================================== proc ::tkcon::ExpandProcname str { # in a first step, get the cmd to check, if we should handle subcommands set cmd [::tkcon::CmdGet $::tkcon::PRIV(console)] # if there are two cmds, and xotcl is loaded, do the xotcl magic if {[llength $cmd]==2 && [EvalAttached [list info exists ::xotcl::version]]} { set o [lindex $cmd 0] set sub [lindex $cmd 1] set match [EvalAttached [list $o info methods $sub*]] } else { # standard behavior set match [EvalAttached [list info commands $str*]] if {[llength $match] == 0} { set ns [EvalAttached \ "namespace children [namespace current] [list $str*]"] if {[llength $ns]==1} { set match [EvalAttached [list info commands ${ns}::*]] } else { set match $ns } } } if {[llength $match] > 1} { regsub -all {([^\]) } [ExpandBestMatch $match $str] {\1\ } str set match [linsert $match 0 $str] } else { regsub -all {([^\]) } $match {\1\ } match } return $match } =====================================================
Oh yeah ... tkcon seems to be certainly well enough architectured (in this case ;) ) to handle this easily. Add this to tkcon:
proc ::tkcon::ExpandXotcl str { # in a first step, get the cmd to check, if we should handle subcommands set cmd [::tkcon::CmdGet $::tkcon::PRIV(console)] # Only do the xotcl magic if there are two cmds and xotcl is loaded if {[llength $cmd] != 2 || ![EvalAttached [list info exists ::xotcl::version]]} { return } set obj [lindex $cmd 0] set sub [lindex $cmd 1] set match [EvalAttached [list $obj info methods $sub*]] if {[llength $match] > 1} { regsub -all {([^\]) } [ExpandBestMatch $match $str] {\1\ } str set match [linsert $match 0 $str] } else { regsub -all {([^\]) } $match {\1\ } match } return $match }
and then do this:
tkcon master set ::tkcon::OPT(expandorder) \ {Xotcl Variable Procname Pathname}
Note that this puts pathname at the end, also addressing Gustaf's request that it's too picky. You have to have Xotcl before Procname for it to be really useful.
I've added the above proc to the tkcon sources, but I didn't change the expandorder to include it yet ... I suspect it's "fast enough", but if somebody with a slow machine could confirm, that would be nice.
Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos
Thanks all, Very helpful Lazy John
Jeff Hobbs wrote:
Oh yeah ... tkcon seems to be certainly well enough architectured (in this case ;) ) to handle this easily. Add this to tkcon:
proc ::tkcon::ExpandXotcl str { # in a first step, get the cmd to check, if we should handle subcommands set cmd [::tkcon::CmdGet $::tkcon::PRIV(console)] # Only do the xotcl magic if there are two cmds and xotcl is loaded if {[llength $cmd] != 2 || ![EvalAttached [list info exists ::xotcl::version]]} { return } set obj [lindex $cmd 0] set sub [lindex $cmd 1] set match [EvalAttached [list $obj info methods $sub*]] if {[llength $match] > 1} { regsub -all {([^\]) } [ExpandBestMatch $match $str] {\1\ } str set match [linsert $match 0 $str] } else { regsub -all {([^\]) } $match {\1\ } match } return $match }
and then do this:
tkcon master set ::tkcon::OPT(expandorder) \ {Xotcl Variable Procname Pathname}
Note that this puts pathname at the end, also addressing Gustaf's request that it's too picky. You have to have Xotcl before Procname for it to be really useful.
I've added the above proc to the tkcon sources, but I didn't change the expandorder to include it yet ... I suspect it's "fast enough", but if somebody with a slow machine could confirm, that would be nice.
Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos
-
Gustaf Neumann -
Jeff Hobbs -
John McGlaughlin