[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