Hi all,
Just adding my 2ยข...
I might disagree. I'm big on semantics, and I would rather have a
lot of commands that create the same look but mean different
things, than have one command that creates a look which could mean
a lot of different things. I don't know how people will be using
LilyPond in the future, but I'd like for the program not to get
stuck in ambiguous semantics.
I agree with your concern with semantics.
-1: I would much rather see one WISIWYG (What It Says Is What You
Get) function rather than multiple WIMGRITSCDF (What It Means Gets
Resolved Internally To Some Completely Different Function) functions.
First of all, it minimizes namespace crowding; secondly, it reduces
confusion and complexity in the docs (no need for crossrefs, etc.).
The user semantic would be worse.
-1: The *composer-user* semantic might [!] be worse, but the
*engraver-user* semantic would be better.
There are two different kinds of semantics that apply. One is the
semantic
that the composer sees. The other is the semantic that the
engraver sees.
If by "engraver" you mean "person who is using Lilypond to engrave",
then +1. =)
The main problem I see in this thread is that we're trying to turn
Lilypond into a *composing* application rather than thinking of it as
purely an *engraving* application: when I *compose* for strings (I
use pen and paper) I create/use/think "harmonics", but when I
*engrave* the score (I use Lilypond) I code/use/think "diamond".
There could be an argument that we don't want to unnecessarily
expand the namespace
+1.
I think that your argument about having correct semantics is a
valid argument.
Meh... -1/2. ;)
Kieren.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
