lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Harmonize point-and-click information for #xxx and $xxx (issue 75010


From: Janek Warchoł
Subject: Re: Harmonize point-and-click information for #xxx and $xxx (issue 7501046)
Date: Wed, 13 Mar 2013 16:43:49 +0100

On Wed, Mar 13, 2013 at 9:11 AM,  <address@hidden> wrote:
> I don't get it.  Seriously.  All of $, #, and \ are lexical elements
> combining with something following behind them (and all can take an
> identifier) and producing an expression or a copy of it.  In the case
> of music, this expression carries point-and-click information.  I
> describe how this point-and-click information is generated in each of
> the given cases.  $xxx and #xxx behave the same, and that is different
> when compared to \xxx.

Ok, now i see what you mean.
I think my problem was that, because of "however", i had thought that
in the description you contrast some new behaviour with some other
behaviour that existed already.  As in "this patch makes $xxx and #xxx
do blah.  However, \xxx won't do blah - it continues to do foo as it
used to".
Maybe you could reword the description using imperative mood, like this:

Harmonize point-and-click information for #xxx and $xxx

Make #xxx and $xxx retain any preexisting origin information when
producing a music expression.  In contrast, \xxx will always receive the
origin information pertaining to the current location even if previous
point-and-click information exists.  This is consistent with the
point-and-click information for music functions as a whole
corresponding to the point of call, while the individual arguments, if
separate music expressions, retain any preexisting origin.

In general, i find using present tense in commit messages confusing. I
think that it's usually better to use future/imperative for behaviour
implemented with the commit, and past when describing behaviour before
it.

>> Could you change it so that it more explicitely says what
>> was the situation before commit and what it is after?
>
> I don't see that describing that is going to make things clearer since
> this patch replaces a non-designed behavior with a designed one.

ok.

thanks,
Janek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]