[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLISS] differentiating pre/post/neutral commands
From: |
David Kastrup |
Subject: |
Re: [GLISS] differentiating pre/post/neutral commands |
Date: |
Tue, 04 Sep 2012 01:23:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
Thomas Morley <address@hidden> writes:
> That said, now some thoughts ontopic:
> In most cases I'm quite fine with the current lily-syntax concerning
> the pre/post-commands.
> But there are cases I'd wish to be more consequent.
>
> Example:
> <c-1\2\rightHandFinger #2 g>
> Sometimes backslash, sometimes dash!
Dash is required for single-character shorthands like -. -- -^ -_ -3 and
similar. It is also required when a _music_ function returning an
articulation follows (like \tweak ... -.). It is not required when an
event function or a variable containing an articulation follows. You
_can_ always add it.
> Well,
> <c-1\2-\rightHandFinger #2 g'>1
> works, too.
>
> But
> <c-1-\2-\rightHandFinger #2 g'>1
> not.
Why wouldn't it? [trying it out] Pfffffft. You are right. I consider
this a bug worth fixing.
> BTW, writing this post and looking for more examples I was surprised,
> that sometimes adding a dash to a post-command works already:
>
> c1-\startTextSpan f-\stopTextSpan
It should always work, without exception. It is just that sometimes it
is optional.
> Summarize:
> I'd vote for no extrem changes to the syntax, but to improve it
> slightly in a more consequent manner.
> Maybe it should be _possible_ to prepend a dash to every post-command.
That's definitely the intent.
> Concerning music-functions, I think we should keep the current
> behaviour. Music-functions mostly affect a larger section of music,
> appending them to any single event would be curious, except this _is_
> the wanted behaviour:
> c-\parenthesize-|
I would like to have this become equivalent to c\parenthesize-| but it
still requires some work to allow LilyPond to _first_ call a music
function, _then_ decide whether the result is a post-event to be
attached to the previous note.
--
David Kastrup
- Re: [GLISS] differentiating pre/post/neutral commands, (continued)
- Re: [GLISS] differentiating pre/post/neutral commands, Han-Wen Nienhuys, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Werner LEMBERG, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Werner LEMBERG, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Jan Nieuwenhuizen, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Werner LEMBERG, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Thomas Morley, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands,
David Kastrup <=
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, Thomas Morley, 2012/09/03
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Graham Percival, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Werner LEMBERG, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Werner LEMBERG, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Benkő Pál, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Francisco Vila, 2012/09/04
- Re: [GLISS] differentiating pre/post/neutral commands, Reinhold Kainhofer, 2012/09/05
- Re: [GLISS] differentiating pre/post/neutral commands, David Kastrup, 2012/09/05