Thomas Morley <[email protected]> writes: > 2013/3/6 David Kastrup <[email protected]>: > >> It is orthogonal to us making \bar "|:" and \bar ":|" well-defined by >> letting : automatically imply a thick bar since nothing else makes >> sense. >> >> We don't want to point users having a simple understandable problem >> to an explanation for a large problem complex, no matter how good >> that explanation is. >> >> We are using things like "|:" and ":|" because they are semi-WYSIWYG >> and thus intuitive. If people write repeats in non-formal ASCII >> lyrics, like "we'll see this problem, |: time and again :|", they >> will not write .|: or :|. since only typesetters realize that repeat >> signs at the end of a piece are indistinguishable from normal repeat >> signs. > > You mentioned your concerns before (can't find it right now), though, > personally I see no _coding-problem_.
Good. > Well, I might be biased, because, although Marc did the major work, I > spent a lot of time and work on the new barline-interface, too. > > But ofcourse you're right here: > a) > In a text I'd write > p.e > " > This is the "Barform": > |: Stollen :| > Abgesang > " > b) The present barline-interface is "pure" WYSIWYG And one of the points of LilyPond is that it does the right things visually without requiring the user for everything. > c) > The first for any user noticable novelty is the change from \bar ":|" > to \bar ":|." > dito for other repeat-signs. > This is covered by a convert-rule. Sure. The question is not how to avoid users having to change habits. The question is what the best user interface would be for someone not having previous exposure to LilyPond. > Ok, you'd prefer processing ":|" as colon-thin-thick-barline with no > need for a converting-rule. > Well, here I think different: I do like the "pure" WYSIWYG-approach > and I'm not convinced that a semi-WYSIWYG-approach would really be > more intuitive. You are assuming that the average user is aware of the visual composition of repeat signs. But that's LilyPond's responsibility. We use "|." for the end bar not because of its _visual_ properties, but because of a _logical_ property, ending a piece. WYSIWYG would be "I" or "|I" or "|]" instead (again, it is not really the job of the user to remember that a thick bar line is always accompanied by a thin one, so he writes something akin to "give me a bar line fit for ending a piece"). "." is in no way a thicker bar line than "|" is. So the whole "WYSIWYG" analogy/principle is a rather strained one, and that means that nobody will understand it without getting a thorough explanation. > What do other users/developers think? My guess would be that they trust the programmers to have good reasons for doing things like they do. I am also pretty sure that in a "frequently asked questions" list for LilyPond, this one will end up occupying a rather high place. And I don't think that is warranted. > Can we reach a consensus? Well, I am a doomsayer faced with optimists. The easiest way to reach consensus is to just wait. I just doubt that we are doing our users a favor with that... >> Do we really need to give _every_ _single_ person on the user list >> the same advice, again and again? > > My first thought would be: Let us improve the documentation. Eure Rede sei "Ja, Ja, Nein, Nein". Alles, was darüber hinaus ist, ist von Übel. The difference between a bad music instrument and a good music instrument is not that a good musician can only make good music on a good instrument. The difference is that a good instrument lets him focus on the music rather than on the instrument, and thus enables him to become a good musician in the first place. I have enjoyed working on the Bach solo partitas and sonatas. They are really tough (containing four part fugues for the violin, not an instrument typical for chord play), but the toughness is not self-serving but serves a musical purpose. You can play the Urtext easily since there never is a serious question about fingering. For much of the material, there is a single fingering making much more sense (or even being possible) than any other fingering. You don't need documentation to figure out how Bach wants you to work with your violin. Working with LilyPond is inherently complex, so people have to learn dealing with complexity. But I want them to get a reasonable payback for that and not get them exhausted on things that don't help them get better into LilyPond. When people consult the documentation, I want them to primarily learn something about LilyPond rather than about its developers. >> While it is quite more efficient to condense it in the manual and >> point to that, pointing every single user to this manual section is >> going to get old as well. > > Well, yes, though, every new code which is expected to be used by > every LilyPond-user will need some time before it is fully understood > and excepted. It was (and sometimes is) the same with the > beaming-rules and spacing-procedures introduced with 2.14. I am not sure our spacing procedures have been accepted. From a user interface design point of view, they are O(n^2) which scales rather badly. I think we'd fare better with a user interface specifying before/after space of any construct, with LilyPond constructing x-y-spacing = max (after-x-spacing, before-y-spacing) by itself. That's a much more natural view. It offers fewer possibilities, but most of the additional possibilities don't even make sense, so having more possibilities does not correspond with having more power to do useful things. >> After telling enough people "the problem is actually simple, it is >> just you who are incompetent", maybe we should think twice about what >> we have to gain by making LilyPond users feel incompetent. > > I never wrote or intended that!! > If any user feels offended by the style/manner of my explanation I > very much apologize. Misunderstanding here: I was not complaining about your explanation, but rather about it being needed in the first place. Yes, there will be a point where one needs documentation, and there will be a point where one needs to thoroughly think about things. But the longer we can postpone these points, the more empowered and competent our users will feel. Because we are giving them an instrument making it easier for them to achieve their goals, letting them focus on their goals rather than on fighting LilyPond. That's a lot of verbiage for a small issue. It will be easier to convince you once you have answered the respective user mails for a year or so. And I am pretty sure that they'll continue to arrive. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
