Am Sa., 19. Okt. 2019 um 05:22 Uhr schrieb Andrew Bernard <andrew.bern...@gmail.com>: > > I have not seen anything get added to lilypond proper for a long time. > I may be wrong, but it's immensely difficult to get changes to core it would > seem. Fair enough too. That's why openlilylib exists.
Nothing against openlilyib or the LSR. Though: $ git log --oneline --since=1.9.2019 8ba40d3d69 (HEAD -> master, origin/staging, origin/master, origin/HEAD) Issue 5571: streamline cat | sed | sed 75b16466ef Issue 5564: fix conversion warnings in beaming code 2d45d5247e Drop requirement for python-devel a6a6f019a9 Fix header variables from musicxml2ly on Windows fa6c70e39a Issue 5567: allow slurs instead of brackets with tuplets cd11e1d06e Update python headers to match surrounding files b7532cf6e6 Issue 5568: make build output terse by default 5674d4570d NR: add snippet to describe `NoteCollision.prefer-dotted-right' 058c7347c1 granados.ly: Improved and updated. c95d96aa71 Typo. d9555cda14 Issue 5565: simplify python-related makefiles 2f1649830b Issue 5559/4: fix regression (ambitus with ottava) 6f319a862d Issue 5556/3: make OttavaBracket text default bold 608aa55988 Issue 5559/2: add regtest 476194c706 Issue 5559/1: Add user-definable ottava markups 7e6a956625 Issue 5561/5562: slurs work without NoteHead stencil 2c2908c905 Issue 5563: make edges of brackets dashable 09bc2e2ed7 Issue 5560: remove script-chart.ly 7930d8777e Issue 5558/2: NR: various minor corrections 3064ac9d3d Issue 5558/1: NR: add many index entries for snippets 1d255547ba Run scripts/auxiliar/makelsr.py 9bef63308f Issue 5557: Remove spurious '% begin verbatim' in Documentation/snippets/new 71c4990e47 run-and-check: Display correct log file directory. c2b424f9f8 Remove old make-countdown-announcement.sh ab3b23941f Issue 5555/3: TimeScaledMusic should not be music-wrapper-music eed07c3e54 Issue 5555/2: add_post_events: check for time-scaled-music explicitly 4402d6c545 Issue 5555/1: reorder checks in add_post_events for efficiency 0457814df4 string-tunings-init: Fix typo in Banjo tuning. 1d3105fce4 run-and-check: Show output directory in case of error. a6f8381ea4 stockhausen-klavierstueckII: Completely rewritten. be39d353b7 Rename `Stockhausen_Klavierstueck2' to `stockhausen-klavierstueckII'. 805e6ef94c bach-schenker.ly: Completely revised. 89036755a7 Replace code.google.com by SourceForge e926c294e3 Issue 5553: fix handling of @lilypond[verbatim] 227fac3a04 We now need texinfo 6.1 or newer. b2799c1823 Issue 5552/2: NR: complete revision of all index entries 714792a1eb Issue 5552/1: HOWTO.index: new guide for creating index entries 1eed54e8ff Issue 5551/2: improve generated documentation 2165edafc5 Issue 5551/1: better indexing support is not exactly what I'd call nothing ;) > > But in fact, while I think this is neat code, I personally strongly > disapprove of underlining, single or double, being a dreary minded classical > typographer myself, and underlining is generally frowned upon anyway in fine > printing (maybe music is not fine printing?) So I would not actually want to > see this encouraged, even though I can see people have uses for it. I don't understand your point. \underline is a markup-command for text. I think every text-typesetting-program has this functionality. Why should we disencourage it? Speaking only for myself I use underline pretty often in educational typesettings and have used it in some serious contemporary music-typesetting as well (composer's request). Cheers, Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user