Thomas Morley <thomasmorle...@gmail.com> writes: > 2016-09-02 13:28 GMT+02:00 David Kastrup <d...@gnu.org>: >> Thomas Morley <thomasmorle...@gmail.com> writes: >> >>> Below an in-file fix curing the symptoms. >>> >>> David, apart from fixing the internals, does it make sense to prepare >>> a patch for bracketify-stencil at the lines of: >>> >>> \version "2.19.47" >>> >>> %% not public, c/p from lily-library.scm >>> #(define (other-axis a) >>> (remainder (+ a 1) 2)) >>> >>> %% doesn't makes sense to bracketify an empty stencil, hence we just >>> return it >> >> I'm not sure whether this would warrant a more detailed approach. For >> one thing, there probably should be a minimum height of the brackets so >> that they stay recognizable. For another, I would sort-of expect that >> an empty stencil is bracketed similarly to a point-stencil _except_ that >> the padding between the brackets is used only once instead of twice. >> Similarly for \hspace (use the given space plus _one_ padding). >> >> That's what feels natural and useful to me, but of course, other >> behaviors might also have a reasonable rationale. >> >> -- >> David Kastrup > > Not sure I agree, putting out something visible for bracketifying an > empty stencil feels strange to me. As a user I wouldn't expect it. > Otoh, there is the hspace-example... > I'm not decided yet.
Nothing if empty, only single padding (along with mandatory minimal height) if Y-empty? That works with hspace but will leave empty stencils alone. Probably not fantastic for this use case, but sounds like it would be logical. Of course, then one should check what parenthesize-stencil does and have it match that behavior... -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
