Comment #15 on issue 4155 by [email protected]: 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
