Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup

[Alan Schmitt]

Rasmus writes:

> Viktor,
>
>>>   1. Viktor's latest patch.
>>>   2. The patch describe above that gets user name and email and works
>>>  on my system. . .
>>
>> Your code works for me. From my point of view, the pros are that per
>> default `org-koma-letter-{author,sender}' pick up the values of
>> `user-full-name' and `user-mail-address' whenever they are changed.
>> That's very nice! The cons are that IHMO it's quite complicated for
>> setting something as simple as author and email and you mentioned a
>> possible crash which I did not test further. Could this be tested using
>> `functionp'? Still, I think we should stick with it for now.
>
> functionp seems better, yes.  I didn't know about it (doh!).  Thanks!
>
> While it is complicated I think it's OK given our desire to disable
> author and still have a similar default to ox-latex.el.  Also, it
> allows for arbitrary functions which could potentially determine the
> name based on the context of the letter (I don't know since it's
> already initialized in the options-alist).
>
> I'll let you and Alan decide.

I like this approach.

>> As a side note, I had quite a few problems working with your patches.
>> None of them applied against master, or against my latest patch as you
>> claimed. 
>
> Right.  I was working off of branch and I guess one reasons is that it
> was against the history of my previoues patches—of which not all was
> applied to the master, it seems (?).  I've now tried to rework the
> entire thing against the current master and produces simplified
> patches.  I tested them with git am and they work on my system.
>
> There are still things I don't understand such as why git wants to
> re-add the authors in patch 4 but I've spend way to much time on
> rebasing and understanding git already and my head hurts.  It seems to
> ignore it when using git am.
>
> Before applying the patches my git log says
>
> commit 847637f4bdacb861723438c1389f1a3bcdac48af
> Merge: 43cc5be 206762b
> Author: Nicolas Goaziou 
> Date:   Sat May 25 22:03:48 2013 +0200
>
> Merge branch 'maint'
>
> Patches:
>
> 1. summarizes all changes in author.  It uses my solution as mentioned above.
> 2. full support for after closing keywords.  See commit message
> 3. signature to nil
> 4. change handling of subject and allow for setting subject in
> OPTION-line.

I'm going to apply the patches. Thanks to both of you for the nice work!

Alan

Re: [O] emacs cygwin external link file+sys:

[Aaron Siegel]

On Sunday, May 26, 2013 05:31:41 PM Aaron Siegel wrote:
> Hello
> 
> I would like to use org-mode to manage my documents. I would like to be able
> to click on a like and have the document open in the operate program for
> the OS;  example a pdf file will open in Adobe Acrobat Reader in windows
> and Okular in my linux system.
> 
> I am trying to migrate to emacs bundle with cygwin in hopes I can create a
> configuration that is portable between the two systems.  I have been using
> the portableApplication emacs and it does work. I am able to click on a
> link and open a document in a Window's application.  Can I get this to work
> with the cygwin version?
> 
> Any recommendation on a emacs for Windows?

I installed the Windows binarys distrubied by the emacs project, it works 
everything.  I set the  enviromental variables ~ and HOME to point to my home 
directory where my .emacs files are stored.  

That was it. I spent months fighting with  PortableApps and the emacs bundle 
with cygwin.

[O] emacs cygwin external link file+sys:

[Aaron Siegel]

Hello

I would like to use org-mode to manage my documents. I would like to be able 
to click on a like and have the document open in the operate program for the 
OS;  example a pdf file will open in Adobe Acrobat Reader in windows and Okular 
in my linux system.

I am trying to migrate to emacs bundle with cygwin in hopes I can create a 
configuration that is portable between the two systems.  I have been using the 
portableApplication emacs and it does work. I am able to click on a link and 
open a document in a Window's application.  Can I get this to work with the 
cygwin version? 

Any recommendation on a emacs for Windows?

Re: [O] Build-System: Why not compile contrib

[Suvayu Ali]

On Sun, May 26, 2013 at 07:01:54PM +0200, Achim Gratz wrote:
> Stefan Nobis writes:
> >
> > The only unaethetic thing left is that now git sees all those files
> > from contrib/lisp copied to lisp as new untracked files (but that does
> > not bother me too much).
> 
> 
> Then get over it and install it someplace (even in …/install in the
> source directory, if you must), usingthe target "up2".

The OP could also set this:

  $ git config status.showuntrackedfiles no

-- 
Suvayu

Open source is the future. It sets us free.

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

[Rainer Stengele]

Am 23.05.2013 12:45, schrieb John Hendy:
> On Thu, May 23, 2013 at 5:16 AM, Michael Brand
>  wrote:
>> Hi Bastien
>>
>> On Thu, May 23, 2013 at 12:07 PM, Bastien  wrote:
>>> Does it make a difference whether the file has a #+setupfile
>>> directive or not?
>>
>> The issue disappears when I remove #+setupfile as I "expected". Sorry,
>> I forgot to mention that the
>> (when (search-forward "#+setupfile" nil t)
>> looked suspicious to me when I looked at the commit.
> 
> Confirmed: if I remove the setupfile line, everything seems alright.
> 
> John
> 
>>
>> Michael
>>
> 
> 
Bastien,

any chance to get that bug resolved? I did not upgrade org since the
commit introducing it.

Thanks,
Rainer

Re: [O] Compiling Org-mode from orgmode.org repository for an Emacs 24.3 at a nonstandard location

[Achim Gratz]

* writes:
> Should sitelispdir point to the location of "datadir" as well?

No.

> I mean: Do I need both of the following lines (or only the first one)
> in my .emacs file?
>
> (add-to-list 'load-path "/home/me/prefix/share/emacs/site-lisp/org")
> (add-to-list 'load-path "/home/me/prefix/emacs/etc/org")

None of the above.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] Compiling Org-mode from orgmode.org repository for an Emacs 24.3 at a nonstandard location

[*]

On 5/26/13, Achim Gratz  wrote:
> * writes:
>> Dear list...
>>
>> I've compiled Emacs 24.3 into this computer. During this process, I've
>> set the following variables:
>>
>> --with-x=no
>> --prefix=/home/me/prefix/emacs-24.3
>> bindir=/home/me/bin
>>
>> Beyond these customizations, I think everything else is default.
>> /home/me/bin/ is already in $PATH...
>>
>> I want to compile and install the Org-mode of orgmode.org's git
>> repository...
>>
>> After cloning and switching to maint branch, I'm setting the following
>> variables in local.mk generated by make config:
>>
>> EMACS   = emacs
>> prefix  = /home/me/prefix
>> lispdir= $(prefix)/emacs-24.3/share/emacs/24.3/lisp/org
>> datadir = $(prefix)/emacs-24.3/share/emacs/24.3/etc/org
>> infodir = $(prefix)/emacs-24.3/share/info
>
> Don't.  This would be trying to overwrite the files that come with
> Emacs.  It seems you are trying to set up a private "/usr/local" in
> "/home/me/prefix", so the canonical place to install Org into would be:
>
> prefix  := /home/me/prefix/share
> lispdir := $(prefix)/emacs/site-lisp/org
> datadir := $(prefix)/emacs/etc/org
>
> You need to check that sitelispdir for your Emacs points to that place
> as well.

Super! Thanks...

Should sitelispdir point to the location of "datadir" as well?

I mean: Do I need both of the following lines (or only the first one)
in my .emacs file?

(add-to-list 'load-path "/home/me/prefix/share/emacs/site-lisp/org")
(add-to-list 'load-path "/home/me/prefix/emacs/etc/org")

>> Once these changes to local.mk have been made, I'm planning to install
>> Org-mode by simply running "make install". In all, the command line
>> sequence for installing and compiling Org-mode would be like:
>>
>> git clone git://orgmode.org/org-mode.git
>> cd org-mode
>> git checkout maint
>> make config
>> emacs local.mk (make above changes...)
>
> make config-all
> make -n install
>
>> make install
>>
>> My questions are: For my Emacs set-up, are these local.mk settings
>> good? Does the command line sequence make sense?
>
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptation for Waldorf Blofeld V1.15B11:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>
>
>

Re: [O] Babel post-processing and export problem

[Sebastien Vauban]

Hello,

"Sebastien Vauban" wrote:
> I'm trying to post-process a LaTeX code block, so that the evaluated results
> gets framed on export.
>
> While almost working, my trials fail, because the results of the code block
> gets wrapped in a table:
>
> | \begin{mdframed} ||  |
> | \begin{itemize}  ||  |
> | \item| Item   | a|
> | \begin{itemize}  ||  |
> | \item| Deeper | item |
> | \end{itemize}||  |
> | \end{itemize}||  |
> | \end{mdframed}   ||  |
>
> Here an ECM demo'ing the problem:
>
> * Syntax
>
> #+name: frameit
> #+begin_src sh :var data="" :results output verbatim
> echo "\begin{mdframed}"
> echo "$data"
> echo "\end{mdframed}"
> #+end_src
>
> ** Post-process the results
>
> I want to display the results of *this LaTeX code's interpretation* inside a
> framebox, so that it clearly stands out from the rest of the document.
>
> #+name: latexcode
> #+begin_src latex :exports both :post frameit(data=*this*) :results verbatim
> \begin{itemize}
> \item Item a
> \begin{itemize}
> \item Deeper item
> \end{itemize}
> \end{itemize}
> #+end_src
>
> ** Results...
>
> #+results: latexcode
> #+BEGIN_LaTeX
> \begin{mdframed}
> \begin{itemize}
> \item Item a
> \begin{itemize}
> \item Deeper item
> \end{itemize}
> \end{itemize}
> \end{mdframed}
> #+END_LaTeX
>
> However, while the results in the Org buffer (here, just above) is correct,
> the one at the export time is not: it is "table'd".

For reasons which still totally escape me (in particular, because of this last
statement above), I've found the way to make the command work correctly:

  #+begin_src latex :exports both :post frameit[:results output](data=*this*) 
:results verbatim
   ^

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Christian Moe]

Darlan Cavalcante Moreira writes:

> I prefer the [cite:citekey] syntax similar to [fn:number] for footnotes.
>
> But no matter which syntax is chosen I think we can easily make reftex work
> with it. All we need is to set the variable reftex-cite-format [1] to a
> string with the desired format. For the syntax [cite:citekey] the string
> would be "[cite:%l]".

Yes, for bibtex. But to clarify, Matt Price and I got on the subject of
using Zotero as both the source database and the reference-formatting
engine for exported documents, with Org in the middle.

Reftex can be used for that as well, e.g. by synching the Zotero db to a
bibtex file with Zotero db keys as citekeys. There are other options,
with different pros and cons. (And I'll start a thread on that soon as
my day job stops interfering with my night life again.)

Yours,
Christian

Re: [O] [OT] Gnus mail tutorial?

[Steinar Bang]

> Richard Lawrence :

> I used Gnus with an IMAP account for a while, but found that (in
> addition to being intimidating and complicated) it was annoyingly slow.

FWIW nnimap was rewritten a couple of years back, and on an IMAP server
that supports QRESYNC (eg. dovecot), it is quite fast these days.

I also think, but I don't know for sure, that if you start up gnus
without any config, it will ask for a server.

And if you give nnimap as the method, and if you give the DNS name of
the server running the IMAP server, and if that server is running on
port 143, then things should more or less work.  All of the folders on
the IMAP server will appear as nnimap groups.

But I could be wrong...:-)

Re: [O] Compiling Org-mode from orgmode.org repository for an Emacs 24.3 at a nonstandard location

[Achim Gratz]

* writes:
> Dear list...
>
> I've compiled Emacs 24.3 into this computer. During this process, I've
> set the following variables:
>
> --with-x=no
> --prefix=/home/me/prefix/emacs-24.3
> bindir=/home/me/bin
>
> Beyond these customizations, I think everything else is default.
> /home/me/bin/ is already in $PATH...
>
> I want to compile and install the Org-mode of orgmode.org's git repository...
>
> After cloning and switching to maint branch, I'm setting the following
> variables in local.mk generated by make config:
>
> EMACS   = emacs
> prefix  = /home/me/prefix
> lispdir= $(prefix)/emacs-24.3/share/emacs/24.3/lisp/org
> datadir = $(prefix)/emacs-24.3/share/emacs/24.3/etc/org
> infodir = $(prefix)/emacs-24.3/share/info

Don't.  This would be trying to overwrite the files that come with
Emacs.  It seems you are trying to set up a private "/usr/local" in
"/home/me/prefix", so the canonical place to install Org into would be:

prefix  := /home/me/prefix/share
lispdir := $(prefix)/emacs/site-lisp/org
datadir := $(prefix)/emacs/etc/org

You need to check that sitelispdir for your Emacs points to that place
as well.

> Once these changes to local.mk have been made, I'm planning to install
> Org-mode by simply running "make install". In all, the command line
> sequence for installing and compiling Org-mode would be like:
>
> git clone git://orgmode.org/org-mode.git
> cd org-mode
> git checkout maint
> make config
> emacs local.mk (make above changes...)

make config-all
make -n install

> make install
>
> My questions are: For my Emacs set-up, are these local.mk settings
> good? Does the command line sequence make sense?



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Xemacs 21.5.32 and org-8.03, compilation problems

[Achim Gratz]

Uwe Brauer writes:
> 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.

No, not really.

> 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

Yes, you should not do this.  A configuration file for XEmacs is here:
http://orgmode.org/worg/dev/org-build-system.html#sec-4-1-4

> Now when running make  the following problems showed up:

You're not using the sources you think you are using.

> Did anybody sucessfully compile the latest org version under
> Xemacs 21.5.X?

No, despite repeated calls for help no feedback from actual XEmacs users
was registered and at some point I've stopped bugging Bastien about the
incompatibilities introduced.  There are at least a handful of functions
that'd need compatibility macros /defuns on XEmacs and I don't know what
turns up when these are out of the way, but the results were sketchy
already on 7.x whenever I tried.  Your best bet is running uncompiled
(which probably still needs compatibility definitions).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] Build-System: Why not compile contrib

[Achim Gratz]

Stefan Nobis writes:
> A little bit. I already know about ORG_ADD_CONTRIB, but I thought it
> would only be used by `make install' and I do not install org-mode, I
> use it directly from my local repository (running `make update' or
> `make up1' from time to time; org-mode/lisp and org-mode/contrib/lisp
> are both in my load-path).
>
> I dug a bit deeper into the Makefiles and now I realized that files
> defined by ORG_ADD_CONTRIB will be copied to the main lisp directory
> and then everything is compiled. Just removing org-mode/contrib/lisp
> from my load-path and only using org-mode/lisp is enough.
>
> The only unaethetic thing left is that now git sees all those files
> from contrib/lisp copied to lisp as new untracked files (but that does
> not bother me too much).


Then get over it and install it someplace (even in …/install in the
source directory, if you must), usingthe target "up2".

 
Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

[O] Compiling Org-mode from orgmode.org repository for an Emacs 24.3 at a nonstandard location

[*]

Dear list...

I've compiled Emacs 24.3 into this computer. During this process, I've
set the following variables:

--with-x=no
--prefix=/home/me/prefix/emacs-24.3
bindir=/home/me/bin

Beyond these customizations, I think everything else is default.
/home/me/bin/ is already in $PATH...

I want to compile and install the Org-mode of orgmode.org's git repository...

After cloning and switching to maint branch, I'm setting the following
variables in local.mk generated by make config:

EMACS   = emacs
prefix  = /home/me/prefix
lispdir= $(prefix)/emacs-24.3/share/emacs/24.3/lisp/org
datadir = $(prefix)/emacs-24.3/share/emacs/24.3/etc/org
infodir = $(prefix)/emacs-24.3/share/info

Once these changes to local.mk have been made, I'm planning to install
Org-mode by simply running "make install". In all, the command line
sequence for installing and compiling Org-mode would be like:

git clone git://orgmode.org/org-mode.git
cd org-mode
git checkout maint
make config
emacs local.mk (make above changes...)
make install

My questions are: For my Emacs set-up, are these local.mk settings
good? Does the command line sequence make sense?

Thanks!!!

Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup

[Rasmus]

> As a side note, I had quite a few problems working with your patches.
> None of them applied against master, or against my latest patch as you
> claimed. I had to merge in some of the changes of 0002 by hand. I
> suggest that we nail down the workings of AUTHOR and EMAIL first (should
> be done now) and then start with clean separate branches branched from
> master for your subject and heading code. We could even use github for
> this, what do you think?

. . . Also, a separate place/branch would allow for a common TODO file
to keep a record of what we discuss and more importantly what we've
concluded on subject X, Y, Z which otherwise might be forgotten.

It could also hold a working copy of Viktor's tutorial which then
could be updated more frequently.  Lot's of explanation (which is my
fault) is now hidden in the commit messages.

–Rasmus 

PS: What would be even better would be to keep the source and tutorial
in the same file encoring updating.  Of course, I'd want the
docstrings to be the main documentation still.

E.g. using Org-babel or "some-other-mechanism".  E.g. paredit
generates info automatically.

Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup

[Rasmus]

Viktor Rosenfeld  writes:

> I'm also not a big fan of the title defaulting to the filename. But I
> think it is a minor issue. What I think is quite useful is setting the
> subject to the headline of the exported subtree. Wouldn't we also lose
> this if subject is nil?

Without knowing the details wrt title: We can control for a special
case and call the vanilla title function otherwise.  How easy it is to
big up this special case?  I don't know.

–Rasnmus

-- 
Vote for proprietary math!

Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup

[Rasmus]

Viktor,

>>   1. Viktor's latest patch.
>>   2. The patch describe above that gets user name and email and works
>>  on my system. . .
>
> Your code works for me. From my point of view, the pros are that per
> default `org-koma-letter-{author,sender}' pick up the values of
> `user-full-name' and `user-mail-address' whenever they are changed.
> That's very nice! The cons are that IHMO it's quite complicated for
> setting something as simple as author and email and you mentioned a
> possible crash which I did not test further. Could this be tested using
> `functionp'? Still, I think we should stick with it for now.

functionp seems better, yes.  I didn't know about it (doh!).  Thanks!

While it is complicated I think it's OK given our desire to disable
author and still have a similar default to ox-latex.el.  Also, it
allows for arbitrary functions which could potentially determine the
name based on the context of the letter (I don't know since it's
already initialized in the options-alist).

I'll let you and Alan decide.

> As a side note, I had quite a few problems working with your patches.
> None of them applied against master, or against my latest patch as you
> claimed. 

Right.  I was working off of branch and I guess one reasons is that it
was against the history of my previoues patches—of which not all was
applied to the master, it seems (?).  I've now tried to rework the
entire thing against the current master and produces simplified
patches.  I tested them with git am and they work on my system.

There are still things I don't understand such as why git wants to
re-add the authors in patch 4 but I've spend way to much time on
rebasing and understanding git already and my head hurts.  It seems to
ignore it when using git am.

Before applying the patches my git log says

commit 847637f4bdacb861723438c1389f1a3bcdac48af
Merge: 43cc5be 206762b
Author: Nicolas Goaziou 
Date:   Sat May 25 22:03:48 2013 +0200

Merge branch 'maint'

Patches:

1. summarizes all changes in author.  It uses my solution as mentioned above.
2. full support for after closing keywords.  See commit message
3. signature to nil
4. change handling of subject and allow for setting subject in OPTION-line.


> I had to merge in some of the changes of 0002 by hand. I
> suggest that we nail down the workings of AUTHOR and EMAIL first (should
> be done now) and then start with clean separate branches branched from
> master for your subject and heading code.

>  We could even use github for this, what do you think?

Yeah, could be better.  It's way too hectic with all the patches and
keeping track of moving repos.  If you think it can ease the burden of
collaborating I'm all for it.

I tried to make a git repo retaining the history of ox-koma-letter.el,
but I ended up with a repo of 42mb even after applying all the
"garbage collection" tips the interweb had to offer. . .

I'm indifferent between bitbucket and github btw, but I'd prefer it
someone with more git skills would set it up.

-Rasmus

-- 
m-mm-mmm- bacon!
>From bd51fc02a1345cf1005d0137fc0888d301e1089b Mon Sep 17 00:00:00 2001
From: "rasmus.pank" 
Date: Sun, 26 May 2013 16:13:39 +0200
Subject: [PATCH 1/4] * ox-koma-letter.el (org-koma-letter-author): defaults to
 a function that returns =`user-full-name'= * ox-koma-letter.el
 (org-koma-letter-email): defaults to a function that returns
 =`user-mail-address'=

Setting the variables `org-koma-letter-author' and
`org-koma-letter-email' to the values of `user-full-name' and
`user-mail-address' respectively, allows the user to skip =#+AUTHOR:=
and =#+EMAIL:= lines when configuring a letter. However, if the user
wishes to set this information in LCO files, these variables need to
be set to nil.

With the old after-init-hook method my user name was always set to "".
Now org-koma-letter will (i) allow for default nil values (good if you
use LCO files); (ii) default to =`user-full-name'= and
=`user-mail-address'= like =ox-latex.el=.  These values are obtained
on-the-fly.

The two variables in question can also be strings or functions
returning strings.
---
 contrib/lisp/ox-koma-letter.el | 50 +-
 1 file changed, 45 insertions(+), 5 deletions(-)

diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 4318db1..7f50530 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -80,6 +80,30 @@
   :group 'org-export-koma-letter
   :type 'string)
 
+(defcustom org-koma-letter-author 'user-full-name
+  "The sender's name.
+
+This variable defaults to calling the function `user-full-name'
+which just returns the current `user-full-name'.  Alternatively a
+string, nil or a function may be given. Functions must return a
+string."
+  :group 'org-export-koma-letter
+  :type '(radio (function-item user-full-name)
+		(string)
+		(function)
+		(const nil)))
+
+(defcustom org-koma-letter-email 'org-koma-letter-email
+  "The sender's email address.
+
+This

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

[Darlan Cavalcante Moreira]

I prefer the [cite:citekey] syntax similar to [fn:number] for footnotes.

But no matter which syntax is chosen I think we can easily make reftex work
with it. All we need is to set the variable reftex-cite-format [1] to a
string with the desired format. For the syntax [cite:citekey] the string
would be "[cite:%l]".

[1] We probably need to make that a local variable in org-mode buffers so
that the global value is kept on default for latex buffers.

--
Darlan


At Thu, 23 May 2013 10:05:37 +0200,
Christian Moe wrote:
> 
> 
> Matt Price writes:
> > On Wed, May 22, 2013 at 5:02 AM, Christian Moe  
> > wrote:
> >>
> >> I have a rough, working example of this enabling Zotero cites for ODT
> >> export (attached).
> 
> > Hi Christian,
> >
> > I'm really interested in this, as I use Zotero not only for writing
> > but for group bibliographies in my  courses.  The broader conversation
> > about the appropriate syntax is a bit beyond me,
> 
> Hi, Matt,
> 
> As the org-zotero-export.el shows, getting Zotero references from Org
> into ODT is pretty simple. That framework could be implemented whatever
> syntax we end up with to take care of the details. I'm interested in
> feedback on the syntax, though -- that is, on the way I'm using the
> description part of the link to convey various bits of information to
> Zotero. Is it worth pursuing, or would people prefer other ways of
> doing it? If worth pursuing, could it be improved?
> 
> > (1) How do you get the Zotero cite keys right now, and what method do
> > you think would ultimately be the best to try for?
> 
> The best to try for: Something with as brilliant an interface as RefTex...
> 
> Since this thread is on citation syntax, I think I'll gather my thoughts
> about how to get there (zotero-plain? Zotero Server API? sqlite? word
> processor plugin emulation?), and about your other questions, and start
> another Zotero-related thread in a day or two.
> 
> Right now: I'm still depending on Quick Copy with a custom Zotero
> translator. That is, I tab from Emacs to Firefox, look up a reference in
> the Zotero pane, and Quick Copy (C-S-c) to a formatted link to the
> clipboard. Tab back to Emacs, yank the link, manually tweak the
> description as necessary. RefTex it ain't, and it's cumbersome for
> multiple citations, but it works.
> 
> 
> Yours,
> Christian
> 
> 

[O] Google calendar synchronization

[Guido Van Hoecke]

To whom it may concern:

The latest ical2org.awk script to convert google.ics file(s) into org
file(s) has been updated to support recurring events.  It is available
at http://orgmode.org/worg/org-tutorials/org-google-sync.html

RRULE records are transformed into recurring org timestamps (a la +xd,
+xw, +xm, +xy etc).

Two caveats:

- COUNT specifiers in RRULE records are ignored.

- EXDATE record to exclude dates from recurring events are ignored

Hoping this may be useful,


Guido

--
fortune: cpu time/usefulness ratio too high -- core dumped.

Re: [O] [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults (was Re: [patch] ox-koma-letter.el: clean-up/semantic bug [4/4])

[Viktor Rosenfeld]

Hi Robert,

Robert Klein wrote:

> Hello,
> On 05/25/2013 03:57 PM, Rasmus wrote:
> > Alan Schmitt  writes:
> > 
> >> Hello,
> >>
> >> Viktor Rosenfeld writes:
> >>
> >>> Hi Robert,
> >>>
> >>> Robert Klein wrote:
> >>>
>  Hi,
> 
>  FWIW, from a users view it would be nice if:
> 
>  - Use Author/Email information from org file
>  - If not present use information from LCO file
>  - if neither org file nor LCO file has any information use
>    user-full-name and user-email-address
> 
>  Could this be solved by having several e.g. `setkomavar{fromname}'
>  and so on in the tex file, so is created as follows:
> > 
> > I'd go with 'no'.  It's not aesthetically pleasing and I don't want my
> > output to look like LyX.  When feasible we should go for beautiful
> > output.  This isn't always the case at the moment, but still.
> >  
>  if no #+AUTHOR in org-file and user-full-name is set:
>  add user-full-name
>  if #+LCO(s) in org-file:
>  add LCO file(s)
>  if #+AUTHOR in org-file:
>  add \setkomavar{fromname}{#+AUTHOR}
>    same for email
> > 
> > Currently the ordering is: #+AUTHOR > #+LCO and AUTHOR default to
> > (user-full-name).
> 
> hmm, sorry, I did not express myself in a good way.
> 
> what I meant is, if #+AUTHOR defaults to (user-full-name), could the
> \setkomavar commands be placed /before/ \LoadLetterOption in the TeX
> file,  and after \LoadLetterOptions if #+AUTHOR is set in the .org file?
> 
> So you'd still get only one set of \setkomavar in the TeX file, but get
> a (for me) more useful order of #+AUTHOR != (user-full-name) > #+LCO >
> #+AUTHOR == (user-full-name)

I'm still having trouble to understand what would be gained by placing
\setkomavar{author}{.} before \LoadLetterOption if it defaults to
user-full-name. Could you maybe describe your setup and what you want to
achieve? 

Cheers,
Viktor

> 
> 
> Best regards
> Robert
> 
> 

Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup

[Viktor Rosenfeld]

Hi Rasmus,

Rasmus wrote:

> Rasmus  writes:
> 
> >   4. Sets defcustom org-koma-letter-signature nil since that
> >  corresponds to default scrlttr2 behavior anyway (p. 183 in the
> >  manual).
> >
> > Re 4.: I'd like to do something similar to
> > org-koma-letter-subject-format.  But I'm not sure how, at the moment
> > (perhaps make t the default and associate it with the current default
> > list).
> 
> 
> This patch makes the subject option "easier" although still relying on
> a list for multiple options (see the description in the patch).  The
> default is t corresponding to do nothing but print komavar subject.
> 
> I haven't found any bugs but please test it (along with other patches)
> if time permits.

I could not apply this either and I am pressed for time right now. Could
you resend a diff against the current master?

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

I'm also not a big fan of the title defaulting to the filename. But I
think it is a minor issue. What I think is quite useful is setting the
subject to the headline of the exported subtree. Wouldn't we also lose
this if subject is nil?

Cheers,
Viktor

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

> >From 880f99622a4513520d1dd4e110428f18453a3af1 Mon Sep 17 00:00:00 2001
> From: "rasmus.pank" 
> Date: Sat, 25 May 2013 20:49:57 +0200
> Subject: [PATCH 5/5] Only print subject options when necessary
> 
> * ox-koma-letter.el (org-koma-letter-subject-format): default is now t
> * ox-koma-letter.el (org-koma-letter-template): better subject handling.
> 
> If =#+OPTIONS: subject:(x,y)= then =\KOMAoption{subject}{x, y}=.  If
> =subject:x= then =\KOMAoption{subject}{x}=.
> If =subject:t= then =\KOMAoption{subject}{...}= is not printed but
> \setkomavar{subject}{...} is printed.  If =subject:nil= neither are
> printed.
> ---
>  contrib/lisp/ox-koma-letter.el | 21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
> index 4cb402e..ca20ec7 100644
> --- a/contrib/lisp/ox-koma-letter.el
> +++ b/contrib/lisp/ox-koma-letter.el
> @@ -137,7 +137,7 @@ function may be given.  Functions must return a string."
>:group 'org-export-koma-letter
>:type 'string)
>  
> -(defcustom org-koma-letter-subject-format '("beforeopening" "left" 
> "untitled")
> +(defcustom org-koma-letter-subject-format t
>"Use the title as the subject of the letter.  At the time of
>  writing the following values are allowed:
>  
> @@ -162,6 +162,7 @@ English manual of 2012-07-22)"
>   (const  "titled")
>   (const  "untitled")
>   (const :tag "No export" nil)
> + (const :tag "Default options" t)
>   (string))
>:group 'org-export-koma-letter)
>  
> @@ -432,20 +433,16 @@ holding export options."
> "\\begin{document}\n\n"
> ;; Subject
> (let* ((with-subject (plist-get info :with-subject))
> -   (subject-format
> -(if (member
> - ;; test if subject-format is t
> - (cond ((symbolp with-subject) (downcase (symbol-name 
> with-subject)))
> -   ((stringp with-subject) (downcase with-subject))
> -   (t nil))
> - '("true" "t"))
> -org-koma-letter-subject-format
> -  with-subject))
> +   (subject-format (cond ((member with-subject '("true" "t" t)) nil)
> + ((stringp with-subject) (list with-subject))
> + ((symbolp with-subject)
> +  (list (symbol-name with-subject)))
> + (t with-subject)))
> (subject (org-export-data (plist-get info :title) info))
> -   (l (if (stringp subject-format) 1 (length subject-format)))
> +   (l (length subject-format))
> (y ""))
>   (concat
> -  (when with-subject
> +  (when (and with-subject subject-format)
>   (concat
>"\\KOMAoption{subject}{"
>(apply 'format
> -- 
> 1.8.2.3
> 

Re: [O] [PATCH][ox-koma-letter]: sender, email and cleanup (was: [PATCH] ox-koma-letter.el: Reintroduce variables removed in commit 832c6fd with proper defaults)

[Viktor Rosenfeld]

Hi Rasmus,

Rasmus wrote:

> Attached are three patches that goes on top of Viktor's latest patch
> (I've also attached it here since I rebased stuff and might have
> changed it by accident).
> 
>   1. Viktor's latest patch.
>   2. The patch describe above that gets user name and email and works
>  on my system. . .

Your code works for me. From my point of view, the pros are that per
default `org-koma-letter-{author,sender}' pick up the values of
`user-full-name' and `user-mail-address' whenever they are changed.
That's very nice! The cons are that IHMO it's quite complicated for
setting something as simple as author and email and you mentioned a
possible crash which I did not test further. Could this be tested using
`functionp'? Still, I think we should stick with it for now.

>   3. Cleaning up special-tags functions introduced in
>  ec108f4c3507ed546a564a48b7379355a65aa9f4.  It works a lot better
>  now and some of the mess in the template is moved to other
>  functions.

I could not apply this.

>   4. Sets defcustom org-koma-letter-signature nil since that
>  corresponds to default scrlttr2 behavior anyway (p. 183 in the
>  manual).  

Works for me.

As a side note, I had quite a few problems working with your patches.
None of them applied against master, or against my latest patch as you
claimed. I had to merge in some of the changes of 0002 by hand. I
suggest that we nail down the workings of AUTHOR and EMAIL first (should
be done now) and then start with clean separate branches branched from
master for your subject and heading code. We could even use github for
this, what do you think?

Cheers,
Viktor
 
> Re 4.: I'd like to do something similar to
> org-koma-letter-subject-format.  But I'm not sure how, at the moment
> (perhaps make t the default and associate it with the current default
> list).
> 
> –Rasmus
> 
> -- 
> This is the kind of tedious nonsense up with which I will not put
> 

> >From bbaf9a6ddd75368b2143e6b8fb50be64bd66b50d Mon Sep 17 00:00:00 2001
> From: Viktor Rosenfeld 
> Date: Thu, 23 May 2013 00:00:38 +0200
> Subject: [PATCH 1/4] ox-koma-letter.el: Reintroduce variables removed in
>  commit 832c6fd with proper defaults.
> 
>   * ox-koma-letter.el (org-koma-letter-author): Dedicated
>   variable to set the KOMA variable fromname; initialized to
>   `user-full-name' using `after-init-hook' if not set
>   explicitly.
>   (org-koma-letter-email): Dedicated variable to set the KOMA
>   variable fromemail; initialized to `user-mail-address' using
>   `after-init-hook' if not set explicitly.
>   (koma-letter): Use dedicated variables for AUTHOR and EMAIL.
>   (org-koma-letter-template): Variable name change.
> 
> Setting the variables `org-koma-letter-author' and `org-koma-letter-email' to 
> the values of `user-full-name' and `user-mail-address' respectively, allows 
> the user to skip =#+AUTHOR:= and =#+EMAIL:= lines when configuring a letter. 
> However, if the user wishes to set this information in LCO files, these 
> variables need to be set to nil.
> ---
>  contrib/lisp/ox-koma-letter.el | 37 +++--
>  1 file changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
> index 92cf13a..24c1ac5 100644
> --- a/contrib/lisp/ox-koma-letter.el
> +++ b/contrib/lisp/ox-koma-letter.el
> @@ -82,6 +82,32 @@
>:group 'org-export-koma-letter
>:type 'string)
>  
> +(defcustom org-koma-letter-author (if (boundp 'org-koma-letter-author)
> +  user-full-name
> +;; Empty string means "not set yet."
> +"")
> +  "The sender's name.
> +
> +This variable defaults to the value of `user-full-name'."
> +  :group 'org-export-koma-letter
> +  :type 'string)
> +
> +(add-hook 'after-init-hook
> +(lambda ()
> +  (if (string= org-koma-letter-author "")
> +(setq org-koma-letter-author user-full-name
> +
> +(defcustom org-koma-letter-email user-mail-address
> +  "The sender's email address.
> +
> +This variable defaults to the value of `user-mail-address'."
> +  :group 'org-export-koma-letter
> +  :type 'string)
> +
> +(add-hook 'after-init-hook
> +(lambda ()
> +  (if (string= org-koma-letter-email "")
> +(setq org-koma-letter-email user-mail-address
>  
>  (defcustom org-koma-letter-from-address nil
>"Sender's address, as a string."
> @@ -93,7 +119,6 @@
>:group 'org-export-koma-letter
>:type 'string)
>  
> -
>  (defcustom org-koma-letter-place nil
>"Place from which the letter is sent."
>:group 'org-export-koma-letter
> @@ -207,10 +232,10 @@ content temporarily.")
>  (org-export-define-derived-backend 'koma-letter 'latex
>:options-alist
>'((:lco "LCO" nil org-koma-letter-class-option-file)
> -(:sender "AUTHOR" nil org-koma-letter-author)
> +(:author "AUTHOR" nil org-koma-letter-author t)
>  (:from-address "FROM_ADDRESS" nil org-koma-letter-from-ad

Re: [O] Seeking advice on structuring my org-mode file

[Karl Voit]

* Marcin Borkowski  wrote:
> Hi all,

Hi!

> I have an Org-mode file with notes concerning a large project connected
> with teaching at my university.  One of the headlines is dedicated to
> one particular course, where I am part of a group developing a concept
> of this course.  So, one subheadline is devoted to that.  Yet another
> (subsub)headline is a list if my proposals of things that should be
> covered during that course, and now it needs 3 more levels down.
> Summing it up: I have 5 levels of headlines and now I need a sixth
> one.  So, my question is: what are good practices of other Org-moders?
> Do you push such a monster to an external file and just include a link
> to it?  Or do you just live with 6-level structure (which is a bit
> cumbersome, since I sometimes want to copy a part of this document to
> an email)?  Or maybe there's yet another way of handling this?

So I assume you've got this:

- project.org
  - courseX
- covered topics (unsure about this one; not necessary)
  - topic 1
- task related to topic 1

Either you are OK with this level of headings (I would not care) or
you have many different possibilities.

1. Additional Org-mode file(s): see other answers

2. Usage of flat hierarchy

- project.org
  - non-educational
  - courseX
  - courseX notes

3. Usage of tags

- project.org
  - X:non-educational:
  - course material:courseX:
  - course topics  :courseX:
  - course notes   :courseX:

Or you can use a combination of these methods or additional methods
which do not come to my mind for now.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] org-export, table.el complex tables, latex html

[Uwe Brauer]

>> "Carsten" == Carsten Dominik  writes:

   > On 25.5.2013, at 22:09, Nicolas Goaziou  wrote:

   >> Uwe Brauer  writes:
   >> 
>> What's about orgtbl-to-latex does this work for you also?
   >> 
   >> It doesn't seem to.

   > orgtbl-to-* does not support table.el tables.

Thanks for clarifying, any plans about it for the feature?

Uwe 

Re: [O] Build-System: Why not compile contrib

[Stefan Nobis]

Suvayu Ali  writes:

> 

> Hope this helps,

A little bit. I already know about ORG_ADD_CONTRIB, but I thought it
would only be used by `make install' and I do not install org-mode, I
use it directly from my local repository (running `make update' or
`make up1' from time to time; org-mode/lisp and org-mode/contrib/lisp
are both in my load-path).

I dug a bit deeper into the Makefiles and now I realized that files
defined by ORG_ADD_CONTRIB will be copied to the main lisp directory
and then everything is compiled. Just removing org-mode/contrib/lisp
from my load-path and only using org-mode/lisp is enough.

The only unaethetic thing left is that now git sees all those files
from contrib/lisp copied to lisp as new untracked files (but that does
not bother me too much).

-- 
Until the next mail...,
Stefan.