Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

[address@hidden]

On Nov 4, 2011, at 1:02 AM, David Kastrup wrote:

> "address@hidden" <address@hidden> writes:
> 
>> On Nov 3, 2011, at 11:39 PM, address@hidden wrote:
>> 
>>> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc
>>> File lily/pure-from-neighbor-engraver.cc (right):
>>> 
>>> http://codereview.appspot.com/5323062/diff/12001/lily/pure-from-neighbor-engraver.cc#newcode32
>>> lily/pure-from-neighbor-engraver.cc:32: vector<Grob *> pures_;
>>> This takes the lilypond-jargon 'pure' even further from its original
>>> inspiration (a pure function that does not depend on nor change program
>>> state).
>>> What is a 'pure' when used as a noun?
>>> 
>> 
>> Grobs that are pure relevant.  I'll use "pure_relevants_" instead.
> 
> Veto.  "pure" sounds like inside jargon which one will tend to look up
> in the internals guide or wherever else one can expect to (and should!)
> find it.  Lilypond "pure" apparently differs from common-sense "pure",
> but seems to roughly mean "an upper bound established without looking at
> line break decisions".  While there _should_ be a word list of commonly
> used terms in our docs, one can figure that out, somewhat painfully,
> after looking at enough code.  The grammatical barrier of nouning a verb
> or verbing a noun is tiny in comparison.
> 
> "pure relevant" is gibberish.  It again uses a Lilypond-specific "pure",
> but tacks on another common-use word in a meaning not usually employed.
> 
> I have absolutely no idea what "grobs that are pure relevant" is
> supposed to mean.  Not the fuzziest.

David,

Pure relevant (and pure-relevant) is used several places in the code (check out 
axis-group-interface.cc, define-grobs.scm, grob-property.cc).  Are you 
suggesting that in a separate patch this nomenclature be rethought?  If so, I 
think it's worth it to post a separate patch doing this.

Cheers,
MS