[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Naming _another_ lacking puzzle piece
From: |
David Kastrup |
Subject: |
Re: Naming _another_ lacking puzzle piece |
Date: |
Sat, 13 Oct 2012 23:29:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) |
Joe Neeman <address@hidden> writes:
> On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup <address@hidden> wrote:
>
>
>
>
> No. I am just pissed at the people clamoring for more ignorance,
> more
>
> bugs, and less control.
>
> If you are referring to Werner's and Reinhold's comments, I think you
> may not be reading them as the authors intended. In particular, I
> believe that Reinhold was merely objecting to the names "push" and
> "pop" as being opaque to non-programmers,
To me it is not only this inconsitency, but rather that the names
push/pop come from programming languages and concepts.
Lately, I have seen many suggestions that would turn lilypond more
^^^^^
into a programming language and away from being a description of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
music. Now, while lilypond really is a programming language, in the
past we have tried to hide the concepts (e.g. queue theory) from the
user, with more or less success.
David's attempts to get rid of the #' in propery names is a great step
in this direction, but using push/pop would be a huge step in the
wrong direction, IMO.
> while Werner was complaining that the plethora of new
> context-manipulation functions have become confusing.
That makes it sound like it would be a chaotic bunch. And what do we
have?
\override overwrites the last definition
\revert throws it away/reestablishes the previous if not overwritten.
Then we have modifiers for possibly multiple combined overrides, as
those are for example available in large numbers in property-init.ly and
we want to be able to use them for as many things as possible without
having to retype them with modifications.
\once \override non-destructively masks the definition for one
time step, then restores
\temporary \override non-destructively masks the last definition
\undo \override drops like corresponding \reverts would
A \tweak goes through a music object rather than through context
properties, so we get
\single \override (again an \override prefix) converts into one or more
tweaks
All those are separate tools, apply in the same manner to one or
multiple overrides, to get a clear effect derived from the original
\override-based command, and complementing each other in functionality.
People shout "I want fewer", but they are a set. It's like saying you
want a smaller set of spanners, so you leave out every second one. But
that means that you won't be able to do a random subset of required
tasks because the spanners are a full set. You can't just randomly
leave out some and expect to be able to still do every job.
> I interpret his comments as a request for orthogonalization rather
> than a complaint about the options that the new commands
> introduce.
What's not orthogonal here? _Every_ modifier works on \overrides
(granted, \undo will also work on \set but just because it does not make
sense not to include this as well). \once allows a one-step temporary
replacement, \temporary and \undo allow the start and stop of a
temporary replacement to be separately specified.
\single converts into a different grob modifier mechanism.
No, the complaint was clear, from several parties:
I get the feeling that we have to completely reconsider how \set,
\revert, and friends are named and used. Your clean-ups and
reorganization of the syntax reveal more and more inconsistencies,
and my head starts aching if I think of \once, \undo, and so on.
[...]
In other words, we have \override, \tweak, \set, \revert, \unset,
\undo, \single (and maybe more). It's getting confusing, at least
for me. I'd prefer to decrease the number of such functions, not
increase them (without deleting functionality, of course).
[...]
Plus \once and now \temporary. I agree this menagerie is going to
be far more confusing to users than the occasional unexpected result
after calling \crossStaff or \harmonicByFret - which no one has ever
noticed. Users get quite confused enough with just \override,
\revert, \set, \unset and \tweak.
We're going too far in this direction now.
> Now, it's true that the comments may not have been entirely
> constructive as they didn't propose alternatives, but I also don't
> think anyone claimed that your proposal is worse than the status quo.
The last comment above states "we're going too far in this direction
now", calls the commands a "confusing menagerie" and states that nobody
noticed the kind of bugs one can fix with that anyway. "quite confused
enough" clearly strongly speaks against providing any more commands,
preferring to stay with problems instead.
> For what it's worth, I think push, pop and clear (perhaps with more
> intuitive-to-non-programmer names) makes a nicer stack interface than
> push, pop-push and pop.
What is "clear" supposed to be?
> I also think that "undo" should be rethought in light of this recent
> discussion. In particular, this discussion has made me realize that
> "undo" doesn't just reverse the effect of an override, since after
> \override Something #'color = #green \override Something #'color =
> #red \undo\override Something #'color = #red, then the color is not
> back to green as one might think.
An \override overwrites the last value if any, and it is gone. That's
not a problem of \undo.
> What if we gave the users a "push, pop and clear" interface and we
> made overrides use "push" and \oneVoice use "clear"? This solves the
> \voiceOne\voiceTwo\oneVoice
> problem
No. Quite a few commands intended to be used "at bottom" have a
combination of overrides and reverts. Having the reverts remove
everything to bottom of stack and the overrides not is not going to make
things more predictable.
> \override Something #'color = #green
> \override Something #'color = #red
> \undo\override Something #'color = #green
> go back to the pre-green color.
Not useful. This is primarily of interest when the outer and the middle
part are provided from different sources and don't know what the
respective other is, and if the middle part happened to be \override
Something #'color = #green for whatever reason, suddenly the scope of
the \undo would flip.
--
David Kastrup
- Re: Naming _another_ lacking puzzle piece, (continued)
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Nalesnik, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Nalesnik, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/13
Re: Naming _another_ lacking puzzle piece, Janek Warchoł, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, Janek Warchoł, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/13
- Re: Naming _another_ lacking puzzle piece,
David Kastrup <=
- Re: Naming _another_ lacking puzzle piece, Reinhold Kainhofer, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, James, 2012/10/13
- Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/14
- Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
Re: Naming _another_ lacking puzzle piece, Joe Neeman, 2012/10/13
Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14
Re: Naming _another_ lacking puzzle piece, Trevor Daniels, 2012/10/14
Re: Naming _another_ lacking puzzle piece, David Kastrup, 2012/10/14