Comments (10)
If you make use of the afterpackage
package then there is no need to worry about the package loading order.
from lyluatex.
Now that most developments about lyluatex
itself are done, here are my thoughts about this point. I really like the reference to \includegraphics
: IMHO, lyluatex
should be for musicexamples
what \includegraphics
is to floating environments. \includegraphics
isn't wrapping anything, it is wrappable. So we should ensure the easiest wrappable behavior from lyluatex
, letting wrapping to musicexamples
(or other packages, as users could have other approaches to this problem).
So I agree that musicexamples
shouldn't depend on lyluatex
; but on the other side, I don't think lyluatex
's behavior should be impacted by musicexamples
.
Perhaps the idea that simply adding a caption does all the magic has something appealing, but I also think it may be confusing. IMHO, the following approach would be less confusing:
\newenvironment{lyfigure}[2][]{%
\edef\mycaption{#2}
\figure
\center
\ly[#1]%
}{%
\endly
\caption{\mycaption}
\endcenter
\endfigure
}
Then the user would have to type:
\begin{lyfigure}[LYLUATEX_OPTIONS]{caption}
LY_CODE
\end{lyfigure}
And if the caption must be before the score, this would only be a question of changing the place of \caption
.
I don't say this approach is exempt of rough edges: ly
is a very special environment, that isn't so easily wrappable as is; but I think this would be the way to go.
from lyluatex.
N. B.: you have another example with \lily
in wrappingcommands.tex; this file could serve to experiment that way.
from lyluatex.
I'm with @jperon on this one. I think that while having musicexamples
and lyluatex
work well together is important, the two package should be maintained separately.
Convenience functions which combine the functionality of the two packages strike me something that belong in the user preamble, however, if they are especially complicated I could see writing a separate style file whose specific goal is to combine the two. In this fashion the basic code in both lyluatex
and musicexamples
remains distinct and relatively clear in its purpose. This new style file could be a part of either the musicexamples
or lyluatex
package, or even its own package.
from lyluatex.
from lyluatex.
I think it is somewhat inappropriate to discuss my pull request #135 in this issue out of context. Changes in that pull request are completely isolated from the question of musicexamples
, and @jperon only comments on half of the story here.
Essentially my PR departs from the idea of hardcoded musicexamples
integration. And what it suggests is not “simply adding a caption does all the magic” rather than adding an option environment
that makes the following possible:
\usepackage[environment=figure]{lyluatex}
% or
\begin{lilypond}[%
environment=figure,
caption={My Example}]
c'
\end{lilypond}
and if environment
is set to something each score will automatically be wrapped in that environment (with env-opts
being there to control the optional argument of the environment, for example to control the positioning).
Now if only a caption
is set (and no environment given as package option) the “magic” is simply to implcitly set environment=figure
for that score.
I really don't see how that could be confusing or overly un-LaTeX-y, and it really is a convenience for the user. When writing a document with scores included system-by-system at least half of the use cases include enclosing the scores in environments, and it will help if lyluatex
not only takes care of wrapping the lilypond
call but also automatically creates the environment around the score.
With that in place I can simply use musicexamples
by using its environments here, and I agree that this should be done in “my” document's preamble or my custom style file.
On the other hand I don't agree with the \lyfigure
idea. This is basically a hard-coded figure
environment around the ly score that doesn't seem to help much: This would at least have to be configurable to allow different environments to be used, different env (not lyluatex) options to be applied and the caption to be placed. I think then the name \lyfigure would become misleading, and it would actually be equally practical to have the user enter their environments manually.
I am convinced that my environment
option is a good idea, and it if there is something to be argued against that (within this issue) it is important to forget about the notion of musicexamples
.
from lyluatex.
@uliska I hope you didn't find my comments aggressive: it's quite complicated to explain why I don't agree in short messages, and all I want is to be the most constructive possible. I've no reason to forget about musicexamples
, as I really want to make interaction between it and lyluatex
the most clever possible.
The lyfigure
idea isn't something I'd like to implement within lyluatex
: it's an example of what can be done either by the user in the header, or in a .cls
. What I think about environment
option is that:
- it's an unusual way to proceed (would you expect something like
\includegraphics[environ=figure]{image}
?); - it adds a real degree of complexity in
lyluatex.lua
, whithout solving a problem that wouldn't be better solved by existing LaTeX tools (especially\newenvironment
); - it's even too restrictive: the user could want to add more than
\begin{environment}
and\end{environment}
before and after the score.
In other words, I think lyluatex
should respect the keep it simple, stupid and do one thing and do it well principles to make integration with the rest better.
from lyluatex.
I replied by email, but I don't see the reply on this page, so I'll repost manually:
Am 18.02.2018 um 12:51 schrieb jperon:
@uliska I hope you didn't find my comments aggressive:
I didn't find them aggressive but I have to admit that I was irritated, especially as you seemed to double down on them through action, namely pushes to master.
it's quite complicated to explain why I don't agree in short messages, and all I want is to be the most constructive possible. I've no reason to forget about musicexamples, as I really want to make interaction between it and lyluatex the most clever possible.
The lyfigure idea isn't something I'd like to implement within lyluatex: it's an example of what can be done either by the user in the header, or in a .cls.
OK, I didn't get it that way since you did add it to lyluatex.sty and even on the master branch.
What I think about environment option is that:
- it's an unusual way to proceed (would you expect something like
\includegraphics[environ=figure]{image}
?);
No, but I would gladly accept \usepackage[environment=figure]{graphicx}
or something similar. Well, maybe not with graphicx as that is a quite general package, but if I had a package that created, say, a small flow chart in a TiKZ image I would appreciate the possibility to not always have to explicitly write an environment around it.
In the case of lyluatex
we have three different ways to enter LilyPond music: a command, an environment, and a file inclusion command. With the environment option it's a unified interface how systems can be wrapped in an environment while with the \lyfgure idea one would have to create individual wrappers for each.
I predict that we'll be back at this point no later than when figuring out how to use lyluatex from Pandoc. I don't see how it is acceptable (or even possible) to enclose a code block in a LaTeX environment like
\begin[figure}
```lilypond
c'
```
\end{figure}
- it adds a real degree of complexity in lyluatex.lua, whithout solving a problem that wouldn't be better solved by existing LaTeX tools (especially \newenvironment);
- it's even too restrictive: the user could want to add more than \begin{environment} and \end{environment before and after the score.
That could be taken care of by a command that is similar to \lysetverbenv
. That's what I actually started to do first but then I found the option approach simpler.
In other words, I think lyluatex should respect the keep it simple, stupid and do one thing and do it well principles to make integration with the rest better.
I admit I don't really agree, but I won't push any further with this.
I assume you don't want the horizontal alignment either, because that's also in the domain of what could be handled on the LaTeX side? But I'm not sure I can avoid working with that when handling protrusion.
from lyluatex.
OK, I didn't get it that way since you did add it to lyluatex.sty and even on the master branch.
As you may check, I didn't. wrappingcommands.tex
is, as the folder name indicates it, an example of what can be done.
I don't see how it is acceptable (or even possible) to enclose a code block in a LaTeX environment
It isn't possible. But anyway, Pandoc is another problem, as we'll have to take care of multiple formats for export; so it won't be possible to simply pass options from Pandoc blocks to LaTeX environments.
That could be taken care of by a command that is similar to
\lysetverbenv
. That's what I actually started to do first but then I found the option approach simpler.
I had thought about something similar, and I think it would indeed be the way to go, if we can't make ordinary LaTeX commands work more smoothly with lyluatex
. The reason is that such commands should be invocated before calculating the dimensions of the score, in case they would change some parameters; so they can't be passed as ordinary options.
As of protrusion, I'm really convinced you have a better view on this problem than I do; so if it's necessary to handle some horizontal alignment for that, do what you like. But indeed, if it's possible to avoid making something that's already handled by LaTeX, I'd prefer.
from lyluatex.
merged into #152
from lyluatex.
Related Issues (20)
- \setmainfont causes problems HOT 6
- The score doesn't contain any music HOT 5
- MiKTeX with LilyPond 2.24: blank scores
- attempt to index a nil value ( field 'metadata') HOT 5
- lyluatex runs slowly on mac HOT 8
- Includepaths no longer working HOT 3
- Reuse precompiled files in different document HOT 3
- Some weird alignment issues when using a custom header HOT 5
- TexLive can't find Lilypond anymore HOT 5
- Make lyluatex work with LilyPond 2.25.4 and newer HOT 2
- Make lyluatex process LilyPond snippets in parallel HOT 6
- Error in lilypond-Log: "/bin/sh: 1: Syntax error: Unterminated quoted string" HOT 4
- Print copyright and tagline below song
- Suppress bar numbers HOT 2
- Large left padding with inline inserts HOT 5
- Can't compile on MacOS - bad argument #1 to 'rawget' HOT 1
- Make lyluatex work with LilyPond v2.25.5 and newer
- Found something incompatible with `fragment` HOT 4
- Compilation fails when using `--output-dir=build` option
- included score is not horizontally centered. HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lyluatex.