Re: Issue 2859: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Janek Warchoł]

On Wed, Oct 3, 2012 at 10:05 PM,   wrote:
>
> Here are a few other suggestions:
>   120 Moby Thesaurus words for "annihilate": [...]

Let's call it \slay.  After that we only need to create a Dragon grob
and we'll have a fairy-tale.

;)

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2859: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[dak]

On 2012/10/03 19:32:15, pounderd_lineone.net wrote:


>Original Message
>From: mailto:d...@gnu.org
>Call me an optimist, but I think we are good now.



Apologies if this ship has sailed, but has anyone considered \suppress



and \unsuppress?


The ship has not sailed, but retailoring the sails at the current
stage is probably not going to be met with a lot of enthusiasm.

Disadvantages I see for \suppress are that it is longer to type.
Also, with \omit/\hide I find it easier to guess which of the two is
not even going to reserve space.  \omit sounds more like something
being left out from the start than \suppress does.  Between omitting a
sneeze and suppressing a sneeze, the latter sounds like a lot more
work.

With regard to grammatical awkwardness of reversal, \un\suppress and
\un\omit are about on par: unsuppress is not really a proper word even
though unsuppressed is (but it is not the past participle of the
negation of suppress, but rather the negation of the past participle
of suppress).

So figure me unimpressed.

Here are a few other suggestions:
  120 Moby Thesaurus words for "annihilate":
 abate, abolish, abrogate, abscind, amputate, annul, ban, bar,
 bereave of life, blot out, bob, bring to naught, cancel,
 carry away, carry off, chloroform, clip, crop, cull, cut, cut away,
 cut down, cut off, cut out, decimate, demolish, deprive of life,
 deracinate, destroy, dispatch, dispose of, do away with, do for,
 do to death, dock, efface, eliminate, end, enucleate, eradicate,
 erase, except, excise, exclude, execute, expunge, exterminate,
 extinguish, extirpate, finish, finish off, immolate, invalidate,
 isolate, kill, knock off, launch into eternity, liquidate, lop,
 lynch, make away with, martyr, martyrize, massacre, murder,
 mutilate, negate, negative, nip, nullify, obliterate, pare, peel,
 pick out, poison, prune, purge, put away, put down, put to death,
 put to sleep, quash, quell, quench, raze, remove, remove from life,
 repeal, revoke, root out, root up, rout, ruin, rule out, sacrifice,
 set apart, set aside, shave, shear, slay, squash, stamp out,
 starve, strike off, strip, strip off, suppress, sweep away,
 take life, take off, take out, truncate, unbuild, undo, uproot,
 vitiate, void, wipe out, wrack, wreck

  81 Moby Thesaurus words for "omit":
 abandon, abbreviate, abridge, ban, bar, bar out, blink at,
 blockade, blot out, blue-pencil, bowdlerize, cancel, censor,
 count out, cross out, cut, cut off, cut out, debar, dele, delete,
 discount, disregard, edit, edit out, embargo, eradicate, erase,
 except, exclude, expunge, expurgate, fail, forget, freeze out,
 goldbrick, goof off, ignore, jump, keep out, kill, leave,
 leave loose ends, leave out, leave undone, let alone, let be,
 let dangle, let go, let slide, lock out, malinger, miss, neglect,
 obliterate, ostracize, overlook, overpass, pass over, pass up,
 preclude, pretermit, procrastinate, prohibit, reject, relegate,
 repudiate, rescind, rub out, send to Coventry, shirk, shut out,
 skip, slack, slight, strike, strike off, strike out, taboo, trifle,
 void

  239 Moby Thesaurus words for "suppress":
 abate, absorb the shock, allay, alleviate, annihilate, arrest,
 asphyxiate, assuage, attemper, ban, bank the fire, bar, beat down,
 bend, black out, block, blunt, bottle up, break, break down,
 break the fall, bring low, bring to terms, browbeat, bulldoze,
 bully, castrate, cease, censor, chasten, check, choke, choke off,
 clamp down on, coerce, compel, conceal, conquer, constrain,
 control, cork, cork up, countercheck, cover up, cow, crack down on,
 crush, curb, cushion, cut off, dam up, damp, damp down, dampen,
 daunt, de-emphasize, deaden, debar, delay, deny, despotize, detain,
 diminish, disallow, discontinue, domineer, domineer over, downplay,
 drown, dull, dwarf, embargo, end, enjoin, enslave, exclude,
 exclude from, extenuate, extinguish, fell, flatten, forbid, gag,
 grind, grind down, halt, henpeck, hide, hinder, hold back,
 hold down, hold in, hold in check, hold up, hugger-mugger, humble,
 humiliate, hush, hush up, hush-hush, impede, inhibit, intercept,
 interdict, interfere, intermeddle, interrupt, intervene,
 intimidate, jump on, keep, keep back, keep down, keep in,
 keep in check, keep quiet, keep secret, keep under,
 keep under control, keep within bounds, kill, lay, lenify, lessen,
 lighten, lock in, lord it over, maintain, master, meddle, mitigate,
 moderate, modulate, muffle, mute, muzzle, neutralize, obstruct,
 obtund, offset, oppose, oppress, outlaw, overawe, overbear,
 overmaster, override, overwhelm, palliate, play down,
 pour water on, preclude, preserve, press heavy on, prevent,
 prohibit, proscribe, prostrate, put, put down, put out, quash,
 quell, quench, quiet, reduce, reduce the temperat

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

[David Kastrup]

Werner LEMBERG  writes:

>>> I prefer \single to \next.
>>>
>>> \justOne \onlyOne ?
>> 
>> It is, in a way, a complement to \once, so I would want to avoid
>> multiple-word approaches leading to CamelCase.
>
> Had someone already suggested \here?

Yes.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

[Werner LEMBERG]

>> I prefer \single to \next.
>>
>> \justOne \onlyOne ?
> 
> It is, in a way, a complement to \once, so I would want to avoid
> multiple-word approaches leading to CamelCase.

Had someone already suggested \here?


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

[David Kastrup]

"Trevor Daniels"  writes:

> David Kastrup wrote Saturday, September 29, 2012 4:47 PM
>
>> Since by far the easiest time to press a change is before a first
>> version is installed, people should speak up now if they feel that
>>  is significantly better than
>>  for changing just the head on e', or if
>> they think they have another good name.
>
> I prefer \single to \next.
>
> \justOne \onlyOne ?

It is, in a way, a complement to \once, so I would want to avoid
multiple-word approaches leading to CamelCase.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

[Trevor Daniels]

David Kastrup wrote Saturday, September 29, 2012 4:47 PM


> Marc Hohl  writes:
> 
>> Am 29.09.2012 11:01, schrieb David Kastrup:
>>> Marc Hohl  writes:
>>>
 Am 28.09.2012 17:40, schrieb d...@gnu.org:
>> hmm... not quite perfect.
>> No other idea, though...
> \here misses the relation to the next item (not that \single is much
> better).  \directly was nicer in that regard.  \next would possibly also
> work.
 Having to choose between \single and \next, I would take \next.
>>> After thinking this over, I realized what worries me about \next: next
>>> is a loop control command in a number of different languages like awk,
>>> perl, Python.
>> ... or think about TeX ;-)
>>>   It is also frequently used for linked list pointers.  All
>>> of those common uses in computing are quite grammatically different in
>>> their usage.
>> But on the other hand, we talk about usability, and I am not quite sure
>> that *every* user thinks Perl/Python/TeX when he or she writes Lilypond.
>> And \next seems to be more self-explanatory than \single (at least to
>> me, it is).
> 
> I am not convinced.  Unless I see either a new proposal that I feel I
> can get behind myself, or more prominent public support for one of the
> numerous existing proposals including \next, I am going to stick with
> \single.
> 
> Since by far the easiest time to press a change is before a first
> version is installed, people should speak up now if they feel that
>  is significantly better than
>  for changing just the head on e', or if
> they think they have another good name.

I prefer \single to \next.

\justOne \onlyOne ?

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Marc Hohl]

Am 29.09.2012 18:54, schrieb Colin Campbell:

On 12-09-29 09:47 AM, David Kastrup wrote:

I am not convinced.  Unless I see either a new proposal that I feel I
can get behind myself, or more prominent public support for one of the
numerous existing proposals including \next, I am going to stick with
\single.

Since by far the easiest time to press a change is before a first
version is installed, people should speak up now if they feel that
 is significantly better than
 for changing just the head on e', or if
they think they have another good name.




From a relatively uninformed point of view, \single seems to be 
directly and tightly coupled to the object following it, and only to 
that one object, only for the life of that object.  \next doesn't seem 
quite so definite and restricted, for some reason, perhaps because 
there could be an implication that it applies to the next instance of 
the object either before or after the \next token.

You are a native speaker, so I would trust you more than my feelings.
\single would be ok for me then.
  It's early and the caffeine level is rather low in the brain stem, 
but \single is the more clear term for me.

Well, here it is 19:00 and the caffeine level is rather low already ;-)

Regards,

Marc


Cheers,
Colin




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Colin Campbell]

On 12-09-29 09:47 AM, David Kastrup wrote:

I am not convinced.  Unless I see either a new proposal that I feel I
can get behind myself, or more prominent public support for one of the
numerous existing proposals including \next, I am going to stick with
\single.

Since by far the easiest time to press a change is before a first
version is installed, people should speak up now if they feel that
 is significantly better than
 for changing just the head on e', or if
they think they have another good name.




From a relatively uninformed point of view, \single seems to be 
directly and tightly coupled to the object following it, and only to 
that one object, only for the life of that object.  \next doesn't seem 
quite so definite and restricted, for some reason, perhaps because there 
could be an implication that it applies to the next instance of the 
object either before or after the \next token.  It's early and the 
caffeine level is rather low in the brain stem, but \single is the more 
clear term for me.


Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands.
You need to be able to throw something back.
-Maya Angelou, poet (1928- )


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[David Kastrup]

Marc Hohl  writes:

> Am 29.09.2012 11:01, schrieb David Kastrup:
>> Marc Hohl  writes:
>>
>>> Am 28.09.2012 17:40, schrieb d...@gnu.org:
> hmm... not quite perfect.
> No other idea, though...
 \here misses the relation to the next item (not that \single is much
 better).  \directly was nicer in that regard.  \next would possibly also
 work.
>>> Having to choose between \single and \next, I would take \next.
>> After thinking this over, I realized what worries me about \next: next
>> is a loop control command in a number of different languages like awk,
>> perl, Python.
> ... or think about TeX ;-)
>>   It is also frequently used for linked list pointers.  All
>> of those common uses in computing are quite grammatically different in
>> their usage.
> But on the other hand, we talk about usability, and I am not quite sure
> that *every* user thinks Perl/Python/TeX when he or she writes Lilypond.
> And \next seems to be more self-explanatory than \single (at least to
> me, it is).

I am not convinced.  Unless I see either a new proposal that I feel I
can get behind myself, or more prominent public support for one of the
numerous existing proposals including \next, I am going to stick with
\single.

Since by far the easiest time to press a change is before a first
version is installed, people should speak up now if they feel that
 is significantly better than
 for changing just the head on e', or if
they think they have another good name.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Marc Hohl]

Am 29.09.2012 11:01, schrieb David Kastrup:

Marc Hohl  writes:


Am 28.09.2012 17:40, schrieb d...@gnu.org:

hmm... not quite perfect.
No other idea, though...

\here misses the relation to the next item (not that \single is much
better).  \directly was nicer in that regard.  \next would possibly also
work.

Having to choose between \single and \next, I would take \next.

After thinking this over, I realized what worries me about \next: next
is a loop control command in a number of different languages like awk,
perl, Python.

... or think about TeX ;-)

  It is also frequently used for linked list pointers.  All
of those common uses in computing are quite grammatically different in
their usage.

But on the other hand, we talk about usability, and I am not quite sure
that *every* user thinks Perl/Python/TeX when he or she writes Lilypond.
And \next seems to be more self-explanatory than \single (at least to 
me, it is).


Regards,

Marc





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[David Kastrup]

Marc Hohl  writes:

> Am 28.09.2012 17:40, schrieb d...@gnu.org:

>>
>>> hmm... not quite perfect.
>>> No other idea, though...
>>
>> \here misses the relation to the next item (not that \single is much
>> better).  \directly was nicer in that regard.  \next would possibly also
>> work.
> Having to choose between \single and \next, I would take \next.

After thinking this over, I realized what worries me about \next: next
is a loop control command in a number of different languages like awk,
perl, Python.  It is also frequently used for linked list pointers.  All
of those common uses in computing are quite grammatically different in
their usage.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Marc Hohl]

Am 28.09.2012 17:40, schrieb d...@gnu.org:

On 2012/09/28 15:06:38, janek wrote:

On Fri, Sep 28, 2012 at 9:30 AM,  wrote:
> I must be in a controversial mood today since I feel like upholding

the

> idea.  I had been thinking about it while fetching breakfast and

eating

> and was about to reenter discussion when I found that I had already
> convinced you, so this is a bit awkward.



lol :)
Actually, my cousin gave another reason to change \omit to something
else: in his opinion omit implies \once in meaning.  Like, \omit
StringNumber sounds like only one StringNumber won't be printed.


Maybe.


> The only drawback is that one might want \yes/\no as a pairing for

some

> different purpose.  \no is really a rather important word.



Yes, this is my concern, too.


Well, at some point of time we need to crack it open, anyway.


What about \delete ?  Afaik it's not taken yet.


Guile begs to differ:
scheme@(guile-user)> delete
$1 = #


On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl 

wrote:

> Am 28.09.2012 09:30, schrieb d...@gnu.org:
>> And things like \once\no Clef also work reasonably well.  The

proposed

>> "\single" is more awkward, but "\single\omit Clef" is not that much
>> better, so maybe "\single" should change.
>
> I don't feel quite happy with \single either; just a spontaneous

idea:

>
> does \here work?
>
> \here\EasyNoteHeadsOn c8 d e
>
> I'm not sure ...



hmm... not quite perfect.
No other idea, though...


\here misses the relation to the next item (not that \single is much
better).  \directly was nicer in that regard.  \next would possibly also
work.

Having to choose between \single and \next, I would take \next.

Regards,

Marc


http://codereview.appspot.com/6575048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Werner LEMBERG]

> The only drawback is that one might want \yes/\no as a pairing for some
> different purpose.  \no is really a rather important word.

I don't think that this is a problem, at least I've never seen someone
using \no.  It's exactly the same amount to type as ##f.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[dak]

On 2012/09/28 15:06:38, janek wrote:

On Fri, Sep 28, 2012 at 9:30 AM,   wrote:
> I must be in a controversial mood today since I feel like upholding

the

> idea.  I had been thinking about it while fetching breakfast and

eating

> and was about to reenter discussion when I found that I had already
> convinced you, so this is a bit awkward.



lol :)
Actually, my cousin gave another reason to change \omit to something
else: in his opinion omit implies \once in meaning.  Like, \omit
StringNumber sounds like only one StringNumber won't be printed.


Maybe.


> The only drawback is that one might want \yes/\no as a pairing for

some

> different purpose.  \no is really a rather important word.



Yes, this is my concern, too.


Well, at some point of time we need to crack it open, anyway.


What about \delete ?  Afaik it's not taken yet.


Guile begs to differ:
scheme@(guile-user)> delete
$1 = #


On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl 

wrote:

> Am 28.09.2012 09:30, schrieb d...@gnu.org:
>> And things like \once\no Clef also work reasonably well.  The

proposed

>> "\single" is more awkward, but "\single\omit Clef" is not that much
>> better, so maybe "\single" should change.
>
> I don't feel quite happy with \single either; just a spontaneous

idea:

>
> does \here work?
>
> \here\EasyNoteHeadsOn c8 d e
>
> I'm not sure ...



hmm... not quite perfect.
No other idea, though...


\here misses the relation to the next item (not that \single is much
better).  \directly was nicer in that regard.  \next would possibly also
work.

http://codereview.appspot.com/6575048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Janek Warchoł]

On Fri, Sep 28, 2012 at 9:30 AM,   wrote:
> I must be in a controversial mood today since I feel like upholding the
> idea.  I had been thinking about it while fetching breakfast and eating
> and was about to reenter discussion when I found that I had already
> convinced you, so this is a bit awkward.

lol :)
Actually, my cousin gave another reason to change \omit to something
else: in his opinion omit implies \once in meaning.  Like, \omit
StringNumber sounds like only one StringNumber won't be printed.

> The only drawback is that one might want \yes/\no as a pairing for some
> different purpose.  \no is really a rather important word.

Yes, this is my concern, too.
What about \delete ?  Afaik it's not taken yet.


On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl  wrote:
> Am 28.09.2012 09:30, schrieb d...@gnu.org:
>> And things like \once\no Clef also work reasonably well.  The proposed
>> "\single" is more awkward, but "\single\omit Clef" is not that much
>> better, so maybe "\single" should change.
>
> I don't feel quite happy with \single either; just a spontaneous idea:
>
> does \here work?
>
> \here\EasyNoteHeadsOn c8 d e
>
> I'm not sure ...

hmm... not quite perfect.
No other idea, though...

best,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Marc Hohl]

Am 28.09.2012 09:30, schrieb d...@gnu.org:

[...]

And things like \once\no Clef also work reasonably well.  The proposed
"\single" is more awkward, but "\single\omit Clef" is not that much
better, so maybe "\single" should change.

I don't feel quite happy with \single either; just a spontaneous idea:

does \here work?

\here\EasyNoteHeadsOn c8 d e

I'm not sure ...

Marc



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[dak]

On 2012/09/28 06:26:03, janek wrote:

On Fri, Sep 28, 2012 at 7:33 AM,   wrote:
>> what about using \no for turning stencil off? e.g.
>> \new Voice \with { \no StringNumber }
>
> It is grammatically cuter in connection with \with, but that's

actually

> more a problem of \with than of \omit: every other command working

on

> properties is a verb: \set, \override, \revert, \hide*.



antother disadvantage of \no is that one would expect plural after it,
i.e. \no StringNumbers.
So i drop the idea.


I must be in a controversial mood today since I feel like upholding the
idea.  I had been thinking about it while fetching breakfast and eating
and was about to reenter discussion when I found that I had already
convinced you, so this is a bit awkward.

The thing is that when a user picks between "\hide" and "\omit" without
much of a clue, "\omit" should rather be the preferred choice.

\no StringNumber
\no TimeSignature
\no Clef

looks quite no-nonsense.  Granted,

\omit StringNumber
\omit TimeSignature
\omit Clef

is quite straightforward as well but it looks a bit more like something
has been forgotten.  I don't thing that the absence of plural is an
issue.  After all, you can use "no" like "No tie, no shirt: no service!"
and you would not say "He was wearing no shirts.".

And things like \once\no Clef also work reasonably well.  The proposed
"\single" is more awkward, but "\single\omit Clef" is not that much
better, so maybe "\single" should change.

The only drawback is that one might want \yes/\no as a pairing for some
different purpose.  \no is really a rather important word.

http://codereview.appspot.com/6575048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[Janek Warchoł]

On Fri, Sep 28, 2012 at 7:33 AM,   wrote:
>> what about using \no for turning stencil off? e.g.
>> \new Voice \with { \no StringNumber }
>
> It is grammatically cuter in connection with \with, but that's actually
> more a problem of \with than of \omit: every other command working on
> properties is a verb: \set, \override, \revert, \hide*.

antother disadvantage of \no is that one would expect plural after it,
i.e. \no StringNumbers.
So i drop the idea.

best,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[dak]

Reviewers: janek,

Message:
On 2012/09/28 05:18:42, janek wrote:

sorry to join the discussion so late...



what about using \no for turning stencil off? e.g.
\new Voice \with { \no StringNumber }



As for the code, it LGTM.


It is grammatically cuter in connection with \with, but that's actually
more a problem of \with than of \omit: every other command working on
properties is a verb: \set, \override, \revert, \hide*.

So while \no definitely has its charme, I think it makes sense to stay
consistent here.  If you want to have more than a one-on-one discussion
on it, it might make sense bringing your proposal up on the developer
list to give it more exposure.  It is not that I am wildly opposed, it
is just that I think "\omit" fits better into our naming schemes and is
less likely than "\no" to make users think of something different.

Description:
Provide \hide and \omit functions for transparent and void glyphs

Both functions take either a grob name to override, or a music
expression to tweak (that is, the type of the argument decides whether
this results in an override or a tweak).

\hide sets #'transparent for the affected grob to ##t,
\omit sets #'stencil for the affected grob to ##f.

Example uses are
\new Voice \with { \omit StringNumber } { c'\4 }
{  g' }

Add string-or-music? predicate

Please review this at http://codereview.appspot.com/6575048/

Affected files:
  M ly/music-functions-init.ly
  M scm/c++.scm
  M scm/lily.scm


Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
e1dcd992e00bf66c60fa7e09e012632732fc7db6..cbdd007c5289bc9b9d7e2ee1f49a484dd0953343  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -475,6 +475,18 @@ given through @var{ratio}.")
 \revert NoteHead #'stencil
   #})

+hide =
+#(define-music-function (parser location item) (string-or-music?)
+   (_i "Set @var{item}'s @samp{transparent} property to @code{#t},
+making it invisible while still retaining its dimensions.
+
+If @var{item} is a string, the result is an override for the grob name
+specified by it.  If @var{item} is a music expression, the result is
+the same music expression with an appropriate tweak applied to it.")
+   (if (string? item)
+   #{ \override $item #'transparent = ##t #}
+   #{ \tweak #'transparent ##t $item #}))
+
 inStaffSegno =
 #(define-music-function (parser location) ()
(_i "Put the segno variant 'varsegno' at this position into the staff,
@@ -664,6 +676,18 @@ octaveCheck =
(make-music 'RelativeOctaveCheck
'pitch pitch))

+omit =
+#(define-music-function (parser location item) (string-or-music?)
+   (_i "Set @var{item}'s @samp{stencil} property to @code{#f},
+effectively omitting it without taking up space.
+
+If @var{item} is a string, the result is an override for the grob name
+specified by it.  If @var{item} is a music expression, the result is
+the same music expression with an appropriate tweak applied to it.")
+   (if (string? item)
+   #{ \override $item #'stencil = ##f #}
+   #{ \tweak #'stencil ##f $item #}))
+
 once =
 #(define-music-function (parser location music) (ly:music?)
(_i "Set @code{once} to @code{#t} on all layout instruction events in  
@var{music}.")

Index: scm/c++.scm
diff --git a/scm/c++.scm b/scm/c++.scm
index  
ded5e9b1209bc0c0be4627db018962d7196eb0f1..444a3e9ba6534b9201c26937785bcbb4fc9e6a5d  
100644

--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -57,6 +57,9 @@
 (define-public (string-or-pair? x)
   (or (string? x) (pair? x)))

+(define-public (string-or-music? x)
+  (or (string? x) (ly:music? x)))
+
 (define-public (number-or-pair? x)
   (or (number? x) (pair? x)))

Index: scm/lily.scm
diff --git a/scm/lily.scm b/scm/lily.scm
index  
9bc04dbddf085f646046893197dd0f11e17dd918..3ee924a1b1c44c429e635156416d8789af7a74de  
100644

--- a/scm/lily.scm
+++ b/scm/lily.scm
@@ -505,6 +505,7 @@ messages into errors.")
 (,rhythmic-location? . "rhythmic location")
 (,scheme? . "any type")
 (,string-or-pair? . "string or pair")
+(,string-or-music? . "string or music")
 (,string-or-symbol? . "string or symbol")
 (,void? . "void")
 ))



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

[janek . lilypond]

sorry to join the discussion so late...

what about using \no for turning stencil off? e.g.
\new Voice \with { \no StringNumber }

As for the code, it LGTM.

http://codereview.appspot.com/6575048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel