RE: [Tile-dev] Scrollbar '-command' callbacks

[Jeff H. <je...@Ac...>]

>      set cmd [$w cget -command]
> -    if {$cmd ne ""} {
> -       uplevel #0 "$cmd scroll $n $units"
> -    }
> +    if {[llength $cmd]} {
> +       uplevel #0 [concat $cmd scroll $n $units]
> +    }

> This forces the -command option to be a list ([llength 
> $cmd]), but still treats it as a string ([concat] instead of 
> [linsert _ end ...])

I should have used [linsert $cmd end ...] to be better
behaved, but I figured the above was "safer".

> The new formulation may have a small performance boost in
> the common case where the -command is a pure list, but
> it's not fully backwards-compatible, since there are 
> valid script prefixes that aren't lists.

No there aren't.  You couldn't pass it to eval or uplevel
in that case:

(Tcl) 49 % set cmd "echo \{ c"
echo { c
(Tcl) 50 % llength $cmd
unmatched open brace in list
(Tcl) 51 % eval $cmd
missing close-brace
(Tcl) 52 % uplevel #0 $cmd
missing close-brace

> We had discussed earlier interpreting callback options
> that append arguments as command prefixes instead of script 
> prefixes; is this something we want to do?  (Callback options 
> that don't append arguments would still be interpreted as
> scripts.)  Personally, I think it's a good idea, but there
> are backwards-compatibility issues.

The real trick is "script prefix" vs "command prefix".  I guess
for most of Tk it's a script prefix, and that remains that way
as long as we use uplevel.  It really matters at the C level,
as there we can force it to be one command, vs a script.  I'm
inclined to say "script" just because that's Tk-ish, but I'm
sure I could be convinced otherwise.

Jeff