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

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

Both #xxx and $xxx retain any preexisting origin information when
producing a music expression.  However, \xxx always receives 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.

[dak, 2013-03-12 14:23:39]

Correct several confusions about evaluation timing

[dak, 2013-03-12 14:29:56]

Testing that this actually compiles would have been good

[janek, 2013-03-12 22:12:34]

As usual, i have a dumb question about the commit message.
What is the relation of \xxx to #xxx and $xxx?
I can't quite grok the commit message :/

[dak, 2013-03-13 06:06:46]

On 2013/03/12 22:12:34, janek wrote:
> As usual, i have a dumb question about the commit message.
> What is the relation of \xxx to #xxx and $xxx?
> I can't quite grok the commit message :/

Uh, \xxx is something starting with a backslash, $xxx is something starting with
a dollar sign, #xxx is something starting with a hash mark.  I have trouble
understanding your trouble.

[janek, 2013-03-13 07:03:16]

On Wed, Mar 13, 2013 at 7:06 AM,  <dak@gnu.org> wrote:
> On 2013/03/12 22:12:34, janek wrote:
>>
>> As usual, i have a dumb question about the commit message.
>> What is the relation of \xxx to #xxx and $xxx?
>> I can't quite grok the commit message :/
>
> Uh, \xxx is something starting with a backslash, $xxx is something
> starting with a dollar sign, #xxx is something starting with a hash
> mark.  I have trouble understanding your trouble.

My trouble is that you wrote a sentence about $xxx and #xxx and then
"however, \xxx ..." and i don't know how to relate these parts of the
description: when i read it, it sounds like "cows and dogs are
mammals.  However, prices of bus tickets have dropped".
It's quite possible that the description is perfectly ok and i'm just
dumb/tired, but then i guess it wouldn't hurt to make it a bit
simpler.  Could you change it so that it more explicitely says what
was the situation before commit and what it is after?

thanks,
Janek

[dak, 2013-03-13 08:11:52]

On 2013/03/13 07:03:16, janek wrote:
> On Wed, Mar 13, 2013 at 7:06 AM,  <mailto:dak@gnu.org> wrote:
> > On 2013/03/12 22:12:34, janek wrote:
> >>
> >> As usual, i have a dumb question about the commit message.
> >> What is the relation of \xxx to #xxx and $xxx?
> >> I can't quite grok the commit message :/
> >
> > Uh, \xxx is something starting with a backslash, $xxx is something
> > starting with a dollar sign, #xxx is something starting with a hash
> > mark.  I have trouble understanding your trouble.
> 
> My trouble is that you wrote a sentence about $xxx and #xxx and then
> "however, \xxx ..." and i don't know how to relate these parts of the
> description: when i read it, it sounds like "cows and dogs are
> mammals.  However, prices of bus tickets have dropped".

We are talking about "Both #xxx and $xxx retain any preexisting origin
information when producing a music expression.  However, \xxx always
receives the origin information pertaining to the current location
even if previous point-and-click information exists."

That's rather "Cows and dogs give birth.  However, fishes lay eggs."

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.

> It's quite possible that the description is perfectly ok and i'm
> just dumb/tired, but then i guess it wouldn't hurt to make it a bit
> simpler.  Could you change it so that it more explicitely says what
> was the situation before commit and what it is after?

The situation before the commit was rather muddled, mostly not
generating any point-and-click information for # and overwriting any
existing information for $ and \.  It was not as much designed as a
consequence of what (single) code location the point-and-click stuff
happened to get placed with.

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.

[janek, 2013-03-13 15:44:20]

On Wed, Mar 13, 2013 at 9:11 AM,  <dak@gnu.org> 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

[dak, 2013-03-13 15:56:58]

On 2013/03/13 15:44:20, janek wrote:
> On Wed, Mar 13, 2013 at 9:11 AM,  <mailto:dak@gnu.org> 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".

Sigh.  "However," and "In contrast," mean _exactly_ the same.
Besides, \xxx is indeed untouched in behavior and continues to do foo
as it used to.  It is now special-cased (while it shared code and
behavior with $ previously) but indeed, the behavior for it is exactly
the same as before.

[janek, 2013-03-13 16:12:14]

On Wed, Mar 13, 2013 at 4:56 PM,  <dak@gnu.org> wrote:
> On 2013/03/13 15:44:20, janek wrote:
>> 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".
>
> Sigh.  "However," and "In contrast," mean _exactly_ the same.
> Besides, \xxx is indeed untouched in behavior and continues to do foo
> as it used to.  It is now special-cased (while it shared code and
> behavior with $ previously) but indeed, the behavior for it is exactly
> the same as before.

:/  I was afraid there was something i missed.  I apologize for being
so dimwitted.
Nevertheless, i think that using imperative for commit messages is a
good idea anyway.

Janek