bug-lilypond
[Top][All Lists]
Advanced

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

Re: Make defining new contexts simpler with better \alias functionality


From: David Kastrup
Subject: Re: Make defining new contexts simpler with better \alias functionality
Date: Fri, 06 Mar 2015 16:11:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Paul Morris <address@hidden> writes:

> This is not a bug but an enhancement idea.
>
> Make defining new contexts simpler with better \alias functionality.
>
> Use \alias for determining what contexts accept other contexts (and
> not just for allowing commands accepted in one context to be used in
> another context).
>
> Jim Long:
>
> “...it would be nice, if it is practical, for "Higher" contexts to
> decide to accept "Lower" contexts based on context name (\ChordNames)
> as well as on alias (\alias ChordNames).
>
> A would accept C because A accepts B, and C is explicitly 
> declared as an alias of B.  Therefore, A would accept B and all 
> aliases of B.”
>
> Paul Morris: 
>
> "Most of the time if we want commands that work in X to work in Y (by
> using \alias X), we also want Y to be accepted wherever X is accepted.
>
> So when Z is determining whether to accept a new context Y... have it
> first check Y's name, and if the name is unknown (not in its "accepts"
> list) then have it check Y's alias (\alias X).  If the alias X is in
> the "accepts" list, then Z would accept Y.

"Most of the time" is not enough.  We don't want a normal Staff to
accept a TabVoice.  Arguably, _most_ \alias "Voice" contexts are not
suitable for inclusion in a \Staff.

> In rare cases where we didn't want these things coupled (where we
> wanted commands from X to work in Y, but we didn't want Y to be
> accepted wherever X is accepted), then we could use \denies and
> \accepts to define exactly where we want Y to be accepted or denied.

That does not work since contexts have no notion of what other contexts
may accept them and \denies does not maintain a list of its own but just
removes material from the \accepts lines.  If an alias is to be accepted
in lieu of an actual context, there is no way to dial back the
acceptance.

> This would really simplify the process of creating custom contexts,
> especially in the common case of wanting a modified version of an
> existing context that works everywhere it does.”
>
> See full discussion thread here:
> http://lists.gnu.org/archive/html/lilypond-user/2015-02/msg00684.html

The discussion does not lead to any workable conclusion.  In its course,
there is a proposal of an additional \alias-like command that would
differ with regard to \alias in that it would declare acceptability.
That's all very wishy-washy.

I think it would make more sense to have a command that will walk
through an output definition and make the required changes, like

\accept-like Voice myVoice
\layout {
  \context {
    \Voice
    \name "myVoice"
    ...
  }
}

That does not require new internals and is pretty straightforward to
write as a scheme function taking two symbols and an output definition
as arguments and returning an output definition.

-- 
David Kastrup



reply via email to

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