[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SLopUF: context name

From: Robin Bannister
Subject: SLopUF: context name
Date: Thu, 14 Aug 2008 22:31:18 +0200

Hallo again!

At the end of LM 3.3.2. there is the caution:
Note the distinction between the name of the context type, Staff, Voice, etc,
and the identifying name of a particular instance of that type ...

Well, I can manage that, I think. Because when I'm looking at the snippets, these names look quite different: one lot are in quotes.

But when I start reading in the manuals about using these names I get confused.
LM says, for example,
 > context name (like Staff or Voice)
But when NR says
 > when setting lyrics the melody is in a named context
it is talking about an identifying name. And quite often they mention > context type which could make someone think that that was something different again, i.e. something else to learn about, but maybe it is because it would be inappropriate to say "name" at that point or maybe "name" is being used nearby for something else.

OK. I know this doesn't fit in with the docs schedule. And I shouldn't really be reading NR 5 yet. This feedback goes orthogonal to the section view, and so will be untimely in many different ways. Feel free to ignore it (for the time being).

Two weak rules:
WR1 Avoid "name" as a verb. WR2. Keep "context" and "name" words well apart. WR1 is because the this verb is ambiguous: A: to refer to by name (like the <type> of \context)
 B: to give a name to     (like the = <id> of \context)
i.e. this is important when used near "\context" where the author might mean A and the reader understands B. (This may only apply to English, but English is the language being translated.)

WR2 is like taking big strides when your shoelaces are undone. It doesn't apply if there is a qualifier which reduces the ambiguity sufficiently: e.g. named voice context (already has a type name, so must mean id) The lilypond word "context" itself is ambiguous if alone, applying to either type or instance. (I'm not talking about normal discourse, which copes with ambiguity). Unambiguity is most important in the command syntax sections. It is less important elsewhere but only if there are watertight definitions the puzzled reader can refer to when needing clarification. To apply these rules you have to find suitable words/phrases to replace the forbidden ones. ________________________________________________

I thought I would try this out to see if it produced something clearer for me. On starting I ran into a different problem: the placeholders used in the new/context/set/override syntax sections vary a lot, making it difficult for the reader to see the similarities. I unified the placeholders for <type> and <id> (but left the others unchanged) and thought up some new verbs. The result is attached as TAB-separated csv with 3 columns: - section numbering - phrases/sentences I considered relevant to to "context" and "name" - my rewording of those phrases/sentences which violated WR1/2.

Cheers, Robin


Attachment: LM.csv
Description: Binary data

Attachment: NR.csv
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]