Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: > Nicolas Goaziou writes: > >> OK. Keep us informed when the process is over. Note this step is not >> mandatory to modify a file in contrib/, so you can do 1-3 meanwhile. > > I've added koma-letter to the repository, in contrib/lisp. Please let me > know if I did something wrong. Great. Thanks Alan! -- Bastien
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: > OK. Keep us informed when the process is over. Note this step is not > mandatory to modify a file in contrib/, so you can do 1-3 meanwhile. I've added koma-letter to the repository, in contrib/lisp. Please let me know if I did something wrong. Alan
Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: >> 3. Add yourself as Maintainer in it (or Author, for that matter). > > As I really haven't done much, [...] yet ;) > I've signed and sent them by sent mail, but I haven't heard back yet > (they're supposed to send me a pdf with their signature added). OK. Keep us informed when the process is over. Note this step is not mandatory to modify a file in contrib/, so you can do 1-3 meanwhile. Regards, -- Nicolas Goaziou
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: >> The non-technical question: I understand this exporter is just a proof >> of concept, but it is working quite well for me, and I'm ready to help >> tweaking this. If I do further modifications, should I send them to the >> list? > > I classified it as "proof of concept" because I was too lazy to dig into > Scrlttr2 documentation and provide a complete enough letter back-end. > I would be glad that someone maintains it. > > I think the simplest solution is to: > > 1. Ask for push access to Org. Done. > 2. Commit file in contrib/ directory. > 3. Add yourself as Maintainer in it (or Author, for that matter). As I really haven't done much, it should at most be maintainer ;-) > 4. Commit additional changes when you see fit, without sending the > file over and over to the ML. > > For point 1, see http://orgmode.org/worg/org-contribute.html (For Org > Developers) > > Also, it would be nice if you signed FSF papers. I've signed and sent them by sent mail, but I haven't heard back yet (they're supposed to send me a pdf with their signature added). Alan
Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: > I had to write yet another letter, so I digged into this and it's now > working well enough for me. I made a few changes to the file (which I > attach): > > - fixed bugs to the menu (export to pdf, open pdf), added "export to tex > file" > - put a default address "no address" instead of a blank line, otherwise > compilation fails > - moved the lco file input before the preamble, so that one can specify > some additional information (like packages). (This may be > questionable, don't hesitate to let me know.) I think that's fine. > I now have two questions: a technical one and a non-technical one. > > The technical one: I see that org-e-koma extends the latex exporter with > some options: > > (org-export-define-derived-backend koma-letter e-latex > :options-alist > ((:closing "CLOSING" nil org-koma-letter-closing) >(:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline) > ... > > These options have 3 arguments instead of 4 in the definition of options > in org-e-latex: > > :options-alist ((:date "DATE" nil org-e-latex-date-format t) > (:latex-class "LATEX_CLASS" nil org-e-latex-default-class t) > ... > > Is the missing argument the one that lets EXPORT_OPTIONS specify if some > parts can be omitted for subtree export? Or is it something different? It's something different: the last argument defines the behaviour when more than one keyword is found in the buffer. When unspecified, it defaults to nil. The syntax is the same as `org-export-options-alist', which defines back-end agnostic export options. You should have a look at its docstring. > The non-technical question: I understand this exporter is just a proof > of concept, but it is working quite well for me, and I'm ready to help > tweaking this. If I do further modifications, should I send them to the > list? I classified it as "proof of concept" because I was too lazy to dig into Scrlttr2 documentation and provide a complete enough letter back-end. I would be glad that someone maintains it. I think the simplest solution is to: 1. Ask for push access to Org. 2. Commit file in contrib/ directory. 3. Add yourself as Maintainer in it (or Author, for that matter). 4. Commit additional changes when you see fit, without sending the file over and over to the ML. For point 1, see http://orgmode.org/worg/org-contribute.html (For Org Developers) Also, it would be nice if you signed FSF papers. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: > The non-technical question: I understand this exporter is just a proof > of concept, but it is working quite well for me, and I'm ready to help > tweaking this. If I do further modifications, should I send them to the > list? YES!! I want to use Org for my (KOMA) letters (which are all of my letters). Unfortunately, I ran into some limitations the last time I used it ¹. Indeed, improving/working with more with KOMA letter exporter is on my TODO list; but at the moment I'm terribly occupied. –Rasmus Footnotes: ¹ https://lists.gnu.org/archive/html/emacs-orgmode/2012-07/msg00703.htlm -- When the facts change, I change my mind. What do you do, sir?
Re: [O] Extending org-koma-letter.el
Hello, Nicolas Goaziou writes: > Anyway, for the record, I'm posting an updated version[1] of the file, > compatible with latest Org (master branch). It may solve your problem. > > > Regards, > > [1] I do not seriously maintain this file. It was a proof of concept. I had to write yet another letter, so I digged into this and it's now working well enough for me. I made a few changes to the file (which I attach): - fixed bugs to the menu (export to pdf, open pdf), added "export to tex file" - put a default address "no address" instead of a blank line, otherwise compilation fails - moved the lco file input before the preamble, so that one can specify some additional information (like packages). (This may be questionable, don't hesitate to let me know.) I now have two questions: a technical one and a non-technical one. The technical one: I see that org-e-koma extends the latex exporter with some options: (org-export-define-derived-backend koma-letter e-latex :options-alist ((:closing "CLOSING" nil org-koma-letter-closing) (:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline) ... These options have 3 arguments instead of 4 in the definition of options in org-e-latex: :options-alist ((:date "DATE" nil org-e-latex-date-format t) (:latex-class "LATEX_CLASS" nil org-e-latex-default-class t) ... Is the missing argument the one that lets EXPORT_OPTIONS specify if some parts can be omitted for subtree export? Or is it something different? The non-technical question: I understand this exporter is just a proof of concept, but it is working quite well for me, and I'm ready to help tweaking this. If I do further modifications, should I send them to the list? Thanks, Alan org-koma-letter.el Description: application/emacs-lisp
Re: [O] Extending org-koma-letter.el
Alan Schmitt writes: > Nicolas Goaziou writes: > >> Anyway, for the record, I'm posting an updated version[1] of the file, >> compatible with latest Org (master branch). It may solve your problem. >> > > Alan Hi: Let me know how the back end is working for you. Bastien asked to work on koma but things have been delayed thanks to work, hurricanes, raccoons, looters, blackouts and now turkey. :) Luis -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: > I cannot reproduce it. Also, I think Luis provided a better option for > letters with his Groff backend. You may want to try it. > > Anyway, for the record, I'm posting an updated version[1] of the file, > compatible with latest Org (master branch). It may solve your problem. > > > Regards, > > [1] I do not seriously maintain this file. It was a proof of concept. Thanks a lot. If there is no plan to maintain a Koma backend, I'll have a look ot Luis's Groff backend. Thanks again, Alan
Re: [O] Extending org-koma-letter.el
Hello,
Alan Schmitt writes:
> I'm resurrecting this old thread because I need to write a
> recommendation letter, which is all ready in org mode. I have put the
> org-koma-letter.el in the contrib/lisp directory, compiled it, and
> required it. I created the association as suggested, but when I export
> to latex, I get some strange results. It seems that the association is
> used (as indicated by the documentclass), but there is no
> "\begin{letter} ... \end{letter}" generated.
I cannot reproduce it. Also, I think Luis provided a better option for
letters with his Groff backend. You may want to try it.
Anyway, for the record, I'm posting an updated version[1] of the file,
compatible with latest Org (master branch). It may solve your problem.
Regards,
[1] I do not seriously maintain this file. It was a proof of concept.
--
Nicolas Goaziou
org-koma-letter.el
Description: KOMA Scrlttr2 backend
Re: [O] Extending org-koma-letter.el
Hello,
Bastien writes:
> Hi Luis,
>
> Luis Anaya writes:
>
>> Nicolas Goaziou writes:
>>
>>>
>>> Code for org-koma-letter.el is at:
>>>
>>> http://permalink.gmane.org/gmane.emacs.orgmode/57547
>
> I added a link to this in
>
> http://orgmode.org/worg/org-contrib/index.html
I'm resurrecting this old thread because I need to write a
recommendation letter, which is all ready in org mode. I have put the
org-koma-letter.el in the contrib/lisp directory, compiled it, and
required it. I created the association as suggested, but when I export
to latex, I get some strange results. It seems that the association is
used (as indicated by the documentclass), but there is no
"\begin{letter} ... \end{letter}" generated. Here is the generated
latex:
#+BEGIN_SRC latex
% Created 2012-11-06 Tue 16:23
\documentclass[%
DIV=14,
fontsize=10pt,
parskip=half,
subject=untitled,
backaddress=true,
fromalign=right,
fromemail=true,
fromphone=false,
InriaRennesFR]{scrlttr2}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{hyperref}
\author{Alan Schmitt}
\date{\today}
\title{Testing the letter}
\hypersetup{
pdfkeywords={},
pdfsubject={},
pdfcreator={Generated by Org mode 7.9.2 in Emacs 24.2.1.}}
\begin{document}
\maketitle
\tableofcontents
\vspace*{1cm}
Hello world
% Generated by Org mode 7.9.2 in Emacs 24.2.1.
\end{document}
#+END_SRC
and the corresponding org source:
#+BEGIN_SRC org
#+LATEX_CLASS: my-inria-fr-letter
#+TITLE: Testing the letter
#+CLOSING: Yo, man
Hello world
#+END_SRC
Finally, this is what I added to my init file:
#+BEGIN_SRC elisp
(require 'org-koma-letter)
(add-to-list 'org-e-latex-classes
'("my-inria-fr-letter"
"\\documentclass\[%
DIV=14,
fontsize=10pt,
parskip=half,
subject=untitled,
backaddress=true,
fromalign=right,
fromemail=true,
fromphone=false,
InriaRennesFR\]\{scrlttr2\}
\[DEFAULT-PACKAGES]
\[PACKAGES]
\[EXTRA]"
("\\section\{%s\}" . "\\section*\{%s\}")
("\\subsection\{%s\}" . "\\subsection*\{%s\}")
("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
#+END_SRC
Any idea as to what I'm doing wrong?
Thanks,
Alan
Re: [O] Extending org-koma-letter.el
Bastien writes: > If you want to take care of this library, please do! > Nicolas told me he won't have time for this anytime soon. Well, that's a challenge... It's now and my wife thinks I have a cyber lover or something being that I spend typing on the keyboard up to the wee hours of the night or morning... plus work which has its demands as it is. Let me finalize the Groff code first, it should give me an idea of the challenges of letter creation. I can see what can I do with the Koma exporter. (and I have to re-learn LaTeX being that I do not use it as much as Groff). We'll see... -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [O] Extending org-koma-letter.el
Hi Luis, Luis Anaya writes: > Nicolas Goaziou writes: > >> >> Code for org-koma-letter.el is at: >> >> http://permalink.gmane.org/gmane.emacs.orgmode/57547 I added a link to this in http://orgmode.org/worg/org-contrib/index.html > Thanks... I'll take a look. I went through the Koma documentation to > get a sense of the LaTeX commands in use for writing letters and see > how they relate to the Groff ones, in this way I have some context on > the code while reading it. If you want to take care of this library, please do! Nicolas told me he won't have time for this anytime soon. Best, -- Bastien
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes: > > Code for org-koma-letter.el is at: > > http://permalink.gmane.org/gmane.emacs.orgmode/57547 Thanks... I'll take a look. I went through the Koma documentation to get a sense of the LaTeX commands in use for writing letters and see how they relate to the Groff ones, in this way I have some context on the code while reading it. Again, thanks for sharing. Luis -- Luis Anaya papo anaya aroba hot mail punto com "Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [O] Extending org-koma-letter.el
Hello, Luis Anaya writes: > Nicolas, I would like to take a look at the code. I've been raking my > brain on how to add support for the .LO/.LT Groff macros being that they > break convention to covers and memorandum types. Code for org-koma-letter.el is at: http://permalink.gmane.org/gmane.emacs.orgmode/57547 Regards, -- Nicolas Goaziou
Re: [O] Extending org-koma-letter.el
Nicolas Goaziou writes:
Hi:
>> Thanks. It's wonderful writing letters with the new latex exporter.
>> You should consider adding it to org_contrib.
> On the other hand, I think that Org deserves a serious letter
> package. If you want to maintain and improve it, I'm all for adding it
> to contrib directory.
Nicolas, I would like to take a look at the code. I've been raking my
brain on how to add support for the .LO/.LT Groff macros being that they
break convention to covers and memorandum types.
>> * my-encl:appendix:
>> #+latex:\encl{
>> - doc 1
>> - doc 2
>> #+latex:}
>> #+end_src
>
> The #+latex: ... parts are ugly. You may implement
> an #+attr_koma: :enclosure t syntax, for example.
This one I can use to enclose the .NS calls (that's how enclosures are
marked in Groff). Right now there's support for Closure and Signature, but
enclosures or carbon copy marks need to be added using Groff code.
>
> #+begin_src emacs-lisp
> (org-element-map
> (plist-get info :parse-tree) 'headline
> (lambda (h)
> (and (member "appendix" (org-export-get-tags h info))
> h))
> info)
> #+end_src
>
Oh, so that's the magic trick :). I was wondering for a good way to do
implement abstracts, but I should be able to use it to use it
for addresses as well.
Thanks for sharing.
--
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo
Re: [O] Extending org-koma-letter.el
Hello,
Rasmus writes:
> Thanks. It's wonderful writing letters with the new latex exporter.
> You should consider adding it to org_contrib.
As you have noticed, it is not complete enough. Also, I haven't looked
at the documentation thoroughly and don't know what is possible to do.
On the other hand, I think that Org deserves a serious letter
package. If you want to maintain and improve it, I'm all for adding it
to contrib directory.
>> It's far from being complete. See it as a proof of concept. Feel free
>> to upgrade it.
> I need two further features to fully adopt org-koma-letter.el, but I am
> not sure how to proceed (I still haven't found too much [non-programmer]
> documentation on how to hack the new org-exporter).
If you have any question, just ask here.
> First, it should allow for contents after \closing{·}, e.g. \ps{·} and
> \encl{·}. Second, it should allow for arbitrary LaTeX command
> \end{letter}, e.g. \includepdf{·}.
This is a reasonable suggestion, indeed.
> Thus, I basically want to extend org-koma-letter-template to include to
> extra content-like elements.
>
>(defun org-koma-letter-template (contents info)
>...
>...
>(format "\n\\closing{%s}\n\n" (plist-get info :closing))
>;; appendix in letter
>appendix
>;; Letter ends.
>"\\end{letter}\n"
>after-letter
>;; Document ends.
>"\\end{document}"
>
>
> I am not sure how to implement this. I want it to operate on tags. So
> I want
> #+begin_src
> * my-encl:appendix:
> #+latex:\encl{
> - doc 1
> - doc 2
> #+latex:}
> #+end_src
The #+latex: ... parts are ugly. You may implement
an #+attr_koma: :enclosure t syntax, for example.
> to /not/ be part of contents, but be recognized as appendix inserted
> after the signature. Likewise headlines with tag :afterletter: should
> only be inserted after \end{letter}.
>
> Could anyone provide any hints as to how to archive this behavior. (I
> can't really understand all the details by just reading the API...).
While in the template, you have to search for headlines with a certain
tag (you could also do the same with properties), and treat them the way
you want.
Parse tree is found in communication channel (INFO argument) via:
(plist-get info :parse-tree)
You can skim through it and collect headlines matching a criteria with
`org-element-map'. Here, the criteria is that "appendix" has to be
a member of headline's tags. These tags are obtained with
`org-export-get-tags'. Hence:
#+begin_src emacs-lisp
(org-element-map
(plist-get info :parse-tree) 'headline
(lambda (h)
(and (member "appendix" (org-export-get-tags h info))
h))
info)
#+end_src
will return a list of all headlines with the "appendix" tag. Now, what
you want to do with them is up to you. You may simply want to export
them right here, in the template. This is done with `org-export-data'.
#+begin_src emacs-liso
(mapconcat (lambda (h) (org-export-data h info))
;; List of "appendix" headlines
(org-element-map
(plist-get info :parse-tree) 'headline
(lambda (h)
(and (member "appendix" (org-export-get-tags h info))
h))
info)
"")
#+end_src
Though, if you transcode them outside of \begin{letter}...\end{letter},
you probably don't want to also see them within that environment. In
other words, you have to tell the function transcoding headlines,
`org-koma-letter-headline', to ignore (that is return a nil value)
headlines with an "appendix" tag when it sees one.
On the other hand, if the headline has no such tag, you may want to
delegate its transcoding to e-latex backend instead. You can use
something like the following:
#+begin_src emacs-lisp
(defun org-koma-letter-headline (headline contents info)
"Transcode a HEADLINE element into KOMA Scrlttr2 code.
CONTENTS is nil. INFO is a plist used as a communication
channel."
(unless (member "appendix" (org-export-get-tags headline info))
(funcall (cdr (assq 'headline org-e-latex-translate-alist))
headline contents info)))
#+end_src
HTH,
Regards,
--
Nicolas Goaziou
[O] Extending org-koma-letter.el (was: HowTo: Letter template method using yasnippet)
Nicolas Goaziou writes:
> Based on [Karl Voit's] work, I've put up the attached back-end:
> org-koma-letter.el.
Thanks. It's wonderful writing letters with the new latex exporter.
You should consider adding it to org_contrib.
> It's far from being complete. See it as a proof of concept. Feel free
> to upgrade it.
I need two further features to fully adopt org-koma-letter.el, but I am
not sure how to proceed (I still haven't found too much [non-programmer]
documentation on how to hack the new org-exporter).
First, it should allow for contents after \closing{·}, e.g. \ps{·} and
\encl{·}. Second, it should allow for arbitrary LaTeX command
\end{letter}, e.g. \includepdf{·}.
Thus, I basically want to extend org-koma-letter-template to include to
extra content-like elements.
(defun org-koma-letter-template (contents info)
...
...
(format "\n\\closing{%s}\n\n" (plist-get info :closing))
;; appendix in letter
appendix
;; Letter ends.
"\\end{letter}\n"
after-letter
;; Document ends.
"\\end{document}"
I am not sure how to implement this. I want it to operate on tags. So
I want
#+begin_src
* my-encl:appendix:
#+latex:\encl{
- doc 1
- doc 2
#+latex:}
#+end_src
to /not/ be part of contents, but be recognized as appendix inserted
after the signature. Likewise headlines with tag :afterletter: should
only be inserted after \end{letter}.
Could anyone provide any hints as to how to archive this behavior. (I
can't really understand all the details by just reading the API...).
BTW: scrlttr2 supports sections with certain lco-files, see
http://www.komascript.de/sections.lco. So perhaps the
org-koma-letter-headline should contain this possibility.
Thanks,
Rasmus
--
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .
