On 2015/09/05 13:11:23, Dan Eble wrote:
On 2015/09/05 13:08:02, Dan Eble wrote: > On 2015/09/03 08:49:13, dak wrote: > > On 2015/09/02 23:27:41, Dan Eble wrote: > > > > > If the sorting criterion uses attributes of the Grob that are
changed by
> > > replacement, the array might not be sorted afterward (or might
be sorted
> when > > it > > > wasn't before). Grob_array does not appear to dictate the
sorting
> criterion. > > > > So the routine should reset the "sorted" flag when any changes are
made?
Correction, "ordered_".
> > Maybe; but it didn't before, and I don't want to deal with the
consequences of
> changing the logic. With your consent, I'd like to move the ticket
along to
> "countdown."
Correction: I'd like your consent to push it. It was already listed
in
"Countdown" in James' email of Sep. 2, but the ticket was out of date.
You are replacing one-shot code with general facilities here. If the circumstances of the one-shot code happen not to trigger a particular problem in a visible manner, that does not mean that this will hold the same for other future uses of the facility. So it's better to make sure that a routine does what it claims to do under its claimed preconditions now while it is fresh. It will be much more troublesome to figure out the culprit when this indeed should become a problem eventually and the code is "long-standing". https://codereview.appspot.com/264950043/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
