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

2014-02-22 Thread Nicolas Goaziou
Hello,

regcl re...@channing.harvard.edu 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



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

2014-02-22 Thread Nicolas Goaziou
Hello,

Richard Lawrence richard.lawre...@berkeley.edu 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] org-export-latex-hyperref-options-format

2014-02-22 Thread Nicolas Goaziou
Hello,

Joe Hirn joseph.h...@gmail.com 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread Nicolas Goaziou
Hello,

David Engster d...@randomsample.de 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread David Engster
Nicolas Goaziou writes:
 David Engster d...@randomsample.de 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] controling width of graphviz source block result

2014-02-22 Thread regcl
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 regcl re...@channing.harvard.edu 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




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

2014-02-22 Thread 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread Nicolas Goaziou
David Engster d...@randomsample.de 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



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

2014-02-22 Thread 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

2014-02-22 Thread David Engster
Nicolas Goaziou writes:
 David Engster d...@randomsample.de 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread Nicolas Goaziou
David Engster d...@randomsample.de 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

2014-02-22 Thread Nick Dokos
Nicolas Goaziou n.goaz...@gmail.com writes:

 David Engster d...@randomsample.de 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] how to group together fields

2014-02-22 Thread 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] [ANN] Firefox extension for org-protocol and org-capture

2014-02-22 Thread 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



[O] ~~ doesn't register as verbatim

2014-02-22 Thread Oleh
Hi all,

I'm using verbatim markers to export them as kbd 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 kbd/kbd on
HTML export?

regards,
Oleh



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

2014-02-22 Thread David Engster
Nicolas Goaziou writes:
 David Engster d...@randomsample.de 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



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

2014-02-22 Thread 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] org-export-latex-hyperref-options-format

2014-02-22 Thread 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 n.goaz...@gmail.comwrote:

 Hello,

 Joe Hirn joseph.h...@gmail.com 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] org-export-latex-hyperref-options-format

2014-02-22 Thread Bastien
Hi Joe,

Joe Hirn joseph.h...@gmail.com 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread Nicolas Goaziou
David Engster d...@randomsample.de 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] Timestamps in properties not exported by icalendar exporter

2014-02-22 Thread David Engster
Nicolas Goaziou writes:
 David Engster d...@randomsample.de 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] [ANN] Firefox extension for org-protocol and org-capture

2014-02-22 Thread 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 http://fsf.org/.


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

2014-02-22 Thread Alan Schmitt
Xebar Saram zelt...@gmail.com 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



[O] Tables with line wrapping?

2014-02-22 Thread 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] how to group together fields

2014-02-22 Thread Michael Brand
Hi Stefan

On Mon, Feb 3, 2014 at 4:25 PM, Stefan Huchler stefan.huch...@mail.de 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



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

2014-02-22 Thread Richard Lawrence
Hi Nicolas and all,

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

Nicolas Goaziou n.goaz...@gmail.com 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] Tables with line wrapping?

2014-02-22 Thread Thomas S. Dye
Aloha Peter,

Peter Davis p...@pfdstudio.com 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] Tables with line wrapping?

2014-02-22 Thread Richard Lawrence
Hi Peter,

Peter Davis p...@pfdstudio.com 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] [patch] Support CUSTOM_ID property in latex export

2014-02-22 Thread Nicolas Goaziou
Richard Lawrence richard.lawre...@berkeley.edu 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



[O] List of figures

2014-02-22 Thread 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] List of figures

2014-02-22 Thread 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




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

2014-02-22 Thread 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 richard.lawre...@berkeley.edu
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 

Re: [O] how to group together fields

2014-02-22 Thread 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] Unable to get file link search to work

2014-02-22 Thread Alexis

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

Thanks!


Alexis flexibe...@gmail.com 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] controling width of graphviz source block result

2014-02-22 Thread regcl
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 regcl re...@channing.harvard.edu 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] Tables with line wrapping?

2014-02-22 Thread 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] Tables with line wrapping?

2014-02-22 Thread 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?

2014-02-22 Thread Jambunathan K
Peter Davis p...@pfdstudio.com 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] Unable to get file link search to work

2014-02-22 Thread 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 flexibe...@gmail.com 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

2014-02-22 Thread Michael Brand
Hi Stefan

On Sun, Feb 23, 2014 at 2:12 AM, Stefan Huchler stefan.huch...@mail.de 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