David Kastrup writes:
> There are also override collections like \voiceOne, and not all
> overrides might apply in every context they are used in: in that case we
> don't want a warning. So it is not an issue quite as simple as it may
> seem at first, but it is definitely on my agenda when I rew
Keith OHara writes:
> David Kastrup gnu.org> writes:
>> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
>> being a context without \defaultchild (to be recursively created from
>> the current context, if that is not a bottom context, by creating the
>> respective defaultchi
>> > I did not hear any serious desire to allow both \f and \F as
>> > distinct.
>>
>> Ugh, it seems that you haven't read my strong objections a few
>> hours ago.
>
> You mostly objected to LilyPond /ignoring/ case, for reasons that
> made sense.
Oops, yes.
Werner
David Kastrup gnu.org> writes:
> "Phil Holmes" philholmes.net> writes:
>
> > What does get me more concerned is how hard
> > it is to find some of the correct ways of tweaking output. Using
> > voice.SomeValue (or is it Voice.someValue) when it should be
> > staff.Somevalue (or was it Staff.so
Keith OHara writes:
> Werner LEMBERG gnu.org> writes:
>
>> Please no heuristics.
>
> By "we" I meant us humans in charge of the software. We humans would
> avoid choosing names like keySignature and KeySignature distinguished
> only by case.
No question about that. Coming up with good names i
Graham Percival writes:
> On Sat, Sep 15, 2012 at 07:56:52PM +0200, Werner LEMBERG wrote:
>>
>> > Distinguishing \f and \F while ignoring case is going to be a rather
>> > difficult operation. While I generally try to accommodate a lot of
>> > "make that work" requests, there are limits to what
Werner LEMBERG gnu.org> writes:
> > I did not hear any serious desire to allow both \f and \F as
> > distinct.
>
> Ugh, it seems that you haven't read my strong objections a few hours
> ago.
You mostly objected to LilyPond /ignoring/ case, for reasons that made sense.
I guess you did say:
> t
>> I agree that distinguishing \f and \F is difficult. [...]
>
> I did not hear any serious desire to allow both \f and \F as
> distinct.
Ugh, it seems that you haven't read my strong objections a few hours
ago.
> To the contrary, the request was to accept (and complain) if we
> mistype
>
> \S
Graham Percival percival-music.ca> writes:
> On Sat, Sep 15, 2012 at 07:56:52PM +0200, Werner LEMBERG wrote:
> >
> > > Distinguishing \f and \F while ignoring case is going to be a rather
> > > difficult operation.
>
> I agree that distinguishing \f and \F is difficult. However, if
> the pro
On Sat, Sep 15, 2012 at 07:56:52PM +0200, Werner LEMBERG wrote:
>
> > Distinguishing \f and \F while ignoring case is going to be a rather
> > difficult operation. While I generally try to accommodate a lot of
> > "make that work" requests, there are limits to what one can achieve
> > when fighti
> Distinguishing \f and \F while ignoring case is going to be a rather
> difficult operation. While I generally try to accommodate a lot of
> "make that work" requests, there are limits to what one can achieve
> when fighting not just the current code base, but rather plain
> logic.
:-)
We
Werner LEMBERG writes:
>> What we're discussing is ideas. No-one has to implement ideas.
>
> Well...
>
>> If there is widespread agreement that the idea is good, then at some
>> point it could be implemented.
>
> ... but as David has correctly mentioned previously, it is not
> fruitful to discus
James writes:
> Hello,
>
> On 15 September 2012 13:55, Werner LEMBERG wrote:
>>
I'm strictly against case-insensivity.
>>>
>>> And I and others are for it. Could you state your reasoning,
>>> please? I've already stated mine.
>>
>> First, it is confusing. Virtually all programming langua
Werner LEMBERG writes:
>> Currently, the parser is still undergoing significant restructuring
>> work in major areas and mechanisms. That work entails a lot of time
>> spent on ironing out parser conflicts where some input would
>> correspond to multiple and diverging interpretations according t
> What we're discussing is ideas. No-one has to implement ideas.
Well...
> If there is widespread agreement that the idea is good, then at some
> point it could be implemented.
... but as David has correctly mentioned previously, it is not
fruitful to discuss something for a long time and make
>> Fourth, Scheme is not case-insensitive.
>
> That's not traditional.
Ah, interesting. I wasn't aware of that. Thanks for the correction.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lil
Werner LEMBERG writes:
>>> I'm strictly against case-insensivity.
>>
>> And I and others are for it. Could you state your reasoning,
>> please? I've already stated mine.
>
> First, it is confusing. Virtually all programming languages of today
> (and lilypond's input code resembles that) are c
- Original Message -
From: "Werner LEMBERG"
To:
Cc:
Sent: Saturday, September 15, 2012 3:24 PM
Subject: Re: [GLISS] - alternative viewpoint
Mhmm. May I recommend a sheet of paper and a pencil instead,
then? :-)
Perhaps you'd prefer to recommend Sibelius, which has no such
difficu
I'm strictly against case-insensivity.
>>
>> First, it is confusing. Virtually all programming languages of today
>> (and lilypond's input code resembles that) are case-sensitive.
>
> So what? I am not a programmer. I am a user.
Urgh. This is a real knock-out argument for everything. Even
Hello,
On 15 September 2012 13:55, Werner LEMBERG wrote:
>
>>> I'm strictly against case-insensivity.
>>
>> And I and others are for it. Could you state your reasoning,
>> please? I've already stated mine.
>
> First, it is confusing. Virtually all programming languages of today
> (and lilypond
> Currently, the parser is still undergoing significant restructuring
> work in major areas and mechanisms. That work entails a lot of time
> spent on ironing out parser conflicts where some input would
> correspond to multiple and diverging interpretations according to
> the current syntax. It
>> I'm strictly against case-insensivity.
>
> And I and others are for it. Could you state your reasoning,
> please? I've already stated mine.
First, it is confusing. Virtually all programming languages of today
(and lilypond's input code resembles that) are case-sensitive.
Second, as David
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Saturday, September 15, 2012 1:08 PM
Subject: Re: [GLISS] - alternative viewpoint
\new Staff works. \New staff doesn't. [...]
I'm strictly against case-insensivity.
And I and others are for it. Could you state your r
> \new Staff works. \New staff doesn't. [...]
I'm strictly against case-insensivity. Guiding the user to find the
right command name (this is, finding the `nearest' command or macro
name to the non-existing one[1]) belongs to the error-help category
IMHO, something which I would add as a reques
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To:
> Sent: Saturday, September 15, 2012 9:20 AM
> Subject: Re: [GLISS] - alternative viewpoint
>
>
>> "Phil Holmes" writes:
>>
>>> And getting rid of case-sensitivity in a lot of this?
>>
>> You need to elaborate.
David Kastrup writes:
>> Is there any
>> possibility to fine-tune this as requested by Phil, in particular,
>> emitting the right usage as an example in the error message?
>
> You mean, currently we basically see the default error message from the
> parser generator. Improving this involves basic
- Original Message -
From: "David Kastrup"
To:
Sent: Saturday, September 15, 2012 9:20 AM
Subject: Re: [GLISS] - alternative viewpoint
"Phil Holmes" writes:
And getting rid of case-sensitivity in a lot of this?
You need to elaborate. It is not clear what you mean with that, and
Werner LEMBERG writes:
>> Here is my multi-stage plan for that:
>
> I essentially agree with everything. Thanks for that plan.
>
>> b) our C++ engravers announce to the type system (and via that, to
>> the documentation) which context properties they read, modify and
>> write. There is no reaso
> Here is my multi-stage plan for that:
I essentially agree with everything. Thanks for that plan.
> b) our C++ engravers announce to the type system (and via that, to
> the documentation) which context properties they read, modify and
> write. There is no reason that this does not also includ
David Kastrup writes:
> Quite agreed. That is what I call "extending the vocabulary", and
> making that feasible continues to be a main objective of my work on
> music functions. We got a few new people on the user list contributing
> music functions so far, but those contributions are not conv
"Phil Holmes" writes:
> OK - so there's been a lot of discussion of pre- and post-fix, and a
> load of other stuff I don't understand.So I had a think about what it
> is about lilypond syntax that p**s me off. And I concluded that it's
> nothing to do with whether we write c4 /p for a quiet croc
On 2012/09/15 06:34:02, Keith wrote:
On 2012/09/13 00:06:12, dak wrote:
> I copy your "not happy" sentiment, but when thinking this through,
> one really wants to have both override and tweak under a reasonably
> idiomatic shortcut available.
After trying them out, the best names I can thin
32 matches
Mail list logo
