Implement \hidden/\hide as a shorthands for \tweak/override #'\stencil = ##f

Implement \hidden/\hide as a shorthands for \tweak/override #'\stencil = ##f

[Graham Percival, 2012-09-12 23:20:46]

I'm really not happy with \hide vs. \hidden depending on whether it's override
or tweak.  How do we expect novice users (or moderate users) to know which they
need to use?

[dak, 2012-09-13 00:06:12]

On 2012/09/12 23:20:46, Graham Percival wrote:
> I'm really not happy with \hide vs. \hidden depending on whether it's override
> or tweak.  How do we expect novice users (or moderate users) to know which
they
> need to use?

How do we expect them to know whether to use \override or \tweak?

I could offer using \hide for both uses like we do with \footnote, by writing
\default in lieu of a music event.  However,

\new Voice \with { \hide StringNumber \default } { ... }

leaves me quite unenthusiastic even though it uses a more functional rather than
grammatical distinction between override and tweak.

I copy your "not happy" sentiment, but when thinking this through, one really
wants to have both override and tweak under a reasonably idiomatic shortcut
available.  If we can only have one, I'd probably take the override since it can
be used in context modifications as well and better matches existing \hide*.

[Graham Percival, 2012-09-13 01:29:35]

On Thu, Sep 13, 2012 at 12:06:12AM +0000, dak@gnu.org wrote:
> How do we expect them to know whether to use \override or \tweak?

I actually don't know.  However, there's nothing in the word
"hide" that brings to mind "tweak" to me.  I suppose that we could
argue that \hide goes with \tweak because they're both the shorter
command, but that seems really weak.  (and also it's the opposite
of the current patch)

What about \hideOverride and \hideTweak ?  or \hideGrob vs.
\hideWhateverElse ?
(not serious suggestions, just thinking out loud)


Ultimately, I really wish that we could end up with a single
\modify command, merging \override \tweak \set \overrideProperty.
But until/unless that happens, I think that giving users a bit
more of a hint than \hidden \hide would be good.

- Graham

[Keith, 2012-09-15 06:34:02]

On 2012/09/13 00:06:12, dak wrote:

> I copy your "not happy" sentiment, but when thinking this through, 
> one really wants to have both override and tweak under a reasonably 
> idiomatic shortcut available.  

After trying them out, the best names I can think of are:

 "hideOne" for the tweak; it should be a verb like "tweak" is a verb, and the
article reminds us to say "one what", unless it directly follows.

 "hideAll" for the override, analogous to hideNotes, again with the article
reminding us to say "all what" and clarifying that it affects all such grobs
from this point forward.

(Maybe "one" and "all" are not considered to be articles in English ... but they
should be.)

 { g4 g-\hideOne\ff->\trill a \hideOne Stem a 
   c \hideAll Stem c  d d  }

As you say, one can say \once\hideAll, and it has pretty much the same effect as
\hideOne, which is nicely unsurprising.

I suggest you put them in, announce as a tentative new feature in changes.tely,
and see if people find them useful.  My only concern is that \override NoteHead
#'stencil = ##f  now causes Lily to hang (I noticed just now) and I hesitate to
make that easier.
  \override

[dak, 2012-09-15 07:25:08]

On 2012/09/15 06:34:02, Keith wrote:
> On 2012/09/13 00:06:12, dak wrote:
> 
> > I copy your "not happy" sentiment, but when thinking this through, 
> > one really wants to have both override and tweak under a reasonably 
> > idiomatic shortcut available.  
> 
> After trying them out, the best names I can think of are:
> 
>  "hideOne" for the tweak; it should be a verb like "tweak" is a verb, and the
> article reminds us to say "one what", unless it directly follows.
> 
>  "hideAll" for the override, analogous to hideNotes, again with the article
> reminding us to say "all what" and clarifying that it affects all such grobs
> from this point forward.
> 
> (Maybe "one" and "all" are not considered to be articles in English ... but
they
> should be.)
> 
>  { g4 g-\hideOne\ff->\trill a \hideOne Stem a 
>    c \hideAll Stem c  d d  }
> 
> As you say, one can say \once\hideAll, and it has pretty much the same effect
as
> \hideOne, which is nicely unsurprising.
> 
> I suggest you put them in, announce as a tentative new feature in
changes.tely,

Nice try, but I won't sneak last-minute changes past the discussion.  Since
there are potentially more cases like this and it does not make sense to do them
inconsistently, we better take the time and leisure to think this through to the
degree we can and reach at least some sort of semi-agreement.

"\tweak" and "\override" are reasonably mnemonic, since "\tweak" changes an
actual object, and "\override" overrides a decision.  I am not exactly
enthusiastic about camel-caps (and I would not want to suggest using underlines
or dashes instead since that would open a much larger "consistency" can of
worms).  Here is one possible way out: only provide the override, ever.  That's
what basically all our preprovided property-setting commands do.  And if we
provide only one basic variant and that is the tweak, we have to remember that a
tweak takes an argument to tweak and you would have to \default that argument
(we actually use that technique for \footnote), something which is a bit
cumbersome to do explicitly every time.

We can already apply \once to more complex property-setting commands.  How about
using a different prefix, like \one or \single, that will take an override and a
music argument and will convert that override into a tweak on the music
argument?

It won't work entirely seamlessly as there is no obvious way (to me) to convert
a \revert into a \tweak without actually performing the revert and looking at
its effects (and I don't think we can easily undo the revert afterwards), so
this will just be able to work on \override and nothing else, but it would open
most of the world of property changes to usage as a tweak.

It would mean having to write more in the input, but it would save us from
inventing camelcase constructs and clever word pairs.