[O] Help proofreading ORG-NEWS for Org 8.1

2013-09-05 Thread Bastien
Hi all,

I have prepared the changelogs for Org 8.1, see the first
section in this file:

  http://orgmode.org/cgit.cgi/org-mode.git/plain/etc/ORG-NEWS

I have not documented changes in the contrib/ directory, as
ORG-NEWS is meant to go into the Emacs trunk.

Please let me know if I missed some important changes or if
some descriptions need some rephrasing/details.

Thanks!

-- 
 Bastien




[O] An org-contacts merge function, may be it is useful to someone

2013-09-05 Thread Feng Shu

This is a contacts merge function, you can use it to merge duplicate
contacts

---

(defun eh-org-contacts-merge-contacts ()
  "Merge duplicate contacts"
  (interactive)
  (dolist (name (let ((contact-list (org-contacts-filter nil nil)))
  (delete-dups
   (loop for contact in contact-list
 collect (substring-no-properties
  (org-contacts-vcard-escape (car contact)))
;; let UPDATE be the first contact matching NAME
(let* ((contacts (org-contacts-filter (concat "\\b" name "\\b")))
   (update (first contacts)))
  (save-excursion
(with-current-buffer (marker-buffer (second update))
  (goto-char (marker-position (second update)))
  ;; for all other contacts matching NAME as CONTACT
  (dolist (contact (rest contacts))
;; add all properties to UPDATE
(loop with special-properties = (mapcar 'first 
(org-entry-properties nil 'special))
  for (property . value) in (third contact)
  unless (member property special-properties)
  do (if (or (string= property "TAGS") (string= property 
"ALLTAGS"))
 (org-set-tags-to (delete-dups
   (nconc (org-get-tags-at)
  (split-string (if value value 
"") ":" t
   (let ((second-value (org-entry-get nil property)))
 (unless (string= (org-contacts-strip-link (if 
second-value second-value ""))
  (org-contacts-strip-link (if value 
value "")))
   (org-entry-put nil property
  (concat (org-entry-get nil property)
  " " value))
;; delete CONTACT
(save-excursion
  (with-current-buffer (marker-buffer (second contact))
(goto-char (marker-position (second contact)))
(let ((plist (second (org-element-at-point
  (delete-region (plist-get plist :begin)
 (plist-get plist :end)))



Re: [O] [BUG] org-cycle on hidden inline task makes also other inline tasks visible

2013-09-05 Thread John Hendy
On Thu, Sep 5, 2013 at 6:33 AM, Jonas Hörsch  wrote:
> hello everyone,
>
> just found a strange behaviour of inline tasks:
>
> calling org-cycle in a situation like
>
> * Heading1
> *** inline1...
> *** inline2...
> *** inline3...
> * Heading2
> *** inline4...
>
> with point on the inline2 heading results in
>
> * Heading1
> *** inline1...
> *** inline2
> *** END
> *** inline3
> *** END
> * Heading2
> *** inline4...
>

I can confirm on 8.0.7. Unfolding an inline task appears to unfold all
inline headlines below it.


John

> tested with emacs -Q on org-mode's master branch of sep 3rd.
>
> cheers,
> jonas
>



Re: [O] [PARSER] Why not add properties to type 'org-data'?

2013-09-05 Thread Thorsten Jolitz
Nicolas Goaziou  writes:

Hello,

> Thorsten Jolitz  writes:
>
>> Wouldn't it make sense to replace 
>>
>> ,--
>> | (org-data nil (section (:begin 1 :end 52 ...)))
>> `--
>>
>> with something like
>>
>> ,-
>> | (org-data (:id-or-name file001 :input-file /my/file.org :author me :date
>> | 01-01-2013 :description my planning data) (section (:begin 1 :end 52
>> | ...)))
>> `-
>>
>> ?
>
> This is way beyond parser's attributions. For example, getting the right
> date means that every SETUPFILE keyword should be inspected. INCLUDE
> keywords too. And some macros could get expanded in the process.
>
> Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and
> made special at the export framework level (see
> `org-export-options-alist'). There are just regular keywords to the
> parser. IOW, for the parser, there is no difference between
>
>   #+DESRCIPTION: something
>
> and
>
>   #+FOO: something
>
> At one point, I thought about combining parse tree and information
> channel, much like what you're suggesting, but in `ox.el'. It would give
> something like an "Org closure" wrapping both contents and environment
> together.
>
> But I discarded that idea, as it was very artificial: the minute the
> closure was created, it was splitted again so it could get processed.

OK, I do like the separation of parse tree and communication channel in
the exporter, and I can use the exporter to extract and put the
necessary 'org-data' DB object attributes, at the very least the file
name or a unique ID.

But sometimes, when only the parse-tree is needed, not the exporter
framework, it would indeed be useful if that highest level element the
others refer to as parent (org-data) would have some kind of unique
name/id.

What would be the cost of introducing just one single unique attribute
like:

,-
| (org-data (:input-file /my/file.org) (section (:begin 1 :end 52 ...)))
`-

or 

,-
| (org-data (:ID 08AF34b12) (section (:begin 1 :end 52 ...)))
`-

to make different parse trees distinguishable (and associated to the
parsed file)?

-- 
cheers,
Thorsten




Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Roger Mason

Hello,

On 09/05/2013 04:15 PM, Nicolas Goaziou wrote:

#+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry}
   #+LATEX_HEADER: \usepackage{parskip}

   * Setup 
:noexport:
   #+BEGIN_SRC emacs-lisp :exports both
   (defun margin-graphics (contents backend info)
   (when (eq backend 'latex)
 (replace-regexp-in-string "\\`includegraphics.*?\\({.+}\\)"
   "marginpar{includegraphics[width=0.9marginparwidth]\\1} "
   contents)))

   (add-to-list (make-local-variable 'org-export-filter-link-functions) 
'margin-graphics)
   #+END_SRC

That got rid of the verbatim output.  Thanks.

Unfortunately the replacement of \includegraphics... by \marginpar... 
still does not work:


#+CAPTION: Acicular
[[../images/acicular.eps]]

produces

\begin{figure}[htb]
\centering
\includegraphics[width=.9\linewidth]{../images/acicular.eps}
\caption{Acicular}
\end{figure}

I'm using org Emacs 24.3.1 (Org mode 8.0.3).

Please don't spend any more time on this on my account:  I'll use 
ConTeXt instead.


Cheers,
Roger


This electronic communication is governed by the terms and conditions at
http://www.mun.ca/cc/policies/electronic_communications_disclaimer_2012.php



[O] Filter not working (org 8.0.3)

2013-09-05 Thread Roger Mason

Hello,

I have this at the top of an org file in order to put graphics in the 
margin:


#+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry} 
\usepackage{parskip}


#+BEGIN_SRC emacs-lisp
(defun margin-graphics (contents backend info)
  (when (eq backend 'latex)
(replace-regexp-in-string "\\`includegraphics.+\\({.+}\\)"
"marginpar{includegraphics[width=0.9marginparwidth]\\1} " 
contents)))


(add-to-list 'org-export-filter-link-functions 'margin-graphics)
#+END_SRC

C-e lp produces a pdf document, but the filter is not applied (org 8.0.3).

Can someone show me what I'm doing wrong?

Thanks,
Roger

This electronic communication is governed by the terms and conditions at
http://www.mun.ca/cc/policies/electronic_communications_disclaimer_2012.php



Re: [O] [PARSER] Why not add properties to type 'org-data'?

2013-09-05 Thread Nicolas Goaziou
Hello,

Thorsten Jolitz  writes:

> Wouldn't it make sense to replace 
>
> ,--
> | (org-data nil (section (:begin 1 :end 52 ...)))
> `--
>
> with something like
>
> ,-
> | (org-data (:id-or-name file001 :input-file /my/file.org :author me :date
> | 01-01-2013 :description my planning data) (section (:begin 1 :end 52
> | ...)))
> `-
>
> ?

This is way beyond parser's attributions. For example, getting the right
date means that every SETUPFILE keyword should be inspected. INCLUDE
keywords too. And some macros could get expanded in the process.

Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and
made special at the export framework level (see
`org-export-options-alist'). There are just regular keywords to the
parser. IOW, for the parser, there is no difference between

  #+DESRCIPTION: something

and

  #+FOO: something

At one point, I thought about combining parse tree and information
channel, much like what you're suggesting, but in `ox.el'. It would give
something like an "Org closure" wrapping both contents and environment
together.

But I discarded that idea, as it was very artificial: the minute the
closure was created, it was splitted again so it could get processed.


Regards,

-- 
Nicolas Goaziou



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Marc Ihm

Hi,

My aproach is low-tech.

I manage two special files:
- token.txt, which (through shell-scripts) moves around with me and helps to 
check,
  that I do not have multiple emacs open on different machines.
- open.txt, which is created by a small piece of elisp and helps to check,
  that I do not have multiple emacs open on the same machine.
With both files I can be sure, that there is only one single instance of emacs 
open
on all my devices (other instances of emacs at least display a warning message).

Having this, synchronisation with rsync is quite easy.

With this approach I do not have merge conflicts (unless I mess up things 
occasionally :-).
I use several instances of windows and linux, that are connected by network or 
usb-stick.

best regards,
Marc





Re: [O] macro expansion not working in #+ATTR_LATEX

2013-09-05 Thread Nicolas Goaziou
Hello,

Johannes Rainer  writes:

> while working nicely for plain text I realized that macros are not expanded
> if put in #+ATTR_LATEX:
>
> e.g. I defined
>
> #+MACRO: image_width 16
>
> and wanted to use this macro like
>
> #+ATTR_LATEX: :center :placement [H] :width {{{image_width}}}cm
>
> however, in the exported tex file I get:
>
> \includegraphics[width={{{image_width}}}cm]{test.png}
>
> is that intentional that macro expansion works only for plain text?

Yes. Macro are only expanded where one can find plain text. See "11.6
Macro replacement" in Org manual.


Regards,

-- 
Nicolas Goaziou



Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Nicolas Goaziou
Roger Mason  writes:

> Unfortunately, :exports both does not make any difference.  Looking at
> the generated LaTeX file I see that it contains:
>
> \begin{verbatim}
> (defun margin-graphics (contents backend info)
>   (when (eq backend 'latex)
> (replace-regexp-in-string "\\`includegraphics.+\\({.+}\\)"
> "marginpar{includegraphics[width=0.9marginparwidth]\\1} "
> contents)))
>
> (add-to-list 'org-export-filter-link-functions 'margin-graphics)
> \end{verbatim}
>
> which seems odd.

It is to be expected since ":exports both" is meant to leave source code
behind.

Anyway, the following works for me (I had to tweak your regexp):

--8<---cut here---start->8---
  #+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry}
  #+LATEX_HEADER: \usepackage{parskip}

  * Setup 
:noexport:
  #+BEGIN_SRC emacs-lisp :exports both
  (defun margin-graphics (contents backend info)
  (when (eq backend 'latex)
(replace-regexp-in-string "\\`includegraphics.*?\\({.+}\\)"
  "marginpar{includegraphics[width=0.9marginparwidth]\\1} "
  contents)))

  (add-to-list (make-local-variable 'org-export-filter-link-functions) 
'margin-graphics)
  #+END_SRC

  * Document

  
[[file:~/Documents/work/2-data/images/2-echantillonnage-1-fluctuations-fig1.png]]
--8<---cut here---end--->8---

I suggest to use `make-local-variable' to keep global filters list
clean.


Regards,

-- 
Nicolas Goaziou



Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Roger Mason

Hello,

On 09/05/2013 04:39 PM, Nicolas Goaziou wrote:
In this case, you need to remove "\\`" from your regexp. Regards, 

That fixed it.

Many thanks.

Roger

This electronic communication is governed by the terms and conditions at
http://www.mun.ca/cc/policies/electronic_communications_disclaimer_2012.php



[O] macro expansion not working in #+ATTR_LATEX

2013-09-05 Thread Johannes Rainer
hi all!

while working nicely for plain text I realized that macros are not expanded
if put in #+ATTR_LATEX:

e.g. I defined

#+MACRO: image_width 16

and wanted to use this macro like

#+ATTR_LATEX: :center :placement [H] :width {{{image_width}}}cm

however, in the exported tex file I get:

\includegraphics[width={{{image_width}}}cm]{test.png}

is that intentional that macro expansion works only for plain text?

thanks, jo


Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Nicolas Goaziou
Roger Mason  writes:

> On 09/05/2013 04:15 PM, Nicolas Goaziou wrote:
>> #+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry}
>>#+LATEX_HEADER: \usepackage{parskip}
>>
>>* Setup 
>> :noexport:
>>#+BEGIN_SRC emacs-lisp :exports both
>>(defun margin-graphics (contents backend info)
>>(when (eq backend 'latex)
>>  (replace-regexp-in-string "\\`includegraphics.*?\\({.+}\\)"
>>"marginpar{includegraphics[width=0.9marginparwidth]\\1} "
>>contents)))
>>
>>(add-to-list (make-local-variable 'org-export-filter-link-functions) 
>> 'margin-graphics)
>>#+END_SRC
> That got rid of the verbatim output.  Thanks.
>
> Unfortunately the replacement of \includegraphics... by \marginpar... 
> still does not work:
>
> #+CAPTION: Acicular
> [[../images/acicular.eps]]
>
> produces
>
> \begin{figure}[htb]
> \centering
> \includegraphics[width=.9\linewidth]{../images/acicular.eps}
> \caption{Acicular}
> \end{figure}

In this case, you need to remove "\\`" from your regexp.


Regards,

-- 
Nicolas Goaziou



Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Roger Mason

Hello again,

On 09/05/2013 01:48 PM, Nicolas Goaziou wrote:

Hello,

Roger Mason  writes:


I have this at the top of an org file in order to put graphics in the
margin:

#+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry}
\usepackage{parskip}

#+BEGIN_SRC emacs-lisp
(defun margin-graphics (contents backend info)
(when (eq backend 'latex)
  (replace-regexp-in-string "\\`includegraphics.+\\({.+}\\)"
"marginpar{includegraphics[width=0.9marginparwidth]\\1} "
contents)))

(add-to-list 'org-export-filter-link-functions 'margin-graphics)
#+END_SRC

C-e lp produces a pdf document, but the filter is not applied (org 8.0.3).

Can someone show me what I'm doing wrong?

I think you need to tell Babel to actually execute the code (e.g.
with :exports both). You may also want to make
`org-export-filter-link-functions' local to the buffer, too.


Regards,


Thanks for the reply.

Unfortunately, :exports both does not make any difference.  Looking at 
the generated LaTeX file I see that it contains:


\begin{verbatim}
(defun margin-graphics (contents backend info)
  (when (eq backend 'latex)
(replace-regexp-in-string "\\`includegraphics.+\\({.+}\\)"
"marginpar{includegraphics[width=0.9marginparwidth]\\1} " 
contents)))


(add-to-list 'org-export-filter-link-functions 'margin-graphics)
\end{verbatim}

which seems odd.

Thanks for the help.

Roger

This electronic communication is governed by the terms and conditions at
http://www.mun.ca/cc/policies/electronic_communications_disclaimer_2012.php



Re: [O] [SYNC] How do you sync your org-mode files between ndevices (n > 2))

2013-09-05 Thread Ramon Diaz-Uriarte

alan.schm...@polytechnique.org writes:

> fatkasuvayu+li...@gmail.com writes:
>
>> On Thu, Sep 05, 2013 at 12:00:02PM +0200, Alan Schmitt wrote:
>>> Hi,
>>> 
>>> fatkasuvayu+li...@gmail.com writes:
>>> 
>>> > I think this would be a wonderful addition to Worg.  Probably the FAQ is
>>> > more appropriate (under "Tips and Tricks") since this is one of most
>>> > commonly asked questions on the list.  On the other hand, if you think
>>> > covering this topic requires more than just a few lines, a longer entry
>>> > or short article in the config section would be more appropriate.
>>> 
>>> I can't promise anything, but I can try to write something. What
>>> external merging tool should I use?
>>
>> I think the most appropriate tool would be org-merge-driver.  But I'm
>> not sure how reliable it is.  That said, what might be nicer is if you
>> treat the external tool bits generically.  Then people can choose their
>> own tools in the future; also that will probably be less work for you
>> since you don't have to figure out the details of the external merging
>> tool yourself.
>
> It makes sense.
>
>> What I'm after is having all the Unison config bits on Worg, then people
>> choose how they want to use it:
>> 1. plain sync,
>> 2. sync with merging (with their own choice of tools)
>>
>> I or someone else could then add the Dropbox like, and "version control
>> (Git) way" of syncing.  This would then be a fairly complete FAQ on
>> synchronisation questions.  Does that seem feasible to you?
>
> I've been playing with the merging using ediff, and it works. I'll
> explain it here, and depending on the feedback, I'll put it on worg.
>


I find it very clear and helpful.  Thanks a lot!


R.


> Alan
>
> * Synchronizing org files with Unison
>
> This describes how to synchronize org files using the 
> [[http://www.cis.upenn.edu/~bcpierce/unison/][Unison file synchronizer]],
> as well as how to configure it to use an external tool to merge conflicting
> edits.
>
> ** Prerequisites
>
> You should have Unison up and running. Binaries can be found 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download.html][here]] and the
> documentation is 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html][here]].
>
> ** Synchronization
>
> Unison is a file synchronizer, thus it may be used to synchronize org files. 
> To
> configure Unison, on uses a /profile/ which states where the things to
> synchronize are as well as some options. Assuming I want to synchronize the
> files in ~/Users/schmitta/dir1~ and ~/Users/schmitta/dir2~, the profile would
> look like this
>
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = /Users/schmitta/dir2
> #+END_EXAMPLE
>
> In most cases Unison will be used with a remote machine. The local machine is
> called the /client/ and the remote one the /server/. For such remote
> synchronization, the ~unison~ binary must be installed in the server as
> well. The simplest way to connect to the machine is using ssh. One should 
> check
> that unison can be found there by doing ~ssh user@remote unison -version~. If
> ~unison~ cannot be found in the path, one may set the ~servercmd~ option as
> indicated in the next example.
>
> (Please see the 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#roots][manual
>  section on roots]] for further details.)
>
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = ssh://user@remote/relative/path/to/dir2
>
> servercmd = /usr/bin/unison
> #+END_EXAMPLE
>
> ** Merging
>
> As Unison works on the level of files, it will trigger a /conflict/ if both
> files have changed since the last synchronization. In that case one can only
> choose which file to keep, which is not satisfying. Unison offers the
> possibility to use external tools to merge the files. There is an 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#merge][extensive
> manual section]] regarding this, we'll just describe how to use emacs and 
> ediff to
> do it.
>
> For better merging, we will ask unison to keep the last synchronized version 
> of
> every org file on the client; this way we can use ediff with ancestor. These
> ~currentbackup~ files may live alongside the synchronized files (with names of
> the form ~.bak.version.name~, which is configurable) or in a central location.
>
> Here is the modified configuration file.
>
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = ssh://user@remote/relative/path/to/dir2
>
> servercmd = /usr/bin/unison
>
> backupcurrent = Name *.org
> backuplocation = local
> maxbackups = 0
>
> merge = Name *.org -> emacsclient -c --eval '(ediff-merge-files-with-ancestor 
> "CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'
>
> #+END_EXAMPLE
>
> The ~backupcurrent~ option tells unison to keep a backup of the last
> synchronized version of ever file with an ~org~ extension. The location of the
> backup should be local (alongside the file). Finally, no ot

Re: [O] Filter not working (org 8.0.3)

2013-09-05 Thread Nicolas Goaziou
Hello,

Roger Mason  writes:

> I have this at the top of an org file in order to put graphics in the 
> margin:
>
> #+LATEX_HEADER: \usepackage[right=2in,left=0.5in]{geometry} 
> \usepackage{parskip}
>
> #+BEGIN_SRC emacs-lisp
> (defun margin-graphics (contents backend info)
>(when (eq backend 'latex)
>  (replace-regexp-in-string "\\`includegraphics.+\\({.+}\\)"
> "marginpar{includegraphics[width=0.9marginparwidth]\\1} " 
> contents)))
>
> (add-to-list 'org-export-filter-link-functions 'margin-graphics)
> #+END_SRC
>
> C-e lp produces a pdf document, but the filter is not applied (org 8.0.3).
>
> Can someone show me what I'm doing wrong?

I think you need to tell Babel to actually execute the code (e.g.
with :exports both). You may also want to make
`org-export-filter-link-functions' local to the buffer, too.


Regards,

-- 
Nicolas Goaziou



[O] [PARSER] Why not add properties to type 'org-data'?

2013-09-05 Thread Thorsten Jolitz

Hi List, 

why isn't some of the meta-data available from the communication channel
during export (especially the environmental data) stored in a property
list for the 'org-data' element type during parsing?

Of course in common use org-elements are tightly bound to a certain org
file, and that org file is used from Emacs, so all the meta-data is
there and available.

But imagine for a moment org-elements (e.g. type 'headline') are stored
somewhere else in a different (DB) format. Then those headlines/subtrees
are not tightly coupled with a file anymore, they can be used
individually, recombined to new documents etc. - each of them becomes a
individual DB object, the original containing org file is merely one of
their attributes.

In such a situation, it would of course be necessary to store
information about the 'org-data' element each of the headline elements
belonged to originally, if only to be able to reconstruct the original
org file. A simple DB link from the headline to the containing
'org-data' could do this - but currently all 'org-data' objects are
anonymous undistinguable objects with empty property lists.

Wouldn't it make sense to replace 

,--
| (org-data nil (section (:begin 1 :end 52 ...)))
`--

with something like

,-
| (org-data (:id-or-name file001 :input-file /my/file.org :author me :date
| 01-01-2013 :description my planning data) (section (:begin 1 :end 52
| ...)))
`-

?

-- 
cheers,
Thorsten





Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Matt Price
On Thu, Sep 5, 2013 at 7:57 AM, Carsten Dominik
 wrote:
>
> On Sep 5, 2013, at 1:43 PM, Suvayu Ali  wrote:
>
>> Hi Carsten,
>>
>> On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
>>>
>>> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou  wrote:
>>>
>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>
> I don't think this is the right behavior, such lines should not be 
> rendered.
> Suvayu is right, with a space after the # they are treated as commendt, 
> but I think
> they should also be ignored with the plus.
>
> Nicolas, what is the reasoning behind rendering them?

 Because this isn't valid Org syntax, so it is treated as regular text
 (i.e. a paragraph). Something similar happens for unbalanced blocks:
>>>
>>> So in a way this is a "syntax error" message. :)
>>>
>>> OK, I get that point.  Is that behaviour documented?
>>
>> I think it is more of a "I don't recognise this as special syntax; it
>> must be text".  In that case, I'm not sure what can be documented, one
>> can have infinitely many text blurbs which look very similar to valid
>> Org syntax but isn't.
>>
>> I have noticed quite a few posts on the list with this kind of
>> misunderstanding.  I think the confusion arises from thinking of special
>> keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
>> they are not.  Lines starting with "#+" are possible keywords, whereas
>> lines starting with "# " are comments.

(sorry, posted my last msg before I saw the more recent contributions)
So how would you suggest org2blog keep track of the relationship
between local and uploaded files?
Should it define a new keyword (perhaps" #+remote:" )?  And if so how
is that best done? Quickly looking at "Export Options (12.2) in the
manual I don't see a built-in mechanism for defining backend-specific
options.  Something like "#+ATTR_BLOG: remote" might do the trick, but
adding multiple links to such a line would be cumbersome, wouldn't it?

Thanks again for your help clarifying this.



Re: [O] ATTENTION: Incompatible change

2013-09-05 Thread Anthony Lander
Hi Carsten,

Sorry for the delay. For org-mac-link, here is a small cleanup patch to org
that changes the customize group name from 'org-mac-link-grabber to
'org-mac-link, and another patch which updates the documentation in worg.
Can you please review, and if OK apply to the repositories?

Thanks,

  -Anthony



On Sat, Aug 31, 2013 at 9:37 AM, Carsten Dominik
wrote:

> Hi all,
>
> I have now replaced both org-mac-message.el and org-mac-link-grabber.el
> with org-mac-link.el.  So after the next pull, you will have to change your
> setup to use this module instead of the others and use the new commands as
> well.  I would appreciate if you your try this soon, so that we can fix
> issue before the next release (very soon).
>
> Thank you, and in particular thanks to Anthony Lander for doing the work.
>
> - Carsten
>
> P.S. Anthony, you promised to update the documentation.  It would be great
> if you could do that now.
>
> Thank you!
>
>
>
diff --git a/org-contrib/org-mac-link.org b/org-contrib/org-mac-link.org
index 3f58616..1cc0f21 100644
--- a/org-contrib/org-mac-link.org
+++ b/org-contrib/org-mac-link.org
@@ -1,4 +1,4 @@
-#+TITLE: org-mac-link-grabber.el -- Grab links from open Mac applications
+#+TITLE: org-mac-link.el -- Grab links from open Mac applications
 #+OPTIONS:   ^:{} author:nil
 #+STARTUP: odd
 
@@ -17,7 +17,7 @@
- Mail.app
- Address Book.app
- Safari.app
-- Skim.app [fn:: Supported in the latest version from Git]
+- Skim.app [fn:: Supported in the latest version from Git]
- Firefox.app
- Firefox.app with the Vimperator plugin
- Google Chrome.app
@@ -26,26 +26,26 @@
 * Installation
   
   Customize the org group by typing =M-x customize-group RET org RET=, then
-  expand the /Modules/ section, and enable =mac-link-grabber=.
+  expand the /Modules/ section, and enable =mac-link=.
 
   You may also optionally bind a key to activate the link grabber menu, like
   this:
 
   : (add-hook 'org-mode-hook (lambda () 
-  :   (define-key org-mode-map (kbd "C-c g") 'omlg-grab-link)))
+  :   (define-key org-mode-map (kbd "C-c g") 'org-mac-grab-link)))
 
-* Usage 
+* Usage
 
-  Activate the grabber by typing =C-c g= (or whatever key you decided
-  to bind, as above), or type =M-x omlg-grab-link RET=. This will give
-  you a menu in the modeline allowing you to select an application.
-  The current selection in that application will be inserted at point
-  as a hyperlink in your org-mode document.
+  Activate the grabber by typing =C-c g= (or whatever key you decided to bind,
+  as above), or type =M-x org-mac-grab-link RET=. This will give you a menu in
+  the modeline allowing you to select an application. The current selection in
+  that application will be inserted at point as a hyperlink in your org-mode
+  document.
 
 * Customizing
 
-  You may customize which applications appear in the grab menu by
-  customizing the group /org-mac-link-grabber/. Changes take effect
-  immediately. If you are using the latest org-mode from Git, you can
-  also customize whether the =org-mac-link-grabber= should highlight
-  the selected text when grabbing the link from Skim.app.
+  You may customize which applications appear in the grab menu by customizing
+  the group /org-mac-link/. Changes take effect immediately. If you are using
+  the latest org-mode from Git, you can also customize whether the
+  =org-mac-link= should highlight the selected text when grabbing the link from
+  Skim.app.
diff --git a/org-mac.org b/org-mac.org
index 074a85e..2015e02 100644
--- a/org-mac.org
+++ b/org-mac.org
@@ -28,7 +28,7 @@ applications other than Emacs...
 ** [[file:org-contrib/org-mac-iCal.org][org-mac-iCal]] -- import OS X iCal.app 
events into Emacs diary
Written by /Christopher Suckling/.
 
-** [[file:org-contrib/org-mac-link-grabber.org][org-mac-link-grabber]] -- 
Hyperlink to items in mac applications
+** [[file:org-contrib/org-mac-link.org][org-mac-link]] -- Hyperlink to items 
in mac applications
grab the current link or selection from an open mac application and
insert it as a hyperlink at point in an org-mode document. Written
by /Anthony Lander/.
diff --git a/contrib/lisp/org-mac-link.el b/contrib/lisp/org-mac-link.el
index 8993919..0ab0354 100644
--- a/contrib/lisp/org-mac-link.el
+++ b/contrib/lisp/org-mac-link.el
@@ -81,58 +81,58 @@
 (require 'org)
 (require 'org-mac-message)
 
-(defgroup org-mac-link-grabber nil
+(defgroup org-mac-link nil
   "Options concerning grabbing links from external Mac
 applications and inserting them in org documents"
-  :tag "Org Mac link grabber"
+  :tag "Org Mac link"
   :group 'org-link)
 
 (defcustom org-mac-grab-Finder-app-p t
   "Enable menu option [F]inder to grab links from the Finder"
   :tag "Grab Finder.app links"
-  :group 'org-mac-link-grabber
+  :group 'org-mac-link
   :type 'boolean)
 
 (defcustom org-mac-grab-Mail-app-p t
   "Enable menu option [m]ail to grab links from Mail.app"
   :

Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Matt Price
On Thu, Sep 5, 2013 at 6:09 AM, Nicolas Goaziou  wrote:
> Hello,
>
> Carsten Dominik  writes:
>
>> On 3.9.2013, at 17:32, Matt Price  wrote:
>>
>>> Hi,
>>>
>>> certain lines are not rendered by the org exporter, but are instead
>>> interpreted as instructions, e.g.:
>>>
>>> #+AUTHOR: Matt Price
>>>
>>> I'm using org2blog/wp, which is only partially converted to the new
>>> exporter.  It works pretty well, but not perfectly.  It has the neat
>>> feature that, when I insert a link to a local image, it will upload
>>> that image to wordpress and link to the uploaded file.  TO keep track
>>> of the location of those images, it writes lines like this to the org
>>> file:
>>>
>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>>
>>> Recently I've noticed that these lines are actually being rendered by
>>> the underlying html exporter before export.
>>
>> I don't think this is the right behavior, such lines should not be rendered.
>> Suvayu is right, with a space after the # they are treated as commendt, but 
>> I think
>> they should also be ignored with the plus.
>>
>> Nicolas, what is the reasoning behind rendering them?
>
> Because this isn't valid Org syntax, so it is treated as regular text
> (i.e. a paragraph). Something similar happens for unbalanced blocks:
>
>   * H
>
>   #+begin_example
>
>   * H2
>
> In the example above, "#+begin_example" is treated as a paragraph.
>
> In both cases, silently ignoring them could cause more trouble that it
> would solve.

Nicolas, can you help clarify under what conditions it's appropriate
to use the #+ syntax, and when to use '#' on its own?  I think
org2blog/wp uses #+ precisely in order to mark those comments as
org-related.  If you cna just tell me what the appropriate behaviour
is I will submit a patch to puneeth.

m


>
>
> Regards,
>
> --
> Nicolas Goaziou



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Robert Horn

Alan Schmitt writes:

> I can't promise anything, but I can try to write something. What
> external merging tool should I use?
>

There was some work done in a Summer of Code last year or the year
before.  I don't know how much more work remains.  It was an effort for
a delta operator for git.

I use a multi-system git environment, and the one area that is beyond
the git capabilities at present is the following kind of problem:

There is a repeating daily task with a log file.  On machine A, the task
is finished on Monday, Wednesday, and Friday.  On machine B, the task is
finished on Tuesday, Thursday, and Saturday.

Git does not understand the task structure, nor does it understand date
oriented logs.  It recognizes that there is a stretch of logfile and
task structure that needs my human intervention and leaves that part for
me to fix.  I have to cut the log entries from machine A version and put them
into the log from machine B version in proper date order.  The last
complete and next lines will come from machine B because they are more
recent.  I understand the date orientation, task structure, etc.  Git
does not.

Proper understanding of things like interleaving date related entries is
a difficult task to get right.  It would be enough to get it 80% right
with 0% improper fixes, and 20% identified for human merging.  But to
reach this level means understanding all the different users of date
tagged lines, entries, headlines, etc. in the org structure.

R Horn



Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Samuel Loury
Thorsten Jolitz  writes:

> A kind of team agende would indeed be useful, accessible form Org-mode
> _and_ other calendar/planning tools (I can't imagine a pure
> Emacs/Org-mode team).
Why not?

> I remember an attempt to make Org-mode a collaborative software (ColOrg
> or so) - whats the state of it? I would guess this is very difficult
> stuff. 
IIRC, the ColOrg project was more about allowing people to edit the same
org buffer simultaneously while the purpose of this thread of for org
documents to contain traces from separate people. In my use case for
instance, we would synchronize via git and would merge the task file.

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature


Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Samuel Loury
Sebastien Vauban  writes:

> Samuel Loury wrote:
>> Sebastien Vauban  writes:
> For example, IIUC, different users will share one file with tasks, where they
> will clock in/out. Then, what about the SCHEDULED and DEADLINE properties?
> Will the tasks be in all the user agendas? Not acceptable. Then, we need first
> to add an ASSIGNEE property, and ignore tasks which wouldn't be assigned to
> me [2]?
You are totally right. I guess the ASSIGNEE property would be a really
good implementation.

We should also create a variable org-collaborative-whoami to know what
tasks to filter.

--
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature


Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Alan Schmitt
fatkasuvayu+li...@gmail.com writes:

> Just a few typo/editorial comments.

I fixed them.

> This a very clear and complete write-up.  Thanks a lot Alan!
>
> :)

Thanks. It's online at
http://orgmode.org/worg/org-tutorials/unison-sync.html (I also changed
the index page to point at it).

Alan



Re: [O] [SYNC] How do you sync your org-mode files between ndevices (n > 2))

2013-09-05 Thread Alan Schmitt
co...@online.de writes:

> On Thu, Sep 05 2013, Karl Voit wrote:
>
>> * Alan Schmitt  wrote:
>>> I can't promise anything, but I can try to write something. What
>>> external merging tool should I use?
>>
>> I haven't used it yet but I read that Emacs offers some kind of a
>> 3-way-merger ...
>
> and then there is an early git-merge-tool[1] or rather the org-merge-driver
> for git. i've been using it for half a year now for my org files in
> git, although i seldom have conflicts, as we're just a small group.
>
> maybe somebody on the list has more info on its status?

If someone is adventurous enough, the command to use org-merge-driver
with unison would be:

org-merge-driver -- CURRENTARCH CURRENT1 CURRENT2 NEW

(see my other mail for the rest of the details)

Alan



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Suvayu Ali
Just a few typo/editorial comments.

On Thu, Sep 05, 2013 at 02:31:42PM +0200, Alan Schmitt wrote:
> 
> * Synchronizing org files with Unison
> 
> This describes how to synchronize org files using the 
> [[http://www.cis.upenn.edu/~bcpierce/unison/][Unison file synchronizer]],
> as well as how to configure it to use an external tool to merge conflicting
> edits.
> 
> ** Prerequisites
> 
> You should have Unison up and running. Binaries can be found 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download.html][here]] and the
> documentation is 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html][here]].
> 
> ** Synchronization
> 
> Unison is a file synchronizer, thus it may be used to synchronize org files. 
> To
> configure Unison, on uses a /profile/ which states where the things to

on uses -> one uses

> synchronize are as well as some options. Assuming I want to synchronize the
> files in ~/Users/schmitta/dir1~ and ~/Users/schmitta/dir2~, the profile would
> look like this
> 
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = /Users/schmitta/dir2
> #+END_EXAMPLE
> 
> In most cases Unison will be used with a remote machine. The local machine is
> called the /client/ and the remote one the /server/. For such remote
> synchronization, the ~unison~ binary must be installed in the server as
> well. The simplest way to connect to the machine is using ssh. One should 
> check
> that unison can be found there by doing ~ssh user@remote unison -version~. If
> ~unison~ cannot be found in the path, one may set the ~servercmd~ option as
> indicated in the next example.
> 
> (Please see the 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#roots][manual
>  section on roots]] for further details.)
> 
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = ssh://user@remote/relative/path/to/dir2
> 
> servercmd = /usr/bin/unison
> #+END_EXAMPLE
> 
> ** Merging
> 
> As Unison works on the level of files, it will trigger a /conflict/ if both
> files have changed since the last synchronization. In that case one can only
> choose which file to keep, which is not satisfying. Unison offers the

Maybe satisfactory is better than satisfying?

> possibility to use external tools to merge the files. There is an 
> [[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#merge][extensive
> manual section]] regarding this, we'll just describe how to use emacs and 
> ediff to
> do it.
> 
> For better merging, we will ask unison to keep the last synchronized version 
> of
> every org file on the client; this way we can use ediff with ancestor. These
> ~currentbackup~ files may live alongside the synchronized files (with names of
> the form ~.bak.version.name~, which is configurable) or in a central location.
> 
> Here is the modified configuration file.
> 
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = ssh://user@remote/relative/path/to/dir2
> 
> servercmd = /usr/bin/unison
> 
> backupcurrent = Name *.org
> backuplocation = local
> maxbackups = 0
> 
> merge = Name *.org -> emacsclient -c --eval '(ediff-merge-files-with-ancestor 
> "CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'
> 
> #+END_EXAMPLE
> 
> The ~backupcurrent~ option tells unison to keep a backup of the last
> synchronized version of ever file with an ~org~ extension. The location of the

ever file -> every file

> backup should be local (alongside the file). Finally, no other backup should 
> be
> created.
> 
> Next follows the merge command. For every org file in conflict, use the 
> command
> that launches a new emacs frame calling the ediff with ancestor function. The
> ~CURRENT1~, ~CURRENT2~, and ~CURRENTARCH~ strings are  replaced with the file
> from the first root, the file from the second root, and the last synchronized
> version. The ~NEW~ file is where Unison expects the file to be saved (which 
> will
> be done by the ediff session).
> 
> Thus, when an org file has been modified on both hosts, an ediff session will 
> be
> launched in a new frame. Closing the frame will make Unison commit the merge 
> (it
> waits until the command has finished).
> 
> If one does not want to use backups, it's possible to use the simpler ediff
> (without ancestor) command as follows.
> 
> #+BEGIN_EXAMPLE
> root = /Users/schmitta/dir1
> root = ssh://user@remote/relative/path/to/dir2
> 
> servercmd = /usr/bin/unison
> 
> merge = Name *.org -> emacsclient -c --eval '(ediff-merge-files "CURRENT1" 
> "CURRENT2" nil "NEW")'
> 
> #+END_EXAMPLE

This a very clear and complete write-up.  Thanks a lot Alan!

:)

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] running some elisp code when exporting a given file

2013-09-05 Thread Alan Schmitt
mylesengl...@gmail.com writes:

> Hi Alan,
>
> Alan Schmitt writes:
>
>> Is there a way to have arbitrary code stored in the file being exported
>> being evaluated before an export?
>
> I think you can use org-export-before-processing-hook for this.

Thank you for the suggestion. My question would then be: how do I set
the hook from within the file being exported? (And the answer is: apply
Nicolas's suggestion, it worked.)

Alan



Re: [O] running some elisp code when exporting a given file

2013-09-05 Thread Alan Schmitt
n.goaz...@gmail.com writes:

> Hello,
>
> Alan Schmitt  writes:
>
>> I would like to inline a css when exporting a file to html, but I don't
>> know how to tell org-mode to set the variable org-html-head from within
>> the file.
>>
>> Here is what I tried: I added the following block at the beginning of my
>> file:
>>
>> #+BEGIN_SRC emacs-lisp :exports none
>>   (set (make-local-variable 'org-html-head) (concat
>>  "\n"
>>  "\n"
>>  "\n"))
>> #+END_SRC
>>
>> It does not seem to be evaluated, however.
>>
>> Is there a way to have arbitrary code stored in the file being exported
>> being evaluated before an export?
>
> I think this has to do with ":exports none", which means that code will
> not be evaluated during export. You may want to try setting the
> attribute to some other value, and put the block in a :noexport: entry.

Thanks a lot, this was it.

Alan



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Alan Schmitt
fatkasuvayu+li...@gmail.com writes:

> On Thu, Sep 05, 2013 at 12:00:02PM +0200, Alan Schmitt wrote:
>> Hi,
>> 
>> fatkasuvayu+li...@gmail.com writes:
>> 
>> > I think this would be a wonderful addition to Worg.  Probably the FAQ is
>> > more appropriate (under "Tips and Tricks") since this is one of most
>> > commonly asked questions on the list.  On the other hand, if you think
>> > covering this topic requires more than just a few lines, a longer entry
>> > or short article in the config section would be more appropriate.
>> 
>> I can't promise anything, but I can try to write something. What
>> external merging tool should I use?
>
> I think the most appropriate tool would be org-merge-driver.  But I'm
> not sure how reliable it is.  That said, what might be nicer is if you
> treat the external tool bits generically.  Then people can choose their
> own tools in the future; also that will probably be less work for you
> since you don't have to figure out the details of the external merging
> tool yourself.

It makes sense.

> What I'm after is having all the Unison config bits on Worg, then people
> choose how they want to use it:
> 1. plain sync,
> 2. sync with merging (with their own choice of tools)
>
> I or someone else could then add the Dropbox like, and "version control
> (Git) way" of syncing.  This would then be a fairly complete FAQ on
> synchronisation questions.  Does that seem feasible to you?

I've been playing with the merging using ediff, and it works. I'll
explain it here, and depending on the feedback, I'll put it on worg.

Alan

* Synchronizing org files with Unison

This describes how to synchronize org files using the 
[[http://www.cis.upenn.edu/~bcpierce/unison/][Unison file synchronizer]],
as well as how to configure it to use an external tool to merge conflicting
edits.

** Prerequisites

You should have Unison up and running. Binaries can be found 
[[http://www.cis.upenn.edu/~bcpierce/unison/download.html][here]] and the
documentation is 
[[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html][here]].

** Synchronization

Unison is a file synchronizer, thus it may be used to synchronize org files. To
configure Unison, on uses a /profile/ which states where the things to
synchronize are as well as some options. Assuming I want to synchronize the
files in ~/Users/schmitta/dir1~ and ~/Users/schmitta/dir2~, the profile would
look like this

#+BEGIN_EXAMPLE
root = /Users/schmitta/dir1
root = /Users/schmitta/dir2
#+END_EXAMPLE

In most cases Unison will be used with a remote machine. The local machine is
called the /client/ and the remote one the /server/. For such remote
synchronization, the ~unison~ binary must be installed in the server as
well. The simplest way to connect to the machine is using ssh. One should check
that unison can be found there by doing ~ssh user@remote unison -version~. If
~unison~ cannot be found in the path, one may set the ~servercmd~ option as
indicated in the next example.

(Please see the 
[[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#roots][manual
 section on roots]] for further details.)

#+BEGIN_EXAMPLE
root = /Users/schmitta/dir1
root = ssh://user@remote/relative/path/to/dir2

servercmd = /usr/bin/unison
#+END_EXAMPLE

** Merging

As Unison works on the level of files, it will trigger a /conflict/ if both
files have changed since the last synchronization. In that case one can only
choose which file to keep, which is not satisfying. Unison offers the
possibility to use external tools to merge the files. There is an 
[[http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#merge][extensive
manual section]] regarding this, we'll just describe how to use emacs and ediff 
to
do it.

For better merging, we will ask unison to keep the last synchronized version of
every org file on the client; this way we can use ediff with ancestor. These
~currentbackup~ files may live alongside the synchronized files (with names of
the form ~.bak.version.name~, which is configurable) or in a central location.

Here is the modified configuration file.

#+BEGIN_EXAMPLE
root = /Users/schmitta/dir1
root = ssh://user@remote/relative/path/to/dir2

servercmd = /usr/bin/unison

backupcurrent = Name *.org
backuplocation = local
maxbackups = 0

merge = Name *.org -> emacsclient -c --eval '(ediff-merge-files-with-ancestor 
"CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'

#+END_EXAMPLE

The ~backupcurrent~ option tells unison to keep a backup of the last
synchronized version of ever file with an ~org~ extension. The location of the
backup should be local (alongside the file). Finally, no other backup should be
created.

Next follows the merge command. For every org file in conflict, use the command
that launches a new emacs frame calling the ediff with ancestor function. The
~CURRENT1~, ~CURRENT2~, and ~CURRENTARCH~ strings are  replaced with the file
from the first root, the file

Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Carsten Dominik

On Sep 3, 2013, at 5:59 PM, Jambunathan K  wrote:

> Matt Price  writes:
> 
>> #+ was enough to get org to treat these lines as non-text
> 
> Try adding a space character after #+.

Nope, this will not work, see the rest of the thread.

- Carsten



Re: [O] (Emacs 23/24 binary compatibility): defstruct, setf

2013-09-05 Thread Jambunathan K
Stefan Monnier  writes:

> More specifically, the setf and the defstruct need to be compiled with
> "the same version" (either both cl.el, or both gv.el).
>
> Does the patch below work for you?

Yes.  Please install.

FWIW, I see following errors reported.


On load of *.el file:



Loading /home/kjambunathan/src/org-mode/contrib/lisp/ox-jabref.el
(source)...

Eager macro-expansion failure: (error "Incompatible place expression
needs recompilation: (org-export-backend-transcoders enhanced-backend)")

gv-get: Incompatible place expression needs recompilation:
(org-export-backend-transcoders enhanced-backend)


On compile of *.el file:


Compiling file /home/kjambunathan/src/org-mode/contrib/lisp/ox-jabref.el
at Wed Sep 4 09:22:25 2013

ox-jabref.el:170:1:Error: Incompatible place expression needs
recompilation: (org-export-backend-transcoders enhanced-backend)



Re: [O] (Emacs 23/24 binary compatibility): defstruct, setf

2013-09-05 Thread Jambunathan K
Stefan Monnier  writes:

>> I think existing *.elc files compiled against Emacs-23.2.1 should load
>> fine on new Emacs versions.
>
> It's indeed an incompatibility I introduced when we switched from CL's
> setf to gv.el's setf, because the two work in a very different way.

In simple terms, the problem seems to be a 24.x style `setf' on a 23.x
defstruct.

NEWS has entries on gv.el and setf-s.  I am not sure which of those
entries "amount" to the above incompatibility.

If we could report on incompatibiliy that would be awesome.  Can the
FIRST EVER setf call make (additional) version checks and report errors.

>
>
> Stefan



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Jambunathan K

> I have a problem. I need to sync my files between several devices
> (currently 3). 

I don't use multiple machines.

I use unison to copy files between Hard disk and USB disk.  Apparently
unison is superior to rsync.



Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Jambunathan K
Matt Price  writes:

> #+ was enough to get org to treat these lines as non-text

Try adding a space character after #+.




Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Carsten Dominik

On Sep 5, 2013, at 1:43 PM, Suvayu Ali  wrote:

> Hi Carsten,
> 
> On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
>> 
>> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou  wrote:
>> 
> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
 
 I don't think this is the right behavior, such lines should not be 
 rendered.
 Suvayu is right, with a space after the # they are treated as commendt, 
 but I think
 they should also be ignored with the plus.
 
 Nicolas, what is the reasoning behind rendering them?
>>> 
>>> Because this isn't valid Org syntax, so it is treated as regular text
>>> (i.e. a paragraph). Something similar happens for unbalanced blocks:
>> 
>> So in a way this is a "syntax error" message. :)
>> 
>> OK, I get that point.  Is that behaviour documented?
> 
> I think it is more of a "I don't recognise this as special syntax; it
> must be text".  In that case, I'm not sure what can be documented, one
> can have infinitely many text blurbs which look very similar to valid
> Org syntax but isn't.
> 
> I have noticed quite a few posts on the list with this kind of
> misunderstanding.  I think the confusion arises from thinking of special
> keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
> they are not.  Lines starting with "#+" are possible keywords, whereas
> lines starting with "# " are comments.

Yes, and I just checked what we have in the manual:

Lines starting with zero or more whitespace characters followed by one
@samp{#} and a whitespace are treated as comments and will never be exported.

So indeed, the white space after the # is in the manual.  I had forgotten about 
this.

> 
> I can see how that can be confusing, but can't think of a way to resolve
> this.  I have two possibilities in mind:
> 1. change "# " to something more distict like: "//", or "##",
> 2. use different faces for the two.

Another way to do this would be that every line starting with "#" (no space) is 
a comment line, except when it is starting with "#+".  This was how I used to 
think about lines starting with "#".  BUt it is not bad the way it is now - we 
just need to be aware and tell people - we just did.

Thanks

- Carsten

> 
> (1) is probably too big a change, whereas (2) might be feasible.
> 
> Nicolas will probably have a better feeling about what is more
> appropriate here.
> 
> Cheers,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.
> 




Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Thorsten Jolitz
"Sebastien Vauban" 
writes:

> Don't misunderstand me. I'm not trying to convince you or anybody to stop and
> cry. On the contrary, I feel that some such possibilities are _needed_ to
> transform Org from a "personal organizer" to a "team organizer". 

A kind of team agende would indeed be useful, accessible form Org-mode
_and_ other calendar/planning tools (I can't imagine a pure
Emacs/Org-mode team).

I remember an attempt to make Org-mode a collaborative software (ColOrg
or so) - whats the state of it? I would guess this is very difficult
stuff. 

-- 
cheers,
Thorsten




Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Suvayu Ali
Hi Carsten,

On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
> 
> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou  wrote:
> 
> >>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
> >>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
> >> 
> >> I don't think this is the right behavior, such lines should not be 
> >> rendered.
> >> Suvayu is right, with a space after the # they are treated as commendt, 
> >> but I think
> >> they should also be ignored with the plus.
> >> 
> >> Nicolas, what is the reasoning behind rendering them?
> > 
> > Because this isn't valid Org syntax, so it is treated as regular text
> > (i.e. a paragraph). Something similar happens for unbalanced blocks:
> 
> So in a way this is a "syntax error" message. :)
> 
> OK, I get that point.  Is that behaviour documented?

I think it is more of a "I don't recognise this as special syntax; it
must be text".  In that case, I'm not sure what can be documented, one
can have infinitely many text blurbs which look very similar to valid
Org syntax but isn't.

I have noticed quite a few posts on the list with this kind of
misunderstanding.  I think the confusion arises from thinking of special
keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
they are not.  Lines starting with "#+" are possible keywords, whereas
lines starting with "# " are comments.

I can see how that can be confusing, but can't think of a way to resolve
this.  I have two possibilities in mind:
1. change "# " to something more distict like: "//", or "##",
2. use different faces for the two.

(1) is probably too big a change, whereas (2) might be feasible.

Nicolas will probably have a better feeling about what is more
appropriate here.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Jonas Hörsch
On Thu, Sep 05 2013, Karl Voit wrote:

> * Alan Schmitt  wrote:
>> I can't promise anything, but I can try to write something. What
>> external merging tool should I use?
>
> I haven't used it yet but I read that Emacs offers some kind of a
> 3-way-merger ...

and then there is an early git-merge-tool[1] or rather the org-merge-driver
for git. i've been using it for half a year now for my org files in
git, although i seldom have conflicts, as we're just a small group.

maybe somebody on the list has more info on its status?

cheers,
jonas

Footnotes:

[1] 
http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/git-merge-tool/index.html


pgp8Skx0v2CKJ.pgp
Description: PGP signature


[O] [BUG] org-cycle on hidden inline task makes also other inline tasks visible

2013-09-05 Thread Jonas Hörsch
hello everyone,

just found a strange behaviour of inline tasks:

calling org-cycle in a situation like

* Heading1
*** inline1...
*** inline2...
*** inline3...
* Heading2
*** inline4...

with point on the inline2 heading results in

* Heading1
*** inline1...
*** inline2
*** END
*** inline3
*** END
* Heading2
*** inline4...

tested with emacs -Q on org-mode's master branch of sep 3rd.

cheers,
jonas

* Heading1
*** inline1
*** END

*** inline2
*** END

*** inline3
*** END

* Heading2
*** inline4
*** END


pgpj0DU0Ql8L4.pgp
Description: PGP signature


Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Carsten Dominik

On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou  wrote:

> Hello,
> 
> Carsten Dominik  writes:
> 
>> On 3.9.2013, at 17:32, Matt Price  wrote:
>> 
>>> Hi,
>>> 
>>> certain lines are not rendered by the org exporter, but are instead
>>> interpreted as instructions, e.g.:
>>> 
>>> #+AUTHOR: Matt Price
>>> 
>>> I'm using org2blog/wp, which is only partially converted to the new
>>> exporter.  It works pretty well, but not perfectly.  It has the neat
>>> feature that, when I insert a link to a local image, it will upload
>>> that image to wordpress and link to the uploaded file.  TO keep track
>>> of the location of those images, it writes lines like this to the org
>>> file:
>>> 
>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>> 
>>> Recently I've noticed that these lines are actually being rendered by
>>> the underlying html exporter before export.
>> 
>> I don't think this is the right behavior, such lines should not be rendered.
>> Suvayu is right, with a space after the # they are treated as commendt, but 
>> I think
>> they should also be ignored with the plus.
>> 
>> Nicolas, what is the reasoning behind rendering them?
> 
> Because this isn't valid Org syntax, so it is treated as regular text
> (i.e. a paragraph). Something similar happens for unbalanced blocks:
> 
>  * H
> 
>  #+begin_example
> 
>  * H2
> 
> In the example above, "#+begin_example" is treated as a paragraph.
> 
> In both cases, silently ignoring them could cause more trouble that it
> would solve.

So in a way this is a "syntax error" message. :)

OK, I get that point.  Is that behaviour documented?

Thanks

- Carsten


Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Suvayu Ali
On Thu, Sep 05, 2013 at 12:00:02PM +0200, Alan Schmitt wrote:
> Hi,
> 
> fatkasuvayu+li...@gmail.com writes:
> 
> > I think this would be a wonderful addition to Worg.  Probably the FAQ is
> > more appropriate (under "Tips and Tricks") since this is one of most
> > commonly asked questions on the list.  On the other hand, if you think
> > covering this topic requires more than just a few lines, a longer entry
> > or short article in the config section would be more appropriate.
> 
> I can't promise anything, but I can try to write something. What
> external merging tool should I use?

I think the most appropriate tool would be org-merge-driver.  But I'm
not sure how reliable it is.  That said, what might be nicer is if you
treat the external tool bits generically.  Then people can choose their
own tools in the future; also that will probably be less work for you
since you don't have to figure out the details of the external merging
tool yourself.

What I'm after is having all the Unison config bits on Worg, then people
choose how they want to use it:
1. plain sync,
2. sync with merging (with their own choice of tools)

I or someone else could then add the Dropbox like, and "version control
(Git) way" of syncing.  This would then be a fairly complete FAQ on
synchronisation questions.  Does that seem feasible to you?

Thanks a lot,

:)

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Sebastien Vauban
Samuel Loury wrote:
> Sebastien Vauban  writes:
>
>> Having thought about that in the past, I had thought of adding "tags" after
>> clock lines, such as:
>>
>> --8<---cut here---start->8---
>> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51  :userA:
>> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36  :devB:
>> --8<---cut here---end--->8---
>
> That sounds good also.

Inserting the user is easy to do with:

#+begin_src emacs-lisp
(defun org-clock-out-mark-clock ()
  (unless remove (insert (format " :%s:" user-full-name

(add-hook 'org-clock-out-hook 'org-clock-out-mark-clock)
#+end_src

>> Though, having separate CLOCK drawers would even be better for Git merges,
>> such as (keeping the idea of pseudo-tags):
>>
>> --8<---cut here---start->8---
>> :CLOCK:userA:
>> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
>> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
>> :END:
>> :CLOCK:devB:
>> CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
>> :END:
>> --8<---cut here---end--->8---
>
> I really like this solution.
>
>> But, of course, a lot of development is required to make this become usable:
>>
>> - clocking reports (`R') must be updated with the knowledge of the current
>>   user
>>
>> - clock checking functions (`v c') must be enhanced to ignore clocks from
>>   other users
>>
>> - etc.
>
> That is my point with the solution by customization of org-clock-string. It
> appears to need only a few corrections of the hard coded "CLOCK:" string
> (that would be required anyway) and it looks like it would work out of the
> box without further development. Wouldn't it?

I've no real idea about how much should be changed for everything to work back
as expected [1], as there are so many functions relying on time clocking. Just
to add two extra points to the above list of possibly complex code changes:

- column view with time summing,

- `org-clock-display' (C-c C-x C-d), which shows subtree times in the entire
  buffer

Maybe you want to give it a try?

Though, I fear such a support requires more than what we expect -- while not
looking at the details (where the devil is).

For example, IIUC, different users will share one file with tasks, where they
will clock in/out. Then, what about the SCHEDULED and DEADLINE properties?
Will the tasks be in all the user agendas? Not acceptable. Then, we need first
to add an ASSIGNEE property, and ignore tasks which wouldn't be assigned to
me [2]?

Don't misunderstand me. I'm not trying to convince you or anybody to stop and
cry. On the contrary, I feel that some such possibilities are _needed_ to
transform Org from a "personal organizer" to a "team organizer". I'd be happy
that this would already be the case (and that we would have a real Web
interface for editing the files ;-)).

So, this discussion clearly is interesting, at least for providing ideas and a
common view on what's missing / what should be nice to have.

Best regards,
  Seb

[1] Don't forget we should be backward-compatible as well...

[2] For backward-compatibility, I guess we'd need to keep unassigned tasks in
all agenda views. Maybe not that nice.

-- 
Sebastien Vauban




Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Karl Voit
* Alan Schmitt  wrote:
> Hi,

Hi,

> fatkasuvayu+li...@gmail.com writes:
>
>> I think this would be a wonderful addition to Worg.  

Absolutely!

I am using unison as well. So far, I resolved conflicts (I try to do
anything I can to avoid them) very basic manually. I'd love to learn
how to do it with software support in a quick how-to.

> I can't promise anything, but I can try to write something. What
> external merging tool should I use?

I haven't used it yet but I read that Emacs offers some kind of a
3-way-merger ...

-- 
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] running some elisp code when exporting a given file

2013-09-05 Thread Nicolas Goaziou
Hello,

Alan Schmitt  writes:

> I would like to inline a css when exporting a file to html, but I don't
> know how to tell org-mode to set the variable org-html-head from within
> the file.
>
> Here is what I tried: I added the following block at the beginning of my
> file:
>
> #+BEGIN_SRC emacs-lisp :exports none
>   (set (make-local-variable 'org-html-head) (concat
>  "\n"
>  "\n"
>  "\n"))
> #+END_SRC
>
> It does not seem to be evaluated, however.
>
> Is there a way to have arbitrary code stored in the file being exported
> being evaluated before an export?

I think this has to do with ":exports none", which means that code will
not be evaluated during export. You may want to try setting the
attribute to some other value, and put the block in a :noexport: entry.


Regards,

-- 
Nicolas Goaziou



Re: [O] syntax for blocks that the exporter should not render?

2013-09-05 Thread Nicolas Goaziou
Hello,

Carsten Dominik  writes:

> On 3.9.2013, at 17:32, Matt Price  wrote:
>
>> Hi,
>> 
>> certain lines are not rendered by the org exporter, but are instead
>> interpreted as instructions, e.g.:
>> 
>> #+AUTHOR: Matt Price
>> 
>> I'm using org2blog/wp, which is only partially converted to the new
>> exporter.  It works pretty well, but not perfectly.  It has the neat
>> feature that, when I insert a link to a local image, it will upload
>> that image to wordpress and link to the uploaded file.  TO keep track
>> of the location of those images, it writes lines like this to the org
>> file:
>> 
>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>> 
>> Recently I've noticed that these lines are actually being rendered by
>> the underlying html exporter before export.
>
> I don't think this is the right behavior, such lines should not be rendered.
> Suvayu is right, with a space after the # they are treated as commendt, but I 
> think
> they should also be ignored with the plus.
>
> Nicolas, what is the reasoning behind rendering them?

Because this isn't valid Org syntax, so it is treated as regular text
(i.e. a paragraph). Something similar happens for unbalanced blocks:

  * H

  #+begin_example

  * H2

In the example above, "#+begin_example" is treated as a paragraph.

In both cases, silently ignoring them could cause more trouble that it
would solve.


Regards,

-- 
Nicolas Goaziou



Re: [O] running some elisp code when exporting a given file

2013-09-05 Thread Myles English

Hi Alan,

Alan Schmitt writes:

> Is there a way to have arbitrary code stored in the file being exported
> being evaluated before an export?

I think you can use org-export-before-processing-hook for this.

"""
12.13 Advanced configuration


Hooks
-

Two hooks are run during the first steps of the export process.  The
first one, 'org-export-before-processing-hook' is called before
expanding macros, Babel code and include keywords in the buffer.  The
second one, 'org-export-before-parsing-hook', as its name suggests,
happens just before parsing the buffer.  Their main use is for heavy
duties, that is duties involving structural modifications of the
document.  For example, one may want to remove every headline in the
buffer during export.
"""

Myles



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Alan Schmitt
Hi,

fatkasuvayu+li...@gmail.com writes:

> Hi Alan,
>
> On Thu, Sep 05, 2013 at 10:50:18AM +0200, Alan Schmitt wrote:
>> fatkasuvayu+li...@gmail.com writes:
>> 
>> > I think the issue with tools like Unison, Dropbox, is conflict
>> > resolution on simultaneous edits.  Traditional version control does a
>> > better job of that, but then it loses the convenience of these other
>> > tools.
>> >
>> > I believe there is a list member (Alan) close to Unison development; in
>> > the thread referenced by Samuel there is some discussion on how this
>> > could be done in a more well defined manner.
>> 
>> Unison can call external tools to merge conflicting files. If someone
>> wants to use such a tool with unison, I can definitely give a hand.
>
> If you can find the time, I have a somewhat more involved proposal for
> you :).
>
> I think this would be a wonderful addition to Worg.  Probably the FAQ is
> more appropriate (under "Tips and Tricks") since this is one of most
> commonly asked questions on the list.  On the other hand, if you think
> covering this topic requires more than just a few lines, a longer entry
> or short article in the config section would be more appropriate.

I can't promise anything, but I can try to write something. What
external merging tool should I use?

Thanks,

Alan



Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Suvayu Ali
Hi Alan,

On Thu, Sep 05, 2013 at 10:50:18AM +0200, Alan Schmitt wrote:
> fatkasuvayu+li...@gmail.com writes:
> 
> > I think the issue with tools like Unison, Dropbox, is conflict
> > resolution on simultaneous edits.  Traditional version control does a
> > better job of that, but then it loses the convenience of these other
> > tools.
> >
> > I believe there is a list member (Alan) close to Unison development; in
> > the thread referenced by Samuel there is some discussion on how this
> > could be done in a more well defined manner.
> 
> Unison can call external tools to merge conflicting files. If someone
> wants to use such a tool with unison, I can definitely give a hand.

If you can find the time, I have a somewhat more involved proposal for
you :).

I think this would be a wonderful addition to Worg.  Probably the FAQ is
more appropriate (under "Tips and Tricks") since this is one of most
commonly asked questions on the list.  On the other hand, if you think
covering this topic requires more than just a few lines, a longer entry
or short article in the config section would be more appropriate.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.



Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Samuel Loury
Sebastien Vauban  writes:

> Having thought about that in the past, I had thought of adding "tags" after
> clock lines, such as:
>
> --8<---cut here---start->8---
> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51  :userA:
> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36  :devB:
> --8<---cut here---end--->8---
That sounds good also.

> Though, having separate CLOCK drawers would even be better for Git merges,
> such as (keeping the idea of pseudo-tags):
>
> --8<---cut here---start->8---
> :CLOCK:userA:
> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
> :END:
> :CLOCK:devB:
> CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
> :END:
> --8<---cut here---end--->8---
I really like this solution.

> But, of course, a lot of development is required to make this become usable:
>
> - clocking reports (`R') must be updated with the knowledge of the current
>   user
>
> - clock checking functions (`v c') must be enhanced to ignore clocks from
>   other users
>
> - etc.
That is my point with the solution by customization of
org-clock-string. It appears to need only a few corrections of the hard
coded "CLOCK:" string (that would be required anyway) and it looks like
it would work out of the box without further development. Wouldn't it?

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature


Re: [O] [SYNC] How do you sync your org-mode files between n devices (n > 2)

2013-09-05 Thread Alan Schmitt
fatkasuvayu+li...@gmail.com writes:

> I think the issue with tools like Unison, Dropbox, is conflict
> resolution on simultaneous edits.  Traditional version control does a
> better job of that, but then it loses the convenience of these other
> tools.
>
> I believe there is a list member (Alan) close to Unison development; in
> the thread referenced by Samuel there is some discussion on how this
> could be done in a more well defined manner.

Unison can call external tools to merge conflicting files. If someone
wants to use such a tool with unison, I can definitely give a hand.

Alan



Re: [O] ATTR_LATEX not being applied on dynamic blocks

2013-09-05 Thread Francesco Pizzolante


Hello Nicolas,

Nicolas Goaziou wrote:
> "Francesco Pizzolante"  writes:
>
>> But if I try what you suggest and move the #+ATTR_LATEX line inside the
>> dynamic block (after the #+BEGIN: clocktable and just before the generated
>> table), then this line gets lost as soon as the dynamic block is
>> regenerated, which is not what I expect.
>
> Then some attribute could be added to dynamic block arguments in order to
> re-create the ATTR_LATEX keyword each time. IIRC we did that for #+CAPTION
> some months ago. It shouldn't be difficult to do it for this one.

I've seen, indeed (thanks!), that there was a ":header" option, which you can
use to add free text in front of the dynamic table.

--8<---cut here---start->8---
#+BEGIN: clocktable :maxlevel 2 :scope ("clock-file.org") :block 2013-08 
:fileskip0 t :lang "en" :header "#+ATTR_LaTeX: :environment longtabu :align 
lXrr\n"
#+ATTR_LaTeX: :environment longtabu :align lXrr
| File   | Headline|   Time |  |
|+-++--|
|| ALL Total time  |   1:44 |  |
|+-++--|
| clock-file.org | File time   | *1:44* |  |
|| Projet management   |   1:44 |  |
|| \__ Writing reports || 1:44 |
#+END:

Though, doing so, there is no CAPTION anymore...

I could add it in the "header", but then I loose the auto-generated (and
useful) stuff in the caption itself:

#+CAPTION: Clock summary at [2013-09-04 Wed 14:22], for August 2013.
--8<---cut here---end--->8---
 ^  ^^^
 useful very useful

Maybe adding a ":header" should not strip the autogenerated caption?

>> With Org 7, having the #+ATTR_LATEX line just before the #+BEGIN:
>> clocktable line applies the attributes to the inner table of the dynamic
>> block and the #+ATTR_LATEX line is not lost each time I regenerate the
>> dynamic block.
>
> This is not possible anymore.

OK.

Regards,
 Francesco




[O] running some elisp code when exporting a given file

2013-09-05 Thread Alan Schmitt
Hello,

I would like to inline a css when exporting a file to html, but I don't
know how to tell org-mode to set the variable org-html-head from within
the file.

Here is what I tried: I added the following block at the beginning of my
file:

--8<---cut here---start->8---
#+BEGIN_SRC emacs-lisp :exports none
  (set (make-local-variable 'org-html-head) (concat
 "\n"
 "\n"
 "\n"))
#+END_SRC
--8<---cut here---end--->8---

It does not seem to be evaluated, however.

Is there a way to have arbitrary code stored in the file being exported
being evaluated before an export?

Thanks,

Alan



Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Sebastien Vauban
Samuel Loury wrote:
> I recently encountered the issues of having to collaborate with other
> persons on the same task (all of us would need at some point to clock
> into this task).
>
> I thought that changing the value of the variable org-clock-string could
> help, but I have not tried it yet. Let me explain why it could help:
>
> It is for the time being set to "CLOCK:", but imagine that the user A
> set it to "CLOCK-A:" and the user B set it to "CLOCK-B:" (in their
> respective .emacs files), then after some time a clocked task would then
> look like:
>
> * Do something
>   CLOCK-A: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
>   CLOCK-A: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
>   CLOCK-B: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
>
> Then the agenda for each user would report only the time spent by
> himself.
>
> The time spent by each participant is clearly separated.
>
> There are some problems with doing so:
> - I don't know yet how to configure a report showing the time spent by
> every body,
> - I am not sure the clock time sum would work.
> - grepping for "CLOCK:" on org sources shows:
>   --8<---cut here---start->8---
>   ./lisp/org-clock.el:782:(while (re-search-forward "CLOCK: 
> \\(\\[.*?\\]\\)$" nil t)
>   ./lisp/org.el:851: (defcustom org-clock-string "CLOCK:"
>   ./lisp/org.el:8501:   (while (re-search-forward "^[ 
> \t]*CLOCK:.*$" nil t)
>   ./lisp/org.el:15007: (defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ 
> \t]*$"
>   ./lisp/org.el:15578: (while (looking-at "^[
> \t]*\\(:CLOCK:\\|:LOGBOOK:\\|CLOCK:\\|:END:\\)")
>   ./lisp/org.el:15579:   (if (member (match-string 1) '("CLOCK:" ":END:"))
>   ./lisp/org.el:17278: (looking-at "^[ \t]*CLOCK:")))
>   --8<---cut here---end--->8---
>   Those look like "hard coded" "CLOCK:" instead of using
>   org-clock-string. They would need to be fixed.
>
> What do you think of this solution? Has anyone already use a solution
> like this?
>
> Best,
>
> PS: I have tried changing the org-clock-into-drawer variable to be
> "CLOCK-A" and "CLOCK-B" so that the task would then look like 
> * Do something
>   :CLOCK-A:
>   CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
>   CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
>   :END:
>   :CLOCK-B:
>   CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
>   :END:
> But it needs org-drawers to contain the values for each collaborators
> for it to work (and then should be maintained) and the folding mechanism
> did not seem to work for those special drawers.

Having thought about that in the past, I had thought of adding "tags" after
clock lines, such as:

--8<---cut here---start->8---
CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51  :userA:
CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36  :devB:
--8<---cut here---end--->8---

Though, having separate CLOCK drawers would even be better for Git merges,
such as (keeping the idea of pseudo-tags):

--8<---cut here---start->8---
:CLOCK:userA:
CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
:END:
:CLOCK:devB:
CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
:END:
--8<---cut here---end--->8---

But, of course, a lot of development is required to make this become usable:

- clocking reports (`R') must be updated with the knowledge of the current
  user

- clock checking functions (`v c') must be enhanced to ignore clocks from
  other users

- etc.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Collaborating with TODO lists and clocks.

2013-09-05 Thread Samuel Loury
Hi,
Richard Lawrence  writes:

> Hi Gareth,
>
> Gareth Smith  writes:
>
>> I hadn't thought of using :tags on a clock table. I still worry if we'll
>> find ourselves in a situation where more than one of us has clocked in
>> some time on the same task.
>
> Yes, I agree this might not be optimal, for that case in particular.
> One nice thing about this use of tags is that you have a representation
> of when more than one person is working on a task, but that makes the
> clock less useful, as it can no longer represent an individual's working
> time without some effort to separate the clocks of the different owners.
I recently encountered the issues of having to collaborate with other
persons on the same task (all of us would need at some point to clock
into this task).

I thought that changing the value of the variable org-clock-string could
help, but I have not tried it yet. Let me explain why it could help:

It is for the time being set to "CLOCK:", but imagine that the user A
set it to "CLOCK-A:" and the user B set it to "CLOCK-B:" (in their
respective .emacs files), then after some time a clocked task would then
look like:

--8<---cut here---start->8---
* Do something
  CLOCK-A: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
  CLOCK-A: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
  CLOCK-B: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
--8<---cut here---end--->8---

Then the agenda for each user would report only the time spent by
himself.

The time spent by each participant is clearly separated.

There are some problems with doing so:
- I don't know yet how to configure a report showing the time spent by
every body,
- I am not sure the clock time sum would work.
- grepping for "CLOCK:" on org sources shows:
  --8<---cut here---start->8---
  ./lisp/org-clock.el:782:  (while (re-search-forward "CLOCK: 
\\(\\[.*?\\]\\)$" nil t)
  ./lisp/org.el:851: (defcustom org-clock-string "CLOCK:"
  ./lisp/org.el:8501: (while (re-search-forward "^[ \t]*CLOCK:.*$" nil 
t)
  ./lisp/org.el:15007: (defconst org-clock-drawer-start-re "^[ \t]*:CLOCK:[ 
\t]*$"
  ./lisp/org.el:15578: (while (looking-at "^[ 
\t]*\\(:CLOCK:\\|:LOGBOOK:\\|CLOCK:\\|:END:\\)")
  ./lisp/org.el:15579:   (if (member (match-string 1) '("CLOCK:" ":END:"))
  ./lisp/org.el:17278: (looking-at "^[ \t]*CLOCK:")))
  --8<---cut here---end--->8---
  Those look like "hard coded" "CLOCK:" instead of using
  org-clock-string. They would need to be fixed.

What do you think of this solution? Has anyone already use a solution
like this?

Best,

PS: I have tried changing the org-clock-into-drawer variable to be
"CLOCK-A" and "CLOCK-B" so that the task would then look like 
--8<---cut here---start->8---
* Do something
  :CLOCK-A:
  CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =>  0:51
  CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =>  0:36
  :END:
  :CLOCK-B:
  CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =>  1:03
  :END:
--8<---cut here---end--->8---
But it needs org-drawers to contain the values for each collaborators
for it to work (and then should be maintained) and the folding mechanism
did not seem to work for those special drawers.

-- 
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A


signature.asc
Description: PGP signature