lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 4155 in lilypond: Patch: Add original-breaks.l


From: lilypond
Subject: Re: [Lilypond-auto] Issue 4155 in lilypond: Patch: Add original-breaks.ly commands
Date: Wed, 15 Oct 2014 15:14:15 +0000


Comment #15 on issue 4155 by address@hidden: Patch: Add original-breaks.ly commands
https://code.google.com/p/lilypond/issues/detail?id=4155

Since LilyPond should be useful for more than just single use cases

I stand to the statement that "my" use case is one of very general relevance.

and the _basic_ problem seems to be one that tagging is supposed to be good for, it would be helpful if you tried to help with figuring out which changes in the "tagging infrastructure" would actually make a difference regarding your case.

I'm afraid I can't help with that because these are actually incompatible requirements. The suggested solutions with the use of tags all "suffer" from one thing: They would still require the actual commands to be defined in the document itself or in a library. And if that's the case I simply don't need any patch because I can already do it with the same amount of effort. My point in making the functionality available in LilyPond itself is two-fold: offering easier accessibility and thus promoting its use - to the benefit of all who use LilyPond to copy from existing sheet music. And I'd like to enable editing tools like Frescobaldi or Denemo to offer an interface to that.

I still think the "basic problem" is something different from the type of problems tags are intended for. My use case is (as said) not to be able to address different output targets but to provide different modes of compilation. Actually it's the same as turning point-and-click on and off: While developing you want the feature but for release you want to have it switched off. This is *not* implemented through tags but through command line options. Please note that I didn't ask for a new command line option. Being able to access the functionality through defining variables would be perfectly sufficient. To give you half a point: If I'd have multiple manuscripts and would want to reflect their different breakings, *then* I agree we'd have a tagging situation, using things like \tag #'manuscript \origBreak in one place and \tag #'publication \origBreak in another.


Can you try helping to flesh out a solution where you can comfortably say "this fits my use case reasonably straightforwardly" without arriving at something _only_ useful for a single purpose?

I don't see the problem with commands that only serve a single purpose. \stemDown also serves one single purpose.

However, a solution that would fit my case perfectly well and that could also be fruitful in a more general way would be to *add* such a library to LilyPond. This could be as simple as adding a directory to the LilyPond distribution that will automatically be in the include path. For this there could be less strict demands for being reviewed, in a way similar to what e.g. TeXLive does. Basically they include *any* package submitted to CTAN if it has a suitable license and doesn't expose any significant technical installation issues. Of course the situation is different with LilyPond, but the idea could be similar.

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

[Prev in Thread] Current Thread [Next in Thread]