[O] Help proofreading ORG-NEWS for Org 8.1
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
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
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'?
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)
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)
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'?
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)
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
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)
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)
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
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)
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)
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))
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)
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'?
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?
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
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?
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)
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.
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.
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)
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))
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)
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
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
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)
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?
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
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
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)
> 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?
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?
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.
"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?
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)
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
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?
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)
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.
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)
* 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
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?
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
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)
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)
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.
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)
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
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
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.
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.
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
