Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

[Alan Schmitt]

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?

Best,

Alan

Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

[Sebastien Vauban]

Hi John,

John Hendy wrote:
> On Mon, May 20, 2013 at 5:15 PM, John Hendy  wrote:
>> Sorry for the long title, but that's the summary! I fired up a fresh
>> Emacs session and used =C-a s search-term RET= to navigate to a
>> headline in the results by putting the cursor on the line and pressing
>> RET.
>>
>> The file text was all black.
>>
>> If I visited the file directly, I had the typical color-coded text for
>> headlines/keywords. I decided to replicate with a minimal config, and
>> I was able to. Here's the context of the min config:
>>
>> #+begin_min-config
>> ;; set load paths
>> ;; set load dirs and global config options
>> (add-to-list 'load-path "~/.elisp/org.git/lisp/")
>> (add-to-list 'load-path "~/.elisp/org.git/contrib/lisp")
>> #+end_min-config
>>
>> This was on a work file, and I couldn't initially replicate with a
>> test file... but it appears it has to do with my header options.
>> Here's the test file:
>>
>> #+begin_src org
>> #+setupfile: "~/org/aux/setupfile.org"
>> #+options: <:t num:t author:t creator:nil tags:t toc:nil date:t
>> #+latex_header: \usepackage{lscape}
>> #+latex_header: \usepackage{amsmath}
>>
>> * Test headline
>>
>> Some paragraph just to give me a keyword to search for
>>
>> ** Sub headline
>>
>> Some more text in the next headline
>> #+end_src
>>
>> My process:
>> - emacs -Q
>> - M-x load-file RET ~/path/to/min-config RET
>> - C-x C-f /path/to/file.org RET
>> - C-c [ to add to agenda list
>> - C-x C-k RET to kill buffer
>> - M-x org-agenda RET s RET text RET
>> - Navigate to test.org matching line RET
>> - File looks like attached pic
>>
>> I deleted everything but my #+setupfile line and it still does that.
>
> Last bit of input -- when this behavior is displayed, if I C-c C-c on
> my options block at the top of the file, it returns to fontified
> behavior and stays that way (even if meddling with headlines). It
> appears that navigating to a headline with various #+keyword lines is
> not letting Org recognize something. Refreshing the setup seems to
> handles this. This is on:
>
> Org-mode version 8.0.3 (release_8.0.3-139-g419b69 @
> /home/jwhendy/.elisp/org.git/lisp/)
>
> Happy to try anything else or provide more info. For now, I think I've
> made enough noise about this!
>
>> Without any #+ options at the top of the file, it appears in color.

End of last week, after updating Org, I also got lots of fontification
troubles inside Org buffers, but as well in more places (Gnus, in particular).

I restarted Emacs many, many times, used Org in different contexts, and
problems did always appear after some time (a couple of minutes, generally).

I did check out an older version of Org, and all the highlighting problems are
gone.

Currently used version: Org-mode version 8.0.3 (release_8.0.3-114-gab3f45 @
~/Public/Repositories/org-mode/lisp/).

I did not have time yet to bisect the problem, but it _seems_ to be a newly
introduced feature.

Maybe you can try to check out older versions (< 10 days ago), and see whether
you can replicate your problem?

Best regards,
Seb

-- 
Sebastien Vauban

Re: [O] TOC in HTML export - how to change formatting of ToDo levels?

[Sebastien Vauban]

Hi David,

David Rogoff wrote:
> I've just started diving back into org-mode. I'm mostly using it for ToDo /
> Status tracking. I've been trying to change the format of the TOC entries with
> little success. I've figured out how to use org-export-html-style to change
> the CSS markup for my customized ToDo levels, but that just affects the
> formatting in the body of the document. The table of contents appears to
> ignore that. I've been digging through org-html.el and the TOC formatting
> (around line 1474) looks to be mostly card-coded with almost no variables to
> control anything. Any ToDo status of done is not marked up at all and anything
> else is just marked as class "todo" instead of the actual class of the item.
>
> Am I missing something? The only solution I've found is to write a script to
> fix the HTML after exporting. Any better solution? It's a very big ToDo list
> and I (and others who will look at the document) want to see the actual status
> (preferably with the CSS font/text markups) in the TOC to know which items to
> look into for further details.

You should be able to customize the todo class only within the TOC context
with such a rule:

--8<---cut here---start->8---
#table-of-contents .todo {
...
}
--8<---cut here---end--->8---

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Customizing Org 8.0 Export

[Sebastien Vauban]

Hi Scott,

Scott Randby wrote:
> 2. I want to put the following in my init.el:
>
>  (add-to-list 'org-latex-classes
>  '("notesclass"
>"\\documentclass{article}"
>("\\section{%s}" . "\\newsection{%s}")
>("\\subsection{%s}" . "\\newsubsection{%s}")))
>
> But when I do, I get the following on startup:
>
>   Warning (initialization): An error occurred while loading
>   `/home/srandby/.emacs.d/init.el':
>
>   Symbol's value as variable is void: org-latex-classes
>
>   To ensure normal operation, you should investigate and remove
>   the cause of the error in your initialization file.  Start
>   Emacs with the `--debug-init' option to view a complete error
>   backtrace.
>
> This means I cannot put the above code in my init.el file where I
> want it to be.

For such cases, I do write:

#+begin_src emacs-lisp
  ;; LaTeX back-end
  (eval-after-load "ox-latex"
'(progn

  ;; your code...

)) ;; eval-after-load "ox-latex" ends here
#+end_src

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Best way to make/add tech diagrams/graphics?

[Christopher Witte]

Asymptote http://asymptote.sourceforge.net/ would also be another option in
a similar vein to TikZ.


On 18 May 2013 01:14, John Hendy  wrote:

> On Fri, May 17, 2013 at 6:09 PM, Marcin Borkowski 
> wrote:
> > Dnia 2013-05-17, o godz. 11:40:17
> > John Hendy  napisał(a):
> >
> >> On Fri, May 17, 2013 at 10:13 AM, Lawrence Bottorff
> >>  wrote:
> >> > I'd like to embed images into my running org file -- for eventual
> >> > conversion to Latex or html. These would be simple diagram-style
> >> > pictures such as math or technical diagrams that cannot be done
> >> > with gnuplot or other formula-to-picture conversion software.
> >> >
> >> > Examples:
> >> >
> http://www.library.utoronto.ca/see/SEED/Vol5-1/Queiroz_Emmeche_El-Hani_files/image003.gif
> >> >
> http://math.ucr.edu/home/baez/irvine/SBGN_process_description_cropped.jpg
> >> >
> >>
> >> A few that come to mind for this sort of thing:
> >> - ditaa: http://ditaa.sourceforge.net/
> >> - graphviz/dot: http://www.graphviz.org/
> >> - my personal favorite, but quite the learning curve, it PFG/TikZ:
> >> http://www.texample.net/tikz/examples/
> >
> > Typo: it's PGF, not PFG, just in case you wanted to google it or
> > something;).
> >
>
> Oops -- typo on my part.
>
> > I'd also mention Metapost, on which I believe TikZ was modeled (at least
> > to some extent).
> >
> > Since you mentioned embedding in LaTeX, I'd also suggest TikZ; it has a
> > huge manual, but /very/ well written, with quite a few tutorials and
> > examples. One benefit is that it is tightly integrated into LaTeX,
> > but it can also export SVG (though with a few limitations compared to
> > the pdfLaTeX-produced output).  Also, you might want to check out the
> > gallery of TikZ examples here: http://www.texample.net/tikz/ .
> >
>
> The examples are great. The link I provided goes right to the examples
> vs. that sort of home page screen which only shows the most recent
> couple that have been submitted.
>
> I'll have to check out metapost, as I'd not heard of that one.
>
>
> Thanks,
> John
>
> >> Good luck!
> >> John
> >
> > Best,
> >
> > --
> > Marcin Borkowski
> > http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> > Adam Mickiewicz University
> >
>
>

Re: [O] Indentation of code blocks within lists

[Francesco Pizzolante]

Hi,

May I bump up this thread?

Thanks,
 Francesco

"Francesco Pizzolante" wrote:
> Hi All,
>
> I'd like to let you know about issues I'm having while trying to put source
> code blocks within lists.
>
> Here's my example and how I indent it:
>
> * First situation
>
> - My first bullet
>
>   We need to do this:
>
>   #+begin_src emacs-lisp
>   (message "this is a string")
>   (defun x()
> "Doc..."
> (interactive)
> (message "hello"))
>   #+end_src
>
> - My second bullet
>
>   #+begin_src emacs-lisp
>   "test"
>   #+end_src
>
>   #+results:
>   : test
>
>   - Sub-point of second bullet
>
> We need to do this as well:
>
> #+begin_src emacs-lisp
> (sort)
> #+end_src
>
> This way if indenting code blocks has the following advantages:
>
> - it looks nice;
>
> - thanks to the indentation, you directly know at which list level the code
>   block belongs to;
>
> - you can easily use Emacs commands (like `C-x TAB') on regions or Org
>   promote/demote commands on items or subtrees to edit and reorganize your
>   text: "relative" indentation is preserved in all cases.
>
> But, I have 2 issues with it:
>
> - when using `C-c '' (`org-edit-special'), I see spaces before my code, while
>   I would expect to see my code starting at column 0 in the edit buffer (the
>   "reference" column for the "margin" being, here, the column with the '#'
>   from '#+begin_src';
>
> - when exporting, the spaces from column 0 to the start of my code are also
>   exported, while I would again expect these spaces to be ignored for the
>   export.
>
> The only way I found to fix these issues is to edit my text like this (and
> make any code to start in column 0):
>
> - My first bullet
>
>   We need to do this:
>
>   #+begin_src emacs-lisp
> (message "this is a string")
> (defun x()
>   "Doc..."
>   (interactive)
>   (message "hello"))
>   #+end_src
>
> - My second bullet
>
>   #+begin_src emacs-lisp
> "test"
>   #+end_src
>
>   #+results:
>   : test
>
>   - Sub-point of second bullet
>
> We need to do this as well:
>
> #+begin_src emacs-lisp
> (sort)
> #+end_src
>
> But:
>
> - as you can see, the text does not look anymore as nice as in the previous
>   example;
>
> - I'm no longer able to edit and reorganize the text using Emacs `C-x TAB'
>   command. That command becomes "forbidden" as it can't correctly respect the
>   indentation requirements:
>
>   + starting at column 0 for code;
>
>   + relative for list items (depending on their depth);
>
> - even Org promote/demote commands are buggy in this case: as a simple
>   example, when I try to promote (with M-Shift-Left) the last point "Sub-point
>   of second bullet" I get an error ("indent-line-to: Wrong type argument:
>   wholenump, -2" ) and the following half-baked result:
>
>   - Sub-point of second bullet
>
> We need to do this:
>
> #+begin_src emacs-lisp
> (sort)
>   #+end_src
>
>   The "#+end_src" line got misaligned.
>
> So, my question is the following: is there a way to edit my text as shown in
> the first example and edit/export it ignoring the "margin" spaces?
>
> Any help is welcome.
>
> Thanks a lot,
>  Francesco

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Rasmus]

Alan Schmitt  writes:

>> It seems there are some semantic bugs in ox-koma-letter.el in that new
>> variables are introduces for SENDER (as opposed to AUTHOR) and a
>> separate email variable as well.  This seems like a semantic bug IMO.
>> This patch fixes these issues if they in fact are issues.
>
> Can we still use an lco file to set these after this change?

(I'll also post this on the list).

You can't set
  
  #+SENDER: 

Which seems to be how it was set up before.  You can use 

  #+AUTHOR

So if you decide to convert your document from something you'd export
with the normal LaTeX exporter it would be smoother this way.  Author
now works the same way that it does in the LaTeX exporter (come to
think of it, we probably shouldn't need to mention anything as it
build on top of the LaTeX exporter anyway). 

Thus, unless you disable export of author it wouldn't work with a LCO
file.  But then we could make export of author conditional on
:with-author as in ox-latex.el and you could use LCO files.

The gain is that in the (for me) 99.9% of the cases where I want to
send a letter in my own name the exporter just figures it out without
be having to specify anything (like in the normal exporter).

–Rasmus


-- 
In theory, practice and theory are the same. In practice they are not

Re: [O] patch for htmlize.el

[Bastien]

Hi Eric,

Carsten Dominik  writes:

> Yes, that is all right at least for now, please go ahead.

Please also send an email to htmlize.el's author -- I think he's
reading the mailing list, but ensuring he does would be nice.

Best,

-- 
 Bastien

Re: [O] GFDL

[Bastien]

Hi Ben,

Ben Finney  writes:

>> It bothers me mostly for the guide, where I did spend a lot of time to
>> make it compact, and now something like one fifth of it is license
>> text.  We may actually consider to re-release the guide under a
>> different license.
>
> Please use this as an opportunity to seriously consider relicensing the
> entire work (programs, documentation, etc.) of Org-mode under the same
> license: the GNU GPL. It does not have the special problems of the FDL,
> and having the whole work under the same license terms makes it simpler
> and clearer.

Well, relicensing the Org compact guide under GNU GPL is definitely
feasible, but relicensing the Org manual is (sadly) not.  Let's take
the feasible step first?

-- 
 Bastien

Re: [O] Effort entry and confusing effort estimates

[Bastien]

Hi Ken,

Ken Mankoff  writes:

> But I'm still confused what 'org-set-effort' expects/interprets
> compared to 'org-clock-modify-effort-estimate'. Any clarification
> will be much appreciated.

`org-set-effort' allows you to _set_ the effort value.

`org-clock-modify-effort-estimate' allows you to either set the effort
value (e.g. if you enter 1:30, the old value will be replaced by this
one) or to increment/decrement the effort value by using +mm or
+n[hdwmy] -- e.g. entering +1d will increment the current value by 1
day.  "1 day" is interpreted depending on `org-effort-durations',
which see.

Hope this clarifies,

-- 
 Bastien

Re: [O] ical2org.py

[Eric S Fraga]

aitor  writes:

> Hi,
>
> I've implemented a little script which converts ics files to
> org-mode. You can find the script here:
>
> https://github.com/asoroa/ical2org.py

Aitor,

I would like to try this out but, as I am not a python user, I have no
idea how to get the two bits you indicate being necessary (icalendar,
pytz) installed.  I have installed python-dateutil and python-pycalendar
as these looked the most obvious candidates for icalendar but no
luck.  Searching the repositories for pytz draws a blank as well.

,
| $ ~/git/ical2org.py/ical2org.py 
| Traceback (most recent call last):
|   File "/home/ucecesf/git/ical2org.py/ical2org.py", line 5, in 
| from icalendar import Calendar
| ImportError: No module named icalendar
| $ 
`

I am using Ubuntu.

Anyway help would be most welcome.

thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.2-94-g5a1400

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Alan Schmitt]

Rasmus writes:

> Alan Schmitt  writes:
>
>>> It seems there are some semantic bugs in ox-koma-letter.el in that new
>>> variables are introduces for SENDER (as opposed to AUTHOR) and a
>>> separate email variable as well.  This seems like a semantic bug IMO.
>>> This patch fixes these issues if they in fact are issues.
>>
>> Can we still use an lco file to set these after this change?
>
> (I'll also post this on the list).
>
> You can't set
>   
>   #+SENDER: 
>
> Which seems to be how it was set up before.  You can use 
>
>   #+AUTHOR
>
> So if you decide to convert your document from something you'd export
> with the normal LaTeX exporter it would be smoother this way.  Author
> now works the same way that it does in the LaTeX exporter (come to
> think of it, we probably shouldn't need to mention anything as it
> build on top of the LaTeX exporter anyway). 
>
> Thus, unless you disable export of author it wouldn't work with a LCO
> file.  But then we could make export of author conditional on
> :with-author as in ox-latex.el and you could use LCO files.
>
> The gain is that in the (for me) 99.9% of the cases where I want to
> send a letter in my own name the exporter just figures it out without
> be having to specify anything (like in the normal exporter).

OK, sounds good, I've applied it.

Thanks,

Alan

Re: [O] Effort entry and confusing effort estimates

[Lawrence Mitchell]

Bastien wrote:
> Hi Ken,

> Ken Mankoff  writes:

>> But I'm still confused what 'org-set-effort' expects/interprets
>> compared to 'org-clock-modify-effort-estimate'. Any clarification
>> will be much appreciated.

> `org-set-effort' allows you to _set_ the effort value.

> `org-clock-modify-effort-estimate' allows you to either set the effort
> value (e.g. if you enter 1:30, the old value will be replaced by this
> one) or to increment/decrement the effort value by using +mm or
> +n[hdwmy] -- e.g. entering +1d will increment the current value by 1
> day.  "1 day" is interpreted depending on `org-effort-durations',
> which see.

I think the problem is slightly more complicated.

org-set-effort does:

read some effort duration

(org-entry-put nil "Effort" duration-we-just-read)

org-clock-modify-effort-estimate does:

read some effort duration
(org-duration-string-to-minutes value)
convert this duration in minutes back to a string
(org-minutes-to-clocksum-string minutes-corresponding-to-value)
(org-entry-put nil "Effort" duration-we-just-calculated)

So org-set-effort doesn't do any conversion of the effort string
we enter.

org-clock-modify-effort-estimate does do conversion.  However, it
does it badly.

org-duration-string-to-minutes always uses org-effort-durations
to convert the input string to minutes.  However,
org-minutes-to-clocksum-string /only/ uses org-effort-durations
if org-time-clocksum-use-effort-durations is non-nil (not the
default).

The problem boils down to:

(let ((org-time-clocksum-use-effort-durations nil))
  (= (org-duration-string-to-minutes "3d 2h") ;; what the user entered
 (org-duration-string-to-minutes  ;; what gets inserted
   (org-minutes-to-clocksum-string
 (org-duration-string-to-minutes "3d 2h")

=> nil

(let ((org-time-clocksum-use-effort-durations t))
  (= (org-duration-string-to-minutes "3d 2h") ;; what the user entered
 (org-duration-string-to-minutes  ;; what gets inserted
   (org-minutes-to-clocksum-string
 (org-duration-string-to-minutes "3d 2h")

=> t

I would argue that

(org-duration-string-to-minutes
  (org-minutes-to-clocksum-string
(org-duration-string-to-minutes some-value)))

Should be a no-op.  But that is only the case if
org-time-clocksum-use-effort-durations is t.


Lawrence

-- 
Lawrence Mitchell 

Re: [O] ical2org.py

[François Pinard]

Eric S Fraga  writes:

> I am not a python user [...]

Hi, Eric.  Nobody is perfect :-).  Regards, François

Re: [O] RFQ - new contribution - org-screenshot.el

[François Pinard]

Max Mikhanosha  writes:

> At Mon, 20 May 2013 13:45:48 -0500, Russell Adams wrote:
>> What advantages would org-screenshot provide by comparison?

> To me the most useful feature is actually "screenshot rotation"
> shortcuts,

I also have my own screenshot tool (this was my first own addition to
Org mode, soon after I started to use it, quite a while ago now!) which
is intermediate in features between Russell's and Max's.

One thing I like in Max's approach is this capability of doing a Dired
display, in which one segregates between used screenshots and orphan
ones.  When a document has many screenshots, such diagnostic help eases
eliminating the dead wood and staying clean overall.

François

Re: [O] odt import

[Detlef Steuer]

On Sun, 19 May 2013 19:27:49 +0200
Uwe Brauer  wrote:

> >> "Ethan" == Ethan Ligon  writes:
> 
>> Uwe Brauer  mat.ucm.es> writes:
>>> 
>>> Uwe Brauer 
>>> 
>>> 
> 
>> Presumably a reference to
> 
>> https://bitbucket.org/josemaria.alkala/odt2org/wiki/Home
> 
>> I haven't used it, and it's rather old (predates org-elements, I think). 
>  
> 
> Thanks but there are now files for downloading so I presume this project
> is dead.
> 

Don't know anything about it but there is something to try:
https://bitbucket.org/josemaria.alkala/odt2org/src

Detlef
 

[O] Let's discuss citation and Org syntax

[Rasmus]

Hi, 

Now that 8.0 has shipped let's talk bibliography support.  This
follows directly upon the discussion around March[1].

The essence of the thread was that some people agreed that it would be
nice to have support for citation commands build into Org (I'll
summarize in the next post).  But let me first restate my own take on
the issue.  IMO a nice format would be:

(*)   [KEYWORD PROPERTIES]

I think we should allow for a more general approach than one just for
citation and this is a good thing (IMO).

The in-buffer display of (*) could be governed by
org-buffer-format-KEYWORD (similar to
gnus-user-format-function-LETTER) or just identity if no function is
defined.  Export could be handled by org-BACKEND-KEYWORD or
org-export-KEYWORD.  With officially recognized KEYWORDs something
like citation could be a 'first-class citizen'.  PROPERTIES could be a
string like:

  optional-keyless-entry :prop1 one :prop2 two ... 

Perhaps, treatment of keyword, could even be handled by an
in-buffer Org Babel function in the spirit of e.g. reproducible
research (see below).

This would be different from Org links in that (*) is more like a
functions that allows for (i) pretty and informative display in
buffer/export and (ii) easy user extension.

I think there are many compelling use-cases for such a framework.

1. Citation: Take the keyword citetext which should be an 'official'
   KEYWORD.  So for instance we could have

 [citetext BIBTEX-KEY :prenote note, w/comma :postnote blah].

   In buffers, via org-in-buffer-format-citetext, it would be
   displayed as
   
 BIBTEX-KEY (note, w/comma, YEAR, blah)
   
   or something similar (depending to what extend bibtex.el would be
   leveraged; e.g. BIBTEX-KEY might show the author/editor key and
   YEAR would also depend on parsing a bibtex file) (obviouesly,
   there's some reference to a bibtex file somewhere).  In LaTeX it
   would be exported as
   
 \citetext[note,w/comma][blah]{BIBTEX-KEY}
   
   In html it might utilize some tool that understand bibtex (there's
   a link to such a tool in the next post).  In ASCII it could almost
   use what would be displayed in the buffer.

2. MY-FUN: MY-FUN is some function that does something with some
   properties, perhaps just a string (simple cases: [sc text] is used
   for small caps, or mayhaps [my-treat-dna-string DNA-STRING]).  I
   might use it in a single file that I want to send to people or I
   might just use it in my notes.  Currently it's implemented via
   org-emphasis-alist or as a link.  Changing emphases is a hacks, and
   they are hard to export with the now more robust Org syntax and
   further permit little control over how they are displayed
   in-buffer.  Links are more flexible but lacks display control and
   becomes somewhat painful with many arguments[2].  Also, MY-FUN
   doesn't take a 'description'.  With (*) I could simply write
   
 [MY-FUN PROPERTIES].
   
   Perhaps, I could even define org-BACKEND-MY-FUN in a babel block
   if it's only relevant to the current file.

There's been some work and some discussion on this already, most
notably Aaron already supplied some patches towards this end[3],
but using a slightly different syntax more like the link syntax;
e.g. textcite above would look like

  [[textcite:bibtex-key&&pre%3Dfoo&&post%3Dbar][whatever]]

where whatever is ignored.  The state of the discussion is to some
extend summarized in the next post.
  
It would love to hear whether other people find something like this to
be a good idea?  Would anyone find a use such a framework?  Would (*)
conflict with anyone's current usage of Org?  Is (*) too ambitious and
in terms of getting citation support?  Is this is taking a musket to
kill a butterfly?  What are the the flaws in the above.

I'm not a good (lisp) programmer, but I think I have a month off this
summer where I could work on something like the above.

Thanks for reading,
Rasmus

Footnotes: 
[1] http://mid.gmane.org/20130303070635.GA12112%40panahar
[2] my citation links often look like postnote;prenote without
showing the BIBTEX-KEY or citation format.
[2] here http://mid.gmane.org/87lia0s7wi.fsf%40bzg.ath.cx
and here http://mid.gmane.org/87wqthk7vj.fsf%40gmail.com.


-- 
When in doubt, do it!

Re: [O] Effort entry and confusing effort estimates

[Bastien]

Hi Lawrence,

Lawrence Mitchell  writes:

> I would argue that
>
> (org-duration-string-to-minutes
>   (org-minutes-to-clocksum-string
> (org-duration-string-to-minutes some-value)))
>
> Should be a no-op.  But that is only the case if
> org-time-clocksum-use-effort-durations is t.

Agreed.  Thanks for the clear explanations.  Can you provide a patch
to get the correct behavior?  At the time, I could not closely watch
the side-effect of introducing `org-time-clocksum-use-effort-durations'
and this is clearly one of them.

Thanks in advance!

-- 
 Bastien

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Rasmus]

Alan Schmitt  writes:

> OK, sounds good, I've applied it.

Thanks.

Let's wait with the rest till Vicktor's had a chance to look over it.

–Rasmus

-- 
Summon the Mothership!

Re: [O] using gnuplot's "splot" and "every" commands on org-mode table data

[Eric S Fraga]

Achim Gratz  writes:

[...]

> I've implemented "calculation separators" that register as hlines for
> table formulas, but are ignored when row groups are constructed for
> export.  Your example table would then look like this:

Achim,

just to apologise for not getting back to you earlier on this.  I've
been swamped with work.  I'll try to have a test of your table updates
this week!

thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_8.0.3-144-gf1b99a

Re: [O] RFQ - new contribution - org-screenshot.el

[Russell Adams]

On Tue, May 21, 2013 at 08:03:45AM -0400, François Pinard wrote:
> I also have my own screenshot tool (this was my first own addition to
> Org mode, soon after I started to use it, quite a while ago now!) which
> is intermediate in features between Russell's and Max's.

I can't take credit, that snippet has floated around on the ML for a
while and I only changed the filename format to suit my tastes.

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: [O] patch for htmlize.el

[Eric Schulte]

Bastien  writes:

> Hi Eric,
>
> Carsten Dominik  writes:
>
>> Yes, that is all right at least for now, please go ahead.
>

Done

>
> Please also send an email to htmlize.el's author -- I think he's
> reading the mailing list, but ensuring he does would be nice.
>

Done, Thanks,

>
> Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: [O] Let's discuss citation and Org syntax

[Rasmus]

A lot of people more clever than me have thought about this topic.
Here I'll just summarize the "org-exp-bibtex missing in
git?"-thread.  The ordering more or less follows how it was
displayed in my Gnus.  I've tried to "stay honest" to the people
I've quoted and hopefully I've not failed too badly.  Also, I hope
I've not forgotten valuable suggestions.  I've not quoted Thomas,
but he gave some insights of what one would want in citation here
http://mid.gmane.org/m1a9qczekf.fsf%40tsdye.com.
   

There were approximately three types of suggestions:
1. the new-type approach, which I've tried to generalize more
   above.  Aaron made valueable suggestions here.  Nicolas gave it
   some support.
2. The extending link approach, notably Bastien, Andreas and Aaron
   even supplied patches!
I've also included some quick references to the "current frontier"
using links.  Lastly, there's some links to implementation in other
formats.

The "new-type" approach
   - Nicolas: 
 #+BEGIN_QUOTE
 It would be good to integrate citations in export framework
 [...]
 Maybe something like [cite:]. org-element could parse this, and
 ox.el provide some tools to access data. Then each back-end could deal
 with them.
 [...]
 I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter
 (link syntax) implies a (optional) description part. I don't think
 a description is ever meaningful in citations.
 #+END_QUOTE
 Ref: http://mid.gmane.org/87ehfwwgdd.fsf%40gmail.com and
 http://mid.gmane.org/874ngkzjt6.fsf%40gmail.com

   - Much of my discussion in the previoues post is similar to Aaron's
 response to my original post
 #+BEGIN_QUOTE
 So, a citation like [cite:doi:parens:some-doi:key=val&key2=val2] would be
 displayed by:
 1. call (org-lookup-cite-doi "some-doi") -> (:author "Foo" :title "bar" 
...)
 2. call (org-display-cite-parens '(:author "Foo" :title "bar" ...)) ->
 "(Foo 2000)"
 3. (font-lock puts an overlay over the citation markup, with the
 returned string)
   
 If you click on the citation, org would open the location (URL or local
 file) returned by (org-resolve-cite-doi "some-doi")
   
 A citation could exported by calling (org-export-cite-parens 'doi
 "some-doi" (:author "foo" :title "bar") current-backend).  This function
 could just return \parencite{foo} if exporting to latex and the citation
 was already in a bibtex file.  But it could also just return “Foo 2000”
 as a static string for dumb backends like ASCII, or write the
 information to a temporary bibtex file (so that latex can atomatically
 use the bibliographic info looked up from a DOI citation).
 #+END_QUOTE
 Ref: http://mid.gmane.org/87txolk7qk.fsf%40gmail.com


- Jamuthan's take on viewing citation as footnotes
 #+BEGIN_QUOTE
 I view Citations as closer to Footnotes.  The syntax should parallels
 footnotes syntax.
 
 1. PROPERTIES should be opaque to Org.  It is a key or a list of
keys possibly bibtex but Org doesn't take stand on how it
looks like.
   
 2. There will be a org-BACKEND-citation-reference.
 3. There will be a org-BACKEND-bibliography.
   
 2, 3 more likely with interface with respective citation processor
 (citation processor as opposed to a database) via CLI.  Citation
 processor could be whatever org-exp-bibtex interfaces with right now.  I
 also have some proof-of-concept - see zotcite - for zotero.
   
 2, 3 will parallel footnote-reference and footnote-section callbacks in
 HTML backend.
   
 4. Footnotes can be introduced with either fn: prefix or cite:
prefix.  There should be a way to put fn: and cite: in same
enumeration context.  There should be a way to put fn: and
cite: in different enumeration context.  The former case could
be a degenerate mode where Org can transcode what is seen in
the buffer where everything is footnotes.  The latter case
will result in Citations and Bibliography being generated by
the above backend transcoders.
   
 5. Citation definitions in Org buffer will be *ignored*.  (It
could be considered when the exporter works in a degenerate
footnote only mode where plain text transcoding is resorted to
because there is no suitable application available for the
backend format.)  Plain text citation definitions are only to
help the author have a glimpse of what he is doing, it has
only UI-value but no contents value.
   
 6. There may be an advisory citation style - say APA, Chicago
etc - which the backends may honor or ignore.
  #+END_QUOTE


The "extend-link" suggestions:

   - Andreas Leha suggest something like what I suggested above, but
 extending upon the link syntax.  What I agree strongly with is:

   citations are more than links but also include informati

Re: [O] GFDL

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> Ben Finney  writes:
>>> It bothers me mostly for the guide, where I did spend a lot of time to
>>> make it compact, and now something like one fifth of it is license
>>> text.  We may actually consider to re-release the guide under a
>>> different license.
>>
>> Please use this as an opportunity to seriously consider relicensing the
>> entire work (programs, documentation, etc.) of Org-mode under the same
>> license: the GNU GPL. It does not have the special problems of the FDL,
>> and having the whole work under the same license terms makes it simpler
>> and clearer.
>
> Well, relicensing the Org compact guide under GNU GPL is definitely
> feasible, but relicensing the Org manual is (sadly) not.  Let's take
> the feasible step first?

FMI, why is GNU GPL not applicable to the manual?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Effort entry and confusing effort estimates

[Ken Mankoff]

Hi Bastien,

On Tue, 21 May 2013, Bastien wrote:


Ken Mankoff  writes:

But I'm still confused what 'org-set-effort' expects/interprets 
compared to 'org-clock-modify-effort-estimate'. Any clarification 
will be much appreciated.


`org-set-effort' allows you to _set_ the effort value.

`org-clock-modify-effort-estimate' allows you to either set the 
effort value (e.g. if you enter 1:30, the old value will be 
replaced by this one) or to increment/decrement the effort value 
by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the 
current value by 1 day.  "1 day" is interpreted depending on 
`org-effort-durations', which see.


Thanks for the explanation. I guess I'm confused why one 
formats/converts/checks the input and the other does not. I guess 
this doesn't imply that org-set-effort does anything different, it 
really is just a pure subset of org-clock-modify-effort-estimate.


Thanks,

  -k.

Re: [O] ical2org.py

[Guido Van Hoecke]

Eric S Fraga  writes:

> aitor  writes:
>
>> Hi,
>>
>> I've implemented a little script which converts ics files to
>> org-mode. You can find the script here:
>>
>> https://github.com/asoroa/ical2org.py
>
> Aitor,
>
> I would like to try this out but, as I am not a python user, I have no
> idea how to get the two bits you indicate being necessary (icalendar,
> pytz) installed.  I have installed python-dateutil and python-pycalendar
> as these looked the most obvious candidates for icalendar but no
> luck.  Searching the repositories for pytz draws a blank as well.

I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it
and ran `sudo python setup.py install'

Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg
file so you just run `sudo easy-install pytz-2013b-py2.7.egg'

This command should get you going:
`./ical2org.py input.ics > output.org

Hope this helps,


Guido

--
Ever since prehistoric times, wise men have tried to understand what,
exactly, make people laugh.  That's why they were called "wise men."
All the other prehistoric people were out puncturing each other with
spears, and the wise men were back in the cave saying: "How about:
Would you please take my wife?  No.  How about: Here is my wife, please
take her right now.  No.  How about:  Would you like to take something?
My wife is available.  No.  How about ..."
-- Dave Barry, "Why Humor is Funny"

Re: [O] GFDL

[François Pinard]

"Sebastien Vauban" 
writes:

> FMI, why is GNU GPL not applicable to the manual?

While I would have long to say, here, I rather censor myself, mostly.

I sometimes happen to think that the GDFL happened not so long after
Richard Stallman and I had a harsh and long dispute about the GNU tar
manual.  In short, I wanted to publish it, Richard wanted that I refrain
from doing so: he expected the manual to be a source of FSF revenue.
The GDFL wording opens the door to Richard's restrictions, while the
GPL, which I used, is more in the spirit of the remainder of the FSF.

GNU tar has it own set of technical difficulties, and I hope I've been
able to put it back on track so it became maintainable again.  But in
many non-technical ways, GNU tar has been an administrative nightmare.

François

Re: [O] RFQ - new contribution - org-screenshot.el

[Haider Rizvi]

Max Mikhanosha  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. 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] Customizing Org 8.0 Export

[Scott Randby]

On 05/21/2013 01:25 AM, John Hendy wrote:
> On May 20, 2013 9:03 PM, "Scott Randby"  wrote:
>> Is there any way to make all of org's variables available for
>> customization on startup?
>>
> 
> Yes, see the original exporter announcement:
> 
> http://article.gmane.org/gmane.emacs.orgmode/65574
> 
> Section 3.0 calls out two methods of setting available backends. I'm
> guessing you are customizing org-export-backends vs (require 'ox-backend).
> Try requiring the backend and all associated variables will be there on
> startup.
> 
> John

Thanks for the solution.

This is the second time in a row I've been referred to the original
exporter announcement. I'm sorry that my questions are so basic, but I
put off switching to 8.0 because my understanding of how org and Emacs
work is not very deep and I know little elisp. Once I have things set
up, I leave them alone and get to work. I'm very grateful to this list
for helping me figure out things that, in hindsight, are obvious.

Scott Randby

Re: [O] GFDL

[Carsten Dominik]

On 21 mei 2013, at 15:34, François Pinard  wrote:

> "Sebastien Vauban" 
> writes:
> 
>> FMI, why is GNU GPL not applicable to the manual?
> 
> While I would have long to say, here, I rather censor myself, mostly.
> 
> I sometimes happen to think that the GDFL happened not so long after
> Richard Stallman and I had a harsh and long dispute about the GNU tar
> manual.  In short, I wanted to publish it, Richard wanted that I refrain
> from doing so: he expected the manual to be a source of FSF revenue.
> The GDFL wording opens the door to Richard's restrictions,

I am curious, what passage does make such restrictions
possible, and which kinds of restrictions?

- Carsten


> while the
> GPL, which I used, is more in the spirit of the remainder of the FSF.
> 
> GNU tar has it own set of technical difficulties, and I hope I've been
> able to put it back on track so it became maintainable again.  But in
> many non-technical ways, GNU tar has been an administrative nightmare.
> 
> François
> 

Re: [O] Customizing Org 8.0 Export

[John Hendy]

On Tue, May 21, 2013 at 8:53 AM, Scott Randby  wrote:
> On 05/21/2013 01:25 AM, John Hendy wrote:
>> On May 20, 2013 9:03 PM, "Scott Randby"  wrote:
>>> Is there any way to make all of org's variables available for
>>> customization on startup?
>>>
>>
>> Yes, see the original exporter announcement:
>>
>> http://article.gmane.org/gmane.emacs.orgmode/65574
>>
>> Section 3.0 calls out two methods of setting available backends. I'm
>> guessing you are customizing org-export-backends vs (require 'ox-backend).
>> Try requiring the backend and all associated variables will be there on
>> startup.
>>
>> John
>
> Thanks for the solution.
>
> This is the second time in a row I've been referred to the original
> exporter announcement. I'm sorry that my questions are so basic, but I
> put off switching to 8.0 because my understanding of how org and Emacs
> work is not very deep and I know little elisp. Once I have things set
> up, I leave them alone and get to work. I'm very grateful to this list
> for helping me figure out things that, in hindsight, are obvious.

No problem, and I wouldn't say it was *that* obvious :) I found this
document extremely helpful:
- http://orgmode.org/worg/org-8.0.html

I also started (and should really update again/maintain!) this as a
landing place for documenting other things as they come up:
- http://orgmode.org/worg/exporters/ox-overview.html

And have a blog post walking through setting things up here, if it helps:
- 
http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html


Good luck! We're all learning here, so no worries on the mailing list.
More things for Google to index for users stumbling on this after you!


John

>
> Scott Randby

Re: [O] GFDL

[François Pinard]

Carsten Dominik  writes:

> I am curious, what passage does make such restrictions possible, and
> which kinds of restrictions?

Oh, I did not read the GFDL in quite a years, and really have no
interest in diving and scrutinizing it again :-).  More away I am from
all this, better I feel :-).  Sorry, just forget I've written this
morning, I was likely in some strange mood.

I do love the FSF idea and theory, and supported the GNU project in an
intense way for maybe more than twenty years.  But by now, in practice,
I just cannot stand their slightest abuse, anymore.  I'm all for
programming freedom, but this ought to include programmer freedom too!

François

Re: [O] ical2org.py

[aitor]

On Tue, May 21, 2013 at 03:10:51PM +0200, Guido Van Hoecke wrote:
>
> I got iCalendar from https://pypi.python.org/pypi/icalendar, untarred it
> and ran `sudo python setup.py install'
> 
> Got pytz from https://pypi.python.org/pypi/pytz/. It comes as an egg
> file so you just run `sudo easy-install pytz-2013b-py2.7.egg'
> 
> This command should get you going:
> `./ical2org.py input.ics > output.org

Hi Guido,

thanks for the help! If the script gets enough interest I can sort out
an easy installation method for it.

best,
aitor

Re: [O] Customizing Org 8.0 Export

[Scott Randby]

On 05/21/2013 10:48 AM, John Hendy wrote:
> On Tue, May 21, 2013 at 8:53 AM, Scott Randby  wrote:
>> On 05/21/2013 01:25 AM, John Hendy wrote:
>>> On May 20, 2013 9:03 PM, "Scott Randby"  wrote:
 Is there any way to make all of org's variables available for
 customization on startup?

>>>
>>> Yes, see the original exporter announcement:
>>>
>>> http://article.gmane.org/gmane.emacs.orgmode/65574
>>>
>>> Section 3.0 calls out two methods of setting available backends. I'm
>>> guessing you are customizing org-export-backends vs (require 'ox-backend).
>>> Try requiring the backend and all associated variables will be there on
>>> startup.
>>>
>>> John
>>
>> Thanks for the solution.
>>
>> This is the second time in a row I've been referred to the original
>> exporter announcement. I'm sorry that my questions are so basic, but I
>> put off switching to 8.0 because my understanding of how org and Emacs
>> work is not very deep and I know little elisp. Once I have things set
>> up, I leave them alone and get to work. I'm very grateful to this list
>> for helping me figure out things that, in hindsight, are obvious.
> 
> No problem, and I wouldn't say it was *that* obvious :) I found this
> document extremely helpful:
> - http://orgmode.org/worg/org-8.0.html
> 
> I also started (and should really update again/maintain!) this as a
> landing place for documenting other things as they come up:
> - http://orgmode.org/worg/exporters/ox-overview.html
> 
> And have a blog post walking through setting things up here, if it helps:
> - 
> http://jwhendy.blogspot.com/2013/03/migrating-to-new-org-mode-exporter-org.html

Thanks for these links. I have been to the org-8.0.html page before, but
I only read part of it. If I would just read through all these nice
pages, then there would be no problem setting things up. But my approach
to Emacs and org is rather haphazard --- I pick up those things I need
and ignore all the rest. My init.el file is a sorry mess. One of these
days I'll go through everything methodically.

> 
> 
> Good luck! We're all learning here, so no worries on the mailing list.
> More things for Google to index for users stumbling on this after you!

Yes, this list is great. I've asked simple questions on other lists and
received nasty RTFM responses.

> 
> 
> John
> 
>>
>> Scott Randby
> 

Re: [O] RFQ - new contribution - org-screenshot.el

[Feng Shu]

Haider Rizvi  writes:

> Max Mikhanosha  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. Here is a
> piece of code that was published earlier with a sample use.

It's a good idea, "import" has nearly same feature as "scrot" and should
work with  org-screenshot ,it is included imagemagick

https://wiki.archlinux.org/index.php/Taking_a_Screenshot


>
> 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, 

-- 

Re: [O] [patch] ox-koma-letter.el: subject changes [2/4]

[Viktor Rosenfeld]

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] GFDL

[Bastien]

"Sebastien Vauban" 
writes:

> FMI, why is GNU GPL not applicable to the manual?

Because the manual is part of GNU Emacs, which is part of the GNU
project, and every project in the GNU project is required to publish
manuals in GNU FDL only.  Dual licensing is not an option here.

There are many discussions about this... a can of (dead) worms.

-- 
 Bastien

Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting

[Bastien]

Hi Sébastien and John,

"Sebastien Vauban" 
writes:

> I did not have time yet to bisect the problem, but it _seems_ to be a newly
> introduced feature.

Can you check if the problems persist *before* this commit?

http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=b83c03

-- 
 Bastien

[O] [OT] Contributors to org.texi (was: GFDL)

[Memnon Anon]

"Sebastien Vauban" 
writes:

> Bastien wrote:
>> Well, relicensing the Org compact guide under GNU GPL is definitely
>> feasible, but relicensing the Org manual is (sadly) not.  Let's take
>> the feasible step first?
>
> FMI, why is GNU GPL not applicable to the manual?

Hehe, on an unrelated side note, that made me curious: 
Who did actually end up in org.texi, and how would I start to find out?

0. $ git blame -C -C -M -e org.texi > ~/git-blame.txt
   (I searched the web for that ;)
1. We are only interested in the email addresses, so quick clean up with
   a keyboard macro.
2. Get rid of duplicates: 
   M-x sort-lines
   C-x h 
   M-x shell-command-on-region 
   uniq

And... I see 67 different addresses. Some clearly belong to one person,
so getting rid of the obvious ones my count goes down to ... 58?

Wow... 
Fun.

Back to work :)

Memon

Re: [O] RFQ - new contribution - org-screenshot.el

[François Pinard]

Feng Shu  writes:
> Haider Rizvi  writes:
>> Max Mikhanosha  writes:
>>> "scrot"
>> screencapture
> "import" (imagemagick)

> https://wiki.archlinux.org/index.php/Taking_a_Screenshot
>> http://thread.gmane.org/gmane.emacs.orgmode/69221/focus=69272

Thanks for these links! :-)

François

Re: [O] [patch] ox-koma-letter.el: credit [3/4]

[Viktor Rosenfeld]

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" 
> 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 "h

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Viktor Rosenfeld]

Hi, 

Rasmus wrote:

> Alan Schmitt  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]

[Viktor Rosenfeld]

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] [patch] ox-koma-letter.el: credit [3/4]

[Rasmus]

Viktor,

Good to hear from you!

>> 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.

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.

Perhaps I had loaded some magic in Emacs when I tested it that wasn't
preserved in the patch.  I'll test it again ASAP.
  
> - The function `org-koma-letter--get-tagged-content' does not use the
>   `info' argument. Also, the function is not documented.

No it doesn't use info.  I guess it's just for consistency.  It's more
or less taken from ox-groff.  I don't mind removing it.

> - The second argument of `org-koma-letter-headline' is misspelled
>   (`conents').

Thanks!

> - 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.


>> 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.

What do you think?

Thanks for your comments.
–Rasmus

-- 
The Kids call him Billy the Saint

Re: [O] RFQ - new contribution - org-screenshot.el

[Viktor Rosenfeld]

Hi,

Haider Rizvi wrote:

> Max Mikhanosha  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

[Viktor Rosenfeld]

Forgot to attach the patch in my last mail.

Sorry about the double posting.

Viktor Rosenfeld wrote:

> Hi,
> 
> Haider Rizvi wrote:
> 
> > Max Mikhanosha  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 
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] [patch] ox-koma-letter.el: subject changes [2/4]

[Rasmus]

Viktor Rosenfeld  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}'.

Thanks, that's a bug.  I'll look into it ASAP. 

> 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}{.}').


Perhaps the  ox-latex.el way is the way to go:
#+TITLE: # i.e. nothing
The difference would be that here would have not to format subject
komavar at all.

> Is this the entended behaviour? I'll try to post a patch for this
> later tonight.

Yeah, let's think about it.  From my point of view, basically never
using LCO files, I think 
  1. it should be possible to not post a subject.  I tried to implement
 this via #+OPTIONS: subject:nil.
  2. But perhaps I'm trying to be too clever.  I might have defined
 komavar-subject in an LCO file, but still changing subject
 formating on the go.  This is not possible.
  3. If letting subject be disabled by an empty title 2. won't break
 it.  So how about the condition (pseudo lisp):
 (or (title is nil) (subject is nil))?

It should be pretty simple to get to that state I think.

> 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. 

OK, perhaps there's a clever way to get it to accept several keywords
without a parenthese.  I'm not sure.

> 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).

That should be possible.  I thought I'd tested it.  Note though, that
giving a single value overwrites the default.  I'm not sure whether it
should extend upon the default.

Cheers,
Rasmus

-- 
C is for Cookie

[O] org-export-html-date-format-string

[Scott Randby]

I'm having trouble customizing the variable
org-export-html-date-format-string. Before I tried to customize it, I
would get the date in the postamble when I exported to html:

  Created: 2013-05-21 Tue 12:44

The original string for the variable is: %Y-%m-%dT%R%z

I don't want this string, so I changed it to %F%T%Z which didn't give
any date when I exported. So I changed the string to %Y-%m-%d and still
had no date after export. Changing back to the default string doesn't
work either.

This seems like a bug. Here is what is in my init.el after customization:

 '(org-export-html-date-format-string "%Y-%m-%dT%R%z")

 '(org-html-postamble t)

 '(org-html-postamble-format (quote (("en" "Author:
%a  Date: %d %c"

Here is the html of the postamble after export:

  
  Author: Scott P. Randby 
  Date: 
  http://www.gnu.org/software/emacs/";>Emacs 24.2.1 (http://orgmode.org";>Org mode 8.0.3)
  

How do I get the date variable to work?

Scott Randby

Re: [O] Let's discuss citation and Org syntax

[Viktor Rosenfeld]

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

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Rasmus]

Viktor Rosenfeld  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.
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?
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. . .
4. Revert the path.

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.

> 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.

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?

–Rasmus

--
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .

[O] Org sources and PDF files on Worg

[Viktor Rosenfeld]

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] Let's discuss citation and Org syntax

[Rasmus]

Viktor Rosenfeld  writes:

>> 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 

I tried to summarize it the second post since the thread was very
long.

> But I was wondering if bibliography support in the LaTeX exporter
> would be BibTex-only or if it would also support biblatex, for
> example.

Currently, you can use both through the link syntax, but it's not so
nice if you use prenote and postnotes.

I solely use biber + biblatex these days.

–Rasmus

-- 
This space left intentionally blank

Re: [O] org-export-html-date-format-string

[Scott Randby]

I solved the problem by putting the following in the file to be exported:

#+DATE: [2013-05-21 Tue 14:45]

However, this means I have to remember to change the date every time I
export. Is there an easier way to do this?

Scott Randby

On 05/21/2013 01:49 PM, Scott Randby wrote:
> I'm having trouble customizing the variable
> org-export-html-date-format-string. Before I tried to customize it, I
> would get the date in the postamble when I exported to html:
> 
>   Created: 2013-05-21 Tue 12:44
> 
> The original string for the variable is: %Y-%m-%dT%R%z
> 
> I don't want this string, so I changed it to %F%T%Z which didn't give
> any date when I exported. So I changed the string to %Y-%m-%d and still
> had no date after export. Changing back to the default string doesn't
> work either.
> 
> This seems like a bug. Here is what is in my init.el after customization:
> 
>  '(org-export-html-date-format-string "%Y-%m-%dT%R%z")
> 
>  '(org-html-postamble t)
> 
>  '(org-html-postamble-format (quote (("en" "Author:
> %a  Date: %d %c"
> 
> Here is the html of the postamble after export:
> 
>   
>   Author: Scott P. Randby 
>   Date: 
>  href="http://www.gnu.org/software/emacs/";>Emacs 24.2.1 (   href="http://orgmode.org";>Org mode 8.0.3)
>   
> 
> How do I get the date variable to work?
> 
> Scott Randby
> 

Re: [O] org-export-html-date-format-string

[Nicolas Goaziou]

Hello,

Scott Randby  writes:

> I'm having trouble customizing the variable
> org-export-html-date-format-string.

Use `org-html-metadata-timestamp-format' instead.


Regards,

-- 
Nicolas Goaziou

Re: [O] TOC in HTML export - how to change formatting of ToDo levels?

[David Rogoff]

> You should be able to customize the todo class only within the TOC context
> with such a rule:
> 
> --8<---cut here---start->8---
> #table-of-contents .todo {
> ...
> }
> --8<---cut here---end--->8---
> 
> Best regards,
>   Seb


Thanks for the info.  This will help a bit but still doesn't address the TOC 
code throwing out the actual ToDo states of the headlines and making everything 
either .todo or .done.

 David

Re: [O] org-export-html-date-format-string

[Scott Randby]

On 05/21/2013 02:55 PM, Nicolas Goaziou wrote:
> Hello,
> 
> Scott Randby  writes:
> 
>> I'm having trouble customizing the variable
>> org-export-html-date-format-string.
> 
> Use `org-html-metadata-timestamp-format' instead.

Thanks. This worked after I replaced %d with %T in the format string for
org-html-postamble-format.

> 
> 
> Regards,
> 

Re: [O] [patch] ox-koma-letter.el: clean-up/semantic bug [4/4]

[Viktor Rosenfeld]

Hi,

Rasmus wrote:

> Viktor Rosenfeld  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. . .
> 

[O] org-plus-contrib elpa and ox-* files

[Seth Mason]

Back in the beginning  of May I pointed out what I thought was a bug
in server.mk that prevented the ox-* files in contrib from getting
included in the Org ELPA archives. It got fixed in
6de09e2d3e38ac84a09659931ee96dff5e5d68c9 (thanks Achim!).

I just installed org-plus-contrib-20130520.tar from Org ELPA but the
ox-* files still aren't there.  Maybe I was wrong about the source of
the issue? Or is there a delay between what hits master and what gets
to the Org ELPA archves?

Thanks in advance,

Re: [O] [patch] ox-koma-letter.el: credit [3/4]

[Viktor Rosenfeld]

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] performance of exporting large tables

[D M German]

 Nicolas Goaziou twisted the bytes to say:


 Nicolas> Nicolas Goaziou  writes:
 >> I am going to have a look at this.

 Nicolas> I pushed a commit caching the results of some table functions. Export 
of
 Nicolas> large tables should be a lot faster (I get 6 s now; it was 90 s 
before).

Hi Nicolas,

thank you very much. This has resolved my issue. I can now export an org file
with these tables in few seconds.

thank you,

--daniel


 Nicolas> Regards,

 Nicolas> -- 
 Nicolas> Nicolas Goaziou


--
Daniel M. German  "To read is to travel without all the hassles 
of luggage."
   Emilio Salgari
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

 

Re: [O] Let's discuss citation and Org syntax

[Marcin Borkowski]

Dnia 2013-05-21, o godz. 19:55:53
Viktor Rosenfeld  napisał(a):

> 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.

Good point.

I do not use Org-mode for authoring (I'm quite happy with LaTeX itself
for that), and in LaTeX, I use neither bibtex nor biblatex; but AFAIK,
bibtex is basically dead like John Cleese's parrot.  I don't even think
that it needs to or should be supported; the faster bibtex usage fades
away, the better.

What I would suggest is to look into amsrefs manual.  The amsrefs
package was (is?) an interesting attempt at a /pure LaTeX/ solution to
the bibliography problem, not dependent on any executable other than
LaTeX.  It is not capable of sorting bibliographies, but other than
that is quite powerful (much more than bibtex, though seemingly less
than biblatex).  What is interesting here is its \ycite and \ocite
commands (see
http://mirrors.ctan.org/macros/latex/contrib/amsrefs/amsrdoc.pdf); it
might be a good idea to support something similar.  (I'm not sure
whether biblatex supports such a thing.)

> Cheers,
> Viktor

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] Org sources and PDF files on Worg

[Jay Kerns]

Hello Viktor,

On Tue, May 21, 2013 at 2:13 PM, Viktor Rosenfeld  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.

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: clean-up/semantic bug [4/4]

[Rasmus]

Viktor Rosenfeld  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.


> 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? 

only through #+LATEX: \input{.} I guess (or something similar).

> 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?)

–Rasmus

-- 
Dung makes an excellent fertilizer>From 92b07bac2d707f01e48796778453b67a9ecd1daa Mon Sep 17 00:00:00 2001
From: "rasmus.pank" 
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-tags-after-closing)
   "Header tags with special meaning")
 
-(defvar org-koma-letter-special-content nil "holds special
+(defvar org-koma-letter-special-contents nil "holds special
 content temporarily.")
 
 
@@ -203,10 +207,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 user-full-name t)
+(:sender "AUTHOR" nil org-koma-letter-author)
 (:from-address "FROM_ADDRESS" nil org-koma-letter-from-address newline)
 (:phone-number "PHONE_NUMBER" nil org-koma-letter-phone-number)
-(:email "EMAIL" nil user-mail-address t)
+(:email "EMAIL" nil org-koma-letter-email)
 (:to-address "TO_ADDRESS" nil nil newline)
 (:place "PLACE" nil org-koma-letter-place)
 (:opening "OPENING" nil org-koma-letter-opening)
@@ -275,29 +279,31 @@ channel."
 ;; Thanks, Luis!
 
 (defun org-koma-letter--get-tagged-content  (tag info)
-  (cdr  (assoc tag org-koma-letter-special-content)))
+  (cdr  (assoc tag org-koma-letter-special-contents)))
 
 
-(defun org-koma-letter-headline (headline conents info)
+(defun org-koma-letter-headline (headline contents info)
   "Transcode a HEADLINE element from Org to LaTeX.
 CONTENTS holds the contents of the headline.  INFO is a plist
 holding contextual informatio.n
 
 Note that if a headline is tagged with a tag from
 `org-koma-letter-special-tags' it will not be exported, but
-stored in `org-koma-letter-special-content' and included at the
+stored in `org-koma-letter-special-contents' and included at the
 appropriate place."
   (let*
   ((tags (and (plist-get info :with-tags)
 		 (org-export-get-tags headline info
-(if (member (car tags) org-koma-letter-special-tags)
-	(cond ((member (car tags) '("PS" "ps"))
-	   (progn
-		 (push (cons (car tags) (concat (plist-get info :ps-pre

Re: [O] Let's discuss citation and Org syntax

[Christian Wittern]

Hi Rasmus,

On 2013-05-21 21:21, Rasmus wrote:

Now that 8.0 has shipped let's talk bibliography support.  This
follows directly upon the discussion around March[1].
Thanks for a great post and for taken initiative for making org-mode even 
better for my purposes.  I started using org for writing papers a few years 
ago and I am not looking back.  The weak point however is bibliographies, as 
you say.


FWIW, I will describe my use case.  For drafting and when I can get away 
with it, I am going from org to PDF through XeLaTex, with either bibtex or 
more recently biber+biblatex.  However, when I submit papers, in most cases 
they have to be in a wordprocessor format, so I am going through the ODT 
export here.   In my current workflow this means that the bibliographie 
falls apart and in the end (deadlines!!) I usually cut and paste what I can 
get into either HTML or PDF.  This is not ideal and if this can improve it 
would mean a lot to me.


One problem I have had with bibtex and which I am now kind of dealing with 
(albeit still in a hackish way) in biber+biblatex is that I need specific 
formatting of the entries depending on the language I am publishing in, 
which is mostly either English or Japanese.  So for Japanese sources cited 
in English papers, I have to give the author and title optionally in 
Japanese characters, but also in romanized form and possibly in translation, 
whereas English sources in Japanese might require a Japanese form of the 
names and again a translation into Japanese.   I ended up adding extra 
fields to my bibtex file, since no bibliographic format I know of (except 
TEI) would support this and still allow me to integrate it into my workflow, 
but the big problem lies of course in integrating this better in my workflow.


So whatever org ends up with having in terms of bibliography, I would like 
to work with you and however jumps in to make sure that it also fits this 
need (which is actually not limited to an exotic field like mine, but is 
quite common for academics working in East Asia).


All the best,

Christian

--
Christian Wittern, Kyoto

Re: [O] GFDL

[Carsten Dominik]

On 21.5.2013, at 17:03, François Pinard  wrote:

> Carsten Dominik  writes:
> 
>> I am curious, what passage does make such restrictions possible, and
>> which kinds of restrictions?
> 
> Oh, I did not read the GFDL in quite a years, and really have no
> interest in diving and scrutinizing it again :-).  

OK, I will not ask again. :)

> More away I am from
> all this, better I feel :-).  Sorry, just forget I've written this
> morning, I was likely in some strange mood.
> 
> I do love the FSF idea and theory, and supported the GNU project in an
> intense way for maybe more than twenty years.  But by now, in practice,
> I just cannot stand their slightest abuse, anymore.  I'm all for
> programming freedom, but this ought to include programmer freedom too!
> 
> François
> 

Re: [O] Let's discuss citation and Org syntax

[Erik Hetzner]

At Tue, 21 May 2013 19:55:53 +0200,
Viktor Rosenfeld wrote:
> 
> 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.

And to further confuse the issue, why not consider pandoc style
citations [1]?

This works right now. Create an org file:

  See [@citekey, p. 10] for more info.

(assuming a bibtex, endnote, ris, ... file that contains a cite with
key “citekey”). Export to markdown. Process in pandoc, either to
latex:

  ❤ pandoc --natbib test.md -t latex -s --biblio test.bib

or to HTML, etc:

  ❤ pandoc test.md -s --biblio test.bib

While it would be nice to make this work natively with org, especially
with latex output, it would be great if compatibility with pandoc
could be obtained.

best, Erik

1. http://johnmacfarlane.net/pandoc/README.html#citation-rendering
Sent from my free software system .

[O] Trigger org-capture window using linux shortcut key

[Jackin]

Hi,

  I am wondering if it is possible to start a org-capture window
(when not within emacs) using a shortcut key. Org-protocol allows this
to be done from a web browser or adobe reader which is very useful. But
I am thinking of a more general solution, for triggering a org-capture
window from any where in Linux -> type in something and -> C-c c-c.

 Any ideas or solutions? Thanks in advance.

-jackin

Re: [O] org-plus-contrib elpa and ox-* files

[Bastien]

Hi Seth,

Seth Mason  writes:

> Back in the beginning  of May I pointed out what I thought was a bug
> in server.mk that prevented the ox-* files in contrib from getting
> included in the Org ELPA archives. It got fixed in
> 6de09e2d3e38ac84a09659931ee96dff5e5d68c9 (thanks Achim!).
>
> I just installed org-plus-contrib-20130520.tar from Org ELPA but the
> ox-* files still aren't there.  Maybe I was wrong about the source of
> the issue? Or is there a delay between what hits master and what gets
> to the Org ELPA archves?

I just modified the local.mk file on the server, taking Achim's change
in server.mk into account.  ELPA and ELPAPLUS should now contain ox-*
files -- thanks for the heads up!

-- 
 Bastien