[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
From: |
address@hidden |
Subject: |
Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062) |
Date: |
Fri, 4 Nov 2011 06:44:54 -0700 |
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
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), (continued)
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/01
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), dak, 2011/11/01
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/01
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), pkx166h, 2011/11/03
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), k-ohara5a5a, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/04
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/05
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/05
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), address@hidden, 2011/11/05
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), David Kastrup, 2011/11/05
- Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062), Keith OHara, 2011/11/07