#2002 Enhancement: Add \hideNote function for hiding single notes only

[Anonymous]

Originally created by: *anonymous

Originally created by: pkx1... (code.google.com)@gmail.com

Adam Spiers lilypond-devel@adamspiers.org via gnu.org to lilypond-devel
--snip--

I noticed that we already have \hideNotes and \unHideNotes, but that
is rather clumsy when you only want to hide a single note.  So I wrote
a patch to add \hideNote, and as a newbie to Lilypond development I
wanted to check that this was a sensible idea.

The patch is here,

https://github.com/aspiers/lilypond/commit/125c734efa2815e358815cdd912acad81940c776

although I haven't tested it properly yet because I'm still getting to
grips with the regression test suite:

It adds one sentence to the documentation which would need
translating.

[Google Importer]

Originally posted by: dak@gnu.org

Issue 2003 <URL:http://codereview.appspot.com/5322065> makes this a matter of

hideNote = \once\hideNotes

and of course you could then just use

\once\hideNotes

directly.  Of course, the bulk of your patch is not implementation but documentation, so it is not exactly a large saving of effort.

But that way might transfer better to similar problems.

[Google Importer]

Originally posted by: dak@gnu.org

Issue 2021 has been merged into this issue.

[Google Importer]

Originally posted by: dak@gnu.org

After looking at ly/property-init.ly, I am of the opinion that it does not make sense to add a single-shot version for one of several dozen of property-setting commands.

The patch from issue 2003 should suffice.  Indeed, the commands in ly/property-init.ly are almost uniformly non-\once.  If we now get one or a few separate only-\once commands with different names, the user interface becomes less logical.

[Google Importer]

Originally posted by: adam.spi... (code.google.com)@gmail.com

I agree - for some reason when this issue was discussed before; I mistakenly got the impression that it was too hard enough to be implemented any time soon, so that my \hideNote patch was still worth submitting.  Having said that,

  \once \hideNotes

is almost as much typing as

  \hideNotes [...] \unHideNotes

so for me ideally we'd have the best of both worlds, i.e. property-init.ly containing

  hideNote = { \once \hideNotes }

(and possibly others) so that the syntactic sugar is available, but its internal implementation avoids any code duplication.  If people are in agreement, most of my patch is still valid, since it's mainly changes to documentation and regtests - the implementation is only one small hunk which can easily be changed.

[Google Importer]

Originally posted by: adam.spi... (code.google.com)@gmail.com

(No comment was entered for this change.)

Labels: Patch-needs_work

[Google Importer]

Originally posted by: gra...@percival-music.ca

http://lilypond.org/doc/v2.15/Documentation/contributor/grand-lilypond-input-syntax-standardization-_0028gliss_0029

unfortunately the debate about this type of syntactic sugar will wait a few months.  Sorry, but I have a strict limit of 10 hours of lilypond work each week, and GLISS has lower priority than making releases, fixing Critical bugs, training new contributors, working on automation, clarifying developer policies in GOP, etc etc.

[Google Importer]

Originally posted by: dak@gnu.org

I don't see what makes \hideNotes more special than any of the dozens of other commands in ly/property-init.ly, so I really don't want to provide it as a core command in Lilypond.

That does not, I repeat not, mean that it does not make perfect sense to define and use \hideNote in documents where it would save considerable typing.  And I definitely agree with you that the user should be able to save typing when necessary.

So I would suggest that you mark this issue as "blocked" on issue 2003, and change your patch by removing the _implementation_ part completely, and instead base your documentation of the user writing
hideNote = \once hideNotes
(no braces required) manually at the start of the document, and use that to illustrate the general possibility of using one-shot property overrides as well as defining shortcuts for them.

The regtest would also get this line added.

Of course, I am shamelessly exploiting your work for the footwork of my own issue.  But I only got thinking about it _because_ of reviewing this, and your notion "I mistakenly got the impression that it was too hard enough to be implemented any time soon" was not at all unreasonable: there are quite a few dark areas in Lilypond that nobody has touched for a long time, even though this might have made things easier elsewhere.

So if you view issue 2003 not as something disrupting your own work or competing with it, but rather enabling you to put your work on a more elegant and general footing than the one you had to start with, perhaps it will get easier to see this not as disrespect.

The real work is documenting this sensibly and creating nice regtests, and you only need few changes to make it fit the new situation perfectly.  Leave the translations to the translators, and you'll find making those changes not all that much work, and certainly not stealing the glory from you just because I subverted the implementation.

@Graham: I don't see this as a GLISS issue as it would just add another command upwards-compatibly.  Making \once applicable to music expressions in total would be more like a GLISS style discussion, though its upward-compatibility makes it a good candidate for passing.

So if anybody is guilty of GLISSading, it is me and not Adam (basically I am throwing a spanner in his works because of my private GLISS).  I could make this a non-GLISS issue by letting \once retain its current implementation, and add a differently named \Once command for the complex cases.  It just seems completely pointless and not helpful to users.

[Google Importer]

Originally posted by: adam.spi... (code.google.com)@gmail.com

Thanks David, we are in almost perfect agreement (especially that your work would make this patch much more elegant), and Graham, I have absolutely no problem with waiting until GLISS - it's easy enough to hack up a stop-gap \include "hideNote.ly", after all.

When the proper time arrives to review syntax, if I'm still around to join the debate I'll be pushing for us not to underestimate the benefits of including syntactic sugar such as \hideNote, \balloonLength, \easyHead, \improvisation etc. as core commands in Lilypond, but I won't say any more on that until then ;-)

Marking as blocked on 2003.

Blockedon: Issue 2003

[Google Importer]

Originally posted by: k-ohara5...@oco.net

Since version 2.15.17 we can use \once\hideNotes

I suggest to the bug squad that this is a complete solution, by setting the fixed label.  Push it back if you can say what more we really want.

Blockedon: -2003
Labels: -Patch-needs_work Fixed_2_15_17

[Google Importer]

Originally posted by: k-ohara5...@oco.net

(No comment was entered for this change.)

Status: Fixed

[Google Importer]

Originally posted by: colingh... (code.google.com)@gmail.com

I had a look at the code review for Issue 2003:

% From:
% http://codereview.appspot.com/5322065/patch/10001/11001

\version "2.15.17"

\header{
  texidoc= "This tests @code{\once} applied to multiple property operations."
}

\relative c' {
  c4 d \hideNotes e4 f |
  \unHideNotes g a \once \hideNotes b c |
}

Running that source against 2.15.34 does results in the expected pattern of shown and hidden notes, whereas running it against 2.14.2 gives a syntax error on the \hideNotes after the \once.

Verified.

Status: Verified