Re: [O] no pdf-output in lilypond code blocks
Hi Achim, Achim Gratz strom...@nexgo.de writes: (or (cdr (assoc (file-name-extension out-file) '((pdf . --pdf ) (ps . --ps ) (png . --png --png ) work just as well? Yes, I've committed this change, thanks. -- Bastien
Re: [O] no pdf-output in lilypond code blocks
Achim Gratz writes: Florian Beck writes: I don't think so. The string evaluates to itself or am I missing something? If it would fall under SELFQUOTING then yes (but I really don't understand what the doc string is trying to tell me there and what would be used for comparison). I've looked at this again and I still don't understand the docstring. I've confirmed that the bytecompiler produces not only a warning during compilation, but the compiled code won't work, so despite indications to the contrary the backquotes are indeed necessary. This means that either the docstring fails to clearly indicate the necessity of using the backquotes on string constants or the bytecompiler fails to compile legal code: I'd suggest you take this example to emacs-bugs and see what the devs have to say. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] no pdf-output in lilypond code blocks
Achim Gratz strom...@nexgo.de writes: Achim Gratz writes: Florian Beck writes: I don't think so. The string evaluates to itself or am I missing something? If it would fall under SELFQUOTING then yes (but I really don't understand what the doc string is trying to tell me there and what would be used for comparison). I've looked at this again and I still don't understand the docstring. I've confirmed that the bytecompiler produces not only a warning during compilation, but the compiled code won't work, I cannot reproduce this. The code works for me and byte compiling doesn't generate any warning. GNU Emacs 24.3.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2013-01-28 on flo-laptop so despite indications to the contrary the backquotes are indeed necessary. This means that either the docstring fails to clearly indicate the necessity of using the backquotes on string constants or the bytecompiler fails to compile legal code: I'd suggest you take this example to emacs-bugs and see what the devs have to say. Regards, Achim. -- Florian Beck
Re: [O] no pdf-output in lilypond code blocks
Florian Beck writes: I cannot reproduce this. The code works for me and byte compiling doesn't generate any warning. GNU Emacs 24.3.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2013-01-28 on flo-laptop Fail: 24.2 (unknown upattern), 23.[34] (malformed function), 22.3 (malformed function) Pass: 24.3.50, 24.2.9[012] So it seems to have been fixed by the macro compilation changes that Stefan Monnier did some months ago. For grins the result with the backquotes: Fail: 23.[34] (old-style backquote warning) 22.3 (old-style backquote warning) Pass: 24.3.50, 24.2.9[012], 24.2 Still not a good idea to use pcase in code that should be backwards compatible… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] no pdf-output in lilypond code blocks
Hi Florian, Florian Beck f...@miszellen.de writes: I can live with setting `ly-gen-pdf', but maybe something like (pcase (file-name-extension out-file) (pdf --pdf ) (ps --ps ) (png --png ) (t --png )) would be even better? Indeed. This is now the case, thanks! -- Bastien
Re: [O] no pdf-output in lilypond code blocks
Bastien writes: Hi Florian, Florian Beck f...@miszellen.de writes: I can live with setting `ly-gen-pdf', but maybe something like (pcase (file-name-extension out-file) (pdf --pdf ) (ps --ps ) (png --png ) (t --png )) would be even better? Indeed. This is now the case, thanks! This would be a bug, I believe you should use backquotes on the string constants if indeed pcase should wend its way into Org (this would be the only place using it): (pcase (file-name-extension out-file) (`pdf --pdf ) (`ps --ps ) (`png --png ) (t --png )) But wouldn't something like (or (cdr (assoc (file-name-extension out-file) '((pdf . --pdf ) (ps . --ps ) (png . --png --png ) work just as well? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] no pdf-output in lilypond code blocks
Achim Gratz strom...@nexgo.de writes: This would be a bug, I believe you should use backquotes on the string constants I don't think so. The string evaluates to itself or am I missing something? The real (but harmless) bug is (t --png )) should be (_ --png )) -- Florian Beck
Re: [O] no pdf-output in lilypond code blocks
Florian Beck writes: I don't think so. The string evaluates to itself or am I missing something? If it would fall under SELFQUOTING then yes (but I really don't understand what the doc string is trying to tell me there and what would be used for comparison). It seems that a string constant is not self-quoting during compilation (the byte-compiler complains about an Unknown upattern `pdf'), most likely due to the pre-expansion of the macro before compilation. Also the string constant pdf compiled ionto the code can not necessarily match itself when compared to a string stored in a variable, although at least in interpretation mode this works. On the other hand a backquoted QPattern where QPattern is a STRING(constant) does use equal for comparison and this is what we want, plus the bytecompiler seems to like that form better than the first. Anyway, pcase is nice when you need it, but in this case I'm not convinced its worth the trouble. It doesn't even put enough syntactic sugar on it to make the code more readable. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] no pdf-output in lilypond code blocks
Hi Florian, Florian Beck f...@miszellen.de writes: If so, I'll fix ly-process-basic so that it depends on ly-gen-png/pdf/html/svg. Thanks for confirming, Thanks for fixing. Done -- please have a try and let me know. -- Bastien
Re: [O] no pdf-output in lilypond code blocks
Bastien b...@altern.org writes: Hi Florian, Florian Beck f...@miszellen.de writes: If so, I'll fix ly-process-basic so that it depends on ly-gen-png/pdf/html/svg. Thanks for confirming, Thanks for fixing. Done -- please have a try and let me know. Minor hitch: the variable is called `ly-use-eps' not `ly-gen-eps'. However, as far as I understand these variables are intended for tangled files. The original bug was that exporting or evaluating a code block doesn't respect the extension of the :file directive. I can live with setting `ly-gen-pdf', but maybe something like (pcase (file-name-extension out-file) (pdf --pdf ) (ps --ps ) (png --png ) (t --png )) would be even better? -- Florian Beck
Re: [O] no pdf-output in lilypond code blocks
Hi Bastien, Line 155 in ob-lilypond.el use --png. Is it okay to use --pdf --html and --svg here too? The only choices are --pdf, --png, and --ps. See: http://www.lilypond.org/doc/v2.16/Documentation/usage/command_002dline-usage#invoking-lilypond If so, I'll fix ly-process-basic so that it depends on ly-gen-png/pdf/html/svg. Thanks for confirming, Thanks for fixing. -- Florian Beck
Re: [O] no pdf-output in lilypond code blocks
Hi Florian, Florian Beck f...@miszellen.de writes: It seems `ly-process-basic' hardcodes a --png option. If I change it to --pdf everything works fine (though it won't produce pngs any more, I guess). Of course, it should really be set as appropriate for the extension. Line 155 in ob-lilypond.el use --png. Is it okay to use --pdf --html and --svg here too? If so, I'll fix ly-process-basic so that it depends on ly-gen-png/pdf/html/svg. Thanks for confirming, -- Bastien
[O] no pdf-output in lilypond code blocks
Hi,
execute the following code block:
#+begin_src lilypond :exports results :file
93bff287-036e-4129-8f17-fd6374f4ccdc.pdf
\header { tagline = ##f }
\score{
\relative c' {
\key d \minor
d2 a'2 f2 d2 }}
#+END_src
This will create a results block:
#+RESULTS:
[[file:93bff287-036e-4129-8f17-fd6374f4ccdc.pdf]]
but actually create the file 93bff287-036e-4129-8f17-fd6374f4ccdc.eps
(note the extension). [I need pdf, because I cannot get xelatex handle
eps files.]
It seems `ly-process-basic' hardcodes a --png option. If I change it
to --pdf everything works fine (though it won't produce pngs any more,
I guess). Of course, it should really be set as appropriate for the extension.
--
Florian Beck
