David Kastrup writes:
I think it was during the documentation of the footnote stuff that we
came up with several examples (including use of s1*0/) that made clear
that we were better off refining the code rather than the documentation.
And that's fine. Changing code because it would be too
Hello,
On 24 September 2012 09:22, Jan Nieuwenhuizen jann...@gnu.org wrote:
David Kastrup writes:
I think it was during the documentation of the footnote stuff that we
came up with several examples (including use of s1*0/) that made clear
that we were better off refining the code rather than
Graham Percival wrote Sunday, September 23, 2012 7:50 AM
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
So I repeat my proposal again: a developer *must* include
regression tests, he *should* do the doc work, but if he feels
not very comfortable at writing some paragraphs for
Sue Daniels s...@treda.co.uk writes:
Graham Percival wrote Sunday, September 23, 2012 7:50 AM
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
So I repeat my proposal again: a developer *must* include
regression tests, he *should* do the doc work, but if he feels
not very
Hi all,
On Mon, Sep 17, 2012 at 11:28 PM, Janek Warchoł
janek.lilyp...@gmail.com wrote:
James,
[...]
Now i feel offended, both as a user and a developer.
At first i was going to write a long reply to your email, but then i
thougt that it would only result in more misunderstandings. Can we
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
Am 21.09.2012 11:00, schrieb David Kastrup:
A user interface change without documentation or regtest is dead code.
Regtests are somewhat mandatory:
http://lilypond.org/doc/v2.17/Documentation/contributor/write-regression-tests
but
Sue Daniels s...@treda.co.uk writes:
Graham Percival wrote Sunday, September 23, 2012 7:50 AM
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
So I repeat my proposal again: a developer *must* include
regression tests, he *should* do the doc work, but if he feels
not very
James pkx1...@gmail.com writes:
But I believe unless we now do something that is backward-incompatible
with a (yet) undocumented function in the Notation or Learning manuals
that we don't hold back the patch for the code, it would be nice to
have it all documented as well, but that isn't
Am 23.09.2012 08:50, schrieb Graham Percival:
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote:
Am 21.09.2012 11:00, schrieb David Kastrup:
A user interface change without documentation or regtest is dead code.
Regtests are somewhat mandatory:
Am 21.09.2012 11:00, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
But I don't want to tackle around with the documentation *yet* while
it is not sure that my patch gets accepted and the new interface is
considered a good idea by most of the developers. So while in an
ideal world
Hi,
i'm sorry for the delay :-( There are so many emails flying around
that i find it hard to keep up.
Don't feel obliged to reply to any i don't understand part - i have
so many emails to write that some of my questions may remain
unanswered.
On Sun, Sep 16, 2012 at 6:02 PM, David Kastrup
On Sun, Sep 16, 2012 at 6:05 PM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
Hmm, this sounds complicated. Do you mean that implementing more
informative (custom) error messages with current parser will wreak
havoc, but if we simplify the parser first, it
On Thu, Sep 20, 2012 at 11:56 AM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
Within your own scores, be consistent in your choices. How this
consistency looks, does not matter. Within LilyPond, there is a large
consistency which elements are uppercase, and which
On Sat, Sep 22, 2012 at 1:42 PM, Marc Hohl m...@hohlart.de wrote:
It would be interesting to post such issues on the -user list,
because this would give users a possiblility to contribute *and*
to describe the new feature from a user's point of view which
is not a bad thing, after all.
+1.
Am 21.09.2012 00:31, schrieb Thomas Morley:
[...]
Hi David, Marc,
speaking only for me: I'm terrible sorry that I currently can't give
you the feedback you desire. Since my injury, I wasn't able to
concentrate on any more involved project or to finish any larger one.
Also, I let Marc
Marc Hohl m...@hohlart.de writes:
But I don't want to tackle around with the documentation *yet* while
it is not sure that my patch gets accepted and the new interface is
considered a good idea by most of the developers. So while in an
ideal world every programmer enhances the documentation
David Kastrup d...@gnu.org writes:
Within your own scores, be consistent in your choices. How this
consistency looks, does not matter. Within LilyPond, there is a large
consistency which elements are uppercase, and which lowercase. The one
thing that actually gets annoying is CamelCase.
Am 20.09.2012 11:56, schrieb David Kastrup:
David Kastrup d...@gnu.org writes:
Within your own scores, be consistent in your choices. How this
consistency looks, does not matter. Within LilyPond, there is a large
consistency which elements are uppercase, and which lowercase. The one
thing
Marc Hohl m...@hohlart.de writes:
Am 20.09.2012 11:56, schrieb David Kastrup:
David Kastrup d...@gnu.org writes:
Within your own scores, be consistent in your choices. How this
consistency looks, does not matter. Within LilyPond, there is a large
consistency which elements are uppercase,
[sorry, forgot to hit Reply to all]
Am 20.09.2012 19:02, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
[...]
The problem is not people not interested in this kind of
discussions/proposals. The problem is people who stop being interested
in an oh so important problem the moment one
Sorry, forgot to complete the mail adresses.
2012/9/20 David Kastrup d...@gnu.org:
Marc Hohl m...@hohlart.de writes:
[...]
But we don't have users involved either. And those are actually the
ones for which such additions are made. Involving them instead in a
planning stage largely
Francisco Vila paconet@gmail.com writes:
2012/9/16 David Kastrup d...@gnu.org:
This is the developer list, after all.
Hey, I have the Dragon Book in my bedside table, I can give a language
to my daughter for her birthday, and still find some things difficult.
Why am I the one figuring
2012/9/17 David Kastrup d...@gnu.org:
Francisco Vila paconet@gmail.com writes:
2012/9/16 David Kastrup d...@gnu.org:
This is the developer list, after all.
Hey, I have the Dragon Book in my bedside table, I can give a language
to my daughter for her birthday, and still find some things
James,
On Sat, Sep 15, 2012 at 3:45 PM, James pkx1...@gmail.com wrote:
Third, the numbers of short user-definable abbreviations gets halved.
Something like
F = \markup { Horn in F }
would no longer be possible because \f is already in use.
So what? You are a developer, fix that. I do
On Sat, Sep 15, 2012 at 5:25 PM, Werner LEMBERG w...@gnu.org wrote:
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
Janek Warchoł janek.lilyp...@gmail.com writes:
On Sat, Sep 15, 2012 at 5:25 PM, Werner LEMBERG w...@gnu.org wrote:
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
... but as David has correctly mentioned previously, it is not
fruitful to discuss something for a long time and make everyone
agree to it, just to find out later on that the idea can't be
implemented in the current framework.
I agree that doing so isn't fruitful. However, it may be better
On Fri, Sep 14, 2012 at 6:56 PM, Phil Holmes em...@philholmes.net wrote:
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.someValue)
Hi,
On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup d...@gnu.org wrote:
Yup. Here is my multi-stage plan for that:
Great! It's inspiring to see such a big plan :)
b) our C++ engravers announce to the type system (and via that, to the
documentation) which context properties they read,
On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup d...@gnu.org wrote:
You mean, currently we basically see the default error message from the
parser generator. Improving this involves basically accepting errors in
input and acting on them by putting out hand-tailored messages.
Currently, the
Janek Warchoł janek.lilyp...@gmail.com writes:
On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup d...@gnu.org wrote:
You mean, currently we basically see the default error message from the
parser generator. Improving this involves basically accepting errors in
input and acting on them by
Janek Warchoł janek.lilyp...@gmail.com writes:
Hi,
On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup d...@gnu.org wrote:
Yup. Here is my multi-stage plan for that:
Great! It's inspiring to see such a big plan :)
b) our C++ engravers announce to the type system (and via that, to the
2012/9/16 David Kastrup d...@gnu.org:
This is the developer list, after all.
Hey, I have the Dragon Book in my bedside table, I can give a language
to my daughter for her birthday, and still find some things difficult.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
Phil Holmes em...@philholmes.net 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
David Kastrup d...@gnu.org 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
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 include
Werner LEMBERG w...@gnu.org 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
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Saturday, September 15, 2012 9:20 AM
Subject: Re: [GLISS] - alternative viewpoint
Phil Holmes em...@philholmes.net writes:
And getting rid of case-sensitivity in a lot of this?
You need
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 basically
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Saturday, September 15, 2012 9:20 AM
Subject: Re: [GLISS] - alternative viewpoint
Phil Holmes em...@philholmes.net writes:
And getting rid of case
\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
- Original Message -
From: Werner LEMBERG w...@gnu.org
To: m...@philholmes.net
Cc: lilypond-devel@gnu.org; d...@gnu.org
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
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 has
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 is
:
- Original Message -
From: David Kastrup d...@gnu.org
To: lilypond-devel@gnu.org
Sent: Saturday, September 15, 2012 9:20 AM
Subject: Re: [GLISS] - alternative viewpoint
Phil Holmes em...@philholmes.net writes:
And getting rid of case-sensitivity in a lot of this?
\new Staff works. \New
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 TeX,
which
- Original Message -
From: Werner LEMBERG w...@gnu.org
To: pkx1...@gmail.com
Cc: lilypond-devel@gnu.org
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
Werner LEMBERG w...@gnu.org 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
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
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
Werner LEMBERG w...@gnu.org 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
James pkx1...@gmail.com writes:
Hello,
On 15 September 2012 13:55, Werner LEMBERG w...@gnu.org 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
Werner LEMBERG w...@gnu.org 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
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.
:-)
Werner
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 fighting not
Graham Percival graham at 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
David Kastrup dak at gnu.org writes:
Phil Holmes email at 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
Keith OHara k-ohara5...@oco.net writes:
David Kastrup dak at 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
David Kastrup d...@gnu.org 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
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 crochet c, as opposed to /p 4c.
On 14 sept. 2012, at 19:56, Phil Holmes em...@philholmes.net wrote:
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
Am 14.09.2012 19:10, schrieb m...@mikesolomon.org:
On 14 sept. 2012, at 19:56, Phil Holmes em...@philholmes.net wrote:
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
On Fri, Sep 14, 2012 at 10:13:00PM +0200, Marc Hohl wrote:
\include guitarSettings
\include choirSettings \with { \SATBoptions }
So you are thinking along the lines of the LaTex package system.
I would go along with that.
Bernard.
___
2012/9/14 Phil Holmes em...@philholmes.net:
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
64 matches
Mail list logo
