Re: [O] org-agenda-filter-by-tag-refine defaults to exclude
Hi Gustav, currently, the remove functionality can also be accessed by C-u /. If we want to provide a dedicated hotkey, then the following definition will do it: (add-hook 'org-agenda-mode-hook (lambda() (local-set-key (kbd "\") '(lambda() (interactive) (org-agenda-filter-by-tag nil nil 'exclude 'append) I would prefer to remove this function because it doesn’t add functionality. Keeping it around just adds another potential source of bugs. Best, Viktor > Am 28.01.2016 um 09:27 schrieb Gustav Wikström <gus...@whil.se>: > > Hi Kyle, Viktor and the group, > > I'd say it's a naming-problem. What, really, is the purpose of the function? > Because applying the proposed change essentially makes the function identical > to the function it calls. Right? And that function is still available for the > user, so a "refinement" can be done without the > org-agenda-filter-by-tag-refine (bound to backslash (\) ) function. As of > now, using the function to exclude tags in the agenda provides a direct > access to that functionality, instead of calling org-agenda-filter-by-tag > (bound to slash (/) ) plus pushing the minus key (-) to switch from filter to > exclude. > > If you want to make any change, I'd suggest to instead change the name of > org-agenda-filter-by-tag-refine to org-agenda-filter-by-tag-exclude and to > leave the code within the function as is (well.. maybe change 'refine to > 'exclude with the same argument as to the function name change). > > Best Regards > Gustav > > -Original Message- > From: Kyle Meyer [mailto:k...@kyleam.com] > Sent: Tuesday, January 12, 2016 07:19 > To: Viktor Rosenfeld <v.rosenf...@gmx.de> > Cc: emacs-orgmode@gnu.org; Gustav Wikström <gus...@whil.se> > Subject: Re: org-agenda-filter-by-tag-refine defaults to exclude > > Hi Viktor, > > Viktor Rosenfeld <v.rosenf...@gmx.de> writes: > >> Hi, >> >> I noticed that org-agenda-filter-by-tag-refine started to exclude >> selected tags by default recently because the 'refine in the call to >> org-agenda-filter-by-tag is interpreted as an exclude flag. > > This seems to have been introduced by 6c6ae99 (org-agenda: Filtering in the > agenda on grouptags, 2015-01-24). > >> The attached patch fixes this. >> >> However, it seems that the function is superfluous because >> org-agenda-filter-by-tag can filter on multiple tags as well if called >> multiple times (that used not to be the case earlier). So maybe it >> should be deprecated and removed? > > I agree. Gustav, does that make sense given your changes in 6c6ae99? > >> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index >> d91b64d..21928de 100644 >> --- a/lisp/org-agenda.el >> +++ b/lisp/org-agenda.el >> @@ -7580,7 +7580,7 @@ to switch between filtering and excluding." >> (defun org-agenda-filter-by-tag-refine (arg char) >> "Refine the current filter. See `org-agenda-filter-by-tag'." >> (interactive "P") >> - (org-agenda-filter-by-tag arg char 'refine)) >> + (org-agenda-filter-by-tag arg char)) > >> (defun org-agenda-filter-make-matcher (filter type expand) >> "Create the form that tests a line for agenda filter. Optional > > > -- > Kyle signature.asc Description: Message signed with OpenPGP using GPGMail
[O] org-agenda-filter-by-tag-refine defaults to exclude
Hi, I noticed that org-agenda-filter-by-tag-refine started to exclude selected tags by default recently because the 'refine in the call to org-agenda-filter-by-tag is interpreted as an exclude flag. The attached patch fixes this. However, it seems that the function is superfluous because org-agenda-filter-by-tag can filter on multiple tags as well if called multiple times (that used not to be the case earlier). So maybe it should be deprecated and removed? Best, Viktor diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index d91b64d..21928de 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7580,7 +7580,7 @@ to switch between filtering and excluding." (defun org-agenda-filter-by-tag-refine (arg char) "Refine the current filter. See `org-agenda-filter-by-tag'." (interactive "P") - (org-agenda-filter-by-tag arg char 'refine)) + (org-agenda-filter-by-tag arg char)) (defun org-agenda-filter-make-matcher (filter type expand) "Create the form that tests a line for agenda filter. Optional signature.asc Description: Message signed with OpenPGP using GPGMail
[O] Org mode export from a large file is slow since release 8.3
Hi, I updated from 8.2.9 to 8.3.2 today and now the export has become very slow. Creating an HTML page or a LaTeX buffer used to be instantaneous but now takes up to 30 seconds. It seems that this is mostly related to file size. For example, exporting a subtree from a large notes file (~8600 lines) is very slow (11 seconds) but if I truncate the file significantly (to ~3000 lines) the export is faster (<2 seconds), and if I move the subtree to a fresh file (while still exporting the subtree only and not the file) it is again instantaneous. It also seems that the maint branch has fixed this problem somewhat, although I can’t really quantify it, but the problem persists. In the *Messages* buffer, I see a new message that hasn’t been there before: org-babel-exp process C at line 7982... org-babel-exp process C at line 7998... org-babel-exp process C at line 8024... org-babel-exp process C at line 8064... org-babel-exp process patch at line 8103... org-babel-exp process patch at line 8119... org-babel-exp process patch at line 8132... org-babel-exp process patch at line 8148... org-babel-exp process C at line 8179... 30 unique files scanned for IDs [8 times] Curiously, after trying to debug this issue, the problem went away for one file but persists for another. I am also able to reproduce this problem with an init.el file containing only: ;; use own Org-mode installation (setq load-path (cons "~/unix/src/org-mode/lisp" load-path)) (setq load-path (cons "~/unix/src/org-mode/contrib/lisp" load-path)) (require 'org-install) (require 'org) (require 'ox-html) I’m using CocoaEmacs 24.4 (9.0) installed via Homebrew on OS X 10.11.1 (El Capitan). Any idea what is causing this? Best, Viktor signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [RFC] Move ox-koma-letter into core?
Hi Tom, Am 17.02.14 22:56, schrieb Thomas S. Dye: FWIW, as a small businessman, the indemnification clause looks fairly standard to me. The contracts for archaeological services that we routinely sign typically have a clause like this, usually coupled with a request for a certificate of insurance that specifies the levels of liability insurance that the business carries. As I read the clause, FSF is in the position of accepting 1) a code contribution from a developer, and 2) the developer's assurance that the contributed code can't be claimed as property by a third party. It seems prudent that, in the event of a successful property claim by a third party to a piece of code contributed by a developer, the developer who gave the false assurance should be held responsible. Otherwise, FSF might be brought down by copyleft opponents who knowingly contribute code to which others have property rights in order to create a basis for lawsuits. Thanks for your reply. I was hoping to get some feedback on how other Orgmode contributors see this issue (although this list is obviously self-selective). The problem I have is that I'm not a lawyer or a businessman and not a native English speaker. I do know enough though not to lightly sign documents I don't fully understand. At this point, I'm considering to actually get proper legal advice about this form, because I'm not satisfied in the state of affairs where I have stopped participating in the Orgmode community because I do not understand the copyright assignment form. Cheers, Viktor
Re: [O] [RFC] Move ox-koma-letter into core?
Hi everybody, sorry for replying so late to this discussion. I stopped following the list a while ago. Rasmus was so kind and tracked me down. Am 18.01.14 19:10, schrieb Carsten Dominik: On 18 Jan 2014, at 00:08, Nicolas Goaziou n.goaz...@gmail.com wrote: There is one thing to consider, though: Viktor Rosenfeld (Cc'ed) contributed a significant number of lines of code to the file but hasn't signed FSF papers, AFAIK. Viktor, what is your positions on this? I had actually started the copyright assignment process in September but did not follow through with it because I did not fully understand the document and did not like some of the language. However, I'm willing to give it another shot and have sent my questions to the FSF. FWIW, I think that the copyright assignment process creates a huge barrier of entry to contribute to Orgmode and that it's unfortunate that one has to jump through hoops like this to contribute actual code (whereas other contributions, e.g., documentation, have no such obligation attached). Also, my view of the document, as I understand it, is that it's very one-sided and unfair to the developer, specifically the future works and indemnification clauses. For the record, I will not sign a document containing the indemnification clause as it currently stands. Cheers, Viktor
Re: [O] [PATCH] ox-icalendar: fix handling of timestamps
Hi Nicolas, Nicolas Goaziou wrote: Hello, Viktor Rosenfeld listuse...@gmail.com writes: * ox-icalendar.el (org-icalendar-entry): Honor setting of `org-icalendar-with-timestamps' for timestamps on headlines and checkboxes. The setting `org-icalendar-with-timestamps' was only applied to timestamps which do not appear on a heading or on a checkbox. E.g., with `org-icalendar-with-timestamps' set to 'active, an heading containing an inactive timestamp on would be exported. This patch fixes this. This would make icalendar back-end inconsistent with other back-ends, see `org-export-with-timestamps' docstring. If inconsistency is desirable in this case, `org-icalendar-with-timestamps' docstring should clearly state it. The docstring of `org-icalendar-with-timestamps' already states: This variable has precedence over `org-export-with-timestamps'. It can also be set with the #+OPTIONS line, e.g. :t. I believe that inconsistency is desirable here. Consider the following use case with three headlines: * TODO An appointment in the future 2013-08-12 So 09:00 * DONE A note about an appointment in the past [2013-08-10 Fr 09:00] * WAIT A reminder how long I've been waiting for something [2013-08-10 Fr] The previous behavior, with `org-icalendar-with-timestamps' set to 'active, was that the first and the last headlines were picked up (even though the timestamp in the last headline is inactive). This was unexpected because the two inactive timestamps are handled differently. My expectation was that only the first headline should have been exported. This is what my patch achieves. (Putting timestamps on the heading is useful to me because then I can see them in the agenda. Also, I often put timestamps on lines with checkboxes. However, I do not want to see any of those in my calendar when I export only active timestamps.) Cheers, Viktor Regards, -- Nicolas Goaziou
Re: [O] [PATCH] ox-icalendar: fix handling of timestamps
Hi Aaron, Aaron Ecay wrote: (lambda (ts) - (let ((uid (format TS%d-%s (incf counter) uid))) -(org-icalendar--vevent entry ts uid summary loc desc cat))) + (let ((type (org-element-property :type ts)) + (uid (format TS%d-%s (incf counter) uid))) +(when (or (eq with-timestamps 'all) Here, I think you want to compare with t, not 'all (check the defcustom for ‘org-icalendar-with-timestamps’). Thanks, fixed! +(and (eq with-timestamps 'active) + (or (eq type 'active) + (eq type 'active-range))) This is only a cosmetic comment, so feel free to disregard it, but: might the ‘(or ...)’ be cleaner as ‘(memq type '(active active-range))’? Thanks, fixed! I did not like the construction with `or' but I didn't know about `memq'. Learning Elisp as I go... New patch is attached. Cheers, Viktor -- Aaron Ecay From 52511b5e2a538d3bb0375c2e32caef0a27e1998e Mon Sep 17 00:00:00 2001 From: Viktor Rosenfeld listuse...@gmail.com Date: Sun, 11 Aug 2013 03:59:29 +0200 Subject: [PATCH] ox-icalendar: fix handling of timestamps * ox-icalendar.el (org-icalendar-entry): Honor setting of `org-icalendar-with-timestamps' for timestamps on headlines and checkboxes. The setting `org-icalendar-with-timestamps' was only applied to timestamps which do not appear on a heading or on a checkbox. E.g., with `org-icalendar-with-timestamps' set to 'active, an heading containing an inactive timestamp on would be exported. This patch fixes this. TINYCHANGE --- lisp/ox-icalendar.el | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el index c6ab295..ab83a48 100644 --- a/lisp/ox-icalendar.el +++ b/lisp/ox-icalendar.el @@ -580,15 +580,22 @@ inlinetask within the section. ;; When collecting plain timestamps from a headline and ;; its title, skip inlinetasks since collection will ;; happen once ENTRY is one of them. - (let ((counter 0)) + (let ((counter 0) + (with-timestamps (plist-get info :with-timestamps))) (mapconcat 'identity (org-element-map (cons (org-element-property :title entry) (org-element-contents inside)) 'timestamp (lambda (ts) - (let ((uid (format TS%d-%s (incf counter) uid))) -(org-icalendar--vevent entry ts uid summary loc desc cat))) + (let ((type (org-element-property :type ts)) +(uid (format TS%d-%s (incf counter) uid))) +(when (or (eq with-timestamps t) + (and (eq with-timestamps 'active) + (memq type '(active active-range))) + (and (eq with-timestamps 'inactive) + (memq type '(inactive 'inactive-range + (org-icalendar--vevent entry ts uid summary loc desc cat info nil (and (eq type 'headline) 'inlinetask)) )) ;; Task: First check if it is appropriate to export it. -- 1.8.3.4
Re: [O] [PATCH] org-mobile.el: Skip after and before elements
Hi Achim, Achim Gratz wrote: Viktor Rosenfeld writes: TINYCHANGE Just declaring things TINYCHANGE doesn't magically make it so, please remember that the limit is cumulative. Org already has changes from you to core files. Additionally you weren't listed as a TINYCHANGE contributor on Worg (I have just added you). Please read http://orgmode.org/worg/org-contribute.html Make up your mind about assigning copyright to the FSF and let us know the outcome. Thank you. Point taken. I did not know that the limit was cumulative. I've started the copyright assignment process and am waiting for the form to arrive. Cheers, Viktor Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] [PATCH] ox-icalendar: fix handling of timestamps
Hi Nicolas, Nicolas Goaziou wrote: Viktor Rosenfeld listuse...@gmail.com writes: The docstring of `org-icalendar-with-timestamps' already states: This variable has precedence over `org-export-with-timestamps'. It can also be set with the #+OPTIONS line, e.g. :t. This wouldn't be sufficient: has precedence over isn't a synonym for change the meaning of. Okay, I see the change in meaning now. I believe that inconsistency is desirable here. Consider the following use case with three headlines: * TODO An appointment in the future 2013-08-12 So 09:00 * DONE A note about an appointment in the past [2013-08-10 Fr 09:00] * WAIT A reminder how long I've been waiting for something [2013-08-10 Fr] The previous behavior, with `org-icalendar-with-timestamps' set to 'active, was that the first and the last headlines were picked up (even though the timestamp in the last headline is inactive). This was unexpected because the two inactive timestamps are handled differently. This is to be expected according to `org-export-with-timestamps'. My expectation was that only the first headline should have been exported. This is what my patch achieves. The meaning of `org-export-with-timestamps' is the result of a discussion in this ML. Please read the whole thread starting at: http://permalink.gmane.org/gmane.emacs.orgmode/69971 Thanks for the link. (It made me realize that something was wrong in my setup. For some reason, I was picking up `org-export-with-timestamps' from `org-exp.el', i.e., pre-8.0 code.) In any case, the docstring of `org-export-with-timestamps' states: This only applies to timestamps isolated in a paragraph containing only timestamps. Other timestamps are always exported. This explains the observerd behavior. But I don't think it's appropriate for the export to iCal. Quoting Carsten from http://thread.gmane.org/gmane.emacs.orgmode/69971/focus=70068: Some people throw in time stamps often while they work, just as a little label, indicating that they were working on this at a specific date, or that the entry was created on a specific date. Many people I know have a hook that throws in such a time stamp in each new entry created. This creates a lot of clutter when you print it, which is why you can turn off export of timestamps. That option was not meant for a contextual line like your first example. If you use the time stamps in this way, you probably will not turn off timestamp export at all, you will just leave it on. If you mix both ways of using time stamps - well, too bad. So the timestamp in the following example is clutter and can be turned off (i.e., it will not be exported): * Meet X 2013-08-11 So But the following will always be exported, even though the date is just o note and will not not cause the task to appear in the agenda: * Do stuff - Started on [2013-08-11 So] I want to make the iCal export mirror the agenda. I think the underlying problem is that there is no way in Org to annotate a timestamp as a fixed appointment. There's SCHEDULED and DEADLINE, but there's no APPT. The consensus is to use a standalone active timestamp for fixed appointments, which is easy enough. But then I would expect only those to appear in an iCal export. So I propose to append the docstring of `org-icalendar-export-timestamps': This variable has precedence over and overrides the behavior of `org-export-with-timestamps'. The setting is applied to every timestamp below a headline and not only to those which are isolated in a paragraph containing only timestamps. It can also be set with the #+OPTIONS line, e.g. :t. Cheers, Viktor (PS: Sorry for the long post.) Regards, -- Nicolas Goaziou
Re: [O] [PATCH] ox-icalendar: fix handling of timestamps
Hi Nicolas, Viktor Rosenfeld wrote: So I propose to append the docstring of `org-icalendar-export-timestamps': This variable has precedence over and overrides the behavior of `org-export-with-timestamps'. The setting is applied to every timestamp below a headline and not only to those which are isolated in a paragraph containing only timestamps. It can also be set with the #+OPTIONS line, e.g. :t. I just realized that this is not enough. The option `org-icalendar-with-timestamps' already changes the meaning of `org-export-with-timestamps'. The latter only removes timestamps from the export whereas during the iCalendar export the presence of a timestamp determines whether the heading is exported at all. So it's more akin to the behavior of :export: and :noexport: tags. I would change the docstring of `org-icalendar-export-timestamps' as such: Non-nil means export headlines with timestamps. It can be set to any of the following values: t export headlines containing any kind of timestamp `active'export headlines containing active timestamps `inactive' export headlines containing inactive timestamps nil do not any headlines Note: This variable overrides the behavior of `org-export-with-timestamps'. `org-export-with-timestamps' controls whether a timestamp is exported or removed from the export. `org-icalendar-export-timestamps' controls whether a headline is exported or removed from the exported. In addition, `org-icalendar-export-timestamps' applies to every timestamp below a headline and not only to those which are isolated in a paragraph containing only timestamps. This variable can also be set with the #+OPTIONS line, e.g. :t. Note that setting the variable in the OPTIONS line is useful to remove a file from the iCalendar export even though it is displayed in the agenda. I actually have this usecase (although right now I exclude by tag). Cheers, Viktor
[O] [PATCH] ox-icalendar: fix handling of timestamps
* ox-icalendar.el (org-icalendar-entry): Honor setting of `org-icalendar-with-timestamps' for timestamps on headlines and checkboxes. The setting `org-icalendar-with-timestamps' was only applied to timestamps which do not appear on a heading or on a checkbox. E.g., with `org-icalendar-with-timestamps' set to 'active, an heading containing an inactive timestamp on would be exported. This patch fixes this. TINYCHANGE --- lisp/ox-icalendar.el | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el index c6ab295..8f15124 100644 --- a/lisp/ox-icalendar.el +++ b/lisp/ox-icalendar.el @@ -580,15 +580,24 @@ inlinetask within the section. ;; When collecting plain timestamps from a headline and ;; its title, skip inlinetasks since collection will ;; happen once ENTRY is one of them. - (let ((counter 0)) + (let ((counter 0) + (with-timestamps (plist-get info :with-timestamps))) (mapconcat 'identity (org-element-map (cons (org-element-property :title entry) (org-element-contents inside)) 'timestamp (lambda (ts) - (let ((uid (format TS%d-%s (incf counter) uid))) -(org-icalendar--vevent entry ts uid summary loc desc cat))) + (let ((type (org-element-property :type ts)) + (uid (format TS%d-%s (incf counter) uid))) +(when (or (eq with-timestamps 'all) +(and (eq with-timestamps 'active) + (or (eq type 'active) + (eq type 'active-range))) +(and (eq with-timestamps 'inactive) + (or (eq type 'inactive) + (eq type 'inactive-range + (org-icalendar--vevent entry ts uid summary loc desc cat info nil (and (eq type 'headline) 'inlinetask)) )) ;; Task: First check if it is appropriate to export it. -- 1.8.3.4
[O] [PATCH] org-mobile.el: Skip after and before elements
* org-mobile.el (org-mobile-add-after): Variable to turn off printing of information inside after element. (org-mobile-add-before): Variable to turn off printing of information inside before element. (org-mobile-sumo-agenda-command): Optionally skip printing of information inside after element. (org-mobile-write-agenda-for-mobile): Optionally skip printing of information inside before element. The MobileOrg push command adds some information inside an after element on the heading, e.g., the agenda key and name, and inside a before element in the body, e.g., the category and time information. This patch adds the ability to disable this behavior. It is not very sophisticated; a better way would be to support custom layouts of the data shown in MobileOrg. TINYCHANGE --- lisp/org-mobile.el | 30 ++ 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el index 7cdaf34..a866293 100644 --- a/lisp/org-mobile.el +++ b/lisp/org-mobile.el @@ -255,6 +255,16 @@ using `rsync' or `scp'.) (defvar org-mobile-files-alist nil) (defvar org-mobile-checksum-files nil) +(defcustom org-mobile-add-after t + Add information inside after element. + :group 'org-mobile + :type 'boolean) + +(defcustom org-mobile-add-before t + Add information inside before element. + :group 'org-mobile + :type 'boolean) + (defun org-mobile-prepare-file-lists () (setq org-mobile-files-alist (org-mobile-files-alist)) (setq org-mobile-checksum-files nil)) @@ -581,10 +591,11 @@ The table of checksums is written to the file mobile-checksums. settings (nth 4 e)) (setq settings (cons (list 'org-agenda-title-append - (concat afterKEYS= key TITLE: - (if (and (stringp desc) ( (length desc) 0)) - desc (symbol-name type)) - /after)) + (when org-mobile-add-after + (concat afterKEYS= key TITLE: + (if (and (stringp desc) ( (length desc) 0)) + desc (symbol-name type)) + /after))) settings)) (push (list type match settings) new)) ((or (functionp (nth 2 e)) (symbolp (nth 2 e))) @@ -601,9 +612,10 @@ The table of checksums is written to the file mobile-checksums. (setq settings (append gsettings settings)) (setq settings (cons (list 'org-agenda-title-append - (concat afterKEYS= gkey # (number-to-string - (setq cnt (1+ cnt))) -TITLE: atitle /after)) + (when org-mobile-add-after + (concat afterKEYS= gkey # (number-to-string +(setq cnt (1+ cnt))) + TITLE: atitle /after))) settings)) (push (list type match settings) new) (and new (list X SUMO (reverse new) @@ -650,7 +662,9 @@ The table of checksums is written to the file mobile-checksums. pl (point-at-eol (delete-region (point-at-bol) (point-at-eol)) - (insert line before prefix /before) + (insert line) + (when org-mobile-add-before + (insert before prefix /before)) (beginning-of-line 1)) (and (looking-at [ \t]+) (replace-match ))) (insert (if in-date *** ** )) -- 1.8.3.4
Re: [O] koma letter exporter: changing the priority of options
Hi,
Alan Schmitt wrote:
- (format \\KOMAoption{backaddress}{%s}\n (if with-backaddress true
false))
- (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks
with-foldmarks false))
- (format \\KOMAoption{fromphone}{%s}\n (if with-phone true false))
- (format \\KOMAoption{fromemail}{%s}\n (if with-email true
false
+ (if with-backaddress (format \\KOMAoption{backaddress}{true}\n) )
+ (if (not (equal with-foldmarks true)) (format
\\KOMAoption{foldmarks}{%s}\n with-foldmarks) )
+ (if with-phone (format \\KOMAoption{fromphone}{true}\n) )
+ (if with-email (format \\KOMAoption{fromemail}{true}\n) )))
If I read the patch correctly then the consequence is that you cannot
configure your LCO file to set defaults for these values and inhibit
them in specific letters by setting the corresponding option to nil. For
example, in my LCO file I enable all of these options but sometimes I
don't want to have foldmarks or a backaddress or whatever. So I can
write #+OPTIONS: backaddress:nil and it is supressed. The patch changes
that.
I did some experiments and it seems that by default foldmarks is
true. The idea behind the patch is that, if we don't change the default
values, then things are not output. Let me know if this is fine with you
and I'll commit this. (I'll also edit the work with the new default
values.)
I still have an issue with the default value for email. I have set-up my
email address in emacs, and it's picked up by the koma exporter. I want
to use a different address in my work letters (which use a custom lco
file), but the email address is overridden by the one picked up by the
following function:
(defun org-koma-letter-email ()
Return the current `user-mail-address'
user-mail-address)
What I propose is the following:
- we leave the default AUTHOR and EMAIL at nil
- if they are still nil, we output the default values _before_ inputting
the lco file
- if they are no longer nil, we output their values _after_ inputting
the lco file
This way, if they are not defined in the file, then the lco can override
them, otherwise the local option will be the one used.
What do you think?
Seems fine by me.
Cheers,
Viktor
Alan
Re: [O] koma letter exporter: changing the priority of options
Hi, Rasmus wrote: I think we need to treat koma variables more generally (I have some sketches locally) if anything. Not make their behavior more specialized. Could you elaborate on what you mean by this? But you'd still end up with two emails in your file, and if you lost the LCO file the other email would still be there. That is a valid criticism. I'd rather not have data specified in the TeX file that is overwritten later on. However, if you lose the LCO file, presumably you can't regenerate the lettern anyway. I slightly less mind-boggling approach would be to replace the default function with one that (1) fetches the LCO values from the file (but what if they are remote?); (2) obtains the path via kpsewhich (run from the current dir); (3) run grep on each of these files with some intelligent keyword. The only hard part is (1) and (2) and (3) are almost foolproof. That approach, in my view, seems overly complicated and also very brittle. Cheers, Viktor –Rasmus -- ツ
Re: [O] Slides about LaTeX export
Hi, Fabrice Niessen wrote: Could one of you report (as suggested by Nick) whether it works (or not) from another browser on the Mac? Snow Leopard 10.6.8: - Chrome: only yellow boxes - Safari: only yellow boxes - Firefox: yellow boxes with code Cheers, Viktor
Re: [O] [suggest] We should import latex template system
Hi Marcin,
Marcin Borkowski wrote:
Dnia 2013-06-12, o godz. 08:46:43
Viktor Rosenfeld listuse...@gmail.com napisał(a):
I would also like to have a template mechanism for my LaTeX exports.
However, I think the way to do it in LaTeX is to write custom *.sty
files which can then be included using #+LATEX_HEADER:
\usepackage{...} for individual exports or more generally using
org-latex-packages-alist.
I've been wanting to learn how to do it but I did not find the time
yet. (Any pointers to good tutorials would be appreciated.)
It's easier than you might think.
http://www.ctan.org/pkg/clsguide
http://tex.stackexchange.com/questions/2416/reference-guide-to-begin-writing-a-class-and-or-a-package
Thanks for these links!
Cheers,
Viktor
Re: [O] [suggest] We should import latex template system
Hi,
Feng Shu wrote:
org-mode odt exporter are using 'org-odt-styles-file, which are odt
templetes, I think latex exporter should do like this. for example:
I would also like to have a template mechanism for my LaTeX exports.
However, I think the way to do it in LaTeX is to write custom *.sty
files which can then be included using #+LATEX_HEADER: \usepackage{...}
for individual exports or more generally using org-latex-packages-alist.
I've been wanting to learn how to do it but I did not find the time yet.
(Any pointers to good tutorials would be appreciated.)
Cheers,
Viktor
org-latex-styles-file or org-latex-templete-file
we can include many different language's templates into org, and no need
touch the ox-latex.el and the user can write theirs template easily,
we can use locale to determine which template will be used
converting latex fragements can use templates too, like:
org-latex-fragment-templete-file
--
Re: [O] ox-koma-letter support for \cc and \encl?
Hi Vikas, Vikas Rawal wrote: Yes. Add two headlines to your letter, one tagged with :CC: and one with :ENCL:. The content below these headlines will be converted to the relevant LaTeX code. This also works with :PS:. However, you need a fairly recent version of ox-koma-letter. Thanks. Works perfect. Is it documented anywhere? I'll document it in the tutorial once Org-mode 8.1 is released. Right now this feature is only available in master. Cheers, Viktor Best, Vikas
Re: [O] ox-koma-letter support for \cc and \encl?
Hi Rasmus,
I didn't have time to look at your code on the weekend, but I had to
write a letter with ENCL and it worked perfectly. I'm liking this setup
more and more. I don't know if you went ahead and implemented the
:with-legacy option, but I think it should default to `nil', so the
stuff in the headlines takes precedence.
Cheers,
Viktor
Rasmus wrote:
Vikas Rawal vikasli...@agrarianresearch.org writes:
Yes. Add two headlines to your letter, one tagged with :CC: and one with
:ENCL:. The content below these headlines will be converted to the
relevant LaTeX code. This also works with :PS:. However, you need a
fairly recent version of ox-koma-letter.
Thanks. Works perfect. Is it documented anywhere?
In the changelogs mostly. I have some documentation locally as well
that hasn't been applied. Here's an unpolished quote:
;; Headlines are in general ignored. However, headlines with special
;; tags can be used for specified contents like postscript (ps), carbon
;; copy (cc), encloses (encl) and code to be inserted after
;; \end{letter} (after_letter).
–Rasmus
--
Hvor meget poesi tror De kommer ud af et glas isvand?
Re: [O] koma letter export
Hi Vikas, Vikas Rawal wrote: I am trying to use ox-koma-letter for my correspondence. I have a functioning test file that produces a nice pdf. But I would like to set it up so as to have one letter per headline, and do subtree export to produce the pdf. I am attaching the test file for the purpose. When I export it using C-c @ C-c C-e k o, this file gives me the following error: I'm not sure about the C-c @ keys. On OS X this results in a message that C-c M-l are not bound. (The @ key is accessed using Alt-L and Alt is mapped to Meta in Emacs.) However, using C-c C-e C-s k o I can create a letter from your example just fine. Note the C-s in the middle which selects the current subtree. Cheers, Viktor let*: Wrong type argument: char-or-string-p, nil Have I made a mistake or is there a bug somewhere? Vikas * A Simple letter :PROPERTIES: :EXPORT_LATEX_CLASS: vikasletter :EXPORT_LCO: DefaultAddress :EXPORT_AUTHOR: Vikas Rawal :EXPORT_DATE: April 22, 2013 :EXPORT_EMAIL: vikasra...@gmail.com :EXPORT_TO_ADDRESS: John Doe\\ :EXPORT_TO_ADDRESS: Other Street 1\\ :EXPORT_TO_ADDRESS: 54321 Other City :EXPORT_OPENING: Dear , :EXPORT_CLOSING: Yours sincerely, :EXPORT_OPTIONS: backaddress:nil :END: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enimad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Re: [O] ox-koma-letter support for \cc and \encl?
Hi Vikas, Vikas Rawal wrote: Does ox-koma-letter support \cc and \encl? Vikas Yes. Add two headlines to your letter, one tagged with :CC: and one with :ENCL:. The content below these headlines will be converted to the relevant LaTeX code. This also works with :PS:. However, you need a fairly recent version of ox-koma-letter. Cheers, Viktor
Re: [O] koma letter exporter: changing the priority of options
Hi Alan,
Alan Schmitt wrote:
Hello,
I just had to write a new letter with a fresh LCO file, and I would like
to propose to change the priority of options. The current priority is:
local options emacs variables lco file.
Unfortunately emacs variables have a default value, which means they are
output in the .tex file even if they are not set. Thus it is impossible
to set some options in the lco file (such as foldmarks or backaddress).
Why not simply set these Emacs variables to nil? Then they are not
written in the TeX file and the LCO file works as expected.
I propose to either change the priority to:
local options lco file emacs variables
I chose the current behavior in order to have the LCO file as a default
which can easily be overwritten if wanted by setting an option line for
an individual header. For example, I have foldmarks and backaddress
enabled in my LCO file. Recently I had to sent a few letters by email
where these things don't make a lot of sense. So I disabled them using
#+OPTIONS: foldmarks:nil backaddress:nil
or to not output these options when they have not been set. Here are the
four options I have not set that end up in my .tex file, shadowing my
lco configuration:
,
| \KOMAoption{backaddress}{true}
| \KOMAoption{foldmarks}{true}
| \KOMAoption{fromphone}{true}
| \KOMAoption{fromemail}{true}
`
Perhaps the best option would be to change the default value of these
variables to nil? We have almost every option that personalizes
a letter, e.g., opening and closing, set to nil already. The only
benefit of having default values is to show off the features of
org-koma-letter. But it seems to be interfering with people's workflow
so best turn them off.
Cheers,
Viktor
What do you think?
Alan
Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup
Hi Xavier,
Xavier Garrido wrote:
Hi koma-letterers,
Patches:
1. summarizes all changes in author. It uses my solution as mentioned
above.
2. full support for after closing keywords. See commit message
3. signature to nil
4. change handling of subject and allow for setting subject in
OPTION-line.
I'm going to apply the patches. Thanks to both of you for the nice work!
I just update Org/git and install ox-koma-letter lisp file. I have a
strange behavior with EMAIL keyword since there will be always a
=\setkomavar{fromemail}= command in my LaTeX produced file even if
there is no #+EMAIL: keyword on top of my org file. This is slightly
different from what I get when I write or not #+AUTHOR: keyword : the
=\setkomavar{fromname}= naturally disappears if AUTHOR is not
written.
I do not want to write every time my email in org file header since
it is already set in a lco file. But given this problem, the email is
always overloaded when exporting to latex/pdf.
Please check the values of `org-koma-letter-email' and
`org-koma-letter-author'. They should be set to nil if you have these
settings defined in an LCO file and do not want to set them in the
generated TeX sources. I use such a setup and the latest master branch
is working for me.
Cheers,
Viktor
I had a look into ox-koma-letter script and even if I saw small
differences when dealing with AUTHOR and EMAIL keywords, I am not
able to solve solve this discrepancy.
Xavier
PS: except from this little problem, it works like a charm, so thanks a lot.
Re: [O] org-effectiveness
Hello, David Arroyo Menéndez wrote: Hello, I would like propose org-effectiveness to contrib. Org effectiveness is a mode to measure the personal effectiveness using org todos. +1 It should use `org-time-clocksum-use-effort-durations'. I definitely like when my weekly clock report tells me that I've worked more than seven days the past week. Awesome! Cheers, Viktor Regards.
Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup (was: [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults)
Hi Rasmus,
Rasmus wrote:
Attached are three patches that goes on top of Viktor's latest patch
(I've also attached it here since I rebased stuff and might have
changed it by accident).
1. Viktor's latest patch.
2. The patch describe above that gets user name and email and works
on my system. . .
Your code works for me. From my point of view, the pros are that per
default `org-koma-letter-{author,sender}' pick up the values of
`user-full-name' and `user-mail-address' whenever they are changed.
That's very nice! The cons are that IHMO it's quite complicated for
setting something as simple as author and email and you mentioned a
possible crash which I did not test further. Could this be tested using
`functionp'? Still, I think we should stick with it for now.
3. Cleaning up special-tags functions introduced in
ec108f4c3507ed546a564a48b7379355a65aa9f4. It works a lot better
now and some of the mess in the template is moved to other
functions.
I could not apply this.
4. Sets defcustom org-koma-letter-signature nil since that
corresponds to default scrlttr2 behavior anyway (p. 183 in the
manual).
Works for me.
As a side note, I had quite a few problems working with your patches.
None of them applied against master, or against my latest patch as you
claimed. I had to merge in some of the changes of 0002 by hand. I
suggest that we nail down the workings of AUTHOR and EMAIL first (should
be done now) and then start with clean separate branches branched from
master for your subject and heading code. We could even use github for
this, what do you think?
Cheers,
Viktor
Re 4.: I'd like to do something similar to
org-koma-letter-subject-format. But I'm not sure how, at the moment
(perhaps make t the default and associate it with the current default
list).
–Rasmus
--
This is the kind of tedious nonsense up with which I will not put
From bbaf9a6ddd75368b2143e6b8fb50be64bd66b50d Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld listuse...@gmail.com
Date: Thu, 23 May 2013 00:00:38 +0200
Subject: [PATCH 1/4] ox-koma-letter.el: Reintroduce variables removed in
commit 832c6fd with proper defaults.
* ox-koma-letter.el (org-koma-letter-author): Dedicated
variable to set the KOMA variable fromname; initialized to
`user-full-name' using `after-init-hook' if not set
explicitly.
(org-koma-letter-email): Dedicated variable to set the KOMA
variable fromemail; initialized to `user-mail-address' using
`after-init-hook' if not set explicitly.
(koma-letter): Use dedicated variables for AUTHOR and EMAIL.
(org-koma-letter-template): Variable name change.
Setting the variables `org-koma-letter-author' and `org-koma-letter-email' to
the values of `user-full-name' and `user-mail-address' respectively, allows
the user to skip =#+AUTHOR:= and =#+EMAIL:= lines when configuring a letter.
However, if the user wishes to set this information in LCO files, these
variables need to be set to nil.
---
contrib/lisp/ox-koma-letter.el | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 92cf13a..24c1ac5 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -82,6 +82,32 @@
:group 'org-export-koma-letter
:type 'string)
+(defcustom org-koma-letter-author (if (boundp 'org-koma-letter-author)
+ user-full-name
+;; Empty string means not set yet.
+)
+ The sender's name.
+
+This variable defaults to the value of `user-full-name'.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(add-hook 'after-init-hook
+(lambda ()
+ (if (string= org-koma-letter-author )
+(setq org-koma-letter-author user-full-name
+
+(defcustom org-koma-letter-email user-mail-address
+ The sender's email address.
+
+This variable defaults to the value of `user-mail-address'.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(add-hook 'after-init-hook
+(lambda ()
+ (if (string= org-koma-letter-email )
+(setq org-koma-letter-email user-mail-address
(defcustom org-koma-letter-from-address nil
Sender's address, as a string.
@@ -93,7 +119,6 @@
:group 'org-export-koma-letter
:type 'string)
-
(defcustom org-koma-letter-place nil
Place from which the letter is sent.
:group 'org-export-koma-letter
@@ -207,10 +232,10 @@ content temporarily.)
(org-export-define-derived-backend 'koma-letter 'latex
:options-alist
'((:lco LCO nil org-koma-letter-class-option-file)
-(:sender AUTHOR nil org-koma-letter-author)
+(:author AUTHOR nil org-koma-letter-author t)
(:from-address FROM_ADDRESS nil org-koma-letter-from-address newline)
(:phone-number PHONE_NUMBER nil org-koma-letter-phone-number)
-(:email EMAIL nil
Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup
Hi Rasmus,
Rasmus wrote:
Rasmus ras...@gmx.us writes:
4. Sets defcustom org-koma-letter-signature nil since that
corresponds to default scrlttr2 behavior anyway (p. 183 in the
manual).
Re 4.: I'd like to do something similar to
org-koma-letter-subject-format. But I'm not sure how, at the moment
(perhaps make t the default and associate it with the current default
list).
This patch makes the subject option easier although still relying on
a list for multiple options (see the description in the patch). The
default is t corresponding to do nothing but print komavar subject.
I haven't found any bugs but please test it (along with other patches)
if time permits.
I could not apply this either and I am pressed for time right now. Could
you resend a diff against the current master?
A potential problem is that subject default to the file name and can
only be disabled with the option subject:nil. The file name to title
convention is bad in ox-latex.el and I think it's if anything worse
here. I'd like to make it nil by default. What do you guys think?
I'm also not a big fan of the title defaulting to the filename. But I
think it is a minor issue. What I think is quite useful is setting the
subject to the headline of the exported subtree. Wouldn't we also lose
this if subject is nil?
Cheers,
Viktor
–Rasmus
PS: Perhaps it would it be beneficial to make some test-letter
displaying the different scenarios in which we use ox-koma-letter? To
make sure that stuff doesn't get broken.
--
May the Force be with you
From 880f99622a4513520d1dd4e110428f18453a3af1 Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Sat, 25 May 2013 20:49:57 +0200
Subject: [PATCH 5/5] Only print subject options when necessary
* ox-koma-letter.el (org-koma-letter-subject-format): default is now t
* ox-koma-letter.el (org-koma-letter-template): better subject handling.
If =#+OPTIONS: subject:(x,y)= then =\KOMAoption{subject}{x, y}=. If
=subject:x= then =\KOMAoption{subject}{x}=.
If =subject:t= then =\KOMAoption{subject}{...}= is not printed but
\setkomavar{subject}{...} is printed. If =subject:nil= neither are
printed.
---
contrib/lisp/ox-koma-letter.el | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 4cb402e..ca20ec7 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -137,7 +137,7 @@ function may be given. Functions must return a string.
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-subject-format '(beforeopening left
untitled)
+(defcustom org-koma-letter-subject-format t
Use the title as the subject of the letter. At the time of
writing the following values are allowed:
@@ -162,6 +162,7 @@ English manual of 2012-07-22)
(const titled)
(const untitled)
(const :tag No export nil)
+ (const :tag Default options t)
(string))
:group 'org-export-koma-letter)
@@ -432,20 +433,16 @@ holding export options.
\\begin{document}\n\n
;; Subject
(let* ((with-subject (plist-get info :with-subject))
- (subject-format
-(if (member
- ;; test if subject-format is t
- (cond ((symbolp with-subject) (downcase (symbol-name
with-subject)))
- ((stringp with-subject) (downcase with-subject))
- (t nil))
- '(true t))
-org-koma-letter-subject-format
- with-subject))
+ (subject-format (cond ((member with-subject '(true t t)) nil)
+ ((stringp with-subject) (list with-subject))
+ ((symbolp with-subject)
+ (list (symbol-name with-subject)))
+ (t with-subject)))
(subject (org-export-data (plist-get info :title) info))
- (l (if (stringp subject-format) 1 (length subject-format)))
+ (l (length subject-format))
(y ))
(concat
- (when with-subject
+ (when (and with-subject subject-format)
(concat
\\KOMAoption{subject}{
(apply 'format
--
1.8.2.3
Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])
Hi Robert,
Robert Klein wrote:
Hello,
On 05/25/2013 03:57 PM, Rasmus wrote:
Alan Schmitt alan.schm...@polytechnique.org writes:
Hello,
Viktor Rosenfeld writes:
Hi Robert,
Robert Klein wrote:
Hi,
FWIW, from a users view it would be nice if:
- Use Author/Email information from org file
- If not present use information from LCO file
- if neither org file nor LCO file has any information use
user-full-name and user-email-address
Could this be solved by having several e.g. `setkomavar{fromname}'
and so on in the tex file, so is created as follows:
I'd go with 'no'. It's not aesthetically pleasing and I don't want my
output to look like LyX. When feasible we should go for beautiful
output. This isn't always the case at the moment, but still.
if no #+AUTHOR in org-file and user-full-name is set:
add user-full-name
if #+LCO(s) in org-file:
add LCO file(s)
if #+AUTHOR in org-file:
add \setkomavar{fromname}{#+AUTHOR}
same for email
Currently the ordering is: #+AUTHOR #+LCO and AUTHOR default to
(user-full-name).
hmm, sorry, I did not express myself in a good way.
what I meant is, if #+AUTHOR defaults to (user-full-name), could the
\setkomavar commands be placed /before/ \LoadLetterOption in the TeX
file, and after \LoadLetterOptions if #+AUTHOR is set in the .org file?
So you'd still get only one set of \setkomavar in the TeX file, but get
a (for me) more useful order of #+AUTHOR != (user-full-name) #+LCO
#+AUTHOR == (user-full-name)
I'm still having trouble to understand what would be gained by placing
\setkomavar{author}{.} before \LoadLetterOption if it defaults to
user-full-name. Could you maybe describe your setup and what you want to
achieve?
Cheers,
Viktor
Best regards
Robert
Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])
Hi Robert,
Robert Klein wrote:
Hi,
FWIW, from a users view it would be nice if:
- Use Author/Email information from org file
- If not present use information from LCO file
- if neither org file nor LCO file has any information use
user-full-name and user-email-address
Could this be solved by having several e.g. `setkomavar{fromname}'
and so on in the tex file, so is created as follows:
if no #+AUTHOR in org-file and user-full-name is set:
add user-full-name
if #+LCO(s) in org-file:
add LCO file(s)
if #+AUTHOR in org-file:
add \setkomavar{fromname}{#+AUTHOR}
same for email
add \setkomavar{signature}{\usekomavar{fromname}}
This is what is implemented by the latest patch
(http://thread.gmane.org/gmane.emacs.orgmode/72430/focus=72525).
so the result tex file may have:
\setkomavar{fromname}{Hans Wurst}
\setkomavar{fromemail}{hans_wu...@example.com}
...
\setkomavar{fromname}{Reiner Zufall}
\setkomavar{fromemail}{reiner_zuf...@example.com}
\setkomavar{signature}{\usekomavar{fromname}}
Why do you repeat fromname and fromemail in your example?
Cheers,
Viktor
This probably isn't a `clean' solution, but should work without a need
to grep LCO files.
Best regards
Robert
On 05/23/2013 12:06 AM, Viktor Rosenfeld wrote:
Hi Rasmus,
Viktor Rosenfeld wrote:
Hi Rasmus,
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)
I once had a teacher who talked about the optimal degree of
conservatism (as well speaking positively about being in the infamoues
ivory tower). 5. is fine with me. So I guess the deal is
1. default value is the same as in ox-latex.
2. . . . but it's kept in a seperete variable ox-kl variable.
I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.
Does the attached patch work for you (also with ps tags?)
It works, but I noticed the following problem: According to the Emacs
documentation `user-mail-address' is only set by Emacs after the
initialization process has completed and if it is not explicitly set
during initialization [1]. So, the defcustom of org-koma-letter-email
does not work as expected if the user has not set `user-mail-address'
before. Instead it is set to the empty string, which according to the
code setting `user-mail-address' means not set yet.
This can be taking care of by using `after-init-hook' as in the example
below. It has the added advantage that the value of `user-mail-address'
will be picked up regardless of whether it is set before or after
require'ing ox-koma-letter.
Note that this creates a slight inconsistency with regard to
`user-full-name' which is only picked up correctly if it is set before
require'ing ox-koma-letter. I've fixed this by a slightly complicated
defcustom definition of `org-koma-letter-author' and another
after-init-hook.
I've also changed the docstring to indicate what are the default values
and added the :group and :type flags again.
I've put my changes into a patch against the current master (commit
06cdb2d2). Could you check it with your setup?
Cheers,
Viktor
Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])
Hi Rasmus,
Rasmus wrote:
The following message is a courtesy copy of an article
that has been posted to gmane.emacs.orgmode as well.
Alan Schmitt alan.schm...@polytechnique.org writes:
Hello,
Viktor Rosenfeld writes:
Hi Robert,
Robert Klein wrote:
Hi,
FWIW, from a users view it would be nice if:
- Use Author/Email information from org file
- If not present use information from LCO file
- if neither org file nor LCO file has any information use
user-full-name and user-email-address
Could this be solved by having several e.g. `setkomavar{fromname}'
and so on in the tex file, so is created as follows:
I'd go with 'no'. It's not aesthetically pleasing and I don't want my
output to look like LyX. When feasible we should go for beautiful
output. This isn't always the case at the moment, but still.
I agree that there should not be multiple instances of, e.g.,
\setkomavar{fromname} in the TeX file. I must have overlooked that bit
in the original mail.
On a side-note, Viktor: this seems to be the default in scrletter
anyway:
add \setkomavar{signature}{\usekomavar{fromname}}
Could we remove it? I'd like us to get to a more clean template (C-e
# koma-letter RET).
I think so, yes.
This is what is implemented by the latest patch
(http://thread.gmane.org/gmane.emacs.orgmode/72430/focus=72525).
I'm waiting for Rasmus's confirmation that it works for him before
committing it.
Thanks and sorry for the wait. No it didn't work for me. My user
name was always overwritten by . . . I couldn't figure out why.
Hmm, that's too bad. I tested it pretty thoroughly. Could you maybe
trace the contents of the variable by adding calls to message in various
places?
I've attached a patch that work for me (it goes on top of Viktor's
patch 148c737ae79f3a98d8e93147c2d0ec0db3a2389a). It allows for nil
and it gets up-to-date default values by default. In my book it's a
bit more clean 'cause it doesn't rely on hooks. It does, introduce a
new helper function to distinguish between a function value (which are
default for the two variables) and a string value (and nil for that
matter). I don't know if this is undesirable. It would crash if you
set the variables to a symbol that isn't nil and isn't a function.
Did you send the patch? I did not receive it and it's not available on
gmane.
Cheers,
Viktor
It seems to work in mine and Viktor's use-case (to the best of my
testing ability).
–Rasmus
--
⠠⠵
Re: [O] Org sources and PDF files on Worg
Hi everybody, Viktor Rosenfeld wrote: I recently wrote a tutorial for the ox-koma-letter exporter [1] which includes a link to an Org file [2] file and a PDF file [3] as examples. The files are checked into the Worg repository, but they are not available online. Is there something I have to do to enable this? At first I thought the problem was related to the switchover to the new exporter, but the issue persists. Also, an old version of the tutorial at an old address [4] is still online even though I've changed the location in the git repository. How can I delete this version? Cheers, Viktor [1] http://orgmode.org/worg/exporters/koma-letter-export.html [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html I believe I can give a partial answer: it looks like Worg isn't publishing right now, which suggests that there was a recent commit which broke things. The search for the problem begins. Once the error is identified and fixed, then things should get back to normal. That's not it. The publishing process was working when I last checked. I just pushed a change and it's reflected in the published HTML file, i.e. [1], but the links are still now working and the old file still exists. So I checked again this morning and now the links to the source file and the PDF example both work. Not sure if it is because of a delay (the commit is only now listed on the worg homepage) or if somebody did actively fix something; in case of the latter, many thanks. The old version of the tutorial is still available at the old address which is a minor annoyance because it is quickly getting out of date. But I'm glad that the links are working. Cheers, Viktor
Re: [O] Org sources and PDF files on Worg
Hi Bastien, Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@gmail.com writes: I believe I can give a partial answer: it looks like Worg isn't publishing right now, which suggests that there was a recent commit which broke things. The search for the problem begins. Once the error is identified and fixed, then things should get back to normal. That's not it. The publishing process was working when I last checked. I just pushed a change and it's reflected in the published HTML file, i.e. [1], but the links are still now working and the old file still exists. I forgot to add some publishing projects during the migration, namely worg-sources and worg-images. This should be fixed now. Thanks for the fix. I can confirm that the links work now. (Did just send a mail to that effect to the mailing list and then your message arrived.) However, the old version of the tutorial still shows at the old address. I moved the file in the worg git repository from org-tutorials/ to exporters/ but now there are two separate HTML copies. Do I have to do something else to explicitly delete the old version? Thanks again, Viktor Thanks, -- Bastien
Re: [O] Org sources and PDF files on Worg
Hi Bastien, Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@gmail.com writes: However, the old version of the tutorial still shows at the old address. I moved the file in the worg git repository from org-tutorials/ to exporters/ but now there are two separate HTML copies. Do I have to do something else to explicitly delete the old version? Er, this is a strong (and quite stupid) limitation of the publishing engine: it does not delete files that exist from a previous publication. I have absolutely no idea for a clever mechanism that would find the files to delete. We can delete them manually for now -- please send me the list of .html files I need to delete. The files are: - http://orgmode.org/worg/org-tutorials/koma-letter-export.html - http://orgmode.org/worg/org-tutorials/koma-letter-example.html Sorry for the inconvenience. Is there also a way not to publish Org files to HTML which are checked into the Worg repository? I am asking because the file http://orgmode.org/worg/exporters/koma-letter-example.html could also be deleted. It is created from http://orgmode.org/worg/sources/exporters/koma-letter-example.org which is included as an example in http://orgmode.org/worg/sources/exporters/koma-letter-export.org. But the HTML file is not linked anywhere. Cheers, Viktor -- Bastien
Re: [O] Org sources and PDF files on Worg
Hi Bastien, Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@gmail.com writes: The files are: - http://orgmode.org/worg/org-tutorials/koma-letter-export.html - http://orgmode.org/worg/org-tutorials/koma-letter-example.html Sorry for the inconvenience. Deleted, thanks. Thanks! Is there also a way not to publish Org files to HTML which are checked into the Worg repository? We could use an :exclude directive in the publishing project, but I'd rather not go this way, too mush maintainance hassle for fixing ~zero inconvenience... I am asking because the file http://orgmode.org/worg/exporters/koma-letter-example.html could also be deleted. It is created from http://orgmode.org/worg/sources/exporters/koma-letter-example.org which is included as an example in http://orgmode.org/worg/sources/exporters/koma-letter-export.org. But the HTML file is not linked anywhere. Well, it does not hurt that much to have this orphan HTML page. I agree. Cheers, Viktor HTH, -- Bastien
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Hi Rasmus,
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)
I once had a teacher who talked about the optimal degree of
conservatism (as well speaking positively about being in the infamoues
ivory tower). 5. is fine with me. So I guess the deal is
1. default value is the same as in ox-latex.
2. . . . but it's kept in a seperete variable ox-kl variable.
I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.
Does the attached patch work for you (also with ps tags?)
It works, but I noticed the following problem: According to the Emacs
documentation `user-mail-address' is only set by Emacs after the
initialization process has completed and if it is not explicitly set
during initialization [1]. So, the defcustom of org-koma-letter-email
does not work as expected if the user has not set `user-mail-address'
before. Instead it is set to the empty string, which according to the
code setting `user-mail-address' means not set yet.
This can be taking care of by using `after-init-hook' as in the example
below. It has the added advantage that the value of `user-mail-address'
will be picked up regardless of whether it is set before or after
require'ing ox-koma-letter.
Note that this creates a slight inconsistency with regard to
`user-full-name' which is only picked up correctly if it is set before
require'ing ox-koma-letter. I've fixed this by a slightly complicated
defcustom definition of `org-koma-letter-author' and another
after-init-hook.
I've also changed the docstring to indicate what are the default values
and added the :group and :type flags again.
#+BEGIN_SRC
(defcustom org-koma-letter-email user-mail-address
The sender's email address.
This variable defaults to the value of `user-mail-address'.
:group 'org-export-koma-letter
:type 'string)
(add-hook 'after-init-hook
(lambda ()
(if (string= org-koma-letter-email )
(setq org-koma-letter-email user-mail-address
(defcustom org-koma-letter-author (if (boundp 'org-koma-letter-author)
user-full-name
;; Empty string means not set yet.
)
The sender's name.
This variable defaults to the value of `user-full-name'.
:group 'org-export-koma-letter
:type 'string)
(add-hook 'after-init-hook
(lambda ()
(if (string= org-koma-letter-author )
(setq org-koma-letter-author user-full-name
#+END_SRC
Cheers,
Viktor
[1]
http://www.gnu.org/software/emacs/manual/html_node/elisp/User-Identification.html#User-Identification
–Rasmus
--
Dung makes an excellent fertilizer
From 92b07bac2d707f01e48796778453b67a9ecd1daa Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Wed, 22 May 2013 01:16:54 +0200
Subject: [PATCH 5/5] Variables for author and email for ox-koma-letter and a
bug fix.
* ox-koma-letter.el (koma-letter): reintroduced koma-letter
specif author and email.
* ox-koma-letter.el (koma-letter): set
org-koma-special-content to nil when exporting
The former is needed so that author/email can be set in a LCO file.
TINYCHANGE
---
contrib/lisp/ox-koma-letter.el | 49
+++---
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 020df52..92cf13a 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -109,6 +109,12 @@
:group 'org-export-koma-letter
:type 'string)
+(defcustom org-koma-letter-email user-mail-address
+ The default email address stored in the letter. )
+
+(defcustom org-koma-letter-author user-full-name
+ The default name of the sender. )
+
(defcustom org-koma-letter-signature \\usekomavar{fromname}
String used as the signature.
:group 'org-export-koma-letter
@@ -143,7 +149,6 @@ English manual of 2012-07-22)
:group 'org-export-koma-letter)
-
(defcustom org-koma-letter-use-backaddress t
Print return address in small line above to address.
:group 'org-export-koma-letter
@@ -179,7 +184,6 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'string)
-
(defconst org-koma-letter-special-tags-after-closing
'(PS ENCL CC)
Headers tags to be inserted after closing)
@@ -193,7 +197,7 @@ Use `foldmarks:true' to activate default fold marks or
org-koma-letter-special
Re: [O] Org sources and PDF files on Worg
Hi, Jay Kerns wrote: Hello Viktor, On Tue, May 21, 2013 at 2:13 PM, Viktor Rosenfeld listuse...@gmail.com wrote: Hi, I recently wrote a tutorial for the ox-koma-letter exporter [1] which includes a link to an Org file [2] file and a PDF file [3] as examples. The files are checked into the Worg repository, but they are not available online. Is there something I have to do to enable this? At first I thought the problem was related to the switchover to the new exporter, but the issue persists. Also, an old version of the tutorial at an old address [4] is still online even though I've changed the location in the git repository. How can I delete this version? Cheers, Viktor [1] http://orgmode.org/worg/exporters/koma-letter-export.html [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html I believe I can give a partial answer: it looks like Worg isn't publishing right now, which suggests that there was a recent commit which broke things. The search for the problem begins. Once the error is identified and fixed, then things should get back to normal. That's not it. The publishing process was working when I last checked. I just pushed a change and it's reflected in the published HTML file, i.e. [1], but the links are still now working and the old file still exists. Cheers, Viktor I've copied Marc on this message - we'll see if we can track the problem down. Thanks for the report. -- Jay Kerns -- G. Jay Kerns, Ph.D. Youngstown State University http://people.ysu.edu/~gkerns/
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Hi,
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Ah, you mean the textsc? Perhaps it is a bit eccentric. But you're
bringing up a good point. It should recognize [p]+s and perhaps even
order them. . .
If there is no PS prefix set, users could simply write these out
themselves. I don't think it is much of a burden. Recognizing multiple
:P[+]S: tags in code seems like overkill to me. The all go into the same
\ps, don't they?
No, you'd want have
\ps{ps:one}
\ps{pps:two}
\ps{pps:three}.
Okay, I didn't know this. But what's the advantage over
\ps{
ps:one
ps:two
ps:three}
The latter example does not really work for me because I often write
letters below a TODO headline (as opposed to a dedicated file). So I
restrict export to a subtree which would not work if I'm below the
letter headline. In my case I would use something like this:
#+BEGIN_EXAMPLE
* TODO write letter
:PROPERTIES:
:EXPORT_OPENING: ...
...
:END:
The letter goes here.
** TO :TO:
...
#+END_EXAMPLE
I have a capture template setup for letters, so I don't normally have to
add the address information manually. I would probably stick to the old
format and use headlines if I have a PS and so on.
Cool, you should write an article about!
Do you mean the capture template? I might put it in the tutorial. I
planned to have a tips and tricks section there anyway.
Cheers,
Viktor
--
Don't panic!!!
[O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])
Hi Rasmus,
Viktor Rosenfeld wrote:
Hi Rasmus,
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)
I once had a teacher who talked about the optimal degree of
conservatism (as well speaking positively about being in the infamoues
ivory tower). 5. is fine with me. So I guess the deal is
1. default value is the same as in ox-latex.
2. . . . but it's kept in a seperete variable ox-kl variable.
I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.
Does the attached patch work for you (also with ps tags?)
It works, but I noticed the following problem: According to the Emacs
documentation `user-mail-address' is only set by Emacs after the
initialization process has completed and if it is not explicitly set
during initialization [1]. So, the defcustom of org-koma-letter-email
does not work as expected if the user has not set `user-mail-address'
before. Instead it is set to the empty string, which according to the
code setting `user-mail-address' means not set yet.
This can be taking care of by using `after-init-hook' as in the example
below. It has the added advantage that the value of `user-mail-address'
will be picked up regardless of whether it is set before or after
require'ing ox-koma-letter.
Note that this creates a slight inconsistency with regard to
`user-full-name' which is only picked up correctly if it is set before
require'ing ox-koma-letter. I've fixed this by a slightly complicated
defcustom definition of `org-koma-letter-author' and another
after-init-hook.
I've also changed the docstring to indicate what are the default values
and added the :group and :type flags again.
I've put my changes into a patch against the current master (commit
06cdb2d2). Could you check it with your setup?
Cheers,
Viktor
From 271c6548aa1f0b61763c30b7116dbb3325364683 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld listuse...@gmail.com
Date: Thu, 23 May 2013 00:00:38 +0200
Subject: [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit
832c6fd with proper defaults.
* ox-koma-letter.el (org-koma-letter-author): Dedicated
variable to set the KOMA variable fromname; initialized to
`user-full-name' using `after-init-hook' if not set
explicitly.
(org-koma-letter-email): Dedicated variable to set the KOMA
variable fromemail; initialized to `user-mail-address' using
`after-init-hook' if not set explicitly.
(koma-letter): Use dedicated variables for AUTHOR and EMAIL.
(org-koma-letter-template): Variable name change.
Setting the variables `org-koma-letter-author' and `org-koma-letter-email' to
the values of `user-full-name' and `user-mail-address' respectively, allows the
user to skip =#+AUTHOR:= and =#+EMAIL:= lines when configuring a letter.
However, if the user wishes to set this information in LCO files, these
variables need to be set to nil.
---
contrib/lisp/ox-koma-letter.el | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 4318db1..b56dadb 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,6 +80,32 @@
:group 'org-export-koma-letter
:type 'string)
+(defcustom org-koma-letter-author (if (boundp 'org-koma-letter-author)
+ user-full-name
+;; Empty string means not set yet.
+)
+ The sender's name.
+
+This variable defaults to the value of `user-full-name'.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(add-hook 'after-init-hook
+(lambda ()
+ (if (string= org-koma-letter-author )
+(setq org-koma-letter-author user-full-name
+
+(defcustom org-koma-letter-email user-mail-address
+ The sender's email address.
+
+This variable defaults to the value of `user-mail-address'.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(add-hook 'after-init-hook
+(lambda ()
+ (if (string= org-koma-letter-email )
+(setq org-koma-letter-email user-mail-address
(defcustom org-koma-letter-from-address nil
Sender's address, as a string.
@@ -91,7 +117,6 @@
:group 'org-export-koma-letter
:type 'string)
-
(defcustom org-koma-letter-place nil
Place from which the letter is sent.
:group 'org-export-koma-letter
@@ -153,10 +178,10 @@ Use
Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]
Hi,
Alan Schmitt wrote:
Rasmus writes:
I found a bug in that the subject variable should be a list cf. the
KOMA manual. This patch fixes this.
It's pretty complex for something so simple, and I might be inclined
to admit to the put it in a LCO-file approach might be better.
I'd really like to have a second opinion on this. Viktor?
I think this patch is great simply from the usability standpoint of
being able to configure the behavior through customize (which I don't
generally use, but admit that it's a good thing).
I found a few issues though:
1. Choosing `No export' in customize results
`\KOMAoption{subject}{nil}'.
2. It is not possible to set a subject format in the LCO file because if
`org-koma-letter-subject-format' is set, the KOMA option will be
overwritten explicitly, and if it is set to `nil' then the subject is
inhibited altogether. This is actually a problem with the old code as
well. One way out of this is to only print the subject line (i.e.,
`\setkomavar{subject}{.}' if `org-koma-letter-subject-format' is nil and
and fix `noexport' to hide the subject (i.e., inhibit
`\setkomavar{subject}{.}'). Is this the entended behaviour? I'll try to
post a patch for this later tonight.
3. I'm not a big fan of the parentheses in the subject:(.) syntax, but
if that's required to use an option list with multiple values I think
it's okay. It would be nice to be able to specify a single value without
the parens, but it's not a high priority (and I don't know how to do
that).
Cheers,
Viktor
Best,
Alan
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Hi,
Rasmus wrote:
This is probably the most fun change. It adds special tags PS, ENCL,
CC, AFTER_CLOSING as in my last patch set, but it uses heading this
time. E.g. ENCLs are under the heading * ENCL :ENCL:. This was
suggested by Nicolas, and it's nicer. The ideas comes from
ox-groff.el file ¹. Thanks Luis!
This is great! A few things:
- It doesn't work because `org-koma-letter-special-content' is set to
nil at the beginning of `org-koma-letter-template'. Why is that? If I
comment it out everything works.
- The function `org-koma-letter--get-tagged-content' does not use the
`info' argument. Also, the function is not documented.
- The second argument of `org-koma-letter-headline' is misspelled
(`conents').
- I would remove the formatting from org-koma-letter-ps-prefix and put
it in the docstring, simply because the separators for \encl and \cc
are also not formatted in the KOMA-Script defaults.
One thing I'd like to discuss is whether to adopt headings for TO and
FROM also. The Groff exporter already does so for it's letters. The
main benefit is that it allows for org-syntax. IMO it's a lot nicer
to look at as well. Check the org-groff site in the footnote for an
example.
I am not sure about this. I often write a letter below a task in my
Org files so I rely on exporting the subtree only. So I would have to
put the TO address below the letter text which looks weird, but is
doable. On the other hand, being able to use Org syntax and not have to
escape linebreaks with `\\' is a big plus.
I'd be happy to look into this the next time I have a free day for
programming if you guys (also) find in a more appealing. (One
additional benefit would be that for simple documents it wouldn't
matter whether groff or scrlttr2 was used as backend).
This would be a nice advantage.
Maybe both options could be supported. I.e., use a FROM headline if
available, but fall back on option lines if not? Or is this too
confusing for users?
Cheers,
Viktor
–Rasmus
Footnotes:
¹
http://orgmode.org/worg/org-tutorials/org-e-groff-documentation.html#sec-1-5
--
Powered by magic pixies!
From eeaa129b6807465566be881b96a94e14706c9a28 Mon Sep 17 00:00:00 2001
From: rasmus.pank rasmus.p...@gmail.com
Date: Sun, 19 May 2013 21:50:14 +0200
Subject: [PATCH 3/4] Added support for after closing and after document
entities in ox-koma-letter.
* ox-koma-letter.el (org-koma-letter-special-tags-after-closing): specials
tags inserted after =\end{closing}=
* ox-koma-letter.el (org-koma-letter-special-tags-other): other special tags
* ox-koma-letter.el (org-koma-letter-special-tags): collect
the two previoues lists (this might be done in a wrong way).
* ox-koma-letter.el (org-koma-letter-ps-prefix): a prefix for
PS since scrlttr does not provide it.
* ox-koma-letter.el (org-koma-letter-headline): stores content
in a special list if it is =`org-koma-letter-special-tags'= as
in ox-groff. Only returns contents if not tags not in special
tags.
* ox-koma-letter.el (org-koma-letter-special-content): holds special
content temporarily.
* ox-koma-letter.el (org-koma-letter-template): added support
for the headings with special tags.
The following example will now export a sensible manner.
* my letter
here's a letter
* PS :PS:
it's requires this patch
* CC :CC:
Nicolas, Viktor and Alan
* ENCL :ENCL:
many patches
1. this patch
2. another patch.
* include patches :AFTER_LETTER:
\myspecial macro
Namely, content of PS, ENCL and CC headings will be exported after
\closing{.} in the order prescribed by
=`org-koma-letter-special-tags-after-closing'=. The concent
of the =AFTER_LETTER= heading will be inserted after
=\end{letter}=, ideal for e.g. =pdfpages= commands.
---
contrib/lisp/ox-koma-letter.el | 86
+++---
1 file changed, 81 insertions(+), 5 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 77d21c7..8ae9fc5 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -183,6 +183,29 @@ Use `foldmarks:true' to activate default fold marks or
:group 'org-export-koma-letter
:type 'boolean)
+(defcustom org-koma-letter-ps-prefix \\textsc{ps}:
+ The prefix of PS. Used to construct PS as \PS-SUFFIX PS\
+ :group 'org-export-koma-letter
+ :type 'string)
+
+
+(defconst org-koma-letter-special-tags-after-closing
+ '(PS ENCL CC)
+ Headers tags to be inserted after closing)
+
+(defconst org-koma-letter-special-tags-other
+ '(FROM AFTER_LETTER)
+ Headers tags to be inserted after closing)
+
+(defconst org-koma-letter-special-tags
+ (append org-koma-letter-special-tags-other
+ org-koma-letter-special-tags-after-closing)
+ Header tags with special meaning)
+
+(defvar org-koma-letter-special-content nil holds special
+content temporarily.)
+
+
;;; Define Back-End
@@ -198,15 +221,18 @@ Use
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Hi, Rasmus wrote: Alan Schmitt alan.schm...@polytechnique.org writes: OK, sounds good, I've applied it. Actually, this patch does break LCO files. Now, if you don't set AUTHOR or EMAIL in the letter the default options from the LaTeX exporter always overwrite the settings defined in LCO files. Rasmus, couldn't you just set the old `org-koma-letter-sender' option if you don't use LCO files? Also, I agree that SENDER should have been called AUTHOR. It was a workaround because the LaTeX backend would ignore nil values for AUTHOR in derived backends (but not for EMAIL, so I kept this). This should now have been fixed. Let's wait with the rest till Vicktor's had a chance to look over it. Hmm, not fast enough. :-) Cheers, Viktor –Rasmus -- Summon the Mothership!
Re: [O] [patch] ox-koma-letter.el: credit [1/4]
Hi, Rasmus wrote: This one just updates the credit: most importantly with Viktor. Cool, thanks! - Is it me or is there no option to have git send-email just fix a the subject and heads and let the email program do the rest?! The manual and various blog post did not reveal how on earth to get it to just use Gnus for sending. . . The program seems not really to follow the Unix principle. . . I use format-patch to create the patch and send them manually. But getting send-email to work would automate some things. Cheers, Viktor
Re: [O] RFQ - new contribution - org-screenshot.el
Hi, Haider Rizvi wrote: Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Attached is a very first try at making org-screenshot run on OS X. Many open issues remain: - Clicking in a window will not take a screenshot using `screencapture -s' but aborts the process altogether and does not create a file. To capture a window one has to use `screencapture -w'. Another option is to use `screencapture -i' and toggle between window and selection mode using the space bar. The problem with this approach is that hitting the control key will place the screenshot into the clipboard and not create a file either. - Delay does not work because `screencapture -d' has a different meaning. To delay a screenshot, one has to use `screencapture -T'. Cheers, Viktor Here is a piece of code that was published earlier with a sample use. http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, -- Haider
Re: [O] RFQ - new contribution - org-screenshot.el
Forgot to attach the patch in my last mail. Sorry about the double posting. Viktor Rosenfeld wrote: Hi, Haider Rizvi wrote: Max Mikhanosha m...@openchat.com writes: Hi All, I've been writing some documentation in OrgMode with screenshots, and as with any screenshot taking, it takes a while to get one just right. A few tiny helper utilities, quickly snowballed into this :-) It may need some cleanup, but IMHO its too awesome not to share it with the list. To try it out, you'll need /usr/bin/scrot which is available as scrot package on most distributions. Cool. Can you make this a bit portable. On Mac OSX, the utility is called screencapture, and can be run with the same flags. Attached is a very first try at making org-screenshot run on OS X. Many open issues remain: - Clicking in a window will not take a screenshot using `screencapture -s' but aborts the process altogether and does not create a file. To capture a window one has to use `screencapture -w'. Another option is to use `screencapture -i' and toggle between window and selection mode using the space bar. The problem with this approach is that hitting the control key will place the screenshot into the clipboard and not create a file either. - Delay does not work because `screencapture -d' has a different meaning. To delay a screenshot, one has to use `screencapture -T'. Cheers, Viktor Here is a piece of code that was published earlier with a sample use. http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272 , | #+BEGIN_SRC emacs-lisp | (defun paste-clipboard-to-file (optional filename temp-dir) | Take a screenshot using the crosshairs and saveit to FILENAME, | if it is given or to a temp file in the TEMP-DIR | directory. Then add an orgmode style link at point. | (interactive) | (let* ((temporary-file-directory (or temp-dir images)) |(fname (or filename (make-temp-file img nil .jpg | (call-process-shell-command (concat | /usr/sbin/screencapture -s fname)) | (insert \n[[file: fname ]]) | (org-display-inline-images))) | ;; | (global-set-key (kbd C-c p) 'paste-clipboard-to-file) | | #+END_SRC ` Regards, -- Haider From 5938b848f4b9b30b25c903e3487834f9400f6ad9 Mon Sep 17 00:00:00 2001 From: Viktor Rosenfeld listuse...@gmail.com Date: Tue, 21 May 2013 19:32:16 +0200 Subject: [PATCH] org-screenshot: Let user configure capture program. * org-screenshot.el (org-screenshot-capture-binary): Configure the binary to capture a screenshot. (org-screenshot-take): Do not use hardcoded `scrot' binary. --- contrib/lisp/org-screenshot.el | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/contrib/lisp/org-screenshot.el b/contrib/lisp/org-screenshot.el index a54cb8f..54c8074 100644 --- a/contrib/lisp/org-screenshot.el +++ b/contrib/lisp/org-screenshot.el @@ -85,6 +85,11 @@ Options for taking and managing screen-shots :group 'org-link) +(defcustom org-screenshot-capture-binary scrot + Binary to capture screen contents. Use `scrot' on Linux and `screencapture' on Mac OS X. + :type 'string + :group 'org-screenshot) + (defcustom org-screenshot-image-directory ./images/ Directory in which screenshot image files will be stored, it be automatically created if it does't already exist. @@ -307,7 +312,7 @@ screenshot is done, any more `C-u' after that increases delay by (or (apply 'start-process (append - (list scrot *scrot* scrot -s path) + (list scrot *scrot* org-screenshot-capture-binary -s path) (when (plusp delay) (list -d (format %d delay) (error Unable to start scrot process))) -- 1.8.2.3
Re: [O] Let's discuss citation and Org syntax
Hi, Rasmus wrote: Hi, Now that 8.0 has shipped let's talk bibliography support. This follows directly upon the discussion around March[1]. I did not follow the discussion in March and only skimmed through the recent discussion in May [2]. But I was wondering if bibliography support in the LaTeX exporter would be BibTex-only or if it would also support biblatex, for example. Cheers, Viktor [1] http://mid.gmane.org/20130303070635.GA12112%40panahar [2] http://thread.gmane.org/gmane.emacs.orgmode/71754
[O] Org sources and PDF files on Worg
Hi, I recently wrote a tutorial for the ox-koma-letter exporter [1] which includes a link to an Org file [2] file and a PDF file [3] as examples. The files are checked into the Worg repository, but they are not available online. Is there something I have to do to enable this? At first I thought the problem was related to the switchover to the new exporter, but the issue persists. Also, an old version of the tutorial at an old address [4] is still online even though I've changed the location in the git repository. How can I delete this version? Cheers, Viktor [1] http://orgmode.org/worg/exporters/koma-letter-export.html [2] http://orgmode.org/worg/sources/exporters/koma-letter-example.org [3] http://orgmode.org/worg/images/ox-koma-letter/koma-letter-example.pdf [4] http://orgmode.org/worg/org-tutorials/koma-letter-export.html
Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]
Hi,
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Actually, this patch does break LCO files. Now, if you don't set
AUTHOR or EMAIL in the letter the default options from the LaTeX
exporter always overwrite the settings defined in LCO files.
This one is tough. . .
One could #+INCLUDE an org-file but that's not really a fair comment.
I'm not really sure how to progress.
1. One way would be do do a grep on the LCO files, but they might be
in the TeX PATH which would vary over TeX systems and OSes.
Way too complicated and brittle, IMHO.
2. Have people have empty AUTHOR and EMAIL if they've got the info in
an LCO file, but this is not desirable.
- Supply an optional filter to remove this info ex-post, but how
would it know when to run?
Empty AUTHOR and EMAIL lines are not user-friendly. However, another
option is to set `user-mail-address' and `user-full-name' to nil, but
then this would also affect other areas of Emacs beside the LaTeX
expoerter (which I currently no use so I can't speak to side-effects).
3. Define some function to intelligently guess values based on
content.
1. Perhaps a TYPE variable. So if TYPE is business or causal
and I select business a list with business-defaults would be
applied. OTOH this might be too complicated to just writing a
LCO files. . .
Basically duplicates LCO files but will never achieve the same
functionality.
4. Revert the path.
Or 5, keep the change from SENDER to AUTHOR but revert the default
values to `org-koma-letter-*' variables. (Right now the AUTHOR and EMAIL
lines could be removed because they duplicate the derived latex
backend.)
What should be the standard? I'm compelled to go with work as the
LaTeX-backend, but it may not be optimal here if there's a need for
chaining email and name regularly.
I prefer 5. :-)
Rasmus, couldn't you just set the old `org-koma-letter-sender'
option if you don't use LCO files?
Sure, I just thought it was inconsistent that the framework didn't use
the same keywords as other backends. But consistent might lack for
good reasons.
The default LaTeX exporter does not have LCO files. Sure you can simply
\input a latex file but there is no dedicated support for this in Org
mode, is there?
The LaTeX exporter also assumes that every LaTeX file needs a title, a
date, and an author, but this is not always true as the scrlttr2 class
shows (title, or subject, is definitely optional). Also, LaTeX blocks
which are evaluated separately don't need these values either. So I
understand striving for consistency, but I think that the use case here
is different enough to break it.
For me the previous behavior was annoying since I usually don't set
AUTHOR and this didn't work nicely.
Also, I agree that SENDER should have been called AUTHOR. It was a
workaround because the LaTeX backend would ignore nil values for
AUTHOR in derived backends (but not for EMAIL, so I kept this). This
should now have been fixed.
OK. So it's OK to switch to the AUTHOR keyword and just the default
is what we need to settle on?
I think that switching from SENDER to AUTHOR, keeping the
`org-koma-letter-{author,email}' variables in the KOMA backend, but
setting them per default to `user-full-name' and `user-mail-address',
would solve both your problems and let me keep LCO files. I would then
simply set these `org-koma-letter-*' variables to `nil' and document
this setup in the docstring. I'll see tomorrow if this is feasable.
Cheers,
Viktor
–Rasmus
--
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .
Re: [O] [patch] ox-koma-letter.el: credit [3/4]
Hi, Rasmus wrote: - It doesn't work because `org-koma-letter-special-content' is set to nil at the beginning of `org-koma-letter-template'. Why is that? If I comment it out everything works. Hmm, it should be populated by the headline function each time. . . That is at least the idea. I.e. - When exporting `org-koma-letter-special-content' gets populated and is available until next export. - When exports run again stuff might have changed so I want to repopulate the variable. Why not clear `org-koma-letter-special-content' at the start of `org-koma-letter-headline'? - I would remove the formatting from org-koma-letter-ps-prefix and put it in the docstring, simply because the separators for \encl and \cc are also not formatted in the KOMA-Script defaults. So you'd set org-koma-letter-ps-prefix to nil or ? The thing is, in scrlttr2 does not add a ps-prefix by itself, which seems inconsistent. So with your suggesting we'd get a more vanilla feel, which I guess would normally be nice, but here somehow feel inconsistent to me. I'm happy to oblige on this issue. Either nil or or even PS. I guess there is no default because people write things like PPS and PPPS and so on. Anyway, in my view having \ps specially formatted is inconsistent because \encl and \cc are not per default. One thing I'd like to discuss is whether to adopt headings for TO and FROM also. The Groff exporter already does so for it's letters. The main benefit is that it allows for org-syntax. IMO it's a lot nicer to look at as well. Check the org-groff site in the footnote for an example. I am not sure about this. I often write a letter below a task in my Org files so I rely on exporting the subtree only. So I would have to put the TO address below the letter text which looks weird, but is doable. On the other hand, being able to use Org syntax and not have to escape linebreaks with `\\' is a big plus. Maybe both options could be supported. I.e., use a FROM headline if available, but fall back on option lines if not? Or is this too confusing for users? The reason why I didn't add it as this point is that I'd want to keep it 'backward compatible' and I had to think about it. I was toying with introducing a =:with-legacy= variable that would govern which of =* TO :TO:= and =#+TO_ADDRESS= would be printed if both are present. I would definitely like to keep the old functionality. I like how your patch uses headlines to add additional information to the letter. But in the letters I wrote I would only need a FROM headline and having this single headline below the letter text seems strange. However, I realize that my preferences are very much tied to my workflow and being able to specify an address below FROM or TO headlines is very useful because it is so powerful (and probably easier to new users). If a letter uses both a headline and an option line to set an address I would think the headline should take precedence, because it is more powerful. A `:with-legacy' variable doesn't really solve anything because what does the exporter do if the variable is missing but there are two addresses set? Maybe the exporter could simply emit a warning in that case. Cheers, Viktor What do you think? Thanks for your comments. –Rasmus -- The Kids call him Billy the Saint
Re: [O] Inhibit default EMAIL in derived exporter
Hi Nicolas, Nicolas Goaziou wrote: commit 16f12e0 changed how the EMAIL option is configured in a derived exporter that also uses this keyword. I fixed it in maint. Thank you for reporting it. Thank you. Everything works as expected now. Cheers, Viktor Regards, -- Nicolas Goaziou
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Suvayu, Suvayu Ali wrote: The convention is to put all documentation about the new exporters under Worg.git/exporters. Take a look here: http://orgmode.org/worg/exporters/ Thanks. I've also added an entry to the index file. Cheers, Viktor Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Tom, Thomas S. Dye wrote: One small nit to pick, according to my dictionary meta data - metadata. Thanks, I've changed this. Cheers, Viktor All the best, Tom
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Rasmus, Rasmus wrote: Optionally download an up-to-date KOMA letter exporter Is this something we want to encourage people to do? We probably shouldn't. The problem is that the tutorial depends on a version that has not yet been released. Once Org-mode 8.1 arrives the best thing to do is to only refer to released functionality. Until then, I've changed the text somewhat and put a bold *Note* in front of it. I think that 1. Add the path containing ox-koma-letter.el to Emacs' load path is so common that it need not be included. If anything it should link to another wiki page explaining how to add stuff to the load path as to not add a step that (what I'd guess) a high percentage of the readers would know. I'd rather have the minimal guide to be complete so newbies do not have to go hunting for information. download the KOMA letter example and you can also download the example PDF letter. Links aren't working here. Somehow the source of the Org file isn't served by the webserver and neither is the PDF I've checked in. Not really sure what the problem is, maybe it has something to do with the change in the exporter. Letter meta data can be configured in one of three ways, listed below from the most specific to the most general: 4. through org-latex-classes (e.g. defining my-business-letter and my-love-letter). But perhaps this is considered bad practice? I haven't thought about this at all. It's somewhat orthogonal to the other configuration options. I've trimmed the latex class definition down because configuration options which are set there are fairly fixed. But it's a valid approach. I've added some text to this effect. Custom LCO files must be placed in a directory where LaTeX will find them. On Linux, this defaults to ~/texmf/tex/latex. On OS X, use ~/Library/texmf/tex/latex instead. These paths can be configured using the following command: Mayhaps one could add: In TeXLive you can test whether foo.lco is recognized by TeXLive by typing =kpsewhich foo.lco=. After adding a file to the TeXLive path you may have to run =mktexlsr=. Thanks, I've added that. Cheers, Viktor –Rasmus -- This is the kind of tedious nonsense up with which I will not put
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan, I just wanted to let you know that the tutorial is now online. I haven't linked to it from the org-tutorials page yet, in case you want to take a look. You can find it at http://orgmode.org/worg/org-tutorials/koma-letter-export.html Cheers, Viktor Alan Schmitt wrote: Viktor Rosenfeld writes: Hi Alan, I've pushed a draft tutorial to Worg, but it's not published yet. Do you know if there is a delay or if I have to do anything else? I saw the publishing process output after my push which ended with the following: remote: Publishing file /home/emacs/git/worg/sitemap.org using `org-publish-org-to-html' remote: Symbol's function definition is void: org-publish-org-to-html remote: worg publish process 7241 exited at 05/05/13@07:53:51 To w...@orgmode.org:worg.git a3eed5c..9531016 master - master I assume this is an error? I guess, I've never published on worg before. In any case, you can find the tutorial at ./org-tutorials/koma-letter-export.org Thanks, I'll have a look. Alan
[O] [PATCH] Honor properties in derived backends with default nil
Hi,
the attached patch fixes the problem. I wasn't sure if the logic simply
reverts the changes in commit 16f12e0 but it passes the test suite.
Cheers,
Viktor
Viktor Rosenfeld wrote:
Hi,
commit 16f12e0 changed how the EMAIL option is configured in a derived
exporter that also uses this keyword.
In `contrib/ox-koma-letter.el', the koma-letter exporter configures the
default
of the EMAIL option to the variable `org-koma-letter-email'. However, since
commit 16f12e0, if the option is missing, the default is set to
`user-mail-address' which is the default for the standard LaTeX exporter.
The current code causes the following bug in koma-letter exporter: If EMAIL is
missing, and `org-koma-letter-email' is `nil', then the exporter should not
set
a email address in the exported LaTeX file. The rationale is that the email
address is configured in an external LCO file (and can be overwritten for an
individual letter, if desired). However, the new behavior causes the email to
be set explicitly, overwriting the value from the LCO file.
Consider the following example:
#+BEGIN_SRC org
#+LATEX_CLASS: my-letter
#+LCO: DefaultAddress
#+END_SRC
The expected LaTeX-code is:
#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% --- email is set here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC
However, since commit 16f12e0, the generated code is:
#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% --- email is set here
\setkomavar{fromemail}{he...@client204-235.wlan.hu-berlin.de} % --- email
is overwritten here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC
Is this a bug in the LaTeX exporter or is this the intended behavior? Should I
maybe use another keyword instead of EMAIL? I think I used SENDER instead of
AUTHOR because of a similar conflict.
Cheers,
Viktor
From 29a3d1ece607c6ddfdb18c5096f04fd08556df50 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld listuse...@gmail.com
Date: Tue, 14 May 2013 18:58:11 +0200
Subject: [PATCH] ox.el: Honor properties in derived backends with default
`nil'.
* ox.el (org-export--get-global-options): Only process
properties once even if their value is `nil'.
TINYCHANGE
---
lisp/ox.el | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lisp/ox.el b/lisp/ox.el
index 3a4a130..64bc799 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -1726,11 +1726,15 @@ process.
;; Priority is given to back-end specific options.
(append (and backend (org-export-backend-options backend))
org-export-options-alist))
- plist)
+ plist
+ seen)
(mapc
(lambda (cell)
(let ((prop (car cell)))
-(unless (plist-member plist prop)
+(unless (or
+ (plist-member plist prop)
+ (member prop seen))
+ (add-to-list 'seen prop)
(let ((value (eval (nth 3 cell
;; Only set property if default value is non-nil.
(when value
--
1.8.2.2
[O] Inhibit default EMAIL in derived exporter
Hi,
commit 16f12e0 changed how the EMAIL option is configured in a derived
exporter that also uses this keyword.
In `contrib/ox-koma-letter.el', the koma-letter exporter configures the default
of the EMAIL option to the variable `org-koma-letter-email'. However, since
commit 16f12e0, if the option is missing, the default is set to
`user-mail-address' which is the default for the standard LaTeX exporter.
The current code causes the following bug in koma-letter exporter: If EMAIL is
missing, and `org-koma-letter-email' is `nil', then the exporter should not set
a email address in the exported LaTeX file. The rationale is that the email
address is configured in an external LCO file (and can be overwritten for an
individual letter, if desired). However, the new behavior causes the email to
be set explicitly, overwriting the value from the LCO file.
Consider the following example:
#+BEGIN_SRC org
#+LATEX_CLASS: my-letter
#+LCO: DefaultAddress
#+END_SRC
The expected LaTeX-code is:
#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% --- email is set here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC
However, since commit 16f12e0, the generated code is:
#+BEGIN_SRC latex
\documentclass{scrlttr2}
\LoadLetterOption{DefaultAddress}% --- email is set here
\setkomavar{fromemail}{he...@client204-235.wlan.hu-berlin.de} % --- email is
overwritten here
% ...
\begin{document}
% ...
\end{document}
#+END_SRC
Is this a bug in the LaTeX exporter or is this the intended behavior? Should I
maybe use another keyword instead of EMAIL? I think I used SENDER instead of
AUTHOR because of a similar conflict.
Cheers,
Viktor
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan, I've removed the defaults from OPENING and CLOSING. See the attached patch. Cheers, Viktor Alan Schmitt wrote: Viktor Rosenfeld writes: Rasmus also suggested setting the default opening and closing to nil because we should not assume that everybody speaks English. Maybe, every variable should default to nil. Yes, I think it's a good idea. I often have lines that set the opening and closing to '~' to avoid having them. Alan From 1455bc78d87649ff2b41760f382c20fae4ecd585 Mon Sep 17 00:00:00 2001 From: Viktor Rosenfeld listuse...@gmail.com Date: Sun, 5 May 2013 15:11:15 +0200 Subject: [PATCH 1/2] ox-koma-letter.el: No default opening and closing line. * ox-koma-letter.el (org-koma-letter-opening): No default / set to nil. (org-koma-letter-closing): No default / set to nil. We should not assume a formal English opening and closing line. A letter requires many personal options, such as the address, so it is no more work to also these options. TINYCHANGE --- contrib/lisp/ox-koma-letter.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 31ccd89..37ff903 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -105,12 +105,12 @@ :group 'org-export-koma-letter :type 'string) -(defcustom org-koma-letter-opening Dear Madam or Sir, +(defcustom org-koma-letter-opening nil Letter's opening, as a string. :group 'org-export-koma-letter :type 'string) -(defcustom org-koma-letter-closing Sincerely yours, +(defcustom org-koma-letter-closing nil Koma-Letter's closing, as a string. :group 'org-export-koma-letter :type 'string) -- 1.8.2.2
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Rasmus and Alan,
I've changed the code so the value for foldmarks is passed through to
KOMA-Script. It's a bit ugly insofar as one has to specify
foldmarks:true to use the default values instead of other options, such
as backaddress:t. However, subject also uses a string already.
See the attached patch.
Cheers,
Viktor
Rasmus wrote:
Viktor Rosenfeld listuse...@gmail.com writes:
Yeah, I guess it's true. Still, since foldmarks depends on which
envelopes you have at hand it might make sense to have it accept a
string. In lisp-terms a string is still t. On the other hand the
current approach is consistent with your approach above so that's a
merit.
The more I think about it the more I agree that you should be able to
set any value of foldmarks. The only problem I see is that for other
boolean options one can use `t' whereas for foldmarks one would need to
use `true' (because `t' is a valid configuration value for foldmarks).
But as long as that's documented I see no problem. I will post a patch,
once Alan applies my previous patches.
I don't know the details of the exporter well enough on this detail,
but perhaps it can be utilized that t ≠ t; if that's true in the
exporter as well. In normal lisp (characterp t) = t and
(characterp t) nil. But I'm not sure if t would be transformed before
being able to check. . .
Thanks,
Rasmus
--
May the Force be with you
From b506dd781404a999056a0348fb7f3eb8c8ef4524 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld listuse...@gmail.com
Date: Sun, 5 May 2013 15:22:51 +0200
Subject: [PATCH 2/2] ox-koma-letter.el: Give the user complete control over
foldmarks appearance.
* ox-koma-letter.el (org-koma-letter-use-foldmarks) Update
documentation
(org-koma-letter-template): Pass foldmarks setting to
KOMA-Script
TINYCHANGE
---
contrib/lisp/ox-koma-letter.el | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 37ff903..96c0569 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -130,10 +130,15 @@
:group 'org-export-koma-letter
:type 'boolean)
-(defcustom org-koma-letter-use-foldmarks t
- Print foldmarks.
+(defcustom org-koma-letter-use-foldmarks true
+ Configure appearence of fold marks.
+
+Accepts any valid value for the KOMA-Script `foldmarks' option.
+
+Use `foldmarks:true' to activate default fold marks or
+`foldmarks:nil' to deactivate fold marks.
:group 'org-export-koma-letter
- :type 'boolean)
+ :type 'string)
(defcustom org-koma-letter-use-phone t
Print sender's phone number.
@@ -286,7 +291,7 @@ holding export options.
(with-email (plist-get info :with-email)))
(concat
(format \\KOMAoption{backaddress}{%s}\n (if with-backaddress true
false))
- (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks true
false))
+ (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks
with-foldmarks false))
(format \\KOMAoption{fromphone}{%s}\n (if with-phone true false))
(format \\KOMAoption{fromemail}{%s}\n (if with-email true false
;; Document start
--
1.8.2.2
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Rasmus, Rasmus wrote: Viktor, In a similar spirit to subject is firsthead. First head is displayed by default in scrlttr2 as far as I recall, which is annoying. Is firsthead something that you change on a letter-by-letter basis? Or do you configure it once for your letters and never change it? In the latter case the configuration can be moved of to an LCO file. In the former case an option would be nice. I had to actually change the options I introduced so far for different letters (e.g., I don't want foldmarks if I send the letter by email). How I use scrlttr2: I rarely use firsthead as I find ugly. I use firstfoot all of the time and I change it regularly. E.g. for some letters I include bank addresse. Still, I see your point. So firsthead would be a boolean export option whereas firstfood would be a variable to set its content? I can see the use. Both take whatever LaTeX you'll throw at them (within reasons) so neither is boolean. I use a table with varying information for my firstfoot and nothing for my first head, but if you had a business letter you'd maybe have a logo up there or what not. But again, the question is whether it should be a LCO file or Org. One thing I'd like to do when time permits is to make a firstfood argument that takes a table name as an input, simply because tables are much nicer to work with in Org. But again it might be an overkill. . . I've thought about it and do not think it is a good idea to introduce specific options for firstfoot and so on. Since firstfoot can take arbitrary TeX-Code, setting it in the Org file can quickly become cumbersome. And a footer containing banking information is fairly consistent, so it can be set in an optional LCO file. I've used this as an example in the tutorial on Worg. (I pushed the tutorial today, but it's not published yet.) Cheers, Viktor –Rasmus -- . . . It begins of course with The Internet. A Net of Peers.
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan, I've pushed a draft tutorial to Worg, but it's not published yet. Do you know if there is a delay or if I have to do anything else? I saw the publishing process output after my push which ended with the following: remote: Publishing file /home/emacs/git/worg/sitemap.org using `org-publish-org-to-html' remote: Symbol's function definition is void: org-publish-org-to-html remote: worg publish process 7241 exited at 05/05/13@07:53:51 To w...@orgmode.org:worg.git a3eed5c..9531016 master - master I assume this is an error? In any case, you can find the tutorial at ./org-tutorials/koma-letter-export.org Cheers, Viktor Alan Schmitt wrote: Hi, Viktor Rosenfeld writes: Hi, I've hacked the ox-koma-letter exporter to make it more configurable. See the Changelog of the attached patch, hopefully I've followed the Changelog guidelines propertly. This looks very nice, thanks a lot. I'm not sure about the procedure to apply this patch, however. Should I do it myself? Also, I could not find an ox-koma-letter tutorial on Worg. I would be willing to create such a tutorial, maybe next weekend. Can anybody edit the contents on Worg or do I need special priviledges? You need to ask for write access. I started writing a tutorial, but I was caught up in too many things and could not finish it. If you want I can send you privately what I have written (or I can push it to worg and we can edit it together). Best, Alan
Re: [O] Is it possible to create links to M-x occur results?
Hi, Rick Frankel wrote: On Fri, May 03, 2013 at 09:14:43AM +0200, Carsten Dominik wrote: On 2.5.2013, at 19:25, Leo Alekseyev dnqu...@gmail.com wrote: Nice! Short and sweet, and works great. It should go on orgmode.org somewhere in the cool hacks section. Make a patch if you don't have write access to worg... I have added it to org-hacks.org between Store link to a message when sending in Gnus and Send html messages and attachments with Wanderlust, but when i push to master, i get the following in the log output from the git-hook and it' doesn't show up in the website: remote: Publishing file /home/emacs/git/worg/sitemap.org using `org-publish-org-to-html' remote: Symbol's function definition is void: org-publish-org-to-html I just pushed a change to Worg and got the same error message. Cheers, Viktor
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan,
Alan Schmitt wrote:
Hi Victor,
Viktor Rosenfeld writes:
Hi Rasmus and Alan,
I've changed the code so the value for foldmarks is passed through to
KOMA-Script. It's a bit ugly insofar as one has to specify
foldmarks:true to use the default values instead of other options, such
as backaddress:t. However, subject also uses a string already.
I have a question about this: is there some special magic that makes the
string nil to be parsed as `nil' and not as the string?
I assume there must be. If I specify `foldmarks:nil' the if-statement in
line 294 evaluates it as false:
#+BEGIN_SRC emacs-lisp
(format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks with-foldmarks
false))
#+END_SRC
About the subject, I had a quick look at the code and I find it
surprising: the default is untitled, and I don't know how one can set
it to nil (unless there is some magic in plist-get that transforms the
nil string into nil).
Same as above. `subject:nil' causes the code to skip the when-statement in line
301.
#+BEGIN_SRC emacs-lisp
(let ((with-subject (plist-get info :with-subject)))
(when with-subject
(concat
(format \\KOMAoption{subject}{%s}\n with-subject)
(format \\setkomavar{subject}{%s}\n\n
(org-export-data (plist-get info :title) info)
#+END_SRC
Note, that untitled prints the subject but without a prefix. Setting it to nil
hides the subject altogether.
Please don't hesitate to educate me, I'm very much an emacs-lisp newbie.
Me too.
Cheers,
Viktor
Best,
Alan
Re: [O] [BUG] Hotkeys defined in org-tag-alist repeated in agenda filter dispatcher
Hi Bastien, with this patch, everything works as expected. Thanks! Cheers, Viktor Bastien wrote: Hi Viktor, thanks for the patient and detailed debugging. I don't have time to test the attached patch myself, but given your description it should be okay. Can you test it and report? Otherwise I will test this myself later on. Thanks!
[O] [PATCH] org.el: Filter agenda by persistent tags
Hi, the attached patch makes `org-agenda-filter-by-tag-refine' pickup the hotkeys defined for tags in `org-tag-persistent-alist'. Cheers, Viktor From 25d8eb08ecab282fc85c95307cddada8b5032e21 Mon Sep 17 00:00:00 2001 From: Viktor Rosenfeld listuse...@gmail.com Date: Wed, 24 Apr 2013 15:54:14 +0200 Subject: [PATCH] org.el: Filter agenda by persistent tags * org.el (org-agenda-prepare-buffers): Add tags defined in org-tag-persistent-alist to org-tag-alist-for-agenda. This makes tag hotkeys defined in `org-tag-persistent-alist' appear when the user invokes `org-agenda-filter-by-tag-refine'. --- lisp/org.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 1c9e9df..8d43840 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -17985,7 +17985,10 @@ When a buffer is unmodified, it is just killed. When modified, it is saved (setq org-drawers-for-agenda (append org-drawers-for-agenda org-drawers)) (setq org-tag-alist-for-agenda - (org-uniquify (append org-tag-alist-for-agenda org-tag-alist))) + (org-uniquify + (append org-tag-alist-for-agenda + org-tag-alist + org-tag-persistent-alist))) (if org-group-tags (setq org-tag-groups-alist-for-agenda (org-uniquify-alist -- 1.8.2
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan, Alan Schmitt wrote: I'm still thinking that the default signature should be nil (so that the option can be picked up from the LCO), but it's a minor nitpick. Rasmus also suggested setting the default opening and closing to nil because we should not assume that everybody speaks English. Maybe, every variable should default to nil. Thanks again for the patch, I'll apply it. Thanks! Cheers, Viktor Alan
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan,
Alan Schmitt wrote:
I've applied the patch. I propose a further tiny improvement:
,
| --- a/contrib/lisp/ox-koma-letter.el
| +++ b/contrib/lisp/ox-koma-letter.el
| @@ -273,7 +273,7 @@ holding export options.
|(when email (format \\setkomavar{fromemail}{%s}\n email))
|(when signature (format \\setkomavar{signature}{%s}\n signature
| ;; Date.
| - (format \\date{%s}\n (org-export-data (org-export-get-date info)
info))
| + (format \\setkomavar{date}{%s}\n (org-export-data
(org-export-get-date info) info))
| ;; Place
| (let ((with-place (plist-get info :with-place))
| (place (plist-get info :place)))
`
It seems that the date is not picked up by the letter unless it's in a
koma var. I can commit this if you think it's correct.
I can't reproduce your error. The date KOMA variable is automatically
set by the \date LaTeX command which can be verified by the snipplet
below. Out of curiosity, what TeX version are you using? I use TeX Live
2012 which includes scrlttr2 2012/07/29 v3.11b.
In any case, the KOMA-Script guide also uses the KOMA variable in its
examples, so I think your patch is fine.
Cheers,
Viktor
#+BEGIN_SRC latex
\documentclass{scrlttr2}
\usepackage[english,ngerman]{babel}
\LoadLetterOption{DIN}
\date{21. April 2013}
\begin{document}
\begin{letter}{Address}
\opening{Opening}
The date: \usekomavar{date}
\closing{Closing}
\end{letter}
\end{document}
#+END_SRC
Thanks,
Alan
Re: [O] Adding new heading results in not in an item
Hi Johan, this is fixed in master. The relevant commit is here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=0fff0ba6da30e4ced73f84c8305d80c955bae132 Cheers, Viktor Johan Ekh wrote: Hi all, I've installed version 8 of org-mode and now I get the message not in an item when I try to add new headings with M-RET. What is wrong? BR / Johan
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan, Alan Schmitt wrote: Also, I could not find an ox-koma-letter tutorial on Worg. I would be willing to create such a tutorial, maybe next weekend. Can anybody edit the contents on Worg or do I need special priviledges? You need to ask for write access. Will do. I started writing a tutorial, but I was caught up in too many things and could not finish it. If you want I can send you privately what I have written (or I can push it to worg and we can edit it together). I'm fine with either way. But if you push to worg, please add a line at the top that the koma exporter is a work in progress. Cheers, Viktor Best, Alan
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan,
Alan Schmitt wrote:
A couple notes about the patch:
- Could you create it using git format-patch? This way we'll have
more metadata in the commit.
I actually did that first and liked it more because then the patch was
split into more logical blocks (nine patches in total). However, I did
not add correct changelog entries to the commits. Should I resend the
individual patches nevertheless? I could add/change the commit message
manually in the email, I suppose.
- I think there is an issue with the handling of signatures. I tried
with an old letter that uses a LCO with a graphical signature in it, but
it gets overridden upon export. Here is the generated TeX.
#+BEGIN_SRC latex
\LoadLetterOption{InriaRennesFR}
\setkomavar{signature}{\usekomavar{fromname}}
#+END_SRC
Have you tried clearing the signature?
#+BEGIN_SRC emacs-lisp
(setq org-koma-letter-signature nil)
#+END_SRC
Cheers,
Viktor
It seems to come from this part of the patch:
#+BEGIN_SRC emacs-lisp
(signature (plist-get info :signature)))
(concat
;; Letter Class Option File
(when lco
(let ((lco-files (split-string lco ))
(lco-def ))
(dolist (lco-file lco-files lco-def)
(setq lco-def (format %s\\LoadLetterOption{%s}\n lco-def
lco-file)))
lco-def))
;; Define From data.
(when sender (format \\setkomavar{fromname}{%s}\n sender))
(when from-address (format \\setkomavar{fromaddress}{%s}\n
from-address))
(when phone-number (format \\setkomavar{fromphone}{%s}\n
phone-number))
(when email (format \\setkomavar{fromemail}{%s}\n email))
(when signature (format \\setkomavar{signature}{%s}\n signature
#+END_SRC
If signature is set for some reason (and it seems to be by default),
then it will override what is in the LCO. I have not found a way to
set the options such that the signature from the LCO gets picked up.
Alan
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Rasmus,
Rasmus wrote:
* Setting of KOMA options
The presence of the sender's phone and email, the letter's place and
subject, as well as foldmarks and the backaddress are
configurable. Consider:
#+OPTIONS: subject:titled place:nil phone:t email:t foldmarks:nil
backaddress:nil
In a similar spirit to subject is firsthead. First head is displayed
by default in scrlttr2 as far as I recall, which is annoying.
Is firsthead something that you change on a letter-by-letter basis? Or
do you configure it once for your letters and never change it? In the
latter case the configuration can be moved of to an LCO file. In the
former case an option would be nice. I had to actually change the
options I introduced so far for different letters (e.g., I don't want
foldmarks if I send the letter by email).
If we make foldmark an option should it not be a string accepting
values from Table 4.3.: Combinable values for the configuration of
folding marks with option foldmarks in the KOMA-Script manual?
Same as above. If I read the scrguide correctly, the foldmark variable
can be set multiple times, e.g.,
#+BEGIN_SRC latex
\KOMAoption{foldmarks}{blmtP}
\KOMAoption{foldmarks}{true}
#+END_SRC
The first line sets the behavior (and could be moved to an LCO file),
the second line can be used to switch foldmarks on or off (and could be
set by the exporter). Haven't tried this though.
[...]
+(defcustom org-koma-letter-opening Dear Madam or Sir,
Letter's opening, as a string.
:group 'org-export-koma-letter
:type 'string)
While I also mainly write English letters I don't think we need to
assume everyone does. I'd also opt for a default nil here.
Fair enough.
[...]
+(defcustom org-koma-letter-use-subject untitled
+ Use the title as the letter's subject.
+ :group 'org-export-koma-letter
+ :type 'string)
Perhaps the default should depend on whether a title is present?
The way I understand the org exporter, a title is always present. If not
explicitly set using #+TITLE it defaults to the file name or the org
heading.
[...]
+(defcustom org-koma-letter-use-place t
+ Print the letter's place next to the date.
+ :group 'org-export-koma-letter
+ :type 'boolean)
+
Sorry for not testing this myself, but what is the behavior if
e.g. org-koma-letter-use-place is t but I didn't specify a place?
Will it print a nil or nothing?
It will print nil. Maybe this variable should also be configured to nil
then.
'(?k Export with KOMA Scrlttr2
- ((?K As LaTeX buffer org-koma-letter-export-as-latex)
- (?k As LaTeX file org-koma-letter-export-to-latex)
+ ((?L As LaTeX buffer org-koma-letter-export-as-latex)
+ (?l As LaTeX file org-koma-letter-export-to-latex)
(?p As PDF file org-koma-letter-export-to-pdf)
- (?O As PDF file and open
+ (?o As PDF file and open
(lambda (a s v b)
Another approach (which I also somehow like) is to put it under the
LaTeX menu. E.g. like beamer or like org-ravel ¹
I didn't know this was possible. I don't care either way, but I suppose
an advantage would be that some commands could be then consolidated to
save space.
+ (let ((with-place (plist-get info :with-place))
+(place (plist-get info :place)))
+ (when (or place (not with-place))
+ (format \\setkomavar{place}{%s}\n (if with-place place
Wouldn't this work better: E.g. it wouldn't allow a place when place
is nil or when with-place is nil?
(when (and place (not with-place))
(format \\setkomavar{place}{%s}\n place ))
This will print the place if it is configured somewhere, even if
=place:nil= is set in #+OPTIONS. Note that I use the empty string to
surpress the space in my code. For example, I have in my LCO file
#+BEGIN_SRC latex
\setkomavar{place}{Berlin}
#+END_SRC
That is, the space is usually printed in every letter.
If I use #+OPTIONS: place:nil in a particular letter, the following code
is emitted:
#+BEGIN_SRC latex
\LoadLetterOption{myletter.lco} % place is set here
\setkomavar{place}{}% this surpresses the printing of place
#+END_SRC
+ ;; KOMA options
+ (let ((with-backaddress (plist-get info :with-backaddress))
+(with-foldmarks (plist-get info :with-foldmarks))
+(with-phone (plist-get info :with-phone))
+(with-email (plist-get info :with-email)))
+ (concat
+ (format \\KOMAoption{backaddress}{%s}\n (if with-backaddress
true false))
+ (format \\KOMAoption{foldmarks}{%s}\n (if with-foldmarks true
false))
+ (format \\KOMAoption{fromphone}{%s}\n (if with-phone true
false))
+ (format \\KOMAoption{fromemail}{%s}\n (if with-email true
false
Relating to configurable foldmarks:
(if with-foldmarks
(format \\KOMAoption{foldmarks}{%s}\n (if foldmarks
foldmarks true)))
(untested).
I would rather adapt the with-foldmarks option to accept a string rather than
adding another
Re: [O] [BUG] Hotkeys defined in org-tag-alist repeated in agenda filter dispatcher
Hi Bastian, Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@gmail.com writes: If I hit the =/= key in the agenda to filter the agenda by tag, the hotkeys defined in the list above are repeated multiple times. Can you test this patch against latest maint or master branch? The problem still remains with the patch. However, I was able to narrow the problem to a specific line and can provide a minimal example: Consider the following configuration (which is loaded in init.el via org-babel-load-file): #+BEGIN_SRC emacs-lisp (global-set-key (kbd f12) 'org-agenda) (setq org-agenda-files '( ~/org/dokumente.org ~/org/openloops.org ~/org/routine.org ~/org/arbeit.org )) (setq org-tag-alist '((:startgroup . nil) (@home . ?h) (@comp . ?c) (@otg . ?o) (@fon . ?f) (@agenda . ?a) (@read . ?r) (@write . ?w) (:endgroup . nil) (:startgroup . nil) (IMPORTANT . ?*) (SOMEDAY . ??) (:endgroup . nil))) #+END_SRC The four agenda files are as follows: The first file, dokumente.org caontains a single headline and a #+TAGS: definition: #+BEGIN_SRC org :tangle dokumente.org #+TAGS: foo * 1996 #+END_SRC The other three files only contain a heading and no #+TAGS: definition: #+BEGIN_SRC org :tangle openloops.org * Inbox #+END_SRC #+BEGIN_SRC org :tangle routine.org * Review #+END_SRC #+BEGIN_SRC org :tangle arbeit.org * 1996 #+END_SRC With this setup the tag hotkeys are repeated three times, one time for each file with no tags definition. If I remove the #+TAGS definition in dokumente.org, the bug disappears. If I add a #+TAGS definition to every other file, then no tag hotkeys are printed, which is another unexpected behavior. In other words, the presence of #+TAGS in a file causes the tag hotkeys to repeated once for every file which does not have a #+TAGS definition. To achieve the correct behavior, either no #+TAGS: definition must appear anywhere or there must be exactly one file without a #+TAGS definition. Note that the number of repetions also depends on where the file with the #+TAGS definition is located in the org-agenda-files list. Using the four files above, if I move the file dokumente.org with the #+TAGS definition to the end of the list then there are no repetitions. Cheers, Viktor Thanks,
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Alan,
Alan Schmitt wrote:
Or you could do a git rebase interactive to merge all the commits
together.
Wow, this is great! I didn't know that you can modify the commit history
so easily. I have attached four patches to this mail which correspond to
the four points in my earlier email. They have to be applied
consecutively.
- I think there is an issue with the handling of signatures. I tried
with an old letter that uses a LCO with a graphical signature in it, but
it gets overridden upon export. Here is the generated TeX.
#+BEGIN_SRC latex
\LoadLetterOption{InriaRennesFR}
\setkomavar{signature}{\usekomavar{fromname}}
#+END_SRC
Have you tried clearing the signature?
#+BEGIN_SRC emacs-lisp
(setq org-koma-letter-signature nil)
#+END_SRC
Yes, I changed it globally and I still get the same thing. I also
tried doing a
#+BEGIN_SRC org
#+signature:
#+END_SRC
and it inserts it in the LaTeX file as such, after my LCO declaration.
I can't reproduce this. I have attached a minimal letter as an example.
If I evaluate the emacs-lisp block and export it I can see a graphic
signature that is defined in `Signed.lco' in my `texmf' directory. What
happens on your end?
Cheers,
Viktor
Alan
From 02727b4259b2530d7e878aeaed6b2d235d271f2a Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld hesk@cartman
Date: Sun, 21 Apr 2013 13:40:09 +0200
Subject: [PATCH 1/4] ox-koma-letter: Use same hotkeys as LaTeX export
* ox-koma-letter.el (koma-letter): Use `L' to export to LaTeX
buffer, `l' to export to LaTeX file, and `o' to export to PDF
file and open.
Patch suggested by Rasmus.
---
contrib/lisp/ox-koma-letter.el | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1ffb455..d8d32e7 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -123,10 +123,10 @@
(template . org-koma-letter-template))
:menu-entry
'(?k Export with KOMA Scrlttr2
- ((?K As LaTeX buffer org-koma-letter-export-as-latex)
- (?k As LaTeX file org-koma-letter-export-to-latex)
+ ((?L As LaTeX buffer org-koma-letter-export-as-latex)
+ (?l As LaTeX file org-koma-letter-export-to-latex)
(?p As PDF file org-koma-letter-export-to-pdf)
- (?O As PDF file and open
+ (?o As PDF file and open
(lambda (a s v b)
(if a (org-koma-letter-export-to-pdf t s v b)
(org-open-file (org-koma-letter-export-to-pdf nil s v b
--
1.8.2
From 1513beb2ba4aa847eaeb3f5e9c86414e7f8d5cd3 Mon Sep 17 00:00:00 2001
From: Viktor Rosenfeld hesk@cartman
Date: Sun, 21 Apr 2013 13:41:22 +0200
Subject: [PATCH 2/4] ox-koma-letter.el: Set LCO option before other KOMA
variables
* ox-koma-letter.el (org-koma-letter-closing): More
business-like closing.
(org-koma-letter-from-address): Do not set default personal
information.
(org-koma-letter-opening): Gendered opening.
(org-koma-letter-phone-number): Do not set default personal
information.
(org-koma-letter-sender): Use `#+SENDER:' instead of
`#+AUTHOR:' because the latter is always set by the LaTeX
exporter.
(org-koma-letter-email): Duplicte `#+EMAIL:' in this exporter
because it is always set by the LaTeX exporter.
(koma-letter): Add additional `#+SENDER:' and `#+EMAIL:' to
exporter (see above).
(org-koma-letter-template): Set LCO before evaluating other
KOMA variables if they are set; add `#+SENDER:' and `#+EMAIL:'
to template (see above).
The LCO file is set loaded first and KOMA variables are only set if
their value is not `nil'.
Example:
#+LCO: Default
#+SIGNATURE: A friend
will result in the following LaTeX code:
#+BEGIN_SRC latex
\LoadLetterOption{Default}% LCO file, with default signature
\setkomavar{signature}{A friend} % Overwrite signature
#+END_SRC
Other KOMA variables defined in the LCO file, e.g., `fromaddress', will
not be overwritten.
---
contrib/lisp/ox-koma-letter.el | 55 +++---
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index d8d32e7..5397cf0 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,22 +80,22 @@
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-closing See you soon,
+(defcustom org-koma-letter-closing Sincerely yours,
Koma-Letter's closing, as a string.
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-from-address Somewhere \\ Over the rainbow.
+(defcustom org-koma-letter-from-address nil
Sender's address, as a string.
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-opening Dear Sir,
+(defcustom org-koma-letter-opening Dear Madam or Sir,
Letter's opening, as a string.
:group 'org-export-koma-letter
:type
Re: [O] [PATCH] Improve configurability of ox-koma-letter
Hi Rasmus,
Rasmus wrote:
In a similar spirit to subject is firsthead. First head is displayed
by default in scrlttr2 as far as I recall, which is annoying.
Is firsthead something that you change on a letter-by-letter basis? Or
do you configure it once for your letters and never change it? In the
latter case the configuration can be moved of to an LCO file. In the
former case an option would be nice. I had to actually change the
options I introduced so far for different letters (e.g., I don't want
foldmarks if I send the letter by email).
How I use scrlttr2: I rarely use firsthead as I find ugly. I use
firstfoot all of the time and I change it regularly. E.g. for some
letters I include bank addresse. Still, I see your point.
So firsthead would be a boolean export option whereas firstfood would be
a variable to set its content? I can see the use.
If we make foldmark an option should it not be a string accepting
values from Table 4.3.: Combinable values for the configuration of
folding marks with option foldmarks in the KOMA-Script manual?
Same as above. If I read the scrguide correctly, the foldmark variable
can be set multiple times, e.g.,
#+BEGIN_SRC latex
\KOMAoption{foldmarks}{blmtP}
\KOMAoption{foldmarks}{true}
#+END_SRC
This is true.
The first line sets the behavior (and could be moved to an LCO file),
the second line can be used to switch foldmarks on or off (and could be
set by the exporter). Haven't tried this though.
Yeah, I guess it's true. Still, since foldmarks depends on which
envelopes you have at hand it might make sense to have it accept a
string. In lisp-terms a string is still t. On the other hand the
current approach is consistent with your approach above so that's a
merit.
The more I think about it the more I agree that you should be able to
set any value of foldmarks. The only problem I see is that for other
boolean options one can use `t' whereas for foldmarks one would need to
use `true' (because `t' is a valid configuration value for foldmarks).
But as long as that's documented I see no problem. I will post a patch,
once Alan applies my previous patches.
Cheers,
Viktor
[O] [PATCH] Improve configurability of ox-koma-letter
Hi,
I've hacked the ox-koma-letter exporter to make it more configurable.
See the Changelog of the attached patch, hopefully I've followed the
Changelog guidelines propertly.
Also, I could not find an ox-koma-letter tutorial on Worg. I would be
willing to create such a tutorial, maybe next weekend. Can anybody edit
the contents on Worg or do I need special priviledges?
Cheers, Viktor
KOMA scrlttr2 export: Improve export configuration options.
* ox-koma-letter.el (org-koma-letter-sender): New option for
the letter's author.
(org-koma-letter-from-address): Do not set default personal information.
(org-koma-letter-phone-number): Do not set default personal information.
(org-koma-letter-email): New option for the sender's email.
(org-koma-letter-place): Specify the letter's place.
(org-koma-letter-opening): Gendered opening.
(org-koma-letter-closing): More business-like closing
(org-koma-letter-use-subject): Configure the appearance of the
subject line.
(org-koma-letter-use-backaddress): Configure the presence of
the backaddress.
(org-koma-letter-use-foldmarks): Configure the presence of foldmarks.
(org-koma-letter-use-phone): Configure the presence of the
sender's phone number.
(org-koma-letter-use-email): Configure the presence of the
sender's email address.
(org-koma-letter-use-place): Configure the presence of the
letter's place.
(koma-letter): Add new options to koma-letter export backend
(org-koma-letter-template): Better KOMA configuration; support for
multiple LCO files.
This patch changes the KOMA-letter exporter in four ways:
* Same hotkeys as the LaTeX exporter
Use =L= (instead of =K=) to export to a buffer, =l= (instead of =k=)
to export to a file, and =O= (instead of =o=) to open the PDF file.
This was already suggested by Rasmus
(http://thread.gmane.org/gmane.emacs.orgmode/67026).
* Setting of KOMA variables
LCO files are loaded first and KOMA variables are only set in the
LaTeX output if their value is not nil. This way most configuration
options can be set once in an LCO file and overwritten if needed.
Consider for example an LCO file =DefaultAddress.lco= in
=~/texmf/tex/latex=.
#+BEGIN_SRC latex
\ProvidesFile{DefaultAddress.lco}
\setkomavar{fromname}{Max Mustermann}
\setkomavar{fromaddress}{Musterstraße 1\\12345 Musterstadt}
#+END_SRC
The default address can then be overwritten in the actual letter. Note
the additional country in the address below.
#+LCO: DefaultAddress
#+FROM_ADDRESS: Musterstraße 1\\12345 Musterstadt\\Germany
* Setting of KOMA options
The presence of the sender's phone and email, the letter's place and
subject, as well as foldmarks and the backaddress are
configurable. Consider:
#+OPTIONS: subject:titled place:nil phone:t email:t foldmarks:nil backaddress:nil
Note, that except for =subject=, all options are boolean, e.g., they
accept the values =t= and =nil=. Subject can also be nil to surpress
printing, or otherwise any possible value for the KOMA option subject,
i.e., afteropening, beforeopening, centered, left, right, titled,
underlined, or untitled.
* Multiple LCO files
Multiple LCO files, separated by spaces, can be specified. This way
one can add optional behavior to the letter export. Consider, e.g., an
LCO file with a default address and a simple textual signature:
#+BEGIN_SRC latex
\ProvidesFile{Default.lco}
% default address
\setkomavar{fromname}{Max Mustermann}
\setkomavar{fromaddress}{Musterstraße 1\\12345 Musterstadt}
% default signature
\renewcommand*{\raggedsignature}{\raggedright}
\setkomavar{signature}{\usekomavar{fromname}}
#+END_SRC
And a second LCO file defining a signature graphic:
#+BEGIN_SRC latex
\ProvidesFile{Signed.lco}
% use signature graphic
\usepackage{graphicx}
\setkomavar{signature}{\\[-2.5\baselineskip]\includegraphics{/home/he-sk/org/data/12/441E34-D2DE-4207-9B4A-23A4DA7AF870/Unterschrift.png}\\[-0.9\baselineskip]\usekomavar{fromname}}
#+END_SRC
Then, a signed letter can be created as follows:
#+LCO: Default Signed
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 1ffb455..31ccd89 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,23 +80,38 @@
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-closing See you soon,
- Koma-Letter's closing, as a string.
+(defcustom org-koma-letter-sender nil
+ Sender's name, as a string.
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-from-address Somewhere \\ Over the rainbow.
+(defcustom org-koma-letter-from-address nil
Sender's address, as a string.
:group 'org-export-koma-letter
:type 'string)
-(defcustom org-koma-letter-opening Dear Sir,
+(defcustom org-koma-letter-phone-number nil
+ Sender's phone number, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(defcustom org-koma-letter-email nil
+ Sender's email, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(defcustom org-koma-letter-place
[O] [BUG] Hotkeys defined in org-tag-alist repeated in agenda filter dispatcher
Hi, I have the following tags defined in my initialization code: #+BEGIN_SRC emacs-lisp (setq org-tag-alist '((:startgroup . nil) (@home . ?h) (@comp . ?c) (@otg . ?o) (@fon . ?f) (@agenda . ?a) (@read . ?r) (@write . ?w) (:endgroup . nil) (:startgroup . nil) (IMPORTANT . ?*) (SOMEDAY . ??) (:endgroup . nil))) #+END_SRC If I hit the =/= key in the agenda to filter the agenda by tag, the hotkeys defined in the list above are repeated multiple times. That is, the string in the Emacs minibuffer reads: #+BEGIN_EXAMPLE Narrow by tag [hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*?hcofarw*? ], [TAB], ... #+END_EXAMPLE This only happens if =org-agenda-files= is set to a directory (or list of directories), e.g.: #+BEGIN_SRC emacs-lisp (setq org-agenda-files '( ~/org )) #+END_SRC If =org-agenda-files= is set to a list of files the hotkeys are not repeated. E.g.: #+BEGIN_SRC emacs-lisp (setq org-agenda-files '( ~/org/openloops.org ~/org/dokumente.org)) #+END_SRC With the setting above the string in the Emacs minibuffer reads, as expected: #+BEGIN_EXAMPLE Narrow by tag [hcofarw*? ], [TAB], ... #+END_EXAMPLE git bisect reveals the following commit as the culprit: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=575c9f16c3a1dc6660dd1aebdd560ec7caa1365e However, before this commit, none of the hotkeys appear in the minibuffer, which is another bug. Apparently, the last commit where everything works as expected is: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=a9880a7710415218d3940e380968a9ed56367880 I am on Ubuntu 12.04.2 with a backported Emacs 24.3.1. Cheers, Viktor
Re: [O] Better way to customize daily/weekly agenda?
Hi Piotr, Piotr Isajew wrote: - daily agenda having grid mode on, and displaying entries from all categories - weekly agenda having grid mode off and filtering out entries from one specific category With regard to the time grid you might want to check out the variable org-agenda-time-grid. I have it set thusly: #+BEGIN_SRC emacs-lisp (setq org-agenda-time-grid '((daily today required-time) (600 1200 1800 2400))) #+END_SRC The first part of the variable shows the time grid in the day agenda, but not in the weekly agenda, except for today's date. Cheers, Viktor
Re: [O] Tips for using orgmode + ledger to record events?
Hi Eric, thanks for explaining your structure. Eric S Fraga wrote: I don't use capture templates; I manually enter the information. I did use to use capture but found it too clumsy for my setup (or I was never able to suss out how to define the right capture templates). I don't reconcile using ledger. I do reconciliation manually by visual inspection. Reconciliation is not a big issue for me. My main use of ledger is simply to keep track of where my money is (or isn't, as the case may be ;-). Reconcilation (using ledger-mode) is an important part of my weekly/monthly workflow and I think you need an actual ledger file to do it. I imagine that one can manually check the balances with the help of a few reports, but I'm pretty satisfied with my current setup. It's interesting that you found capture templates clumsy. I don't use them right now, but was thinking about using them to record recurring information. Right now, I do this manually each month while reconciling my bank account. Thanks again, Viktor
Re: [O] Tips for using orgmode + ledger to record events?
Hi Eric, Eric S Fraga wrote: Using org for this is easier than having to work with ledger comments. I can also then include, in the org file, the specific ledger instantiations to get the kinds of reports I want and execute these with C-c C-c. So, for instance, I have ledger reports on the current balances, the taxable income from any particular year, etc. I just remembered that I do mix ledger and org-mode, as I also have ledger source blocks to generate weekly and monthly reports. Going over you original reply, I was wondering how you add to blocks such as expenses-car which you reference in your report statement. Also, do you use capture templates for your expenses and how do you reconcile your accounts without having a ledger file as your primary data file? Cheers, Viktor
Re: [O] Tips for using orgmode + ledger to record events?
Hi, Eric S Fraga wrote: My view would be to avoid having two files, an org one and a ledger one, and instead combine them into an org file. I'm using both org-mode and ledger but I do not mix them. I'm having a hard time imagining the benefits of such a system, especially since ledger's query functionality is so powerful. It seems to that this just adds lot's of unnecessary complexity. But I'm interested to hear what advantages you derive from the combined approach. Cheers, Viktor
Re: [O] Wish: switch active time-stamps to inactive when CANCELED
Hi Bastien, Bastien wrote: Viktor Rosenfeld listuse...@gmail.com writes: #+BEGIN_SRC emacs-lisp (setq org-todo-state-tags-triggers '((CANCELLED (ARCHIVE . t #+END_SRC I shared this as a new FAQ, thanks! The credit should go to Bernt Hansen. I found it in his org-mode setup. Cheers, Viktor
Re: [O] Wish: switch active time-stamps to inactive when CANCELED
Hi, Karl Voit wrote: ELISP is nothing you can learn in a single weekend. I've got the feeling that this is a task that requires a longer period of time. It's in SOMEDAY state in my Org along with: I've found that you can pick up enough ELISP on a weekend to start hacking small snipplets right away. Of course, you'll be very slow in the beginning, and reverting to message-debugging all the time, but over time you'll get more proficient. And you get to solve your problems, which should lead to higher productivity in the long run. Anyway, thanks for the links. Cheers, Viktor
Re: [O] Wish: switch active time-stamps to inactive when CANCELED
Hi, Karl Voit wrote: But still: there are two steps I have to make: (a) mark as canceled because I want this CANCELED string attached and (b) add the ARCHIVE tag. You can set the ARCHIVE tag when switching the TODO state automatically using org-todo-state-tags-triggers. For example (untestet): #+BEGIN_SRC emacs-lisp (setq org-todo-state-tags-triggers '((CANCELLED (ARCHIVE . t #+END_SRC Cheers, Viktor
Re: [O] A mail client that is org-mode compatible
thanks, very informative! Suvayu Ali wrote: Sorry for the late response, I was on holidays.
Re: [O] A mail client that is org-mode compatible
Hi, Suvayu Ali wrote: On Mon, Dec 31, 2012 at 08:29:12AM +0100, Gour wrote: I use notmuch for indexing only, and read and send emails from mutt. Although I do not use gnus, I do use emacs as my editor (hence message-mode) to compose emails; there I find Org is supported rather well. For linking to emails, I have been using org-notmuch quite successfully for the last year now. If you are interested, feel free to ask I can share more details. I'm interested in your mutt+notmuch setup. Happy new year! Cheers, Viktor
Re: [O] [BUG] [contrib/org-koma-letter.el] #+DATE and #+TO_ADDRESS picked up from outside the current subtree
Hi Alan, Alan Schmitt wrote: If you want subtree exporting, the information should be in a :PROPERTIES: drawer at the beginning of the thing to export. Here is what I did for a recent letter: #+BEGIN_SRC org ** Lettre d'Accueil pour ... :PROPERTIES: :EXPORT_LATEX_CLASS: my-inria-fr-letter :EXPORT_LCO: InriaRennesFR :EXPORT_OPENING: ~ :EXPORT_CLOSING: ~ :END: text text ... #+END_SRC Note that in such drawers, the name of the option has EXPORT_ before it. Of course! I know that, but I got confused while trying out the new exporter. Thanks, anyway. As an aside, what's the purpose of wrapping the letter in an org-mode source block? Or did you just do that to wrap the example in the e-mail? Cheers, Viktor
[O] [BUG] [contrib/org-koma-letter.el] #+DATE and #+TO_ADDRESS picked up from outside the current subtree
Hi, I've configured the scrlttr2 exporter found in contrib/lisp/org-koma-letter.el to write letters directly in org-mode. I'm very happy with the results, but I've noticed the following bug: If there are multiple letters defined in an org-file, the contents of every #+DATE and #+TO_ADDRESS field will be picked up, even if the export is restricted to the current subtree. In the attached file, if you export the first letter with 3 k k from the export dispatch menu, the address will read Max Mustermann Musterstraße 1 12345 Musterstadt Moritz Mustermann Musterallee 10 54321 Musterstadt and the date will be set to December 28 from the second letter. Regards, Viktor * Letter 1 #+AUTHOR: Viktor Rosenfeld #+DATE: 1. Dezember 2012 #+LATEX_CLASS: my-letter #+TO_ADDRESS: Max Mustermann\\ #+TO_ADDRESS: Musterstraße 1\\ #+TO_ADDRESS: 12345 Musterstadt ich möchte mich auf diesem Wege bei ihrem Kollegen mit der Dienstnummer 12055 bedanken. Ich hatte am 2. September 2012 meine Brieftasche im Treptower Park verloren. Sie wurde später bei der Polizei abgegeben und der Polizist brachte sie mir nach Hause. Ich fand das überaus freundlich und hilfsbereit. * Letter 2 #+AUTHOR: Viktor Rosenfeld #+DATE: 28. Dezember 2012 #+LATEX_CLASS: my-letter #+TO_ADDRESS: Moritz Mustermann\\ #+TO_ADDRESS: Musterallee 10\\ #+TO_ADDRESS: 54321 Musterstadt ich möchte mich auf diesem Wege bei ihrem Kollegen mit der Dienstnummer 12055 bedanken. Ich hatte am 2. September 2012 meine Brieftasche im Treptower Park verloren. Sie wurde später bei der Polizei abgegeben und der Polizist brachte sie mir nach Hause. Ich fand das überaus freundlich und hilfsbereit.
[O] [PATCH] [contrib/org-koma-letter.el] Configurable subject title and place and signature bugfix
Hi,
the attached patch adds the following options to the scrlttr2 exporter:
- #+PLACE, or org-koma-letter-place: the place before the date,
e.g., Berlin, 28. Dezember 2012; the place is only typeset if this
variable is defined
- #+SUBJECT_TITLE, or org-koma-letter-subject-title: the subject keyword
on the subject line, e.g., the German Betreff
It also fixes the behavior if no signature is defined, i.e., it uses the
KOMA variable fromname as described in the documentation.
Cheers,
Viktor
diff --git a/contrib/lisp/org-koma-letter.el b/contrib/lisp/org-koma-letter.el
index 58714d2..3094171 100644
--- a/contrib/lisp/org-koma-letter.el
+++ b/contrib/lisp/org-koma-letter.el
@@ -36,7 +36,9 @@
;; `org-koma-letter-class-option-file'), OPENING (see
;; `org-koma-letter-opening'), PHONE_NUMBER (see
;; `org-koma-letter-phone-number'), SIGNATURE (see
-;; `org-koma-letter-signature') and TO_ADDRESS.
+;; `org-koma-letter-signature'), SUBJECT_TITLE (see
+;; `org-koma-letter-subject-title'), PLACE (see
+;; `org-koma-letter-place'), and TO_ADDRESS.
;;
;; You will need to add an appropriate association in
;; `org-e-latex-classes' in order to use the KOMA Scrlttr2 class. For
@@ -106,6 +108,16 @@
:group 'org-export-koma-letter
:type 'string)
+(defcustom org-koma-letter-subject-title
Subject\\usekomavar{subjectseparator}
+ String used as the title for the subject.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(defcustom org-koma-letter-place nil
+ Sender's location, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
;;; Define Back-End
@@ -116,7 +128,9 @@
(:lco LCO nil org-koma-letter-class-option-file)
(:opening OPENING nil org-koma-letter-opening)
(:phone-number PHONE_NUMBER nil org-koma-letter-phone-number)
- (:signature SIGNATURE nil nil newline)
+ (:signature SIGNATURE nil org-koma-letter-signature newline)
+ (:subject-title SUBJECT_TITLE nil org-koma-letter-subject-title)
+ (:place PLACE nil org-koma-letter-place)
(:to-address TO_ADDRESS nil nil newline))
:translate-alist ((export-block . org-koma-letter-export-block)
(export-snippet . org-koma-letter-export-snippet)
@@ -205,14 +219,18 @@ holding export options.
(format \\setkomavar{fromemail}{%s}\n
(org-export-data (plist-get info :email) info))
(format \\setkomavar{fromphone}{%s}\n (plist-get info :phone-number))
- ;; Date.
+ ;; Place
+ (let ((place (plist-get info :place)))
+ (when place
+ (format \\setkomavar{place}{%s}\n place)))
+ ;; Date
(format \\date{%s}\n (org-export-data (plist-get info :date) info))
;; Letter Class Option File
(format \\LoadLetterOption{%s}\n (plist-get info :lco))
;; Letter start.
\\begin{document}\n\n
- (format \\setkomavar{subject}{%s}\n\n
- (org-export-data (plist-get info :title) info))
+ (format \\setkomavar{subject}[%s]{%s}\n\n
+ (plist-get info :subject-title) (org-export-data (plist-get info
:title) info))
(format \\begin{letter}{%%\n%s}\n\n (or (plist-get info :to-address) no
address given))
;; Opening.
(format \\opening{%s}\n\n (plist-get info :opening))
Re: [O] Question re. Bernt's agenda setup
Alan Schmitt wrote: Viktor Rosenfeld listuse...@gmail.com writes: Hi Manish, it's Shift-P and you need to bind the function bh/narrow-to-project to the keycode. See the code blocks in the following two sections: http://doc.norang.ca/org-mode.html#SpeedCommands http://doc.norang.ca/org-mode.html#NarrowToSubtree I managed to make this work, but if I run the command in the agenda I need to refresh it afterwards (using 'g'). Are you seeing the same thing? Yes, unfortunately. I think I remember that it used to refresh the agenda automatically. This is above my pay grade, I'm afraid. Cheers, Viktor And I also want to say I have learned a lot implementing the suggestions in that document. Alan
Re: [O] Question re. Bernt's agenda setup
Hi Manish, it's Shift-P and you need to bind the function bh/narrow-to-project to the keycode. See the code blocks in the following two sections: http://doc.norang.ca/org-mode.html#SpeedCommands http://doc.norang.ca/org-mode.html#NarrowToSubtree Cheers, Viktor PS: I agree that Bernt's document is absolutely awesome! Manish wrote: Hello Bernt and others, I was picking up tips from Bernt's awesome and famous document at http://doc.norang.ca/org-mode.html. In section 7.1, just between the two screenshots, I came across following text: ,[ excerpt from section 7.1 ] | After selecting a project (with P on any task in the agenda) the block | agenda changes to show the project and any subprojects in the Projects | section. Tasks show project-related tasks that are hidden when not | narrowed to a project. ` The feature/concept seems very useful to be able to zoom into a project of interest but I could't figure out how =P= helps with this since it seems to move to previous item while in the ageda view. Can someone (or Bernt) using the setup point me to right direction please? Regards --Manish
[O] date function in table formula does not understand German date stamps
Hi, I use the function `date' in a table formula to convert org date stamps to integers for further processing. However, after switching Emacs to a German locale, this no longer works. Consider the table below: | Stamp| date | |--+| | [2012-10-31 Wed] | 734808 | | [2012-10-31 Mi] | #ERROR | #+TBLFM: $2=date($1) Org mode generally works fine with the German version of the date stamp, i.e., it is picked up in the agenda and deadline warnings work as expected. However, the `date' function in a table formula does not work. My Emacs inserts the German version of the date stamp after I've added the following file as `.MacOSX/environment.plist': ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyLANG/key stringde_DE.UTF-8/string keyLC_ALL/key stringde_DE.UTF-8/string /dict /plist This was necessary to make Cocoa Emacs correctly process filenames with umlauts. Any idea how the date function can be made locale-aware? Or is there another alternative for this calculation? Thanks, Viktor
Re: [O] An org-attach link type [7.9.1 (7.9.1-elpa @ /home/youngfrog/.emacs.d/elpa/org-20120903/)]
Hi Nicolas,
I played around with your function and it's pretty nifty, but I had to make
a few changes to get it working:
- I have to load the cl module, otherwise the case function is void.
- I had to replace find-lisp-find-files with directory-files because
the former does not exist on my Emacs installation. I use GNU Emacs
24.2.1 on OS X compiled from MacPorts.
- I don't need to map the returned files to their relative paths.
- I couldn't find a difference between the 'relative and 'full options.
org-attach-expand-link always returns the path as specified in the
ATTACH_DIR property or constructed from the ID, but never the full
(absolute) path unless it is explicitly specified. In other words, it
does the same thing as your code for the 'relative options. I've
removed both options and replaced it with a 'file option that calls
org-attach-expand-link.
- I use attach instead of att as a link prefix in my files and had
to change the names of the functions. Sorry about that, but I did not
want to fix all my links.
Code is below. I'm using Org-mode 7.9.1.
Cheers,
Viktor
#+BEGIN_SRC emacs-lisp
(defvar org-attach-complete-how 'attach
Determines how org-attach-complete-link completes links to attachments.
It can be the symbols :
- `file' :: A \file:\ link is returned including the attachment directory.
- `attach' :: An \attach:\ link is returned.)
(require 'cl)
(defun org-attach-complete-link ()
File completion for the \attach\ filetype in `org-mode'.
(let* ((attach-dir (org-attach-dir nil))
files file)
(unless attach-dir
(error No attachment dir.))
(setq files (directory-files attach-dir nil ^[^.].*[^~]$ nil)
file (org-icompleting-read Find attachment: files))
(case org-attach-complete-how
('file (org-attach-expand-link file))
('attach (concat attach: file)
#+END_SRC
Nicolas Richard wrote:
Hello there,
Some people already have suggested and produced some code (see [1,2]) in
order to have an attach (or att, as it was called) link type in
org-mode. I never found a org--complete-link function for these links
on the net, so I tried to write it for myself. In order to do that, I had
to modify org-insert-link so that the org-mode buffer is made current
(instead of *Org Links*) when calling org-link-try-special-completion.
This allows the org--complete-link family of functions to access the actual
org buffer from which org-insert-link was called. A patch in this direction
is at the end of my email. (This is the first time that I use
git-format-patch, I hope I got that right).
With that change, here is some code that adds an att link type with
completion:
(defun org-att-complete-link ()
File completion for the \att\ filetype in `org-mode'.
(let* ((attach-dir (org-attach-dir nil))
files file)
(unless attach-dir
(error No attachment dir.))
(setq files (find-lisp-find-files attach-dir ^[^.].*[^~]$)
file (org-icompleting-read Find attachment:
(mapcar
(lambda (x) (file-relative-name x
attach-dir))
files)
nil t))
(case org-att-complete-how
('full (org-attach-expand-link file))
('relative (concat file: attach-dir file))
('attach (concat att: file)
(defvar org-att-complete-how 'attach
Determines how org-att-complete-link completes links to attachments.
It can be the symbols :
- `full' :: A \file:\ link with full path is returned,
- `relative' :: a \file:\ link containg a path relative to the directory
where the org-file resides is returned, or
- `attach' :: an \att:\ link is returned.
`full' is probably best avoided.)
(org-add-link-type att 'org-att-open-link)
(defun org-att-open-link (file)
(org-open-file (org-attach-expand file)))
I hope that this is useful to anybody, and not too sloppy (I'm not
fluent in elisp)
[1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00010.html
[2] http://lists.gnu.org/archive/html/emacs-orgmode/2011-02/msg00952.html
The patch for the above mentionned change in org.el follows :
-- 8 --
Subject: [PATCH] Allow org--complete-read family of functions to access
current-buffer
This allows for link-completion features based on information around the
point.
---
lisp/org.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 3dfd073..fc5d709 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9411,6 +9411,7 @@ If the DEFAULT-DESCRIPTION parameter is non-nil, this
value will
be used as the default description.
(interactive P)
(let* ((wcf (current-window-configuration))
+ (buffer (current-buffer))
(region (if (org-region-active-p)
(buffer-substring (region-beginning) (region-end
(remove (and
Re: [O] An org-attach link type [7.9.1 (7.9.1-elpa @ /home/youngfrog/.emacs.d/elpa/org-20120903/)]
Hi Nicolas, Nicolas Richard wrote: Hello Viktor, Thanks for your input. - I have to load the cl module, otherwise the case function is void. Sorry about that. I didn't notice it was from cl. - I had to replace find-lisp-find-files with directory-files because the former does not exist on my Emacs installation. I use GNU Emacs 24.2.1 on OS X compiled from MacPorts. Oops again. (require 'find-lisp) should fix that. The big difference with directory-files is that find-lisp-find-files looks also in subdirectories (I often attach subdirectories and like to link files from therein). And it returns full paths, too, which explains some parts of the rest of the code. If find-lisp-find-files returns full paths then the discrimination in org-attach-complete-how makes sense. Pretty cool. Cheers, Viktor
[O] make org-agenda-tree-to-indirect-buffer use new frame only
Hi, I've recently switched from Aquamacs to Emacs.app and noticed a different behavior of C-c C-x b in the agenda. I have the following in my Emacs settings: (setq org-indirect-buffer-display 'new-frame) If I open in indirect buffer from the agenda, it creates a new frame, but also splits the agenda frame and opens the task in another window. How can I stop it from doing the latter? Thanks, Viktor
Re: [O] Output of R babel blocks with quotes is mangled/truncated
Hi Charles,
cbe...@tajo.ucsd.edu wrote:
Viktor Rosenfeld listuse...@googlemail.com writes:
Hi,
if a value outputted by R in a Babel block contains quotes only the
quoted parted is exported.
Try
#+begin_src R :results verbatim
q = 'cat=S'
q
#+end_src
This is not a solution since I want to output vectors or data frames
from R as a table.
E.g. the following should return a table, but verbatim returns a quoted
block which I cannot use further in my processing:
#+NAME: quote-mangling
#+BEGIN_SRC R
q = c('cat=S', 'pos=VVFIN')
q
#+END_SRC
I also tried an extra newline at the end, but it makes no difference.
Cheers,
Viktor
Consider this:
#+BEGIN_SRC R
q = 'cat=S'
q
#+END_SRC
#+RESULTS:
: S
The expected result would be entire string, i.e. 'cat=S' (without
single quotes). Is there a workaround? I've tried escaping with
backslashes to no avail.
Cheers,
Viktor
--
Charles C. BerryDept of Family/Preventive Medicine
cberry at ucsd eduUC San Diego
http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[O] Functions in SBE blocks
Hi, I can't get SBE blocks called from a table to work, if they use functions like org-parse-time-string. Suppose I have the following table: | Start| Ende | | |--+--+-| | [2011-06-29 Wed] | [2012-02-29 Wed] | | #+TBLFM: $3='(sbe billable-month (start $1) (end $2)) and the following source block: #+NAME: billable-month(start=[2011-06-29 Wed], end=[2012-02-29 Wed]) #+BEGIN_SRC emacs-lisp (let* ((start-date start)) (message %s start-date)) #+END_SRC If I evaluate the table, the start date is put into the last column. However, if I change the code to the following: #+NAME: billable-month(start=[2011-06-29 Wed], end=[2012-02-29 Wed]) #+BEGIN_SRC emacs-lisp (let* ((start-date (org-parse-time-string start))) (message %s (nth 4 start-date))) #+END_SRC then the string #ERROR is inserted into the table. Evaluating the source block directly yields the correct result. What's going on here? Thanks, Viktor
Re: [O] Functions in SBE blocks
Hi Nick,
Nick Dokos wrote:
Viktor Rosenfeld listuse...@googlemail.com wrote:
Hi,
I can't get SBE blocks called from a table to work, if they use
functions like org-parse-time-string.
Suppose I have the following table:
| Start| Ende | |
|--+--+-|
| [2011-06-29 Wed] | [2012-02-29 Wed] | |
#+TBLFM: $3='(sbe billable-month (start $1) (end $2))
and the following source block:
#+NAME: billable-month(start=[2011-06-29 Wed], end=[2012-02-29 Wed])
#+BEGIN_SRC emacs-lisp
(let* ((start-date start))
(message %s start-date))
#+END_SRC
If I evaluate the table, the start date is put into the last column.
However, if I change the code to the following:
#+NAME: billable-month(start=[2011-06-29 Wed], end=[2012-02-29 Wed])
#+BEGIN_SRC emacs-lisp
(let* ((start-date (org-parse-time-string start)))
(message %s (nth 4 start-date)))
#+END_SRC
then the string #ERROR is inserted into the table. Evaluating the source
block directly yields the correct result.
What's going on here?
Finicky type matching: if you evaluate the second code block in the buffer
with
ESC ESC : (sbe billable-month (start [2011-06-29 Wed]) (end
[2012-02-29 Wed])) RET
you get a backtrace similar to this:
,
| Debugger entered--Lisp error: (wrong-type-argument stringp [2011-06-29 Wed])
|
string-match(\\(\\([0-9]\\{4\\}\\)-\\([0-9]\\{2\\}\\)-\\([0-9]\\{2\\}\\)\\(
+[^]+0-9
\n -]+\\)?\\( +\\([0-9]\\{1,2\\}\\):\\([0-9]\\{2\\}\\)\\)?\\) [2011-06-29
Wed])
| (if (string-match org-ts-regexp0 s) (list 0 (if (or (match-beginning 8)
(not nodefault)) (string-to-number (or (match-string 8 s) 0))) (if (or
(match-beginning 7) (not nodefault)) (string-to-number (or (match-string 7 s)
0))) (string-to-number (match-string 4 s)) (string-to-number (match-string
3 s)) (string-to-number (match-string 2 s)) nil nil nil) (error Not a
standard Org-mode time string: %s s))
| org-parse-time-string([2011-06-29 Wed])
| (let* ((start-date (org-parse-time-string start))) (format %d (nth 4
start-date)))
| ...
`
Somewhere, the string becomes not a string. Try modifying the block to this:
#+BEGIN_SRC emacs-lisp
(let* ((start-date (org-parse-time-string (format %s start
(message %s (nth 4 start-date)))
#+END_SRC
Nick
Thanks, that does the trick. The double ESC evaluation is helpful, too.
Cheers,
Viktor
[O] Output of R babel blocks with quotes is mangled/truncated
Hi, if a value outputted by R in a Babel block contains quotes only the quoted parted is exported. Consider this: #+BEGIN_SRC R q = 'cat=S' q #+END_SRC #+RESULTS: : S The expected result would be entire string, i.e. 'cat=S' (without single quotes). Is there a workaround? I've tried escaping with backslashes to no avail. Cheers, Viktor
Re: [O] How to escape spaces after full stops?
Hi,
I typically use a non-breaking space in this case with C-x 8 space.
This also prevents a linebreak at this position. For this to work I have
to add the following line in the LaTeX preamble:
\DeclareUnicodeCharacter{00A0}{~}
Cheers,
Viktor
Marius Hofert wrote:
Dear org-mode experts,
If I create a .org file containing this line...
,[ minimal_example.org ]
| This is just some text on p. 17. Some more text.
`
... and then export it to pdf via C-c C-e p, you can see from the output that
the space after p. is too large. In a standard .tex file one would escape
the
space via p.\ 17. But this leads to a backslash in the .pdf (when
exported). How can this space be escaped?
Cheers,
Marius
Re: [O] Drawers within inline tasks
Hi, when I open the parent task of an inline task drawers are not folded anymore. Not sure when this regression occured. Cheers, Viktor Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@googlemail.com writes: Thanks for the quick patch, but there's a small problem. The drawer is collapsed if the inline task is opened, but not if the parent task is opened. Example: * Parent Task *** Inline Task :PROPERTIES: :Effort: 0:15 :END: *** END Pressing TAB on Inline Task keeps the property drawer collapsed. Pressing TAB on Parent Task opens it. Fixed, thanks. I first didn't take care of this because it seemed logical to show all the content of an inline task here: the purpose of the inline task is to stay out of the hierarchical structure, such a task is *not* a subtree... so the real content of Parent task is all the text below -- whether it contains inline tasks or not. But I can see that it's not visually consistent with the habit of keeping stuff folded, so let's go that way. Thanks for reporting this, -- Bastien
Re: [O] Drawers within inline tasks
Hi Bastien, Bastien wrote: Hi Viktor, Viktor Rosenfeld listuse...@googlemail.com writes: when I open the parent task of an inline task drawers are not folded anymore. Not sure when this regression occured. Allowing tihs was causing performance regression in `org-cycle-internal-local'. If you can provide a patch that let `org-cycle-internal-local' without any performance regression, please do. I'm afraid that my lisp-fu is not up to that. :( Cheers, Viktor
Re: [O] Tangling without clutter?
Hi Jos'h, have you looked at the :session header argument? I use it to define environment variables in bash that are used in later code blocks. Something like this: #+BEGIN_SRC sh :session foo export W=world. #+END_SRC #+RESULTS: #+BEGIN_SRC sh :session foo echo Hello $W #+END_SRC If these code blocks are executed in order, the latter returns Hello world. Not sure though, how it interacts with Python. Cheers, Viktor Jos'h Fuller wrote: Hi! It seems like I almost need some variant of the tangle argument to :noweb where syntax references are expanded for evaluation, but not for anything else. Why would you want to tangle out a python src file with an un-expanded noweb reference? Either way, who am I to judge. I've just added a new eval option to the noweb header argument which will expand noweb references *only* during interactive evaluation. Please allow me to explain, I think it's a legitimate use case... I would like to provide a listing of a Python function, then later in the document show a demonstration of how it's used. I just did this when preparing some documentation for another programmer who is porting an application between languages. So I listed the function, then after a discussion, I had a demonstration of how to use the function. I wanted the output from the demonstration to be live, generated from the demonstration code. Therefore, I needed to reference the function defined above. Unfortunately, the reference was expanded during export so that the same block of code appeared /twice/, presenting the reader with something like this: : Here's a function: : def gorking(): : return gork : : Here's how to use the function: : def gorking(): : return gork : : print gorking() : : Which gives us: : gork As you can see, it's rather clumsy to have the function in the output twice. It's not too bad for this example, but anything more than a few lines becomes quite a distraction! This would have been preferable: : Here's a function: : def gorking(): : return gork : : Here's how to use the function: : function-gorking : : print gorking() : : Which gives us: : gork The original %.org file would look like this: : Here's a function: : #+name: function-gorking : #+begin_src python :tangle yes : def gorking(): : return gork : #+end_src : : Here's how to use the function: : #+name: function-gorking-demo : #+begin_src python :tangle yes : function-gorking : : print gorking() : #+end_src : : Which gives us: : #+results: function-gorking-demo : gork Does that explain it better? Thanks! Jos'h
Re: [O] [BABEL] Redirect stderr to stdout?
Hi Eric, Eric Schulte wrote: Viktor Rosenfeld listuse...@googlemail.com writes: Hi Eric, Eric Schulte wrote: Currently the only action Babel takes with STDERR is to display it in a pop-up buffer when code block evaluation fails. On my system (OS X) the buffer does not popup. I just tried #+BEGIN_SRC sh echo foo 12 #+END_SRC That is because the evaluation did not fail, try #+BEGIN_SRC sh echo foo 12 exit 1 #+END_SRC Thanks, that did the trick. It also explains why some error output from psql and the like does not make it into the buffer. [Snip] As always demand outstrips development resources. And still, org-mode is great product! Cheers, Viktor
