If there is fault here, it's only that the proposed change didn't/doesn't justify its existence well enough, given the sensitive central position of @file in Leo's functioning. (Reinhard hasn't been around long enough to know that @file is surrounded on all sides by more "here be dragons" and "you might be eaten by a grue" than all other parts of Leo, combined.)
To my admittedly neophyte eye, the "expressed intention" of the compute leading whitespace change is clear enough. The significant points are a) there is a significant performance gain (some data for that now provided), and b) that it is provably safe and equivalent to what it replaces (and/or deviations documented and deemed ok). A unit test demonstrating that the two pieces of code are equivalent **for > all relevant strings** > A corpus of all relevant strings to throw at this function would be useful at this juncture. I tried to find a link to insert here, but am unsure of the right target; perhaps LeoPyref.leo >> Code >> Testing? -matt On Mon, Nov 25, 2013 at 9:46 AM, Matt Wilkie <[email protected]> wrote: > > On Mon, Nov 25, 2013 at 7:31 AM, Reinhard Engel < > [email protected]> wrote: > >> And now I learned that is is not the place to discuss such code details. > > > I don't think that is the correct conclusion to draw from the > conversation. This is most definitely the place to discuss code and debate > the relative merits of proposed approaches and changes. > > -matt > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
