Re: [O] how to group together fields

[Michael Brand]

Hi Stefan

On Sun, Feb 23, 2014 at 2:12 AM, Stefan Huchler  wrote:
> that works great, sadly I have to type in the name of the shop
> redundantly but I can live with that, with a good org-capture template I
> could tab-complete them so it would not be that problem.
>
> I dont want to bother you endlessly but just if you happen to know that
> randomly:
>
> can you somehow define a template that autocompletes to all other values
> like that:
>
> %^{Shop|shop 1|shop 2|**all-knows-old-choices**}

Although there are many completion tools I doubt that there is one
which knows in which Org table column you are.
http://www.emacswiki.org/emacs/CategoryCompletion

But [...]_ALL to predefine Org property values to be selected easily
in the column view as described here
http://orgmode.org/manual/Property-syntax.html
knows in which column you are. To make benefit of this you could use a
flat tree with an entry for each purchase and a property for product,
shop and rating and capture the column view with
http://orgmode.org/manual/Capturing-column-view.html
into the known table "#+NAME: data" to be processed further.

> A second question for me in trying to understand your code:
>
>  @I$4..@>$4
>
> I get @> stands for something like first line or is it a * wildcard? I
> should find that somewhere in doku but what does @I stand for?

@> is the last row, @I is the first hline to exclude the table header
that could have more than one line. For both and more see
http://orgmode.org/manual/References.html

Michael

Re: [O] Unable to get file link search to work

[Christian Moe]

Hi,

Just to say, I reproduce it, so I think it's a bug. Note, the below only
happens for me when using "file+emacs:" to force opening in emacs. The
links work with regular "file:" links, or just starting the link with
"./" Since my .org files open with emacs anyway, I normally wouldn't
add "+emacs". But the manual suggests I could.

Yours,
Christian

Alexis writes:

> Bump. Any suggestions as to whether the below is me doing something
> wrong (more likely) or a bug (less likely)?
>
> Thanks!
>
>
> Alexis  writes:
>
>> Hi all,
>>
>> i'm running org-mode 8.2.5h in Emacs 24.3.
>>
>> Say i have file a.org:
>>
>>   * Main
>>   ** Group
>>   *** Firstname Lastname
>>
>> My reading of
>>
>> http://orgmode.org/manual/External-links.html#External-links
>>
>> and
>>
>> http://orgmode.org/manual/Search-options.html#Search-options
>>
>> is that i should be able to, in b.org - which resides in the same
>> directory as a.org - have something like:
>>
>>   [[file+emacs:a.org::*Firstname]]
>>
>> such that when i move point over that link, and enter C-c C-o
>> (i.e. org-open-at-point), i will be taken to a buffer containing a.org,
>> with point on the 'Firstname Lastname' heading. Instead, what happens is
>> that a new buffer is created, attached to a new file called, literally,
>> 'a.org::*Firstname'.
>>
>> Similarly, if in b.org i have something like:
>>
>>   [[file+emacs:a.org::2]]
>>
>> i am not taken to line 2 of a.org, but instead to a new buffer attached
>> to a new file literally called 'a.org::2'.
>>
>> i have observed this behaviour with
>> org-link-search-must-match-exact-headline set to either 'query-to-create
>> or to nil.
>>
>> What am i doing wrong?
>>
>>
>> Alexis.

Re: [O] Tables with line wrapping?

[Jambunathan K]

Peter Davis  writes:

> I'm using org-mode to prepare a document that will ultimately be
> exported to PDF. Unfortunately, I need to include a table whose contents
> will wrap as needed.

You can export to PDF via ODT.  Use list tables.  See the links at the
end of the following post.

https://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg01101.html

The list items (that you see below) is not limited to single lines but
can be multi-line, multi-paragraph (including inline image links).  The
Hrules are optional.

Some of the attributes you see below won't work on Org trunk but will
work on my ELPA package.

http://cauvery.nfshost.com/wiki.pl/ODT_Exporter

--8<---cut here---start->8---
#+ATTR_ODT: :widths 1,2,4,8
#+ATTR_ODT: :rel-width 80
#+ATTR_ODT: :list-table t
- -
- Row 1
  - 1.1
  - 1.2
  - 1.3
- -
- Row 2
  - 2.1
  - 2.2
  - 2.3
- -
--8<---cut here---end--->8---

Re: [O] Tables with line wrapping?

[Peter Davis]

On Sat, Feb 22, 2014 at 01:05:34PM -0800, Richard Lawrence wrote:
> 
> What about just maintaining the table as an embedded LaTeX block? e.g.
> 
> ... your Org text here ...
> #+BEGIN_LATEX
> \begin{tabular} % or wrap with \begin{table} if you need, etc.
> % ...
> \end{tabular}
> #+END_LATEX
> 
> That way, at least, you can edit your document and the table at the same
> time and in the same file, though it means giving up Org's nice table
> editing features.

Thank you, Richard! I was not aware of this, but it seems like it would have a 
slew of uses. (My first thought it to embed pstricks graphics into my 
documents, but then I'd have to bypass pdflatex and use xelatex or something 
instead.)

Thank you!

-pd


-- 

Peter Davis
The Tech Curmudgeon
www.techcurmudgeon.com

Re: [O] Tables with line wrapping?

[Peter Davis]

On Sat, Feb 22, 2014 at 11:01:45AM -1000, Thomas S. Dye wrote:
> 
> You can set the :align attribute.  Something like this will wrap the
> second column in the pdf file:
> 
>   #+ATTR_LATEX :align lp{6cm}
>   | col | wrapcol |

Hi, Thomas,

Excellent! Sorry I was completely unaware of this. That solves my problem 
perfectly.

Thank you!

-pd


-- 

Peter Davis
The Tech Curmudgeon
www.techcurmudgeon.com

Re: [O] controling width of graphviz source block result

[regcl]

Nicolas Goaziou  writes:

> Hello,
>
> regcl  writes:
>
>> So I am understanding from your answer that attribues only "modify" the
>> next immediate "thing" in the .org document, and do not persist, so to
>> speak.
>
> "things" are called "elements" in Org lingo and "attributes" are called
> "affiliated keywords". So, yes, affiliated keywords apply to the element
> right after them.
>
>> But I have discovered that it works to stack them up like this ...
>>
>> #+ATTR_HTML: :width 1000
>> #+ATTR_ODT: :width 15 :height 15
>> [[file:gnus.png]]
>>
>> ... so I am a little confused. 
>>
>> Could you please clarify?
>
> Both keywords are affiliated keywords. There is only one element in this
> example (a paragraph containing a single link). Affiliated keywords
> apply to the next element, not the next affiliated keyword.
>
> For more information, see:
>
>   http://orgmode.org/worg/dev/org-syntax.html
>
> or the comments at the beginning of "org-element.el".
>
>
> Regards,

Thank you, this is helpful. May require a little study ;)

best,
regcl

Re: [O] Unable to get file link search to work

[Alexis]

Bump. Any suggestions as to whether the below is me doing something
wrong (more likely) or a bug (less likely)?

Thanks!


Alexis  writes:

> Hi all,
>
> i'm running org-mode 8.2.5h in Emacs 24.3.
>
> Say i have file a.org:
>
>   * Main
>   ** Group
>   *** Firstname Lastname
>
> My reading of
>
> http://orgmode.org/manual/External-links.html#External-links
>
> and
>
> http://orgmode.org/manual/Search-options.html#Search-options
>
> is that i should be able to, in b.org - which resides in the same
> directory as a.org - have something like:
>
>   [[file+emacs:a.org::*Firstname]]
>
> such that when i move point over that link, and enter C-c C-o
> (i.e. org-open-at-point), i will be taken to a buffer containing a.org,
> with point on the 'Firstname Lastname' heading. Instead, what happens is
> that a new buffer is created, attached to a new file called, literally,
> 'a.org::*Firstname'.
>
> Similarly, if in b.org i have something like:
>
>   [[file+emacs:a.org::2]]
>
> i am not taken to line 2 of a.org, but instead to a new buffer attached
> to a new file literally called 'a.org::2'.
>
> i have observed this behaviour with
> org-link-search-must-match-exact-headline set to either 'query-to-create
> or to nil.
>
> What am i doing wrong?
>
>
> Alexis.

Re: [O] how to group together fields

[Stefan Huchler]

thank you Michael,

that works great, sadly I have to type in the name of the shop
redundantly but I can live with that, with a good org-capture template I
could tab-complete them so it would not be that problem.

I dont want to bother you endlessly but just if you happen to know that
randomly:

can you somehow define a template that autocompletes to all other values
like that:

%^{Shop|shop 1|shop 2|**all-knows-old-choices**}

that would that make perfekt but I think thats maybe a wet dream ;)

A second question for me in trying to understand your code:

 @I$4..@>$4

I get @> stands for something like first line or is it a * wildcard? I
should find that somewhere in doku but what does @I stand for?

Maybe I should not try to understand it ;)

Thx again ;)

Re: [O] [patch] Support CUSTOM_ID property in latex export

[Richard Lawrence]

Hi Nicolas and all,

OK, I think I've got a patch now that addresses everything you asked
for.  It is attached.  This has been quite a learning experience!  Let
me know if other changes are necessary.  

>From 07bfc34a48858aa386c0416e592082610c913ef3 Mon Sep 17 00:00:00 2001
From: Richard Lawrence 
Date: Fri, 21 Feb 2014 11:22:08 -0800
Subject: [PATCH] Support using CUSTOM_ID property to generate section labels
 during LaTeX export
To: emacs-orgmode@gnu.org
Cc: n.goaz...@gmail.com

This allows the user to control how Org generates label keys for
headlines during LaTeX export, and thus to know their keys in advance.
This is useful for e.g. using \ref commands inside of embedded LaTeX
blocks.

* lisp/ox-latex.el:
  (defcustom org-latex-custom-id-as-label): Variable to control using
CUSTOM_ID values as labels during export

  Backend definition: Add :latex-custom-id-labels option to backend's
:options-alist, using value of org-latex-custom-id-as-label to
define its behavior

  (org-latex-headline): Optionally generate label keys based on CUSTOM_ID,
depending on value of :latex-custom-id-labels option

  (org-latex-link): Optionally generate refs based on CUSTOM_ID,
depending on value of :latex-custom-id-labels option

This change was discussed in the following thread:
http://thread.gmane.org/gmane.emacs.orgmode/82392
---
 lisp/ox-latex.el |   84 +++---
 1 file changed, 73 insertions(+), 11 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 5815874..4ae4bf4 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -106,7 +106,8 @@
 		   (:latex-class-options "LATEX_CLASS_OPTIONS" nil nil t)
 		   (:latex-header "LATEX_HEADER" nil nil newline)
 		   (:latex-header-extra "LATEX_HEADER_EXTRA" nil nil newline)
-		   (:latex-hyperref-p nil "texht" org-latex-with-hyperref t))
+		   (:latex-hyperref-p nil "texht" org-latex-with-hyperref t)
+		   (:latex-custom-id-labels nil nil org-latex-custom-id-as-label))
   :filters-alist '((:filter-options . org-latex-math-block-options-filter)
 		   (:filter-parse-tree . org-latex-math-block-tree-filter)))
 
@@ -375,6 +376,59 @@ which format headlines like for Org version prior to 8.0."
   :package-version '(Org . "8.0")
   :type 'function)
 
+(defcustom org-latex-custom-id-as-label nil
+   "Toggle use of CUSTOM_ID properties for generating section labels.
+
+When this variable is non-nil, Org will use the value of a
+headline's CUSTOM_ID property as the key for the \\label command
+for the LaTeX section corresponding to the headline.
+
+By default, Org generates its own internal section labels for all
+headlines during LaTeX export.  This process ensures that the
+\\label keys are unique and valid, but it means the keys are not
+available in advance of the export process.
+
+Setting this variable gives you control over how Org generates
+labels for sections during LaTeX export, so that you may know
+their keys in advance.  One reason to do this is that it allows
+you to refer to headlines using a single label both in Org's link
+syntax and in embedded LaTeX code.
+
+For example, when this variable is non-nil, a headline like this:
+
+  ** Some section
+ :PROPERTIES:
+ :CUSTOM_ID: sec:foo
+ :END:
+  This is section [[#sec:foo]].
+  #+BEGIN_LATEX
+  And this is still section \\ref{sec:foo}.
+  #+END_LATEX
+
+will be exported to LaTeX as:
+
+  \\subsection{Some section}
+  \\label{sec:foo}
+  This is section \\ref{sec:foo}.
+  And this is still section \\ref{sec:foo}.
+
+Note, however, that setting this variable introduces a limitation
+on the possible values for CUSTOM_ID.  When this variable is
+non-nil and a headline defines a CUSTOM_ID value, Org simply
+passes this value to \\label unchanged.  You are responsible for
+ensuring that the value is a valid LaTeX \\label key, and that no
+other \\label commands with the same key appear elsewhere in your
+document.  (Keys may contain letters, numbers, and the following
+punctuation: '_' '.' '-' ':'.)  There are no such limitations on
+CUSTOM_ID when this variable is nil.
+ 
+For headlines that do not define the CUSTOM_ID property, Org will
+continue to use its default labeling scheme to generate labels
+and resolve links into section references."
+  :group 'org-export-latex
+  :type 'boolean
+  :version "24.5"
+  :package-version '(Org . "8.3"))
 
  Footnotes
 
@@ -1373,10 +1427,14 @@ holding contextual information."
 			   todo todo-type priority text tags))
 	   ;; Associate \label to the headline for internal links.
 	   (headline-label
-	(format "\\label{sec-%s}\n"
-		(mapconcat 'number-to-string
-			   (org-export-get-headline-number headline info)
-			   "-")))
+	(let ((custom-label (and (plist-get info :latex-custom-id-labels)
+ (org-element-property :CUSTOM_ID headline
+	  (if custom-label
+		  (format "\\label{%s}\n" custom-label)
+		(format "\\label{sec-%s}\n"
+			(mapconcat 'number-

Re: [O] List of figures

[Rasmus]

t...@tsdye.com (Thomas S. Dye) writes:

> 1) Is there a reason that the TOC keyword doesn't accept the value
> "figures"? The reference to org-export-collect-figures suggests that it
> should accept this value.

AFAIK it is not supported.  It has puzzled me as well.  It's trivial
to make a patch for ox-latex; the hard part is adding it to other
backends.

> 2) Is there some other way to generate a list of figures for LaTeX
> export?

There's the obvious one:

#+LATEX: \listoffigures

But that's probably not what you're looking for.

As you'll see from org-latex-keyword you can also "cheat" Org by
setting org-latex-listings to nil and use #+TOC: listings.

Hope it helps,
Rasmus

-- 
May contains speling mistake

[O] List of figures

[Thomas S. Dye]

Aloha all,

I'm trying to generate a list of figures for LaTeX export.  I thought to
use #+TOC: figures, but this didn't work.

The Org Export Reference Documentation has this:

  “TOC” keyword. It accepts three common values: “headlines”, “tables” and
  “listings”. Also, “headlines” value can have an optional numeric
  argument to specify depth of the contents.

  See org-export-collect-headlines, org-export-collect-tables,
  org-export-collect-figures and org-export-collect-listings.

Two questions:

1) Is there a reason that the TOC keyword doesn't accept the value
"figures"? The reference to org-export-collect-figures suggests that it
should accept this value.

2) Is there some other way to generate a list of figures for LaTeX
export?

All the best,
Tom
-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: [O] [patch] Support CUSTOM_ID property in latex export

[Nicolas Goaziou]

Richard Lawrence  writes:

> True, it is explained that CUSTOM_ID must be unique, but not that the
> generated label must be.  I have changed this to:
>
> "You are responsible for ensuring that the value is a valid LaTeX
> \\label key, and that no other \\label commands with the same key appear
> elsewhere in your document."
>
> That seems clearer to me; it forbids e.g. introducing labels with the
> same key on a #+LATEX: line.  Sound good?

Fair enough.

> I can't actually find a clear explanation anywhere of exactly what is
> and isn't allowed in a label key.  All the LaTeX documentation seems to
> just say:
>
> "A key can consist of any sequence of letters, digits, or punctuation
> characters. Upper and lowercase letters are different."
>
> But clearly, the issue is what sort of "punctuation" is allowed.  ":"
> and "_" are OK, but "%" and "$" aren't...is there a definitive list
> somewhere I should refer to?

I don't know any.

> Maybe I should just say the user should have a look at the regexp in
> org-export-solidify-link-text?

Besides alphanumeric characters, this function allows "_", ".", "-" and
":". I think it is safe to assume only these punctuation characters are
allowed.

Also, the docstring should insist on the fact that this limitation only
applies when the variable is non-nil.

>> There is one thing to consider here. We can define the new variable as
>> a back-end options, i.e., add
>>
>>   (:latex-manual-id nil nil org-latex-custom-id-as-label)
>>
>>
>> in the back-end definition (the name of the property doesn't matter
>> much, you can change it).
>
>>
>> This is not strictly necessary, but it allows, for example, to change
>> its value for specific projects (in the publishing sense) without
>> setting the variable globally.
>>
>> If you think it is useful to do so,
>>
>>   (and org-latex-custom-id-as-label
>>
>> should become
>>
>>   (and (plist-get info :latex-manual-id)
>>
>>> +  (let* ((custom-label (and org-latex-custom-id-as-label
>>> +   (org-element-property :CUSTOM_ID 
>>> destination)))
>>
>> Ditto.
>>
>
> OK, that sounds like a good idea, but are these the only changes that
> would be necessary?

Yes.

> Where should the name of the back-end option and its relationship to
> this variable be documented?

Probably in:

  (info "(org) Publishing options")

Unfortunately, only generic and html-specific options are described
there. We could add a LaTeX section (but it wouldn't contain much).


Regards,

-- 
Nicolas Goaziou

Re: [O] Tables with line wrapping?

[Richard Lawrence]

Hi Peter,

Peter Davis  writes:

> I'm using org-mode to prepare a document that will ultimately be
> exported to PDF. Unfortunately, I need to include a table whose contents
> will wrap as needed.

I've run into this problem before too, but I haven't found a good
solution. (Though I haven't looked that hard.)  Maybe someone else will
have a better suggestion than the workaround I've used (see below).

> The options I can see are:
>
> 1) Do everything I can in org-mode, then export and edit the
> intermediate .tex file, or
>
> 2) Create the table with some other tool, and include it as an image
> into the org document
>
> Am I missing anything? Are there other (better?) ways? As I expect to be
> revising both the table and the rest of the document for a while, the
> uni-directional workflow in #1 above would be difficult.

What about just maintaining the table as an embedded LaTeX block? e.g.

... your Org text here ...
#+BEGIN_LATEX
\begin{tabular} % or wrap with \begin{table} if you need, etc.
% ...
\end{tabular}
#+END_LATEX

That way, at least, you can edit your document and the table at the same
time and in the same file, though it means giving up Org's nice table
editing features.
 
Best,
Richard

Re: [O] Tables with line wrapping?

[Thomas S. Dye]

Aloha Peter,

Peter Davis  writes:

> I'm using org-mode to prepare a document that will ultimately be
> exported to PDF. Unfortunately, I need to include a table whose contents
> will wrap as needed. The options I can see are:
>
> 1) Do everything I can in org-mode, then export and edit the
> intermediate .tex file, or
>
> 2) Create the table with some other tool, and include it as an image
> into the org document
>
> Am I missing anything? Are there other (better?) ways? As I expect to be
> revising both the table and the rest of the document for a while, the
> uni-directional workflow in #1 above would be difficult.

You can set the :align attribute.  Something like this will wrap the
second column in the pdf file:

  #+ATTR_LATEX :align lp{6cm}
  | col | wrapcol |

You might also want to look at the LaTeX tabularx environment if you
want the table to be a particular width.

hth,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] [patch] Support CUSTOM_ID property in latex export

[Richard Lawrence]

Hi Nicolas and all,

Thanks for your feedback.  I have a couple of questions about your
comments:

Nicolas Goaziou  writes:

> I think you can remove "that it is unique throughout the generated
> document", as it is already explained in the manual, and not specific to
> this variable.

True, it is explained that CUSTOM_ID must be unique, but not that the
generated label must be.  I have changed this to:

"You are responsible for ensuring that the value is a valid LaTeX
\\label key, and that no other \\label commands with the same key appear
elsewhere in your document."

That seems clearer to me; it forbids e.g. introducing labels with the
same key on a #+LATEX: line.  Sound good?

> OTOH, it would be nice to specify what is a valid \label key (e.g.,
> forbidden characters) and that the default value doesn't have this
> limitation (otherwise, that wouldn't be much of a trade-off).
>
>> +(let ((custom-label (and org-latex-custom-id-as-label
>> + (org-element-property :CUSTOM_ID 
>> headline
>

I can't actually find a clear explanation anywhere of exactly what is
and isn't allowed in a label key.  All the LaTeX documentation seems to
just say:

"A key can consist of any sequence of letters, digits, or punctuation
characters. Upper and lowercase letters are different."

But clearly, the issue is what sort of "punctuation" is allowed.  ":"
and "_" are OK, but "%" and "$" aren't...is there a definitive list
somewhere I should refer to?  Maybe I should just say the user should
have a look at the regexp in org-export-solidify-link-text?

> There is one thing to consider here. We can define the new variable as
> a back-end options, i.e., add
>
>   (:latex-manual-id nil nil org-latex-custom-id-as-label)
>
>
> in the back-end definition (the name of the property doesn't matter
> much, you can change it).

>
> This is not strictly necessary, but it allows, for example, to change
> its value for specific projects (in the publishing sense) without
> setting the variable globally.
>
> If you think it is useful to do so,
>
>   (and org-latex-custom-id-as-label
>
> should become
>
>   (and (plist-get info :latex-manual-id)
>
>> +   (let* ((custom-label (and org-latex-custom-id-as-label
>> +(org-element-property :CUSTOM_ID 
>> destination)))
>
> Ditto.
>

OK, that sounds like a good idea, but are these the only changes that
would be necessary?  Where should the name of the back-end option and
its relationship to this variable be documented?

Best,
Richard


(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)

Re: [O] how to group together fields

[Michael Brand]

Hi Stefan

On Mon, Feb 3, 2014 at 4:25 PM, Stefan Huchler  wrote:
> I get with the 1. COLUMNS line something like that:
>
> Tea Shop 1 |  5.0   | ...
> Tea Shop 2 |  7.0   | ...
>
> I want another output that looks like that:
>
> Blend 1|  6.0   | ...
> Blend 2|  3.0   | ...

My suggestion for these several GROUP BY as in SQL on the same data is
to use Org babel with R or TBLFM.

I am not a user of the R programming language and therefore can not
provide a working example but it would be one of the simpler
solutions. Put all data into one Org table just like "#+NAME: data"
below and for each result table use an Org babel source block with R
that reads from this table.

Some R example of GROUP BY as in SQL:
http://stats.stackexchange.com/questions/8225/how-to-summarize-data-by-group-in-r

With TBLFM the only thing that comes to my mind is org-lookup-all. The
disadvantage of this solution is that you have to enumerate all groups
manually in the result tables:

#+NAME: data
| Purchase | Product | Shop | Rating |
|--+-+--+|
| a| p1  | s1   |  1 |
| b| p1  | s2   |  4 |
| c| p2  | s1   |  2 |
| d| p3  | s2   |  8 |

Product rating and ranking by average purchase:

| Product | Rating | Ranking |
|-++-|
| p1  |2.5 |   2 |
| p2  |2.0 |   3 |
| p3  |8.0 |   1 |
#+TBLFM: $2 = '(let ((all (org-lookup-all '$1 '(remote(data,
@I$2..@>$2)) '(remote(data, @I$4..@>$4) (/ (apply '+ all) (length
all) 1.0)); L :: $3 = '(+ 1 (length (org-lookup-all $2 '(@I$2..@>$2)
nil '<))); N

Shop rating and ranking by average purchase:

| Shop | Rating | Ranking |
|--++-|
| s1   |1.5 |   2 |
| s2   |6.0 |   1 |
#+TBLFM: $2 = '(let ((all (org-lookup-all '$1 '(remote(data,
@I$3..@>$3)) '(remote(data, @I$4..@>$4) (/ (apply '+ all) (length
all) 1.0)); L :: $3 = '(+ 1 (length (org-lookup-all $2 '(@I$2..@>$2)
nil '<))); N

I added the above TBLFM solution as an ERT that can also be found via
Worg: On the page with the Worg tutorials in the spreadsheet section
follow the link to the "Emacs Regression Test (ERT) for Org tables"
with example use cases for TBLFM:
http://orgmode.org/worg/org-tutorials/index.html#Spreadsheet
In the ERT it is test-org-table/org-lookup-all.

Michael

[O] Tables with line wrapping?

[Peter Davis]

I'm using org-mode to prepare a document that will ultimately be
exported to PDF. Unfortunately, I need to include a table whose contents
will wrap as needed. The options I can see are:

1) Do everything I can in org-mode, then export and edit the
intermediate .tex file, or

2) Create the table with some other tool, and include it as an image
into the org document

Am I missing anything? Are there other (better?) ways? As I expect to be
revising both the table and the rest of the document for a while, the
uni-directional workflow in #1 above would be difficult.

Thanks!

-pd


-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Alan Schmitt]

Xebar Saram  writes:

> one thing though, is there a way to define which client it oepns? i have
> several emacs client opened at once and prefer the extension nowt to use
> a current one but pop up a new CLI emacsclient for quick adding which
> will go away after i finish capturing, is that possible?

I have a shell script bound to a key here to allow capture everywhere.
It's like this:

#+begin_src sh
  /usr/local/bin/emacsclient -n -e '(make-orgcapture-frame)'
#+end_src

The function is as follows (I also include my capture settings, which
are relevant here):

#+BEGIN_SRC emacs-lisp
  (setq org-capture-templates
(quote
 (("t" "todo" entry (file "refile-orgx.org")
   "* TODO %?\n %U")
  ("T" "todo with link" entry (file "refile-orgx.org")
   "* TODO %?\n %U\n\n%a"
  
  (define-key global-map "\C-cr" 'org-capture)
  
  ;; to be called from outside using
  ;; emacsclient -n -e '(make-orgcapture-frame)'
  
  (defun make-orgcapture-frame ()  
"Create a new frame and run org-capture."  
(interactive)  
(make-frame '((name . "remember") (width . 80) (height . 16)
  (top . 400) (left . 300)
  (font . 
"-*-Consolas-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1")
  ))
(select-frame-by-name "remember")
(delete-other-windows)
(flet ((switch-to-buffer-other-window (buf) (switch-to-buffer buf)))
  (org-capture nil "t")))
  
  ;; delete the frame in that case
  (add-hook 'org-capture-after-finalize-hook
(lambda ()
  (when (equal
 (cdr (assoc 'name (frame-parameters (selected-frame
 "remember")
(delete-frame
#+END_SRC

Maybe you can adapt this for this firefox plugin.

Alan

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Erik Hetzner]

At Sat, 22 Feb 2014 17:27:26 +0100,
Olivier Schwander wrote:
> 
> Le 21 Feb 2014 18:22, Erik Hetzner a écrit:
> > I had to start emacsclient in a terminal, probably because my emacs
> > was run with emacs --daemon ? I made a little wrapper script that runs
> > emacsclient in a terminal.
> 
> Are you happy with the wrapper ? The other solution would be to give
> full control on the command line launched, but I think I will be too
> complex.

Hi Olivier,

I did a little more debugging. I think the issue I had is that if the
user starts emacs with `emacs --daemon` and has no current frame for
that emacs, your extension will not work, because the behavior of
emacsclient when no frame exists is to run in the terminal, and this
doesn’t work from Firefox.

Maybe the solution is to use the `-c` option to emacsclient by
default to create a new frame?

best, Erik

-- 
Sent from my free software system .

Re: [O] Timestamps in properties not exported by icalendar exporter

[David Engster]

Nicolas Goaziou writes:
> David Engster  writes:
>
>> I'm actually not sure what org-element is capable of nowadays. What I'd
>> like to have is a way to parse entries into a structure
>
> See `org-element-parse-buffer'.
>
>> which lets me access certain elements of the entry, like headline,
>> timestamps, properties, body text, etc.,
>
> See `org-element-map'.
>
>> and also a way to convert this structure *back* to a plain Org entry.
>
> See `org-element-interpret-data'.

I had a hunch you already implemented all this. :-)

I'll look into it.

Thanks,
-David

Re: [O] Timestamps in properties not exported by icalendar exporter

[Nicolas Goaziou]

David Engster  writes:

> I'm actually not sure what org-element is capable of nowadays. What I'd
> like to have is a way to parse entries into a structure

See `org-element-parse-buffer'.

> which lets me access certain elements of the entry, like headline,
> timestamps, properties, body text, etc.,

See `org-element-map'.

> and also a way to convert this structure *back* to a plain Org entry.

See `org-element-interpret-data'.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-export-latex-hyperref-options-format

[Bastien]

Hi Joe,

Joe Hirn  writes:

> Where can I clone the master branch from?

This should do the trick:

~$ git clone git://orgmode.org/org-mode.git

Best,

-- 
 Bastien

Re: [O] org-export-latex-hyperref-options-format

[Joe Hirn]

Where can I clone the master branch from? I requested access to clone it
from the contribution page but was told that's reserved for frequent
committers. I generated this patch against the most recent version pulled
down from package.el (version 20140210).


On Sat, Feb 22, 2014 at 3:39 AM, Nicolas Goaziou wrote:

> Hello,
>
> Joe Hirn  writes:
>
> > Here you go.
>
> Thank you for the patch.
>
> Unfortunately, I cannot apply it on master branch. Would you mind
> updating your repository and generate the patch again?
>
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Olivier Schwander]

Le 21 Feb 2014 18:22, Erik Hetzner a écrit:
> I had to start emacsclient in a terminal, probably because my emacs
> was run with emacs --daemon ? I made a little wrapper script that runs
> emacsclient in a terminal.

Are you happy with the wrapper ? The other solution would be to give
full control on the command line launched, but I think I will be too
complex.

Olivier

Re: [O] Timestamps in properties not exported by icalendar exporter

[David Engster]

Nicolas Goaziou writes:
> David Engster  writes:
>
>> It's these multitude of timestamp locations which makes changing the
>> timestamp of an existing entry through Elisp so tedious (I had to deal
>> with that in org-caldav)
>
> The number of locations may be daunting but all of them make sense
> actually. Also, I don't think it is really difficult to change
> a timestamp through Elisp, due to specialized functions (e.g.
> `org-schedule').

Not difficult, but tedious. The problem is that an entry might have
several timestamps, and you have to find the correct one to change.

> Anyway, if you think this area can be improved, feel free to make
> suggestions.

I'm actually not sure what org-element is capable of nowadays. What I'd
like to have is a way to parse entries into a structure which lets me
access certain elements of the entry, like headline, timestamps,
properties, body text, etc., and also a way to convert this structure
*back* to a plain Org entry. This way, I could change certain elements
of the entry in a robust way. It might be that the *appearance* of the
entry changes a bit during this procedure, but its elements should be
preserved.

(BTW: This is similar to what we have in CEDET, where the Semantic
parser generates 'tags' which describes things like variable or function
declarations, and you can define SRecode templates which can generate
textual output from these tags in pretty much any way you like.)

For example, in org-caldav I had to write a function which changes the
headline of an entry, but preserves any timestamps which might be in
it. Again: not difficult to do, especially since there is
org-complex-heading-regexp, but it's still tedious since Org entries are
so flexible in their appearance.

>> so using a property for it seemed like a good idea.
>
> This has been discussed a few times on this ML already.
>
> Carsten's argument is that new users shouldn't have to deal with hidden
> data, like property drawers, for such basic features.

Oh no, the user shouldn't have to do this, I agree
completely. Properties are nice for *code*, since they can be easily
parsed.

-David

[O] ~"~ doesn't register as verbatim

[Oleh]

Hi all,

I'm using verbatim markers to export them as  in HTML.
But ~"~ isn't recognized as verbatim. I've tried fiddling with org-verbatim-re,
but it doesn't update on revert-buffer.

Can someone hep me with this?
Maybe a workaround inline snippet that transforms to " on
HTML export?

regards,
Oleh

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Xebar Saram]

hya

yeah i mean several windows sorry :) a check box or an option on the
command line would be epic

thx again!

Z


On Sat, Feb 22, 2014 at 2:58 PM, Olivier Schwander <
olivier.schwan...@chadok.info> wrote:

> Le 21 Feb 2014 19:06, Xebar Saram a écrit:
> > one thing though, is there a way to define which client it oepns? i have
> > several emacs client opened at once and prefer the extension nowt to use
> a
> > current one but pop up a new CLI emacsclient for quick adding which will
> go
> > away after i finish capturing, is that possible?
>
> Several Emacs client open ? You mean several Emacs windows and you want
> to open a new one, right ? Is calling emacsclient with the -c flag
> enough for your need ? Or do you want the -nw flaf ? In that case, I
> will need to launch something like "xterm -e 'emacsclient -nw ...'".
>
> I may add either a simple checkbox for creating a new window, or allow
> to add option on the command line, or even give full control on the
> command line which is called.
>
> Olivier
>

Re: [O] how to group together fields

[Stefan Huchler]

hi (Alexander and everybody else who is interested in this topic),

sorry the thread is old and I did not update it, sadly Bastian did not
react to my last post.

I just thought I try it myself, but its tricky and org-colview.el has
1000 lines of code. And I wrote only small functions in (e)lisp so far.

But you did say something that it would be "totaly doable" to output
what I want in a new buffer.

I dont really care to much how it exactly work. I tried this also with
org-tables and failed with it too.

I just want a way to write down data (table or org-structure is both k)
of this orders ONE time and get both data, the mean score of tea from a
shop and the mean score from a tea brand (tea garden) so I can speculate
if I just dont like tea from this plantage/region or if just that shop
has low quality of tea.

Do you have idea how I could get there a quick hack, of course it would
be nice if it would be not a hardcoded tea-shop-function ^^.
But maybe it would be easier to write it first static to exact this
data.

Re: [O] Timestamps in properties not exported by icalendar exporter

[Nick Dokos]

Nicolas Goaziou  writes:

> David Engster  writes:
>
>> Yes, I could do that for my specific setup. But it would be nice if this
>> stuff could "just work", so that things like Outlook calendar invites
>> can be directly exported to .ics.
>
> AFAIU, we're talking about a third-party package which implements its
> own UI. We cannot support every UI in the wild.
>

I was confused at first because David has (had?) his own gnus-icalendar
package, but I believe he means the gnus-icalendar that is part of
gnus. That's probably a bit more official than a third-party package in
the wild, but I appreciate Nicolas's desire to control the chaos.

It might make more sense to advertise an API/convention/whatever that
such packages can use and provide a patch to modify gnus-icalendar
accordingly. After all, I presume gnus-icalendar can only be used with
gnus, so other mailers will have to have their own icalendar->org. If
each picks its own convention, chaos reigns.

We just need to come up with the "standard" and advertise it
appropriately. Maybe something like this:

"provide the starting time/duration information as a scheduled
timestamp, and optionally provide everything in properties.
The names of the properties should be the names that gnus-icalendar
currently uses (explicitly listed out, of course)."

>> I mean, those entries show up in the agenda, so I found it rather
>> surprising that they are completely ignored by the exporter.
>
> This is an agenda bug, which probably use a regexp to find timestamps.
> But timestamps in properties are not valid Org timestamps, per Org
> syntax.
>

If gnus-icalendar is modified as above, then when the agenda is
rewritten using org-element, things are not going to break.

>> I think it would make sense if the exporter also looked for
>> time-stamps in the properties.
>
> There are already plenty of locations to use timestamps. We have
> scheduled, deadline, plain timestamps... I don't think we need more of
> them.
>
> Also, a hook is easy enough to implement in this situation.
>

-- 
Nick

Re: [O] Timestamps in properties not exported by icalendar exporter

[Nicolas Goaziou]

David Engster  writes:

> It's these multitude of timestamp locations which makes changing the
> timestamp of an existing entry through Elisp so tedious (I had to deal
> with that in org-caldav)

The number of locations may be daunting but all of them make sense
actually. Also, I don't think it is really difficult to change
a timestamp through Elisp, due to specialized functions (e.g.
`org-schedule').

Anyway, if you think this area can be improved, feel free to make
suggestions.

> so using a property for it seemed like a good idea.

This has been discussed a few times on this ML already.

Carsten's argument is that new users shouldn't have to deal with hidden
data, like property drawers, for such basic features.

IMO, it also have an advantage from an implementation POV: important
timestamps are located right below the headline, whereas a property
drawer can be found anywhere in the whole section.

> Anyway, I understand your reasoning, and I guess we should change how
> gnus-icalendar generates its Org entries.

I think so, too.


Regards,

-- 
Nicolas Goaziou

Re: [O] Timestamps in properties not exported by icalendar exporter

[David Engster]

Nicolas Goaziou writes:
> David Engster  writes:
>> I mean, those entries show up in the agenda, so I found it rather
>> surprising that they are completely ignored by the exporter.
>
> This is an agenda bug, which probably use a regexp to find timestamps.
> But timestamps in properties are not valid Org timestamps, per Org
> syntax.

OK.

>> I think it would make sense if the exporter also looked for
>> time-stamps in the properties.
>
> There are already plenty of locations to use timestamps. We have
> scheduled, deadline, plain timestamps... I don't think we need more of
> them.

It's these multitude of timestamp locations which makes changing the
timestamp of an existing entry through Elisp so tedious (I had to deal
with that in org-caldav), so using a property for it seemed like a good
idea. Anyway, I understand your reasoning, and I guess we should change
how gnus-icalendar generates its Org entries.

-David

Re: [O] [ANN] Firefox extension for org-protocol and org-capture

[Olivier Schwander]

Le 21 Feb 2014 18:34, Peter Salazar a écrit:
> I'm having the same issue as Nick: the command line invocation works, but
> the button in Firefox has no effect. I changed the emacs binary path to
> /usr/bin/aquamacs

Is /usr/bin/aquamacs also doing the job of emacsclient ? What is your
version of Firefox ? Nick manages to use the FF27 but not FF26.

Olivier

Re: [O] Timestamps in properties not exported by icalendar exporter

[Nicolas Goaziou]

David Engster  writes:

> Yes, I could do that for my specific setup. But it would be nice if this
> stuff could "just work", so that things like Outlook calendar invites
> can be directly exported to .ics.

AFAIU, we're talking about a third-party package which implements its
own UI. We cannot support every UI in the wild.

> I mean, those entries show up in the agenda, so I found it rather
> surprising that they are completely ignored by the exporter.

This is an agenda bug, which probably use a regexp to find timestamps.
But timestamps in properties are not valid Org timestamps, per Org
syntax.

> I think it would make sense if the exporter also looked for
> time-stamps in the properties.

There are already plenty of locations to use timestamps. We have
scheduled, deadline, plain timestamps... I don't think we need more of
them.

Also, a hook is easy enough to implement in this situation.


Regards,

-- 
Nicolas Goaziou

[O] Bug: Unsure about warning messages [8.2.5h (8.2.5h-elpa @ /Users/kevin/.emacs.d/elpa/org-20140130/)]

[Kevin Van Horn]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


When installing org-mode using M-x package-install RET org, I got the
following warnings, and I cannot tell if this is an actual problem or not:


Compiling file /Users/kevin/.emacs.d/elpa/org-20140130/ob-C.el at Sat Feb 22 
01:13:21 2014
Entering directory `/Users/kevin/.emacs.d/elpa/org-20140130/'

In org-babel-C-val-to-C-type:
ob-C.el:174:35:Warning: `(type (org-babel-C-val-to-C-list-type val))' is a
malformed function
ob-C.el:182:20:Warning: reference to free variable `type'

In end of data:
ob-C.el:244:1:Warning: the function `lexical-let' is not known to be defined.


Compiling file /Users/kevin/.emacs.d/elpa/org-20140130/org-gnus.el at Sat Feb 
22 01:13:46 2014

In end of data:
org-gnus.el:301:1:Warning: the following functions might not be defined at 
runtime:
gnus-summary-goto-subject, gnus-summary-select-article,
message-narrow-to-headers, message-generate-headers,
message-unquote-tokens, message-tokenize-header,
gnus-activate-group, gnus-find-method-for-group,
gnus-group-read-group, gnus-summary-goto-article,
gnus-group-jump-to-group


Emacs  : GNU Emacs 24.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.36)
 of 2013-03-12 on bob.porkrind.org
Package: Org-mode version 8.2.5h (8.2.5h-elpa @ 
/Users/kevin/.emacs.d/elpa/org-20140130/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
  org-src-native-tab-command-maybe
  org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
  org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-html-format-drawer-function '(lambda (name contents) contents)
 org-latex-format-inlinetask-function 'ignore
 org-confirm-shell-link-function 'yes-or-no-p
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-latex-format-drawer-function '(lambda (name contents) contents)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-show-block-all
append local]
   5]
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-ascii-format-drawer-function '(lambda (name contents width) contents)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
  org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
  org-cycle-hide-inline-tasks org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-headline-function 'ignore
 org-html-format-inlinetask-function 'ignore
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] controling width of graphviz source block result

[regcl]

Nicolas Goaziou  writes:

> Hello,
>
> regcl  writes:
>
>> When I try to control the width of the image produced by 
>> included graphviz (DOT) code like so ...
>>
>> #+ATTR_HTML: :width 300
>> #+INCLUDE: gnus.dot SRC dot :file gnus.png :exports results
>>
>> ... width is not controlled.
>
> Here the HTML attribute applies to the INCLUDE keyword below.
>
>> #+INCLUDE: "gnus.dot" SRC dot :file gnus.png :exports none
>> #+ATTR_HTML: :width 300
>> file:gnus.png
>
> Here, the HTML attribute applies to the link below.
>
> Therefore, the behaviour is to be expected.
>
>
> Regards,

So I am understanding from your answer that attribues only "modify" the
next immediate "thing" in the .org document, and do not persist, so to
speak.

But I have discovered that it works to stack them up like this ...

#+ATTR_HTML: :width 1000
#+ATTR_ODT: :width 15 :height 15
[[file:gnus.png]]

... so I am a little confused. 

Could you please clarify?

Thanks,
regcl

Re: [O] Timestamps in properties not exported by icalendar exporter

[David Engster]

Nicolas Goaziou writes:
> David Engster  writes:
>> These entries show up in the agenda just fine, but the icalendar
>> exporter does not export it because the timestamp is in the properties
>> (the gnus-icalendar package puts it there so that you can easily change
>> it if the organizer decides to change the event and sends a change
>> request).
>>
>> The exporter could of course simply take the first timestamp it finds in
>> the properties, but it could be the wrong one; for instance, there could
>> be a LOGBOOK timestamp before the one in DT. Hence I think it would be
>> nice if you could tell the exporter which property to use as timestamp
>> during export.
>
> Can't you just walk the buffer and turn such properties into plain
> time-stamps (or scheduled, deadline...), in a hook?

Yes, I could do that for my specific setup. But it would be nice if this
stuff could "just work", so that things like Outlook calendar invites
can be directly exported to .ics.

I mean, those entries show up in the agenda, so I found it rather
surprising that they are completely ignored by the exporter. I think it
would make sense if the exporter also looked for time-stamps in the
properties. Maybe it could just take the first one it finds (which I
guess is what the agenda does?), and also give the user the ability to
configure which properties to look at (or maybe an exclude option).

-David

Re: [O] Timestamps in properties not exported by icalendar exporter

[Nicolas Goaziou]

Hello,

David Engster  writes:

> I have the problem that a certain kind Org entries is not exported by
> the icalendar exporter, namely those created by the gnus-icalendar
> package.
>
> This package creates Org entries from calendar invites in the following
> way (I've omitted some of the properties, but you get the idea);
>
> ** Some appointment (location)
>:PROPERTIES:
>:ICAL_EVENT: t
>:ID:   04008200E00074C5B7101A82E00800
>:DT:   <2013-12-09 Mon 13:00-13:30>
>:END:
>
>Body text
>
>
> These entries show up in the agenda just fine, but the icalendar
> exporter does not export it because the timestamp is in the properties
> (the gnus-icalendar package puts it there so that you can easily change
> it if the organizer decides to change the event and sends a change
> request).
>
> The exporter could of course simply take the first timestamp it finds in
> the properties, but it could be the wrong one; for instance, there could
> be a LOGBOOK timestamp before the one in DT. Hence I think it would be
> nice if you could tell the exporter which property to use as timestamp
> during export.

Can't you just walk the buffer and turn such properties into plain
time-stamps (or scheduled, deadline...), in a hook?


Regards,

-- 
Nicolas Goaziou

Re: [O] org-export-latex-hyperref-options-format

[Nicolas Goaziou]

Hello,

Joe Hirn  writes:

> Here you go.

Thank you for the patch.

Unfortunately, I cannot apply it on master branch. Would you mind
updating your repository and generate the patch again?


Regards,

-- 
Nicolas Goaziou

Re: [O] [patch] Support CUSTOM_ID property in latex export

[Nicolas Goaziou]

Hello,

Richard Lawrence  writes:

> Here's a new patch that adds a variable org-latex-custom-id-as-label to
> control whether CUSTOM_ID should be used to generate labels during LaTeX
> export.

Thank you for this.

> Let me know what you think.  In particular, I wasn't sure if I should
> provide more information in the defcustom statement beyond :group and
> :type (like :package-version?).

I think we should provide temporary (fake) values so we remember to
update them during the next merge.

   :version "24.5"
   :package-version '(Org . "8.3")

> Also, does the docstring represent the trade-offs of using this
> variable well enough?

The docstring is quite complete. I added a few suggestions. Also, you
need to escape backslashes (e.g., \\label).

> I wasn't sure how to get git format-patch to generate a single patch for
> the changes between my branch and master (since there are now two
> commits on my branch), so this was generated with git diff --patch.  If
> you want me to send the commit message, etc. can you let me know how to
> do this in whatever way is most convenient for you?

You can first merge the two commits on your branch into a single one
with "git rebase -i". Within Magit, it boils down to use key E on the
first of the two commits, then use key s on the second one and
eventually C-c C-c. This will merge them and give you a chance to edit
the final commit message.

Then you can send it with git format-patch.

> diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
> index 5815874..df22768 100644
> --- a/lisp/ox-latex.el
> +++ b/lisp/ox-latex.el
> @@ -375,6 +375,47 @@ which format headlines like for Org version prior to 
> 8.0."
>:package-version '(Org . "8.0")
>:type 'function)
>  
> +(defcustom org-latex-custom-id-as-label nil
> +   "Toggle use of CUSTOM_ID properties for generating section labels.
> +
> +If non-nil, Org will use the value of a headline's CUSTOM_ID
> +property as the argument to the \label command for the LaTeX
> +section corresponding to the headline.

I may be useful to add a note about the default behaviour:

  By default, Org generates unique labels for all headlines.  When this
  variable is non-nil...

> +Setting this variable gives you control over how Org generates
> +labels for sections during LaTeX export.  One reason to do this
> +is that it allows you to refer to headlines using a single label
> +both in Org's link syntax and in embedded LaTeX code.
> +
> +For example, when this variable is non-nil, a headline like this:
> +
> +  ** Some section
> + :PROPERTIES:
> + :CUSTOM_ID: sec:foo
> + :END:
> +  This is section [[#sec:foo]].
> +  #+BEGIN_LATEX
> +  And this is still section \ref{sec:foo}.
> +  #+END_LATEX
> +
> +will be exported to LaTeX as:
> +
> +  \subsection{Some section}
> +  \label{sec:foo}
> +  This is section \ref{sec:foo}.
> +  And this is still section \ref{sec:foo}.
> +
> +Note, however, that when a headline defines a value for
> +CUSTOM_ID, Org simply passes this value to \label unchanged.  You
> +are responsible for ensuring that the value is a valid LaTeX
> +\label key, that it is unique throughout the generated document,
> +etc.

I think you can remove "that it is unique throughout the generated
document", as it is already explained in the manual, and not specific to
this variable.

OTOH, it would be nice to specify what is a valid \label key (e.g.,
forbidden characters) and that the default value doesn't have this
limitation (otherwise, that wouldn't be much of a trade-off).

> + (let ((custom-label (and org-latex-custom-id-as-label
> +  (org-element-property :CUSTOM_ID 
> headline

There is one thing to consider here. We can define the new variable as
a back-end options, i.e., add

  (:latex-manual-id nil nil org-latex-custom-id-as-label)

in the back-end definition (the name of the property doesn't matter
much, you can change it).

This is not strictly necessary, but it allows, for example, to change
its value for specific projects (in the publishing sense) without
setting the variable globally.

If you think it is useful to do so,

  (and org-latex-custom-id-as-label

should become

  (and (plist-get info :latex-manual-id)

> +(let* ((custom-label (and org-latex-custom-id-as-label
> + (org-element-property :CUSTOM_ID 
> destination)))

Ditto.


What do you think?


Regards,

-- 
Nicolas Goaziou

Re: [O] controling width of graphviz source block result

[Nicolas Goaziou]

Hello,

regcl  writes:

> So I am understanding from your answer that attribues only "modify" the
> next immediate "thing" in the .org document, and do not persist, so to
> speak.

"things" are called "elements" in Org lingo and "attributes" are called
"affiliated keywords". So, yes, affiliated keywords apply to the element
right after them.

> But I have discovered that it works to stack them up like this ...
>
> #+ATTR_HTML: :width 1000
> #+ATTR_ODT: :width 15 :height 15
> [[file:gnus.png]]
>
> ... so I am a little confused. 
>
> Could you please clarify?

Both keywords are affiliated keywords. There is only one element in this
example (a paragraph containing a single link). Affiliated keywords
apply to the next element, not the next affiliated keyword.

For more information, see:

  http://orgmode.org/worg/dev/org-syntax.html

or the comments at the beginning of "org-element.el".


Regards,

-- 
Nicolas Goaziou