<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode">
    <title>gmane.emacs.orgmode</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72692"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72691"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72690"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72689"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72688"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72687"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72686"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72685"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72684"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72683"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72682"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72681"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72680"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72679"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72678"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72677"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72676"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72675"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72674"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.emacs.orgmode/72673"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72692">
    <title>Re: [OT] Gnus mail tutorial?</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72692</link>
    <description>&lt;pre&gt;

Yes. They say it's better these days.  Whether it's true I don't know.
I use dovecot.

For the record, this is what I use:

(setq rasmus/imap-method
        `(nnimap "mail"
                 (nnimap-stream shell)
                 (nnimap-shell-program "MAIL=maildir:$HOME/mail /usr/lib/dovecot/imap")))
(setq gnus-select-method '(nnml ""))  ;; good for offline
(add-to-list 'gnus-secondary-select-methods rasmus/imap-method)
(add-to-list 'gnus-secondary-select-methods
             '(nntp "gmane"
                    (nntp-address "news.gmane.org")))
(add-to-list 'gnus-secondary-select-methods
             '(nntp "gwene"
                    (nntp-address "news.gwene.org")))


In my dovecot.conf (v2+) I have the following; I don't know if it's
important.

mail_location = maildir:~/mail:LAYOUT=fs

passdb {driver = pam}
ssl = no
userdb {driver = passwd}


–Rasmus

&lt;/pre&gt;</description>
    <dc:creator>Rasmus</dc:creator>
    <dc:date>2013-05-25T22:24:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72691">
    <title>Re: [PATCH] ox-koma-letter.el: Reintroduce variables removed incommit 832c6fd with proper defaults</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72691</link>
    <description>&lt;pre&gt;Hi Robert,


I see.  It could be done but it could be kind of inconvenient, I
guess, since currently #+AUTHOR and the default org-koma-letter-author
share the same variable name during export.  You can always disable it
with empty values, although a bit of a hassle (e.g. "#+AUTHOR:\n").

If my memory serves me correctly Viktor decided the order of LCO
values versus file values carefully so he'll have a better idea about
this.

That being said, I can think of two ways to do it. 
 1. use something like
   `org-koma-letter--prepare-special-contents-as-macro' and make an
   ordering dependent on a list like with
   org-koma-letter-special-tags-after-closing.
 2. Test whether a particular value is equal to the default.  But it
    seems like something that could easily go wrong. . .

–Rasmus

&lt;/pre&gt;</description>
    <dc:creator>Rasmus</dc:creator>
    <dc:date>2013-05-25T21:41:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72690">
    <title>Re: Archive scheduled (done) items to date-tree wrt scheduleddate</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72690</link>
    <description>&lt;pre&gt;Hi Olivier, org-mode users and -developoers,
* Olivier Berger &amp;lt;oberger&amp;lt; at &amp;gt;ouvaton.org&amp;gt; [25. May. 2013]:

Is it possible to refile to a date tree?  This would be very
helpful.

Ciao; Gregor


&lt;/pre&gt;</description>
    <dc:creator>Gregor Zattler</dc:creator>
    <dc:date>2013-05-25T21:32:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72689">
    <title>Re: [PATCH][ox-koma-letter]: sender, email and cleanup</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72689</link>
    <description>&lt;pre&gt;


This patch makes the subject option "easier" although still relying on
a list for multiple options (see the description in the patch).  The
default is t corresponding to do nothing but print komavar subject.

I haven't found any bugs but please test it (along with other patches)
if time permits.

A potential problem is that subject default to the file name and can
only be disabled with the option subject:nil.  The file name to title
convention is bad in ox-latex.el and I think it's if anything worse
here.  I'd like to make it nil by default.  What do you guys think?
  
–Rasmus

PS: Perhaps it would it be beneficial to make some test-letter
displaying the different scenarios in which we use ox-koma-letter?  To
make sure that stuff doesn't get broken.

--
May the Force be with you
&lt;/pre&gt;</description>
    <dc:creator>Rasmus</dc:creator>
    <dc:date>2013-05-25T21:27:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72688">
    <title>Re: Archive scheduled (done) items to date-tree wrt scheduleddate - Was: Was: Re: Can I set achive or refile target to date-tree?</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72688</link>
    <description>&lt;pre&gt;Hi.

Olivier Berger &amp;lt;oberger&amp;lt; at &amp;gt;ouvaton.org&amp;gt; writes:


Responding to myself : there's now a ::datetree/ option for
org-archive-location which renders the org-archive-subtree-defadvice.el
"hack" useless.

More details in http://orgmode.org/worg/doc.html#org-archive-location

May I suggest to remove the hack from
http://orgmode.org/worg/org-hacks.html#sec-1-7-2 too, then ?

Hope this helps.

Best regards,
&lt;/pre&gt;</description>
    <dc:creator>Olivier Berger</dc:creator>
    <dc:date>2013-05-25T21:07:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72687">
    <title>Re: [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72687</link>
    <description>&lt;pre&gt;Hello,
On 05/25/2013 03:57 PM, Rasmus wrote:

hmm, sorry, I did not express myself in a good way.

what I meant is, if #+AUTHOR defaults to (user-full-name), could the
\setkomavar commands be placed /before/ \LoadLetterOption in the TeX
file,  and after \LoadLetterOptions if #+AUTHOR is set in the .org file?

So you'd still get only one set of \setkomavar in the TeX file, but get
a (for me) more useful order of #+AUTHOR != (user-full-name) &amp;gt; #+LCO &amp;gt;
#+AUTHOR == (user-full-name)


Best regards
Robert



&lt;/pre&gt;</description>
    <dc:creator>Robert Klein</dc:creator>
    <dc:date>2013-05-25T20:51:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72686">
    <title>Re: Minor problems with dvipng latex image preview</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72686</link>
    <description>&lt;pre&gt;


I'm not sure there is a really good reason to drop it. Is it inferior in
some way?

Also, imagemagick is not optimal either. Since it uses
`org-latex-pdf-process', "pdflatex" is called three times by default,
which is unnecessary for a short snippet.

So, both dvipng and imagemagick should have a variable to set the
program to call, along with its arguments.


A worg page can't hurt, but a URL in the docstring is not very handy
either. It also defeats the "self-documenting" part of Emacs.


Some parts of Org already have their own debug variable (see
`org-export-async-debug'). A meta debug variable would not be optimal,
would it?


Regards,

&lt;/pre&gt;</description>
    <dc:creator>Nicolas Goaziou</dc:creator>
    <dc:date>2013-05-25T20:20:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72685">
    <title>Re: org-export, table.el complex tables, latex html</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72685</link>
    <description>&lt;pre&gt;

It doesn't seem to.


Regards,

&lt;/pre&gt;</description>
    <dc:creator>Nicolas Goaziou</dc:creator>
    <dc:date>2013-05-25T20:09:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72684">
    <title>Archive scheduled (done) items to date-tree wrt scheduled date- Was: Was: Re: Can I set achive or refile target to date-tree?</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72684</link>
    <description>&lt;pre&gt;Hi.

I found the org-archive-subtree-defadvice.el quite useful, but I'd like
to be able to archive DONE items not to today's date in a date-tree
archive file, but instead to their scheduled date.

Thus, it reconstructs a journal of done things, and not a journal of my
archiving activity.

Anyone with a suggestion ?

Thanks in advance.

Best regards,

Osamu OKANO &amp;lt;okano.osamu&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:


&lt;/pre&gt;</description>
    <dc:creator>Olivier Berger</dc:creator>
    <dc:date>2013-05-25T19:34:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72683">
    <title>Problem with org-insert-heading on multi-line items?</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72683</link>
    <description>&lt;pre&gt;Hi folks,

I'm using Org 8.0.3 and Emacs 24.3.1.

I noticed with interest this note in the Org 8.0 release notes:

"When a list item has a checkbox, inserting a new item uses a checkbox
too."

I'm finding, however, that Org will in many cases insert a new
checkbox even if the current item has none. Specifically, invoking
org-insert-heading on the second or subsequent lines of a multi-line item
will create a new checkbox item every time, whether the current
item has a checkbox or not. To illustrate:

1. org-insert-heading invoked here creates a new plain item
2. org-insert-heading invoked on this second item does the same
3. However, org-insert-heading, invoked on the SECOND line of this
    creates a following checkbox item:
4. [ ]

However, invoking org-insert-heading on the first line of a multi-line
item creates new items of the correct type, checkbox or not. So it
seems like the first line is determinative.

May I ask if anybody else is seeing this behavior? Is it as designed?

Regards,
Tom Davey

--
Tom&lt;/pre&gt;</description>
    <dc:creator>Tom Davey</dc:creator>
    <dc:date>2013-05-25T18:53:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72682">
    <title>Xemacs 21.5.32 and org-8.03, compilation problems</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72682</link>
    <description>&lt;pre&gt;Hello

I know that compiling  org under Xemacs is delicate. I succeeded with
7.8.3 but it seems that the installation process has changed quite a
      bit.

I edit the relevant 

default.mk
file (OK I should not do that but create local.mk)

EMACS=/usr/local/bin/xemacs
BATCH = $(EMACS) -batch -vanilla # Xemacs

Now when running make  the following problems showed up:

    - in almost all files the message:
      Symbol's value as variable
      is void: org-babel-temp-file

      Popped up

    -  in org-footnote
** The following functions are not known to be defined:
    org-in-commented-line, org-in-indented-comment-line,
    org-inside-LaTeX-fragment-p, org-in-verbatim-emphasis,
    org-in-block-p, org-in-regexp, org-inside-latex-macro-p, org-trim,
    org-mark-ring-push, org-show-context, org-id-uuid,
    org-icompleting-read, org-back-over-empty-lines,
    org-fill-paragraph, org-end-of-subtree, outline-next-heading


    -  org-list has similar complains, which I don't want to
       mention here

   &lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-25T18:17:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72681">
    <title>Re: org-export, table.el complex tables, latex html</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72681</link>
    <description>&lt;pre&gt;
   &amp;gt; Hello,
   &amp;gt; Uwe Brauer &amp;lt;oub&amp;lt; at &amp;gt;mat.ucm.es&amp;gt; writes:

   &amp;gt;&amp;gt; 
   &amp;gt;&amp;gt; Org version 7.8.03 with Emacs version 21

   &amp;gt; You need to update Org. I cannot reproduce the problem on Org 8.0.3.

Ok, I try.
What's about orgtbl-to-latex does this work for you also?

Uwe Brauer



&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-25T17:55:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72680">
    <title>[PATCH][ox-koma-letter]: sender,email and cleanup (was: [PATCH] ox-koma-letter.el: Reintroducevariables removed in commit 832c6fd with proper defaults)</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72680</link>
    <description>&lt;pre&gt;
Dear Viktor and Alan,


I tried to figure it out.  For some reason it kept resetting my name
to "".


My apology.  It should inform me when something is supposed to be
attached but isn't.  I've attached them this time so if they are not
here now something funky is going on that I'm not in control of. 

Attached are three patches that goes on top of Viktor's latest patch
(I've also attached it here since I rebased stuff and might have
changed it by accident).

  1. Viktor's latest patch.
  2. The patch describe above that gets user name and email and works
     on my system. . .
  3. Cleaning up special-tags functions introduced in
     ec108f4c3507ed546a564a48b7379355a65aa9f4.  It works a lot better
     now and some of the mess in the template is moved to other
     functions.
  4. Sets defcustom org-koma-letter-signature nil since that
     corresponds to default scrlttr2 behavior anyway (p. 183 in the
     manual).  

Re 4.: I'd like to do something similar to
org-koma-letter-subject-format.  But I'm not&lt;/pre&gt;</description>
    <dc:creator>Rasmus</dc:creator>
    <dc:date>2013-05-25T17:48:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72679">
    <title>Re: org-export, table.el complex tables, latex html</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72679</link>
    <description>&lt;pre&gt;Hello,

Uwe Brauer &amp;lt;oub&amp;lt; at &amp;gt;mat.ucm.es&amp;gt; writes:


You need to update Org. I cannot reproduce the problem on Org 8.0.3.


Regards,

&lt;/pre&gt;</description>
    <dc:creator>Nicolas Goaziou</dc:creator>
    <dc:date>2013-05-25T17:25:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72678">
    <title>org-export, table.el complex tables, latex html</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72678</link>
    <description>&lt;pre&gt;

Hello

I have attached an org file which contains a complex table, which I
generated partially with table.el.

Now org-export can export this table *correctly* to latex, most likely
using (table-generate-source 'latex "table.latex" "Table"), however
org-export fails when exporting to html.

Could this export option also please be implemented.

Thanks 

Uwe Brauer 


&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-25T16:30:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72677">
    <title>table.el complex tables and orgtbl-to-latex</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72677</link>
    <description>&lt;pre&gt;
Hello 

As I described in a previous message, org-export can successfully export
complex table which I have partially generated (end edited) by table.el
into latex. 

However orgtbl-to-latex cannot not deal with such tables.


Given the successful org-export function could orgtbl-to-latex be
modified to include that feature?

thanks

Uwe Brauer 



&lt;/pre&gt;</description>
    <dc:creator>Uwe Brauer</dc:creator>
    <dc:date>2013-05-25T16:35:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72676">
    <title>Re: [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72676</link>
    <description>&lt;pre&gt;Hi Rasmus,

Rasmus wrote:


I agree that there should not be multiple instances of, e.g.,
\setkomavar{fromname} in the TeX file. I must have overlooked that bit
in the original mail.


I think so, yes.


Hmm, that's too bad. I tested it pretty thoroughly. Could you maybe
trace the contents of the variable by adding calls to message in various
places?
 

Did you send the patch? I did not receive it and it's not available on
gmane.

Cheers,
Viktor



&lt;/pre&gt;</description>
    <dc:creator>Viktor Rosenfeld</dc:creator>
    <dc:date>2013-05-25T17:03:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72675">
    <title>Re: format for clocktable</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72675</link>
    <description>&lt;pre&gt;Changing the value of org-time-clocksum-format was the trick!!
Thank you for the pointer.

Jean

Le 25 mai 2013 à 18:20, Jean Wallemacq &amp;lt;jean.wallemacq&amp;lt; at &amp;gt;skynet.be&amp;gt; a écrit :




&lt;/pre&gt;</description>
    <dc:creator>Jean Wallemacq</dc:creator>
    <dc:date>2013-05-25T16:35:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72674">
    <title>Re: format for clocktable</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72674</link>
    <description>&lt;pre&gt;value is nil
in the screen, something is mentioned about some default value having been changed with emacs 24.  My change to org 8.0.3 was made at the same time than an upgrade of emacs, so it may be linked to that.

Further help is welcome !

Jean

Le 25 mai 2013 à 17:50, Bastien &amp;lt;bzg&amp;lt; at &amp;gt;gnu.org&amp;gt; a écrit :




&lt;/pre&gt;</description>
    <dc:creator>Jean Wallemacq</dc:creator>
    <dc:date>2013-05-25T16:20:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72673">
    <title>Re: [PATCH] org.el: Don't flyspell check within source codeblocks</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72673</link>
    <description>&lt;pre&gt;Hi Trevor,

Trevor Murphy &amp;lt;trevor.m.murphy&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:


I think `org-in-src-block-p', while a bit less reliable, will be
faster, and reliable/fast enough for this use-case.

Let's see what others think/test.

Thanks,

&lt;/pre&gt;</description>
    <dc:creator>Bastien</dc:creator>
    <dc:date>2013-05-25T15:52:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.emacs.orgmode/72672">
    <title>Re: format for clocktable</title>
    <link>http://permalink.gmane.org/gmane.emacs.orgmode/72672</link>
    <description>&lt;pre&gt;Hi Jean,

Jean Wallemacq &amp;lt;jean.wallemacq&amp;lt; at &amp;gt;skynet.be&amp;gt; writes:


What is the value of `org-time-clocksum-use-effort-durations' for you?

C-h v org-time-clocksum-use-effort-durations RET

Thanks,

&lt;/pre&gt;</description>
    <dc:creator>Bastien</dc:creator>
    <dc:date>2013-05-25T15:50:45</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.emacs.orgmode">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.emacs.orgmode</link>
  </textinput>
</rdf:RDF>
