Re: Org-babel-lilypond always renders full pages
This throws an error:
org-babel-exp process emacs-lisp at position 1...
org-babel-exp process lilypond at position 480...
sort: Wrong type argument: stringp, (:prologue . "paper{
indent=0mm
line-width=120mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}")
On 30.03.20 07:35, stardiviner wrote:
You might want to try this:
#+begin_src emacs-lisp
(add-to-list 'org-babel-default-header-args:lilypond
'((:prologue . "\paper{
indent=0\mm
line-width=120\mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}")))
#+end_src
Re: Org-babel-lilypond always renders full pages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
You might want to try this:
#+begin_src emacs-lisp
(add-to-list 'org-babel-default-header-args:lilypond
'((:prologue . "\paper{
indent=0\mm
line-width=120\mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}")))
#+end_src
Oliver Heck writes:
> Hi Jonathan,
>
> that works fine. Thank you!
>
> Can I set this as default header somewhere in the org file or will I have to
> include it to every snippet (I will have a lot of them).
>
> Oliver
>
> On 30.03.20 01:58, Jonathan Gregory wrote:
>> Hi
>> On 29 Mar 2020, Oliver Heck wrote:
>>
>>> Hi,
>>>
>>> I am trying to use org-babel-lilypond and basically got it running.
>>> But somehow I always get full lilypond pages back instead of a small
>>> snippet.
>>> This is what I have in my org-file:
>>>
>>> #+NAME: Lilypond
>>> #+BEGIN_SRC lilypond :file test.png
>>>\relative c'' { c d e f }
>>> #+END_SRC
>>>
>>>
>>> I read through the documentation on
>>> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
>>> but cannot find a clue.
>>>
>>> Any idea what I am doing wrong here?
>>>
>>> Cheers,
>>> Oliver
>> The lilypond manual suggests using \paper variables to reduce the white
>> space around the score. In particular, you should set oddFooterMarkup
>> and oddHeaderMarkup to false.
>> \paper{
>>indent=0\mm
>>line-width=120\mm
>>oddFooterMarkup=##f
>>oddHeaderMarkup=##f
>>bookTitleMarkup = ##f
>>scoreTitleMarkup = ##f
>> }
>> http://lilypond.org/doc/v2.18/Documentation/usage/lilypond-output-in-other-programs
>> --
>> Jonathan
>>
>
> --
- --
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-
iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6BhTYUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsP5FAf/cxuPIpA7asX7esGCgZo3p+xJEbaj
sblsus9U586m6uwrGDyCAlNFCTsIFNx5cby1HKHQ7pI5EswrQxu7rve4qpqspqbI
ifw615Q5Q6cwCEPC1DTSQp6w7m6qHrDu1TrgL8bhvgPciaf9GH9uHszpuYi259R4
/66iyCyYEK55JAfFmoYpXhMoY1PsUHt2E8/PCHnbkys8Cbg1b2P9IUCNHq2XoiF2
1vFoGtVHGaGx48bmqztg/J4xTkJpj0VgeEMF3d/reT05ToZsYoa4mCFj/TWv+6q7
/zahVFf1KempQgM1KLbBvfRXzw8J8h9f2N9rCurdtFnr/03T2T5uEx+zqw==
=9fTG
-END PGP SIGNATURE-
Re: Org-babel-lilypond always renders full pages
Hi Jonathan,
that works fine. Thank you!
Can I set this as default header somewhere in the org file or will I
have to include it to every snippet (I will have a lot of them).
Oliver
On 30.03.20 01:58, Jonathan Gregory wrote:
Hi
On 29 Mar 2020, Oliver Heck wrote:
Hi,
I am trying to use org-babel-lilypond and basically got it running.
But somehow I always get full lilypond pages back instead of a small
snippet.
This is what I have in my org-file:
#+NAME: Lilypond
#+BEGIN_SRC lilypond :file test.png
\relative c'' { c d e f }
#+END_SRC
I read through the documentation on
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
but cannot find a clue.
Any idea what I am doing wrong here?
Cheers,
Oliver
The lilypond manual suggests using \paper variables to reduce the white
space around the score. In particular, you should set oddFooterMarkup
and oddHeaderMarkup to false.
\paper{
indent=0\mm
line-width=120\mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}
http://lilypond.org/doc/v2.18/Documentation/usage/lilypond-output-in-other-programs
--
Jonathan
--
--
If you are thinking without writing, you only think you are thinking.
(Leslie Lamport)
Re: Org-babel-lilypond always renders full pages
Hi
On 29 Mar 2020, Oliver Heck wrote:
> Hi,
>
> I am trying to use org-babel-lilypond and basically got it running.
> But somehow I always get full lilypond pages back instead of a small
> snippet.
> This is what I have in my org-file:
>
> #+NAME: Lilypond
> #+BEGIN_SRC lilypond :file test.png
> \relative c'' { c d e f }
> #+END_SRC
>
>
> I read through the documentation on
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
> but cannot find a clue.
>
> Any idea what I am doing wrong here?
>
> Cheers,
> Oliver
The lilypond manual suggests using \paper variables to reduce the white
space around the score. In particular, you should set oddFooterMarkup
and oddHeaderMarkup to false.
\paper{
indent=0\mm
line-width=120\mm
oddFooterMarkup=##f
oddHeaderMarkup=##f
bookTitleMarkup = ##f
scoreTitleMarkup = ##f
}
http://lilypond.org/doc/v2.18/Documentation/usage/lilypond-output-in-other-programs
--
Jonathan
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
Header args overwrite. Change python to python+ to append header args. Please excuse brevity. Sent from tiny pocket computer with non-haptic feedback keyboard. On Sun, Mar 29, 2020, 15:42 Joost Kremers wrote: > > On Mon, Mar 30 2020, Joost Kremers wrote: > > Looks like a bug, right? > > And while I'm at it, this doesn't work as expected either: > > ``` > #+PROPERTY: header-args :dir /home/joost/tmp/dlpy/ > > * Header 1 > :PROPERTIES: > :header-args:python: :tangle out1.py > :header-args:python: :session py1 :results function > :END: > > #+begin_src python > a=1 > b=2 > c=a+b > return c > #+end_src > ``` > > I would expect that the file `out1.py` is created in the directory > `/home/joost/tmp/dlpy`, but it's created in the same directory as > the Org file. > > Are my expectations wrong or is this really a bug? > > > -- > Joost Kremers > Life has its moments > >
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Mon, Mar 30 2020, Joost Kremers wrote: Looks like a bug, right? And while I'm at it, this doesn't work as expected either: ``` #+PROPERTY: header-args :dir /home/joost/tmp/dlpy/ * Header 1 :PROPERTIES: :header-args:python: :tangle out1.py :header-args:python: :session py1 :results function :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src ``` I would expect that the file `out1.py` is created in the directory `/home/joost/tmp/dlpy`, but it's created in the same directory as the Org file. Are my expectations wrong or is this really a bug? -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. wrote: What we really need is an ECM rather than snippets of code. Yes, my apologies. It seems that having more than one `header-arg` line doesn't work properly. The following works: ``` * Header 1 :PROPERTIES: :header-args:python: :tangle out1.py :header-args:python: :session py1 :results function :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: : 3 ``` But if I swap the two `header-args` lines, tangling stops working and at the same time evaluating the code block doesn't give any output at all: ``` * Header 1 :PROPERTIES: :header-args:python: :session py1 :results function :header-args:python: :tangle out1.py :END: #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: ``` With a `#+PROPERTY` line, I can't make it work at all: ``` #+PROPERTY: header-args:python :tangle out.py #+PROPERTY: header-args:python :results function * Header 1 #+begin_src python a=1 b=2 c=a+b return c #+end_src #+RESULTS: : 3 ``` Evaluating the code block works, but tangling doesn't. Reversing the order of the `#+PROPERTY` lines has no effect in this case. Looks like a bug, right? -- Joost Kremers Life has its moments
Org-babel-lilypond always renders full pages
Hi,
I am trying to use org-babel-lilypond and basically got it running. But
somehow I always get full lilypond pages back instead of a small snippet.
This is what I have in my org-file:
#+NAME: Lilypond
#+BEGIN_SRC lilypond :file test.png
\relative c'' { c d e f }
#+END_SRC
I read through the documentation on
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
but cannot find a clue.
Any idea what I am doing wrong here?
Cheers,
Oliver
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
> On Mar 29, 2020, at 1:13 PM, Joost Kremers wrote: > > > On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. > wrote: >>> On Mar 28, 2020, at 3:00 PM, Joost Kremers wrote: >>> Is this expected behaviour? Am I doing something wrong? >> >> IIUC what you did, then yes and yes. >> >> This is the accepted idiom: >> >> #+PROPERTY: header-args :tangle yes > What we really need is an ECM rather than snippets of code. This ECM works for me: #+begin_src org ,* try python :PROPERTIES: :header-args:python: :tangle yes :END: ,#+begin_src python "a+b" ,#+end_src #+end_src producing a file of the same name with the .py extension with one line containing "a+b". I am on release Org mode version 9.3.6 (release_9.3.6-442-g97f0f1 ), but this also work on release_9.3-34-g2eee3c HTH, Chuck p.s. `M-x org-lint' may reveal some issues with your file that might not be obvious to the eye. > I have tried: > > #+begin_example > #+PROPERTY: header-args:python :tangle yes :dir /home/joost/tmp/dlpy > #+end_example > > which AFAICT is the syntax shown in the info node you mentioned. I have also > tried a file name instead of =yes=, both with and without quotes, but it > doesn't work. > > What I really want is to have a property block with the =:tangle= arg under > each top-level header, like so: > > #+begin_example > :PROPERTIES: > :header-args:python: :tangle out1.py > :END: > #+begin_example > > because I want the code below each top-level header to be tangled to a > separate file. Again, AFAICT this is the syntax described in the info manual. > > Hmm, experimenting a bit more I find that if I leave out the =python= part, > it works: > > #+begin_example > :PROPERTIES: > :header-args: :tangle out1.py > :END: > #+begin_example > > But the info manual gives this example: > > #+begin_example > :PROPERTIES: > :header-args:clojure::session *clojure-1* > :END: > #+begin_example > > The same is true for the #+PROPERTY block at the top of the file: leave out > the =python=, it works. Isn't it possible to restrict tangling to source > blocks of a particular language? (Or, more specifically what I want: to > specify different tangling targets for different language? I wanted to have > both python and bash code blocks under one header and have them tangled to > different files...) > > Joost > > > -- > Joost Kremers > Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
On Sun, Mar 29 2020, Berry, Charles via General discussions about Org-mode. wrote: On Mar 28, 2020, at 3:00 PM, Joost Kremers wrote: Is this expected behaviour? Am I doing something wrong? IIUC what you did, then yes and yes. This is the accepted idiom: #+PROPERTY: header-args :tangle yes I have tried: #+begin_example #+PROPERTY: header-args:python :tangle yes :dir /home/joost/tmp/dlpy #+end_example which AFAICT is the syntax shown in the info node you mentioned. I have also tried a file name instead of =yes=, both with and without quotes, but it doesn't work. What I really want is to have a property block with the =:tangle= arg under each top-level header, like so: #+begin_example :PROPERTIES: :header-args:python: :tangle out1.py :END: #+begin_example because I want the code below each top-level header to be tangled to a separate file. Again, AFAICT this is the syntax described in the info manual. Hmm, experimenting a bit more I find that if I leave out the =python= part, it works: #+begin_example :PROPERTIES: :header-args: :tangle out1.py :END: #+begin_example But the info manual gives this example: #+begin_example :PROPERTIES: :header-args:clojure::session *clojure-1* :END: #+begin_example The same is true for the #+PROPERTY block at the top of the file: leave out the =python=, it works. Isn't it possible to restrict tangling to source blocks of a particular language? (Or, more specifically what I want: to specify different tangling targets for different language? I wanted to have both python and bash code blocks under one header and have them tangled to different files...) Joost -- Joost Kremers Life has its moments
Re: :tangle header argument not picked up in #+PROPERTY line or :PROPERTIES: block
> On Mar 28, 2020, at 3:00 PM, Joost Kremers wrote: > > Hi list, > > I'm having trouble tangling an Org file. Basically, if I put a =:tangle= > header argument in a =#+PROPERTY= line at the top of the file or in a > =:PROPERTIES:= block under a header, it is not picked up and the code blocks > to which (I think) it should apply are not tangled. Only when I put a > =:tangle= argument at the top of the source block itself is the source block > tangled. > > Is this expected behaviour? Am I doing something wrong? IIUC what you did, then yes and yes. This is the accepted idiom: #+PROPERTY: header-args :tangle yes Remember that if you add or change that line you need to update with C-c C-c or `org-mode-restart'. Maybe you omitted the `header-args'. That used to be correct syntax but was obsoleted some time back. See (info "(org) Using Header Arguments") HTH, Chuck > > Emacs 26.3, Org 9.3.6. > > TIA > > Joost > > > -- > Joost Kremers > Life has its moments > >
Re: Bug: Latex-Export does not respect custom latex section hierarchy [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Hello, Lukas Juhrich writes: > Following the manual[1], I wanted to extend `org-latex-classes` to > support `paragraph` as a fourth level instead of enumerating. > However, everything after the third entry in an `org-latex-classes` > entry is ignored. See `org-export-headline-levels' Regards, -- Nicolas Goaziou
Bug: Latex-Export does not respect custom latex section hierarchy [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]
Following the manual[1], I wanted to extend `org-latex-classes` to
support `paragraph` as a fourth level instead of enumerating.
However, everything after the third entry in an `org-latex-classes`
entry is ignored.
[1] https://orgmode.org/worg/org-tutorials/org-latex-export.html#org09a8ac4
The MWE looks as follows (don't forget to C-c on the emacs-lisp block):
```org
#+name: setup
#+begin_src emacs-lisp :results silent :exports none
(unless (find "per-file-class" org-latex-classes :key 'car
:test 'equal))
(add-to-list 'org-latex-classes
'("per-file-class"
"\\documentclass{scrartcl}
[NO-DEFAULT-PACKAGES]
[EXTRA]"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src
#+LATEX_CLASS: per-file-class
* Test
** sub
*** subsub
Paragraph a
This is a test!
```
Expected behavior
=
When exporting a latex buffer (or file or compiled pdf), `Paragraph a`
should be exported as `\paragraph{Paragraph a}`.
Observed behavior
=
It is exported as an `\item` in an enumerated list:
```latex
% Created 2020-03-28 Sa 17:06
% Intended LaTeX compiler: pdflatex
\documentclass{scrartcl}
\date{\today}
\title{}
\hypersetup{
pdfauthor={},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 26.3 (Org mode 9.1.9)},
pdflang={English}}
\begin{document}
\tableofcontents
\section{Test}
\label{sec:org95b2e92}
\subsection{sub}
\label{sec:org59c5bb4}
\subsubsection{subsub}
\label{sec:org3d1fda1}
\begin{enumerate}
\item Paragraph a
\label{sec:org6fb5426}
This is a test!
\end{enumerate}
\end{document}
```
Rest
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
of 2019-08-29
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-latex-default-packages-alist '(("AUTO" "inputenc" t) ("T1"
"fontenc" t) ("" "fixltx2e" nil) ("" "graphicx" t)
("" "grffile" t) ("" "longtable"
nil) ("" "wrapfig" nil) ("" "rotating" nil)
("normalem" "ulem" t) ("" "amsmath"
t) ("" "textcomp" t) ("" "amssymb" t)
("" "capt-of" nil) ("" "hyperref"
nil) ("" "commath" nil))
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-agenda-files '("~/org/official.org" "~/org/ag/sipa.org"
"~/org/ag/ag.org" "~/org/misc.org" "~/org/phy.org"
"~/org/agenda-enabled/")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-modules '(org-habit org-w3m org-bbdb org-bibtex org-docview
org-gnus org-info org-irc org-mhe org-rmail)
org-shiftup-final-hook '(windmove-up)
org-mode-hook '(org-clock-load
(lambda nil
(if
(member
(quote
("scrartcl" "\\documentclass{scrartcl}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
)
org-latex-classes)
org-latex-classes
(setq org-latex-classes
(cons
(quote
("scrartcl" "\\documentclass{scrartcl}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
)
org-latex-classes)
)
)
)
org-bullets-mode er/add-org-mode-expansions
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-block-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-clock-persist 'history
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
Re: Automatic formatting of the table as you type
> I suggest being very careful with this. While it's a very nice feature, > it's bound to be slow with large tables. And it is very frustrating for > users when typing becomes laggy. The feature could be an optional minor mode first and then later made default if it proves to work well in every situation. With the techniques I suggested there should be no lag at all, because for smaller tables emacs can handle automatic formatting instantly and with bigger tables the code can introduce an automatic idle delay (sit-for), so the automatic reformat will happen only when the user is idle for a short while. The idle period length can depend on the size and complexity of the table.
Re: virtual org-mode meetup tomorrow 11am EST
Ihor Radchenko writes: > FYI: > I have recently stumbled upon a FOSS service for video conferencing: > https://meet.jit.si/ (recommended in Tor blog > https://blog.torproject.org/remote-work-personal-safety) > > Might be another option for future meetings. Yes, that's what was used for EmacsConf 2019. It seemed to work well enough. See the archived videos.
Re: Automatic formatting of the table as you type
ndame writes: > As for org-at-table-p being slow storing the start and end position of > the table could be a solution, so if point is between them then there > is no need to check org-at-table-p again. > > org-table-align seemed fast enough for me when I tried the posted > code, but if it's slower for large tables then the code could measure > the time it takes to perform the alignment for the current table and > if it's above a certain threshold then it could introduce a bit of > idle delay for the update, so it doesn't hold back the user from > typing, and if the alignment is fast then it could perform the update > without delay. > > Anyway, I think if implemented properly then this feature could be a > worthy addition to org, even as default if it works well, because it's > a much better user experience and a much better first impression for > new users, instead of the current default fragile table which falls > apart during typing and fixed only when TAB is pressed. I suggest being very careful with this. While it's a very nice feature, it's bound to be slow with large tables. And it is very frustrating for users when typing becomes laggy. Most users who encounter it would probably not know if there's a way to fix the problem, e.g. by disabling a feature, because they probably wouldn't even know what to look for. Most would probably think it a bug, and it could harm Org's and Emacs's reputation, making people think they're inherently slow or laggy when typing. Pressing TAB (or any other key that moves to the next field) to realign a table is not a significant burden. A feature like this should probably remain an add-on package, or at least disabled by default.
