Re: Exmh 2.7 Flist much slower?

>>>John Beck said:
 > Note: moved to the -workers list as it seemed more appropriate.  Apologies
 > to Brent if this is undesired, and if so, feel free to move back...

no worries

 > There does appear to be such a something, which would be the ftoc (i.e. scan
     )
 > cache: I have
 > 
 > *ftextLines:    14
 > 
 > in my defaults file but the new version had it much bigger than that.  By
 > playing with the number in Preferences, I observed a formula something like
 > 	20 + (n / 2)
 > meaning that e.g. with n set to 14, there would actually be 27 lines in the
 > display, though the baseline of 20 may have been a little smaller, and there
 > were some oddities with n = 0 or 1.  I did not fully understand the diffs to
 > exwin.tcl, but by backing out its changes (i.e., restoring the 2.7.0 version
     )
 > I got back the behavior I'm used to.

yeah, I recall that goofy behavior, too.  I think I fixed it by using
the black diamond resize bar instead of setting preferences.  But, looking
at the diffs I believe it is due to this code added around line 382.
I don't know why this is necessary, and is probably the cause.  I'm not
at an X windows display right now so I can't test that theory.  Try eliminating
this new block of code from the latest exwin.tcl:
(i.e., nuke the +'d lines)

--- 369,382 ----
                set var fdisp(maxLines)
            }
        }
+
+         if {!$exwin(toplevelFtoc)} {
+             $exwin(ftocframe) configure -height [expr [winfo height $exwin(fto
cframe)] + $dy]
+         }
+         if {!$exwin(toplevelMsg)} {
+             $exwin(msgframe)  configure -height [expr [winfo height $exwin(msg
frame)] - $dy]
+         }
+
        # Let redisplay kick in
            }
        }
    }
}

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]