Re: [O] [RFC] Standardized code block keywords

[Christian Moe]

I disagree with Tom on [1]: it should clearly be "srcname", in analogy
to #+tblname - and also so I don't have to change my files :-} (but see
my question about tblname below).


I'll have to change my files, either way. The price one pays for 
inconsistency. But as I've recently learned from Carsten, it should be 
a one-liner in Perl. :-)


For the sake of analogy, I'll cast my vote for SRCNAME, even if SOURCE 
is more aesthetically pleasing.




I agree on [2] "call".


+1



I'm confused by [3] so I will say nothing for now, except to ask some
questions: are we talking about what a human would use to label a piece
of data for consumption by a block (including perhaps the future
possibilities of lists and paragraphs that Tom brought up)? what babel
would use to label a results block (possibly so that it could be
consumed by another block in a chain)? both? would that mean
that #+tblname would go the way of the dodo and that tables would be
labelled with #+data (or #+object or whatever else we come up with)?


+1 (Confused, too)

I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME 
don't?


A reason to keep TBLNAME is that it's also used by the spreadsheet 
remote references. If Babel looked for DATA instead, a table that is 
both a remote reference for another spreadsheet and a data source for 
a src block would need both TBLNAME and DATA, which seems redundant.


As for labeling lists and paragraphs, I recall from the list that 
Nicolas Goaziou is working on a generalized way to set captions, 
labels and attributes for various kinds of Org block, as is possible 
now for tables and images. I thought that sounded promising. I don't 
know if he planned for block names, too (currently we have tblname but 
no imgname), but that could make sense. In which case it might be a 
good idea to coordinate.

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Sebastien Vauban]

Hi Eric and Nick,

Eric Schulte wrote:
> Nick Dokos  writes:
>> Eric Schulte  wrote:
>>
>>> > Other than "colon confusion" (having to specify ``:results silent'' on
>>> > the src block header line and ``results silent'' in the #+PROPERTY line
>>> > to get the same behavior), this looks better. Not sure what (if
>>> > anything) can or should be done about the colons.
>>> >
>>> 
>>> I don't know of a good solution for colons.  If we decided to add colons
>>> then the subtree property blocks would become akward, with entries like
>>> 
>>> ** foo
>>>:PROPERTIES:
>>>::results: silent
>>>:END:
>>> 
>>> I would say we could look for each value both with and without colons,
>>> but property searches of this nature are slow and doubling the speed
>>> impact simply for allow colon flexibility doesn't seem to be a good
>>> tradeoff.  I think this will just have to be something that users will
>>> need to learn.
>>
>> [fn:1] ...but I take some perverse pleasure from the fact that both
>> Suvayu and Seb asked the question :-)
>
> I noticed that too, and it no doubt means that this same question will
> occur to future users.

I knew there was no beginning colon in the #+PROPERTY line (and that does not
bother me).

>> For example, how do we translate, in the new syntax,
>>
>> #+BABEL::results output code append
>>
>> (where `:results' is the "name", and `output', `code' and `append' are
>> "values")?
>
> The above would become
>
> #+PROPERTY: results output code append
>
> Since only one property may be specified per property line there is no
> need for colons.  This mirrors exactly the way the properties are saved
> under subtrees in :PROPERTY: blocks.
>
> Multiple lines may be used to specify multiple properties. e.g.,
>
> #+PROPERTY: results silent
> #+PROPERTY: cache yes

*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first word
  is the "name" without colon, and the rest are "values"

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Standardized code block keywords

[Torsten Wagner]

Hi,

> Ideally if we limit each of the above to only one alternative we could
> simplify the specification of code blocks in Org-mode making them easier
> to learn and use and removing some of the mystery around their syntax.
>
> What does everyone think?

Just to make it as easy as possible for everyone
Might it be possible to introduce a small flags like "obsolete" and
"stable" (standard)
Old functions, old syntax, etc., might move first to obsolete before
completely removed...
We could open an older file and if it isn't working, we could try

#+PROPERTY: babel-function-set obsolete

if it works, we have to modify the code, because obviously the code
requires changed to be compatible in the future. However, just for the
moment it is still working. This would give people more time to change
there code accordingly. As murphy law tells us one will notice that
the particular file is broken exact 5 minutes before the meeting with
your boss standing behind you yelling print it, print it  ;)

I know git would be perfect to keep the code base frozen for a certain
syntax. However, babel is bundled with org-mode which is bundled with
Emacs. Thus, it might be very difficult to tell people they have to
use org-babel from git with the tag [org-babel_XX] if they want to use
there old style files.  AFAIK org-babel does not even come with a own
version numbering, right?

Alternatively, keep the syntax a little bit longer as it is and create
warning messages to point users to future changes (not sure how much
time left for emacs24)
"Warning: #+lob: in line XX is obsolete, please use #+call: in the
future. (manual-link)"

To make is short, is is possible to introduce changes "slowly"

As for voting:
[1]
#+function: would be what I would expect from other programming
languages. Where an unnamed source code block would be something like
a lambda function.
However, "function" as a term is heavily used in many target languages
too. This makes parsing, reading and discussing a bit difficult. ("I
called the function foo", "Wait, do you call the org-mode function
foo, or the python function foo?")
Thus, I vote for #+srcname similar to #+tblname to make sure about the
difference between org-babel and the target languages.

[2]
#+call:, simply because I never can remember "lob" and the acronym is
something difficult for newbies.

[3]
I tend to  #+results: because it fits more to the entire babel syntax.
However, earlier on the mailing list people were pointing out that one
is going to change "results" for a unknown source block (that was the
reason "data" was introduced) and I think this is a valid
argument. Maybe "data" and "results" should be both valid if only to
pleasure human thinking. However, if I understood correctly, maybe
data could be changed to be more some type of constant? That is,
#+data: foo can not be changed by a source code block named foo
(because it isn't a "result" but "data") but only by human (as a
"data" input). Does this make sense?

Totti

Re: [O] org-contacts or bbdb?

[henry atting]

Rasmus  writes:

> pmli...@free.fr (Peter Münster) writes:
>
>> Hello,
>>
>> I would like to manage my contacts, so that I can
>> - easily search them
>> - add new email addresses from gnus (summary buffer)
>> - complete email addresses in gnus (message buffer and prompts in
>>   mini-buffer)
>> - and perhaps more in the future
>>
>> Could you guide me please, what to choose, org-contacts or bbdb?
>> I don't see the advantages of the one or of the other...
>> TIA for any hints!
>
> I used org-contacts but now use bbdb3.  I think bbdb does it all and
> it's quite nice.
>
> I don't remember why I dropped Org-contant, but I think I found it hard
> to manage my contacts in the way I would ideally like to with it.
> [...]

+1

As I thougt that bbdb is no longer developped I switched to
org-contacts some time ago - which did not satisfy my needs in some
way. The (re-)discovery of bbdb3 elicits a sigh of relief...

Thanks,
henry


-- 
http://literaturlatenight.de

Re: [O] Patch for bug in adjusting time ranges in Agenda

[Carsten Dominik]

I have just checked in a slightly modified patch.

Thanks, this was really a bug.

- Carsten

On Oct 17, 2011, at 10:50 AM, Niels Giesen wrote:

> 
> 
> On Sun, Oct 16, 2011 at 6:43 PM, Nick Dokos  wrote:
> Niels Giesen  wrote:
> 
> > *bump*
> >
> > Has this one slipped through (as I were posting two other patches round the 
> > same date, one also
> > having to do with date/time ranges in the agenda -- which were both 
> > accepted), or am I just
> > impatient?
> >
> 
> I tried to check patchwork 
> (http://patchwork.newartisans.com/project/org-mode/)
> but the server seems to be having problems right now. However, that's the 
> first
> place to check when it comes back: if it's there, somebody will get to it 
> sooner
> or later.
> 
> Ok, I checked today (server is up again) and it's not there. But I've been a 
> fool. Should've submitted as an attachment as per 
> http://orgmode.org/worg/org-contribute.html . Should I try and resubmit?
>  
> 
> Nick
> 
> > On Sun, Oct 2, 2011 at 12:24 PM, Niels Giesen  
> > wrote:
> >
> > Hi Orgers,
> >
> > The discussion in the recent thread "Time range end in agenda view not
> > displayed" prompted me to take a closer look at time/date ranges in the
> > Agenda view. I noticed that the commands `org-agenda-do-date-later' and
> > `org-agenda-do-date-earlier' do not work correctly on timestamp ranges,
> > in that they only shift the rightmost timestamp in the range. The patch
> > below should fix this.
> >
> > #+begin_src diff
> >  From 2e6b64dc8dcae0fd312729af96ab10d8d2e9d91b Mon Sep 17 00:00:00 2001
> >  From: Niels Giesen 
> >  Date: Sun, 2 Oct 2011 09:15:21 +0200
> >  Subject: [PATCH] Fix shift-adjusting time and date ranges from within 
> > Agenda.
> >
> >  ,* org-mode/lisp/org-agenda.el (org-agenda-date-later): Adjust both
> >start and end timestamp for a range, and set
> >`org-last-changed-timestamp' to a representation of the new range.
> >  ---
> >   lisp/org-agenda.el |8 +++-
> >   1 files changed, 7 insertions(+), 1 deletions(-)
> >
> >  diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> >  index b1fa5f5..e4c1053 100644
> >  --- a/lisp/org-agenda.el
> >  +++ b/lisp/org-agenda.el
> >  @@ -7517,7 +7517,13 @@ the same tree node, and the headline of the 
> > tree node in the Org-mode
> > file."
> >  (goto-char pos)
> >  (if (not (org-at-timestamp-p))
> > (error "Cannot find time stamp"))
> >  -   (org-timestamp-change arg (or what 'day)))
> >  +   (org-timestamp-change arg (or what 'day))
> >  +   (when (org-at-date-range-p)
> >  + (let ((end org-last-changed-timestamp))
> >  +   (re-search-backward org-tr-regexp-both)
> >  +   (org-timestamp-change arg (or what 'day))
> >  +   (setq org-last-changed-timestamp
> >  +(concat org-last-changed-timestamp "--" end)
> >(org-agenda-show-new-time marker org-last-changed-timestamp))
> >   (message "Time stamp changed to %s" org-last-changed-timestamp)))
> >
> >  --
> >  1.7.2.5
> >
> > #+end_src
> >
> > Regards,
> > niels
> > --
> > http://pft.github.com
> >
> > --
> > http://pft.github.com
> >
> >
> > 
> > Alternatives:
> >
> > 
> 
> 
> 
> -- 
> http://pft.github.com

- Carsten

[O] [Accepted] Check marker is valid before use

[Carsten Dominik]

Patch 994 (http://patchwork.newartisans.com/patch/994/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3Cm1ipnj8mj4.fsf%40gmail.com%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [O] Check marker is valid before use
> Date: Fri, 21 Oct 2011 00:56:31 -
> From: Leo 
> X-Patchwork-Id: 994
> Message-Id: 
> To: emacs-orgmode@gnu.org
> 
> lisp/org-agenda.el |   14 +++---
>  1 files changed, 7 insertions(+), 7 deletions(-)
> 
> 
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index bf03b68c..f4b8bcbf 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -6784,13 +6784,13 @@ (defun org-agenda-previous-line ()
>  (defun org-agenda-do-context-action ()
>"Show outline path and, maybe, follow mode window."
>(let ((m (org-get-at-bol 'org-marker)))
> -(if (and org-agenda-follow-mode m)
> - (if org-agenda-follow-indirect
> - (org-agenda-tree-to-indirect-buffer)
> -   (org-agenda-show)))
> -(if (and m org-agenda-show-outline-path)
> - (org-with-point-at m
> -   (org-display-outline-path t)
> +(when (and (markerp m) (marker-buffer m))
> +  (and org-agenda-follow-mode
> +(if org-agenda-follow-indirect
> +(org-agenda-tree-to-indirect-buffer)
> +  (org-agenda-show)))
> +  (and org-agenda-show-outline-path
> +(org-with-point-at m (org-display-outline-path t))
>  
>  (defun org-agenda-show-priority ()
>"Show the priority of the current item.
> 

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Hi again,

I can quickly think of two advantages of the late lamented (if only by 
me) #+BABEL header over using properties.


1. Allowing you to specify multiple buffer-wide options on the same 
line (keeping things short), in the same colon :syntax as used in a 
src block header (keeping things consistent and easy to copy back and 
forth). None of this makes a substantive difference.


2. Allowing you to pass multiple buffer-wide arguments with :var. This 
could make a substantive difference in some applications. The 
following will work:


  #+BABEL: :var euro=1.3791 :var salestax=.15

The following will not, since it tries to set the same property:

  #+PROPERTY: var euro=1.3791
  #+PROPERTY: var salestax=.15

If BABEL is dropped for PROPERTY, it would be good for the :var: 
property to support multiple arguments (comma-separated would be good 
for consistency with passing arguments through the SRCNAME). E.g.:


  #+PROPERTY: var euro=1.3791, salestax=.15

I think I'd like this better in any case.

Yours,
Christian


On 10/21/11 9:28 AM, Sebastien Vauban wrote:

Multiple lines may be used to specify multiple properties. e.g.,

#+PROPERTY: results silent
#+PROPERTY: cache yes


*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first word
   is the "name" without colon, and the rest are "values"

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
   Seb

Re: [O] [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Nick, Tom, Eric and all,

Nick Dokos wrote:
> Thomas S. Dye  wrote:
>> Eric Schulte  writes:
>> 
 [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, 
 #+FUNCTION,
 #+CALL, #+LOB, and SBE, some of which are interchangeable; some
 not. I'd prefer deprecating an old form when a better one is found.
>>>
>>> This point of view has been raised previously both on the mailing list
>>> and in the #org-mode IRC chat room. I think it is time that we decided as
>>> a community what we want to do about the prevalence of code block
>>> synonyms -- we should make this decision before the release of Emacs24
>>> after which syntax will become harder to change.

Thanks for tackling this.

>>> There are currently a number of instances of synonymous keywords when
>>> dealing with code blocks, specifically.
>>>
>>>  named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>> named data [3] -- "tblname" "resname" "results" "data"
>>>
>>> Ideally if we limit each of the above to only one alternative we could
>>> simplify the specification of code blocks in Org-mode making them easier
>>> to learn and use and removing some of the mystery around their syntax.
>>>
>>> What does everyone think?
>>>
>>> Are there suggestions for the best names for each code block entity
>>> (either in the list or not in the list)?
>>>
>>> Are there cases where we want to continue to allow synonyms (e.g., in
>>> named data so that "results" can be used for code block results but
>>> "data" can be used for hand-written data)?
>>>
>>> Thanks -- Eric
>>>
>>> Footnotes: 
>>> [1] named code blocks
>>>
>>> #+source: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> #+srcname: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> #+function: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> [2]  calling external functions
>>>
>>> #+call: foo()
>>>
>>> #+lob: foo()
>>>
>>> [3]  named data
>>>
>>> #+data: something
>>> : something
>>> #+results: something
>>> : something
>>>
>>> etc...
>>
>> named code blocks [1] "source"
>> calling external functions [2] "call"
>> named data [3] "object"
>>
>> My motivation for [3] "object" instead of the suggested alternates is the
>> hope that it will be possible to name things like lists and paragraphs
>> (that aren't results or data) and pass these objects to source code blocks.
>
> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see my
> question about tblname below).

I have low attraction for "function" as this seems too-programming oriented:
IMHO, it's too much minded toward the "results value" aspect of Babel
("functional mode"), and not at all toward the "scripting mode" (shell
scripts, SQL commands).

Moreover, in fact, in such blocks, we don't have executable code per se: just
think at Ledger transactions that I would want to wrap...

#+srcname: journal
#+begin_src ledger
2008/01/03 * ( ) ME
Assets:Bank:Checking:77045030   550.00 
EUR
Assets:Bank:Transferred

2008/01/01 * ( ) UNKNOWN-PAYEE
Assets:Bank:Checking:7704503021.91 
EUR
Expenses:Unknown
#+end_src

..., and reuse in a block later (through the Noweb expansion):

#+srcname: ledger-balance
#+begin_src ledger :cmdline bal :noweb yes
<>
#+end_src

Though, in this latter case, one could object I could maybe (?) refer them
through the "object" name facility -- I'm referring to point 3 of Tom's
answer, see below.

Note -- Then, I would loose the language-editing facility. When we create
an "object" ("results" or "data"), there is no "language" associated,
hence no ability to edit easily via C-c ', and no correct "native
fontification". In fact, such an object has no delimiter either, so it
would never be a true replacement.

Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
entering for me. That's currently "srcname". I don't have a strong opinion,
though, to choose one over the other, except that I like Nick's argument with
the table analogy.

> I agree on [2] "call".

I clearly agree on "call" as well.

Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
call, absolutely similar to "call". Is there a technical reason to be forced
to differentiate both?  If no, can we use "call" as well instead of "sbe"?

> I'm confused by [3] so I will say nothing for now, except to ask some
> questions: are we talking about what a human would use to label a piece of
> data for consumption by a block (including perhaps the future possibilities
> of lists and paragraphs that Tom brought up)? what babel would use to label
> a results block (possibly so that it could

Re: [O] [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Torsten,

Torsten Wagner wrote:
> I tend to  #+results: because it fits more to the entire babel syntax.
> However, earlier on the mailing list people were pointing out that one
> is going to change "results" for a unknown source block (that was the
> reason "data" was introduced) and I think this is a valid
> argument. Maybe "data" and "results" should be both valid if only to
> pleasure human thinking. However, if I understood correctly, maybe
> data could be changed to be more some type of constant? That is,
> #+data: foo can not be changed by a source code block named foo
> (because it isn't a "result" but "data") but only by human (as a
> "data" input). Does this make sense?

Yes, #+results are automatically generated by execution of some code.

But, if you want to start with something, not generated, you had to insert
yourself a #+results block until the more logical #+data had been introduced.

I like your explanation about the fact that such a manually-entered block is
"constant".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Asciidoc

[Christian Egli]

Hi

Stephen Nelson-Smith  writes:

> I have a large piece of writing to do, which my publisher wants in
> asciidoc.  I'd prefer to write in orgmode and export as asciidoc. 

I used to use asciidoc but much prefer orgmode now.

> Is this feasible?  Anyone doing this or done this before?

Not directly as far as I know. You have different options:

- Export to odt and from there to mediawiki followed by some text munging
- Use the generic exporter to generate mediawiki again followed by
  some text munging 
- Tweak the generic exporter (don't know how feasible and easy that is)
- Write an exporter. For simple ascii exporter that should be doable.
  There are however different competing starting points. There is an
  experimental generic exporter by Bastien and there is apparently one
  by Jambunathan. Can't tell you which one is better.

Hope that helps

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] Patch for bug in adjusting time ranges in Agenda

[Christian Egli]

Hi Carsten

Carsten Dominik  writes:

> I have just checked in a slightly modified patch.

I think there is a problem with this checkin. The variable
org-agenda-move-date-from-past-immediately-to-today is not defined.
Should this be a defcustom somewhere?

Debugger entered--Lisp error: (void-variable 
org-agenda-move-date-from-past-immediately-to-today)
  org-agenda-date-later(1)
  org-agenda-do-date-later(nil)
  call-interactively(org-agenda-do-date-later nil nil)

Thanks
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe wrote:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by me)
> #+BABEL header over using properties.
>

I also think that keeping the #+BABEL would be a good idea, as it keeps the
options for babel separate (as are the functions - org-babel... ). It is
true that babel is getting more and more interwined with org (which is a
good think), but especially in my case, I use org more or less exclusively
for literate programming (babel) and some org features (archiving, note
capture...) in this context, it would be really nice to be able to keep the
options for babel easily identifyable.

I defined a new drawer (:BABEL:) and put my options / arguments / properties
for babel in there. So my question would be: would i be possible to leave
#+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, but also
used to make these options easily identifyable.

My setup at the moment:

#+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX

:BABEL:
#+BABEL: :session *R*
#+BABEL: :results output
#+BABEL: :exports code
#+BABEL: :comments yes
#+BABEL: :tangle Analysis_sensitivity.R
#+BABEL: :var
RESULTSDIR="/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/"
#+BABEL: :var
ANALYSISDIR="/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/"
:END:



> 1. Allowing you to specify multiple buffer-wide options on the same line
> (keeping things short), in the same colon :syntax as used in a src block
> header (keeping things consistent and easy to copy back and forth). None of
> this makes a substantive difference.
>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The following will
> work:
>
>  #+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>  #+PROPERTY: var euro=1.3791
>  #+PROPERTY: var salestax=.15
>

I think it is a very important point, that the construct with :var still
works - but as Eric only mentioned the *naming*, I assume that in the actual
usage nothing changes.

OK - the colon at the beginning - but I clud live with that change, although
it makes it clear what the actual argument is which is set.


> If BABEL is dropped for PROPERTY, it would be good for the :var: property
> to support multiple arguments (comma-separated would be good for consistency
> with passing arguments through the SRCNAME). E.g.:
>
>  #+PROPERTY: var euro=1.3791, salestax=.15
>

I think that would be a good idea, but I think that was already discussed
some time ago and rejected?


> I think I'd like this better in any case.
>

No - rather in separate lines... but different strokes for different
folks...

Cheers,

Rainer


> Yours,
> Christian
>
>
>
> On 10/21/11 9:28 AM, Sebastien Vauban wrote:
>
>> Multiple lines may be used to specify multiple properties. e.g.,
>>>
>>> #+PROPERTY: results silent
>>> #+PROPERTY: cache yes
>>>
>>
>> *But* I did not know it was limited to _one property per line_.
>>
>> Knowing that:
>>
>> - there is no confusion at all -- we simply (have to) know that the first
>> word
>>   is the "name" without colon, and the rest are "values"
>>
>> - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.
>>
>> To sum up, I'm perfectly happy with the new choice.
>>
>> Best regards,
>>   Seb
>>
>>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/21/11 11:12 AM, Rainer M Krug wrote:



On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe mailto:m...@christianmoe.com>> wrote:

(...)

2. Allowing you to pass multiple buffer-wide arguments with :var.
This could make a substantive difference in some applications. The
following will work:

  #+BABEL: :var euro=1.3791 :var salestax=.15

The following will not, since it tries to set the same property:

  #+PROPERTY: var euro=1.3791
  #+PROPERTY: var salestax=.15


I think it is a very important point, that the construct with :var
still works - but as Eric only mentioned the *naming*, I assume that
in the actual usage nothing changes.



Hi, Rainer,

My point was that there is at least one (minor) case where properties 
are not functionally equivalent to the BABEL line: You cannot pass 
arguments for more than one variable buffer-wide, because you can't 
have multiple var properties at the same time, and at present, one var 
property only sets one variable.


The behavior of properties has not changed. What has changed is the 
removal of the BABEL header, whose colon (:var) syntax did allow you 
to set multiple variables buffer-wide should you wish to.


Yours,
Christian

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

On Fri, Oct 21, 2011 at 12:47 PM, Christian Moe wrote:

> On 10/21/11 11:12 AM, Rainer M Krug wrote:
>
>>
>>
>> On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe > **> wrote:
>>
> (...)
>
> 2. Allowing you to pass multiple buffer-wide arguments with :var.
>>This could make a substantive difference in some applications. The
>>following will work:
>>
>>  #+BABEL: :var euro=1.3791 :var salestax=.15
>>
>>The following will not, since it tries to set the same property:
>>
>>  #+PROPERTY: var euro=1.3791
>>  #+PROPERTY: var salestax=.15
>>
>>
>> I think it is a very important point, that the construct with :var
>> still works - but as Eric only mentioned the *naming*, I assume that
>> in the actual usage nothing changes.
>>
>>
> Hi, Rainer,
>
> My point was that there is at least one (minor) case where properties are
> not functionally equivalent to the BABEL line: You cannot pass arguments for
> more than one variable buffer-wide, because you can't have multiple var
> properties at the same time, and at present, one var property only sets one
> variable.
>

So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one salestax=.15,
and euro is unset? That would be quite bad.


>
> The behavior of properties has not changed. What has changed is the removal
> of the BABEL header, whose colon (:var) syntax did allow you to set multiple
> variables buffer-wide should you wish to.
>

To clarify: before, we could use #+BABEL and #PROPERTY to do similar things.
Now the whole #+BABEL has been removed, and only the functionality from
#+PROPERTY is left - correct?

Rainer



>
> Yours,
> Christian
>
>
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

On 10/21/11 12:59 PM, Rainer M Krug wrote:


So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one
salestax=.15, and euro is unset? That would be quite bad.


That's what I'd expected, but actually, euro is set and salestax is 
not. Apparently subsequent PROPERTY lines are ignored if they try to 
set an already existing property.



To clarify: before, we could use #+BABEL and #PROPERTY to do similar
things. Now the whole #+BABEL has been removed, and only the
functionality from #+PROPERTY is left - correct?


That's my understanding. And #+PROPERTY offers equivalent 
functionality in almost every way, but not, as far as I can 
understand, in this corner case.


Christian

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

On Fri, Oct 21, 2011 at 1:17 PM, Christian Moe wrote:

> On 10/21/11 12:59 PM, Rainer M Krug wrote:
>
>  So, using your above mentioned example, after the first PROPERTY line,
>> euro=1.3795 and SALESTAX not set, while after the second one
>> salestax=.15, and euro is unset? That would be quite bad.
>>
>
> That's what I'd expected, but actually, euro is set and salestax is not.
> Apparently subsequent PROPERTY lines are ignored if they try to set an
> already existing property.
>

That's bad - really bad. Because then I have to substantially change my
files.


>
>  To clarify: before, we could use #+BABEL and #PROPERTY to do similar
>> things. Now the whole #+BABEL has been removed, and only the
>> functionality from #+PROPERTY is left - correct?
>>
>
> That's my understanding. And #+PROPERTY offers equivalent functionality in
> almost every way, but not, as far as I can understand, in this corner case.
>

Then I would suggest to leave #+BABEL until these cases are also implemented
in #+PROPERTY - but I suppose, they are there for a purpose.

Cheers,

Rainer


>
> Christian
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] [RFC] Standardized code block keywords

[Nicolas Goaziou]

Hello,

Eric Schulte  writes:

> There are currently a number of instances of synonymous keywords when
> dealing with code blocks, specifically.
>
>  named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
> named data [3] -- "tblname" "resname" "results" "data"
>

- Cases [1] and [2] : I'd suggest to drop all of them and to use "name",
  shared by both source code and data. Is it really different to name
  a source block or a list?

- Case [3] : I like "call". "lob" is too cryptic.

> Are there cases where we want to continue to allow synonyms (e.g., in
> named data so that "results" can be used for code block results but
> "data" can be used for hand-written data)?

No. One Keyword to name them all.

Regards,

[1] DEFINITION NOT FOUND: 1

[2] DEFINITION NOT FOUND: 3

[3] DEFINITION NOT FOUND: 2

-- 
Nicolas Goaziou

[O] Cannot display images inline any more

[Rainer Stengele]

Hi all,

I am no more able to display images inline.
I was able when I used Emacs-23-CvsP091103-EmacsW32-1.58.exe.


I have for example

[[file:c:/img.jpg]]

which is exported correctly as html.

In Emacs, after "C-c C-x v" Org says: "No images to display inline".

Does anybody use Emacs 24.0.90.1 and is able to display images inline?

Regards,
Rainer


Org-mode version 7.7 (release_7.7.449.g2055)
GNU Emacs 24.0.90.1 (i386-mingw-nt5.1.2600) of 2011-10-19 on MARVIN

Re: [O] Cannot display images inline any more

[suvayu ali]

On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
 wrote:
>
> I have for example
>
> [[file:c:/img.jpg]]
>
> which is exported correctly as html.
>
> In Emacs, after "C-c C-x v" Org says: "No images to display inline".
>
> Does anybody use Emacs 24.0.90.1 and is able to display images inline?
>

My Emacs is 2 days older than yours and it works fine.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Cannot display images inline any more

[Sebastien Vauban]

Hi Suvayu and Rainer,

suvayu ali wrote:
> On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
>  wrote:
>>
>> I have for example
>>
>> [[file:c:/img.jpg]]
>>
>> which is exported correctly as html.
>>
>> In Emacs, after "C-c C-x v" Org says: "No images to display inline".
>>
>> Does anybody use Emacs 24.0.90.1 and is able to display images inline?
>
> My Emacs is 2 days older than yours and it works fine.

I wonder if it's not related to some types of images (PNG, JPG) and Emacs 24
under Windows. Have read such things, IIRC.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Cannot display images inline any more

[Rainer Stengele]

Am 21.10.2011 15:33, schrieb Sebastien Vauban:
> Hi Suvayu and Rainer,
> 
> suvayu ali wrote:
>> On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
>>  wrote:
>>>
>>> I have for example
>>>
>>> [[file:c:/img.jpg]]
>>>
>>> which is exported correctly as html.
>>>
>>> In Emacs, after "C-c C-x v" Org says: "No images to display inline".
>>>
>>> Does anybody use Emacs 24.0.90.1 and is able to display images inline?
>>
>> My Emacs is 2 days older than yours and it works fine.
> 
> I wonder if it's not related to some types of images (PNG, JPG) and Emacs 24
> under Windows. Have read such things, IIRC.
> 
> Best regards,
>   Seb
> 

Well, who is telling me "No images to display inline"? Is it Emacs or Org?
How could I debug the funtion?

Anybody?
Rainer

Re: [O] Cannot display images inline any more

[Jambunathan K]

Rainer Stengele  writes:

> Am 21.10.2011 15:33, schrieb Sebastien Vauban:
>> Hi Suvayu and Rainer,
>> 
>> suvayu ali wrote:
>>> On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
>>>  wrote:

 I have for example

 [[file:c:/img.jpg]]

 which is exported correctly as html.

 In Emacs, after "C-c C-x v" Org says: "No images to display inline".

 Does anybody use Emacs 24.0.90.1 and is able to display images inline?
>>>
>>> My Emacs is 2 days older than yours and it works fine.
>> 
>> I wonder if it's not related to some types of images (PNG, JPG) and Emacs 24
>> under Windows. Have read such things, IIRC.
>> 
>> Best regards,
>>   Seb
>> 
>
> Well, who is telling me "No images to display inline"? Is it Emacs or Org?
> How could I debug the funtion?

C-h v dynamic-library-alist
C-h v image-library-alist

You can copy the required dll to bin if you are on Windows.

> Anybody?
> Rainer
>
>
>

-- 

Re: [O] Cannot display images inline any more

[Jambunathan K]

> Well, who is telling me "No images to display inline"? Is it Emacs or Org?

Should be straight-forward right? How about C-x C-f image.file?

-- 

Re: [O] Cannot display images inline any more

[Carsten Dominik]

On Oct 21, 2011, at 4:00 PM, Rainer Stengele wrote:

> Am 21.10.2011 15:33, schrieb Sebastien Vauban:
>> Hi Suvayu and Rainer,
>> 
>> suvayu ali wrote:
>>> On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
>>>  wrote:
 
 I have for example
 
 [[file:c:/img.jpg]]
 
 which is exported correctly as html.
 
 In Emacs, after "C-c C-x v" Org says: "No images to display inline".
 
 Does anybody use Emacs 24.0.90.1 and is able to display images inline?
>>> 
>>> My Emacs is 2 days older than yours and it works fine.
>> 
>> I wonder if it's not related to some types of images (PNG, JPG) and Emacs 24
>> under Windows. Have read such things, IIRC.
>> 
>> Best regards,
>>  Seb
>> 
> 
> Well, who is telling me "No images to display inline"? Is it Emacs or Org?
> How could I debug the funtion?

This message is generated by Org-mode, after a call to 
(org-display-inline-images) did not produce any images to display.  Possible 
reason are that the regular expression did not find any image-like links, or 
that the listed files does not exist.

So reload org source files, set debug-on-entry for that function and watch it 
fail.

- Carsten

> 
> Anybody?
> Rainer
> 
> 

- Carsten

Re: [O] "git describe" in version of info file with "make info_git_describe"

[Carsten Dominik]

Hi,

is there an agreement that this is a good patch?  I have not followed the 
discussion.

- Carsten

On Oct 16, 2011, at 9:12 PM, Michael Brand wrote:

> Hi all
> 
> I made a new patch replacing the previous, now considering the
> Makefile targets "target" and "help" introduced meanwhile by Achim
> Gratz and with a shorter name "info-vg" for the new target for easier
> typing of the make command.
> 
> The previous patch attachment had a wrong mime type, could therefore
> not be caught by patchwork and has not been accepted.
> 
> Michael
> 
> On Thu, Jun 2, 2011 at 21:36, Michael Brand  
> wrote:
>> The patch is ready and attached.
>> 
>> On Thu, Jun 2, 2011 at 17:05, Michael Brand  
>> wrote:
>> [...]
>>> Since I would like to give the more often used "git describe"
>>> precedence I will make org-version and "make info_git_describe"
>>> consistent with git. The ".dirty" postfix of org-version I will leave
>>> untouched in org-version of course and support also in "make
>>> info_git_describe".
> <0001-Makefile-info-vg-set-info-version-to-git-describe.patch.txt>

- Carsten

Re: [O] outline-demote incorrectly demotes leaf nodes

[Carsten Dominik]

On Oct 19, 2011, at 5:39 PM, Michael Brand wrote:

> Hi Carsten
> 
> On 18.10.2011, at 20:03, Sanjoy Mahajan wrote:
>> I do worry about one point, namely that C-c C-> (outline-demote) should still
>> work.  And it does work in regular outline mode.  For example, if I rename my
>> test file to c.otl and then use C-c C-> on the main heading, all the subtrees
>> are demoted as I expected.  Whereas in org mode the leaf subtree gets a space
>> instead of a * when it is being demoted.
> 
> On Wed, Oct 19, 2011 at 09:14, Carsten Dominik
>  wrote:
>> Another option, if you prefer the C-> and C-< bindings is this:
>> 
>> (add-hook 'org-mode-hook
>>  (lambda ()
>>(define-key org-mode-map [(control ?<)] 'org-promote-subtree)
>>(define-key org-mode-map [(control ?>)] 'org-demote-subtree)))
> 
> My suggestion is something like
> 
> (define-key org-mode-map [remap outline-promote] 'org-promote-subtree)
> (define-key org-mode-map [remap outline-demote] 'org-demote-subtree)
> [...]
> 
> permanently built into Org mode (not in org-mode-hook) for these and
> maybe even a few more outline-* bindings to get the incompatible
> outline-* bindings out of the way from within Org mode.
> 
> This remap does not affect the bindings in Outline mode and resolves
> the issue of the OP in Org mode, independent of, to which key any user
> might have mapped outline-*mote.

Would you like to carefully think about which other functions you might want to 
have remapped, and then prepare a patch?

- Carsten

Re: [O] Cannot display images inline any more => solved

[Rainer Stengele]

Am 21.10.2011 16:19, schrieb Jambunathan K:
> Rainer Stengele  writes:
> 
>> Am 21.10.2011 15:33, schrieb Sebastien Vauban:
>>> Hi Suvayu and Rainer,
>>>
>>> suvayu ali wrote:
 On Fri, Oct 21, 2011 at 2:39 PM, Rainer Stengele
  wrote:
>
> I have for example
>
> [[file:c:/img.jpg]]
>
> which is exported correctly as html.
>
> In Emacs, after "C-c C-x v" Org says: "No images to display inline".
>
> Does anybody use Emacs 24.0.90.1 and is able to display images inline?

 My Emacs is 2 days older than yours and it works fine.
>>>
>>> I wonder if it's not related to some types of images (PNG, JPG) and Emacs 24
>>> under Windows. Have read such things, IIRC.
>>>
>>> Best regards,
>>>   Seb
>>>
>>
>> Well, who is telling me "No images to display inline"? Is it Emacs or Org?
>> How could I debug the funtion?
> 
> C-h v dynamic-library-alist
> C-h v image-library-alist
> 
> You can copy the required dll to bin if you are on Windows.
> 
>> Anybody?
>> Rainer
>>
>>
>>
> 

Ok, that was it.
I copied the libs from my old emacs w32 installation to my emacs bin folder and 
that did it.
I never knew that Lennard Borgman did the nice job packaging these libs in his 
emacsw32 (which is out of date unfortunately - thanks Lennard
anyway).

Thank you for the hint Jambunathan, helped me to understand a bit more of how 
emacs is working.

Rainer

Re: [O] outline-demote incorrectly demotes leaf nodes

[Bastien]

Hi Michael,

Michael Brand  writes:

> My suggestion is something like
>
> (define-key org-mode-map [remap outline-promote] 'org-promote-subtree)
> (define-key org-mode-map [remap outline-demote] 'org-demote-subtree)

I've taken this road and committed the change, thanks for the
suggestion. 

> permanently built into Org mode (not in org-mode-hook) for these and
> maybe even a few more outline-* bindings to get the incompatible
> outline-* bindings out of the way from within Org mode.

If other use-cases come up, we will handle them then.  

Thanks,

-- 
 Bastien

Re: [O] Can't use char ">" in TODO state

[Bastien]

Hi Sébastien,

"Sebastien Vauban"  writes:

> I find this behavior not entirely satisfying, even if I can fully accept that
> ">" is a forbidden character in the TODO states. For example, we could think
> of a warning being generated, or of the state being fully ignored, or ...

I agree there is inconsistency here.  Special chars are allowed in TODO
keywords but they create the confusion you describe when used at the beg
or the end of the keyword ("NE>W" is safe AFAICT.)

> BTW, do you have an alternative for this "NEW" state, in 4 positions?
> ;-)

NIOU?

:)

-- 
 Bastien

Re: [O] property values and timestamps

[Bastien]

Hi Skip and Nick,

Nick Dokos  writes:

> Still a proof-of-concept, but better than the first attempt - set
> recursive minibuffers locally and use the standard keybinding:
>
> (defun org-completing-read (&rest args)
>   "Completing-read with SPACE being a normal character."
>   (let ((minibuffer-local-completion-map
>(copy-keymap minibuffer-local-completion-map))
>   (enable-recursive-minibuffers t))
> (org-defkey minibuffer-local-completion-map " " 'self-insert-command)
> (org-defkey minibuffer-local-completion-map "?" 'self-insert-command)
> (org-defkey minibuffer-local-completion-map (kbd "C-c !") 
> 'org-time-stamp-inactive)
> (apply 'org-icompleting-read args)))

I allowed recursive minibuffers in `org-completing-read'.

Thanks for this neat idea and proof-of-concept!

-- 
 Bastien

Re: [O] org-bibtex org-exp-bibtex tutorial and config needed

[Bastien]

Hi Ezequiel,

Ezequiel Birman  writes:

> I am trying to get the most of org-bibtex and org-exp-bibtex. Could
> anybody describe briefly his configuration and workflow? Especially with
> regards to reftex.

What tutorial did you already check?  That will help people understand
what particular information you are really missing...  Thanks!

-- 
 Bastien

Re: [O] Can't use char ">" in TODO state

[Bastien]

Hi,

Michael Brand  writes:

> It works with this patch
> http://patchwork.newartisans.com/patch/964
> from Nicolas which I am still using to test it.

Has anyone else been using this patch without problems?

If so, then Nicolas please apply it.  It really simplifies
the way headlines are matched in many places in the code.

Thanks,

-- 
 Bastien

Re: [O] property values and timestamps

[Bastien]

Hi Skip,

Skip Collins  writes:

>> Still a proof-of-concept, but better than the first attempt - set
>> recursive minibuffers locally and use the standard keybinding:
>
> That was easy. I'm looking forward to this making its way into the
> main repository. Where else would a recursive minibuffer make sense?

I think `org-completing-read' is the most significant one, but yes, 
there might be others.  Please keep us posted about new ideas.

-- 
 Bastien

Re: [O] outline-demote incorrectly demotes leaf nodes

[Bastien]

Hi Carsten,

Carsten Dominik  writes:

>> permanently built into Org mode (not in org-mode-hook) for these and
>> maybe even a few more outline-* bindings to get the incompatible
>> outline-* bindings out of the way from within Org mode.
>> 
>> This remap does not affect the bindings in Outline mode and resolves
>> the issue of the OP in Org mode, independent of, to which key any user
>> might have mapped outline-*mote.
>
> Would you like to carefully think about which other functions you might
> want to have remapped, and then prepare a patch?

I went ahead a applied a patch with Michael's suggestion.  

Please feel free to revert the commit while waiting for a more
complete patch.

-- 
 Bastien

Re: [O] "git describe" in version of info file with "make info_git_describe"

[Bernt Hansen]

I still have this as a TODO item for review.  I'll take a look at it
this weekend.

-Bernt

Carsten Dominik  writes:

> Hi,
>
> is there an agreement that this is a good patch?  I have not followed the 
> discussion.
>
> - Carsten
>
> On Oct 16, 2011, at 9:12 PM, Michael Brand wrote:
>
>> Hi all
>> 
>> I made a new patch replacing the previous, now considering the
>> Makefile targets "target" and "help" introduced meanwhile by Achim
>> Gratz and with a shorter name "info-vg" for the new target for easier
>> typing of the make command.
>> 
>> The previous patch attachment had a wrong mime type, could therefore
>> not be caught by patchwork and has not been accepted.
>> 
>> Michael
>> 
>> On Thu, Jun 2, 2011 at 21:36, Michael Brand  
>> wrote:
>>> The patch is ready and attached.
>>> 
>>> On Thu, Jun 2, 2011 at 17:05, Michael Brand  
>>> wrote:
>>> [...]
 Since I would like to give the more often used "git describe"
 precedence I will make org-version and "make info_git_describe"
 consistent with git. The ".dirty" postfix of org-version I will leave
 untouched in org-version of course and support also in "make
 info_git_describe".
>> <0001-Makefile-info-vg-set-info-version-to-git-describe.patch.txt>
>
> - Carsten

Re: [O] No updates on git server?

[Bastien]

Rainer M Krug  writes:

> [...] or has org reached a stable state?

Is it April fools' day already?

:)

-- 
 Bastien

[O] [PATCH 1/5] bind org-export-current-backend in generic exporter.

[Robert P. Goldman]

This is needed for org-export-preprocess-string to function correctly.
---
 contrib/lisp/org-export-generic.el |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/contrib/lisp/org-export-generic.el 
b/contrib/lisp/org-export-generic.el
index bb42b60..29e90b8 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -617,6 +617,7 @@ underlined headlines.  The default is 3."
  (buffer-substring
   (if (org-region-active-p) (region-beginning) (point-min))
   (if (org-region-active-p) (region-end) (point-max
+(org-export-current-backend 'org-export-generic)
 (lines (org-split-string
 (org-export-preprocess-string
  region
-- 
1.7.3.5

[O] Patches for org-generic-export

[Robert P. Goldman]

Attached is a set of patches to the org-generic-exporter.  They fix a
change in the org-preprocess process that means that all uses of the
org-generic export facility will crash.  They also add rudimentary
support for trac wiki and tikiwiki export.  Finally, I have removed
the HTML exporter from the org-generic export.  I don't see any reason
to struggle to support this, since it is done better by the core parts
of org-mode.

Cheers,
r


Table of contents:

[PATCH 1/5] bind org-export-current-backend in generic exporter.
[PATCH 2/5] Added trac-wiki and tikiwiki export settings.
[PATCH 3/5] Kill the HTML exporter.
[PATCH 4/5] Fixed section-header-prefix for trac wiki.
[PATCH 5/5] Fix header prefixes for trac wiki.

[O] [PATCH 4/5] Fixed section-header-prefix for trac wiki.

[Robert P. Goldman]

---
 contrib/lisp/org-export-generic.el |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-export-generic.el 
b/contrib/lisp/org-export-generic.el
index 15afe6a..5a5af14 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -405,8 +405,8 @@ in this way, it will be wrapped."
  :body-header-section-numbers   nil
  :body-section-prefix   "\n"
 
- :body-section-header-prefix("== " "=== " " "
-"= " "== " "=== ")
+ :body-section-header-prefix(" == " " === " "  "
+" = " " == " " === ")
  :body-section-header-suffix(" ==\n\n" " ===\n\n" " \n\n" 
 " =\n\n" " ==\n\n" " ===\n\n")
 
-- 
1.7.3.5

[O] [PATCH 5/5] Fix header prefixes for trac wiki.

[Robert P. Goldman]

trac wiki has hard limit on number of headers.  Need space before
macro characters in trac wiki.

Add a couple of TODO comments.
---
 contrib/lisp/org-export-generic.el |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/contrib/lisp/org-export-generic.el 
b/contrib/lisp/org-export-generic.el
index 5a5af14..12bbcdb 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -87,7 +87,9 @@
 ;; *** allow different open/closing prefixes
 ;;   * properties
 ;;   * drawers
-;;   * oh my
+;;   * Escape camel-case for wiki exporters.
+;;   * Adjust to depth limits on headers --- need to roll-over from headers
+;; to lists, as per other exporters
 ;;   * optmization (many plist extracts should be in let vars)
 ;;   * define defcustom spec for the specifier list
 ;;   * fonts:  at least monospace is not handled at all here.
@@ -406,7 +408,7 @@ in this way, it will be wrapped."
  :body-section-prefix   "\n"
 
  :body-section-header-prefix(" == " " === " "  "
-" = " " == " " === ")
+" = " )
  :body-section-header-suffix(" ==\n\n" " ===\n\n" " \n\n" 
 " =\n\n" " ==\n\n" " ===\n\n")
 
-- 
1.7.3.5

[O] [PATCH 2/5] Added trac-wiki and tikiwiki export settings.

[Robert P. Goldman]

---
 contrib/lisp/org-export-generic.el |  107 +++-
 1 files changed, 93 insertions(+), 14 deletions(-)

diff --git a/contrib/lisp/org-export-generic.el 
b/contrib/lisp/org-export-generic.el
index 29e90b8..e3a8680 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -187,8 +187,8 @@ in this way, it will be wrapped."
; section prefixes/suffixes can be 
direct strings or lists as well
  :body-section-prefix "\n"
  :body-section-suffix "\n"
-;   :body-section-prefix ("\n" "\n" "\n")
-;   :body-section-suffix ("\n" "\n" "\n")
+   ;:body-section-prefix 
("\n" "\n" "\n")
+   ;:body-section-suffix 
("\n" "\n" "\n")
 
 
; if preformated text should be 
included (eg, : prefixed)
@@ -263,28 +263,28 @@ in this way, it will be wrapped."
  :body-header-section-numbers 3
  :body-section-prefix "\n"
 
-;   :body-section-header-prefix  "\n"
-;   :body-section-header-format  "%s\n"
-;   :body-section-header-suffix  (?\$ ?\# ?^ ?\~ ?\= ?\-)
+   ;:body-section-header-prefix  
"\n"
+   ;:body-section-header-format  
"%s\n"
+   ;:body-section-header-suffix  
(?\$ ?\# ?^ ?\~ ?\= ?\-)
 
  :body-section-header-prefix  ("" "" "" "* " "  + " "- ")
  :body-section-header-format  "%s\n"
  :body-section-header-suffix  (?~ ?= ?- "\n" "\n" "\n")
 
-;   :body-section-marker-prefix  ""
-;   :body-section-marker-chars   (?\$ ?\# ?^ ?\~ ?\= ?\-)
-;   :body-section-marker-suffix  "\n"
+   ;:body-section-marker-prefix  ""
+   ;:body-section-marker-chars   
(?\$ ?\# ?^ ?\~ ?\= ?\-)
+   ;:body-section-marker-suffix  
"\n"
 
  :body-line-export-preformated t
  :body-line-format "%s\n"
  :body-line-wrap   75
 
-;   :body-text-prefix "\n"
-;   :body-text-suffix "\n"
+   ;:body-text-prefix "\n"
+   ;:body-text-suffix "\n"
 
 
  :body-bullet-list-prefix  (?* ?+ ?-)
-;   :body-bullet-list-suffix  (?* ?+ ?-)
+   ;:body-bullet-list-suffix  
(?* ?+ ?-)
  )
 
 ;;
@@ -350,8 +350,8 @@ in this way, it will be wrapped."
 
  :body-section-prefix "\n"
  :body-section-suffix "\n"
-;   :body-section-prefix ("\n" "\n" "\n")
-;   :body-section-suffix ("\n" "\n" "\n")
+   ;:body-section-prefix 
("\n" "\n" "\n")
+   ;:body-section-suffix 
("\n" "\n" "\n")
 
  :body-line-export-preformated t
  :body-line-format "%s\n"
@@ -360,7 +360,7 @@ in this way, it will be wrapped."
  :body-text-suffix "\n"
 
  :body-bullet-list-prefix  (?* ?+ ?-)
-;   :body-bullet-list-suffix  (?* ?+ ?-)
+   ;:body-bullet-list-suffix  
(?* ?+ ?-)
  )
 
 ;;
@@ -429,6 +429,85 @@ in this way, it will be wrapped."
  :body-list-format"%s\n"
 
  )
+("trac-wiki" 
+ :file-suffix ".txt"
+ :key-binding ?T
+
+ ;; lifted from wikipedia exporter
+ :header-prefix""
+ :header-suffix""
+
+ :title-format "= %s =\n"
+
+ :date-export  nil
+
+ :toc-exportnil
+
+ :body-header-section-numbers   nil
+ :body-section-prefix   "\n"
+
+ :body-section-header-prefix("== " "=== " " "
+"= " "== " "=== ")
+ :body-section-header-suffix(" ==\n\n" " ===\n\n" " \n\n" 
+" =\n\n" " ==\n\n" " ===\n\n")
+
+ :body-line-export-preformated  t ;; yes/no/maybe???
+ :body-line-format  "%s\n"
+ :body-line-wrap75
+
+ :body-line-fixed-format   " %s\n"
+
+ :body-list-format  " * %s\n"
+ :body-number-list-format   " # %s\n"
+ ;;:body-list-prefix  "LISTSTART"
+ ;;:body-list-suffix  "LISTEND"
+
+ ;; this is ignored! [2010/02/02:rpg]
+ :body-bullet-list-prefix   ("* " "** " "*** " " " "* ")
+ )
+("tikiwiki" 
+ :file-suffix ".txt"
+ :key-binding ?U
+
+ ;; lifted from wikipedia exporter
+ :header-prefix""

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

>
> I disagree with Tom on [1]: it should clearly be "srcname", in analogy
> to #+tblname - and also so I don't have to change my files :-} (but see
> my question about tblname below).
>
> I agree on [2] "call".
>

noted

>
> I'm confused by [3] so I will say nothing for now, except to ask some
> questions: are we talking about what a human would use to label a piece
> of data for consumption by a block (including perhaps the future
> possibilities of lists and paragraphs that Tom brought up)?

Yes, and lists are already supported.  Supporting paragraphs would not
be difficult.

> what babel would use to label a results block (possibly so that it
> could be consumed by another block in a chain)? both?

yes

> would that mean that #+tblname would go the way of the dodo and that
> tables would be labelled with #+data (or #+object or whatever else we
> come up with)?
>

I am hesitant to suggest changing #+tblname: as it is used throughout
the rest of Org-mode, so it may be that whatever choice is made here
tblname will remain a synonymous option.

Thanks -- Eric

>
> Thanks,
> Nick
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

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

> Eric Schulte  writes:
>
>>> [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, 
>>> #+FUNCTION,
>>> #+CALL, #+LOB, and SBE, some of which are interchangeable; some
>>> not. I'd prefer
>>> deprecating an old form when a better one is found.
>>
>> This point of view has been raised previously both on the mailing list
>> and in the #org-mode IRC chat room.  I think it is time that we decided
>> as a community what we want to do about the prevalence of code block
>> synonyms -- we should make this decision before the release of Emacs24
>> after which syntax will become harder to change.
>>
>> There are currently a number of instances of synonymous keywords when
>> dealing with code blocks, specifically.
>>
>>  named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>> named data [3] -- "tblname" "resname" "results" "data"
>>
>> Ideally if we limit each of the above to only one alternative we could
>> simplify the specification of code blocks in Org-mode making them easier
>> to learn and use and removing some of the mystery around their syntax.
>>
>> What does everyone think?
>>
>> Are there suggestions for the best names for each code block entity
>> (either in the list or not in the list)?
>>
>> Are there cases where we want to continue to allow synonyms (e.g., in
>> named data so that "results" can be used for code block results but
>> "data" can be used for hand-written data)?
>>
>> Thanks -- Eric
>>
>> Footnotes: 
>> [1] named code blocks
>>
>> #+source: foo
>> #+begin_src emacs-lisp
>>   'foo
>> #+end_src
>>
>> #+srcname: foo
>> #+begin_src emacs-lisp
>>   'foo
>> #+end_src
>>
>> #+function: foo
>> #+begin_src emacs-lisp
>>   'foo
>> #+end_src
>>
>> [2]  calling external functions
>>
>> #+call: foo()
>>
>> #+lob: foo()
>>
>> [3]  named data
>>
>> #+data: something
>> : something
>> #+results: something
>> : something
>>
>> etc...
>
> Hi Eric,
>
> named code blocks [1] "source"
> calling external functions [2] "call"
> named data [3] "object"
>

Noted, thanks, your choices for 1 and 2 are my favorite as well.

>
> My motivation for [3] "object" instead of the suggested alternates is
> the hope that it will be possible to name things like lists and
> paragraphs (that aren't results or data) and pass these objects to
> source code blocks.
>

I would say that I would consider paragraphs and lists to be "data" as
well, but I think object is a fine alternative.  Also, lists are already
a supported data type.

#+data: something
- 1
- 2
- 3

#+begin_src emacs-lisp :var it=something :results list
  (reverse it)
#+end_src

#+results:
- 3
- 2
- 1

Thanks for sharing -- Eric

>
> All the best,
> Tom

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

>> I'm confused by [3] so I will say nothing for now, except to ask some
>> questions: are we talking about what a human would use to label a piece
>> of data for consumption by a block (including perhaps the future
>> possibilities of lists and paragraphs that Tom brought up)? what babel
>> would use to label a results block (possibly so that it could be
>> consumed by another block in a chain)? both? would that mean
>> that #+tblname would go the way of the dodo and that tables would be
>> labelled with #+data (or #+object or whatever else we come up with)?
>
> +1 (Confused, too)
>

well, I guess it is good that this discussion has begun if only to clear
up this lingering uncertainty.

>
> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
> don't?
>

from the prospective of code blocks it is exactly synonymous with
tblname.  Srcname is different in that it labels code blocks.

>
> A reason to keep TBLNAME is that it's also used by the spreadsheet
> remote references. If Babel looked for DATA instead, a table that is
> both a remote reference for another spreadsheet and a data source for
> a src block would need both TBLNAME and DATA, which seems redundant.
>

agreed, I'm thinking that tblname will at least remain an option no
matter what decision is made.

>
> As for labeling lists and paragraphs, I recall from the list that
> Nicolas Goaziou is working on a generalized way to set captions,
> labels and attributes for various kinds of Org block, as is possible
> now for tables and images. I thought that sounded promising. I don't
> know if he planned for block names, too (currently we have tblname but
> no imgname), but that could make sense. In which case it might be a
> good idea to coordinate.
>

Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
I would like to voice my desire to be able to add captions to code
blocks, the lack of this feature has bitten me in the past.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Schulte  writes:
>
>> There are currently a number of instances of synonymous keywords when
>> dealing with code blocks, specifically.
>>
>>  named code blocks [1] -- "source" "srcname" "function"
>> calling external functions [2] -- "call" "lob"
>> named data [3] -- "tblname" "resname" "results" "data"
>>
>
> - Cases [1] and [2] : I'd suggest to drop all of them and to use "name",
>   shared by both source code and data. Is it really different to name
>   a source block or a list?
>

I think you mean [1] and [3] in the above, and I agree, these could
easily be the same term and "name" has a nice generality to it.
Although it is unintuitive in the case of un-named data, e.g.,

#+name:
| 1 |
| 2 |
| 3 |

looks weird to me.

>
> - Case [3] : I like "call". "lob" is too cryptic.
>

assuming you mean [2] above, I think call is emerging as the clear
winner in this case.

>
>> Are there cases where we want to continue to allow synonyms (e.g., in
>> named data so that "results" can be used for code block results but
>> "data" can be used for hand-written data)?
>
> No. One Keyword to name them all.
>

Noted, Thanks for the input -- Eric

>
> Regards,
>
> [1] DEFINITION NOT FOUND: 1
>
> [2] DEFINITION NOT FOUND: 3
>
> [3] DEFINITION NOT FOUND: 2

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] Include does not work when doing org-export-as-org

[Bastien]

Carsten Dominik  writes:

> You are welcome - and I think it might be good in integrate
> Nicks function into Org and make it available through the menu
> or a key.

Indeed -- IIRC the problem is that Nick cannot submit non-tiny 
patches :(  I added Nick's code to Worg/org-hacks.org.  Carsten,
could you apply a patch with a rewrite of Nick's code and the 
changes in the menu/keymap?  (If Nick doesn't mind, of course.)

-- 
 Bastien

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

>
> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
> entering for me. That's currently "srcname". I don't have a strong opinion,
> though, to choose one over the other, except that I like Nick's argument with
> the table analogy.
>
>> I agree on [2] "call".
>
> I clearly agree on "call" as well.
>

noted, thanks

>
> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
> call, absolutely similar to "call". Is there a technical reason to be forced
> to differentiate both?  If no, can we use "call" as well instead of "sbe"?
>

The only difference is that sbe is a function name, and to name a
function call (a function which will take up that term in the entire
Emacs-lisp namespace across all applications) seems somewhat pushy.

>
>> I'm confused by [3] so I will say nothing for now, except to ask some
>> questions: are we talking about what a human would use to label a piece of
>> data for consumption by a block (including perhaps the future possibilities
>> of lists and paragraphs that Tom brought up)? what babel would use to label
>> a results block (possibly so that it could be consumed by another block in a
>> chain)? both? would that mean that #+tblname would go the way of the dodo
>> and that tables would be labelled with #+data (or #+object or whatever else
>> we come up with)?
>
> For point 3, Eric, I guess that whichever term is chosen, that does not mean
> that "results" will change (I mean: when it's a result of a block execution)?
>

I would be happy for results to change to data or tblname (if a table)
or whatever else is selected.

>
> In other words, if we choose for "object", we still will have the possibility
> to use "results" (automatically generated) and "object" to refer to something
> we want to use in another call?
>
 named data [3] -- "tblname" "resname" "results" "data"
>
> I don't specifically like "resname".
>
> I would keep "results" for automatically generated "results".
>
> I do like "data", but can learn to like "object" as a more generic term,
> future-proof for coming extensions.
>

I'll mark you down as undecided for this term. :)

>
> Last remark: we could get one step further and wonder if it wouldn't be good
> to impose a single way to pass variables? We currently have two different
> mechanisms:
>
> #+srcname: convert-date-to-French-format
> #+begin_src sql :var column=""
> CONVERT(varchar(10), $column, 103) AS $column
> #+end_src
>
> and
>
> #+srcname: convert-date-to-French-format(column="")
> #+begin_src sql
> CONVERT(varchar(10), $column, 103) AS $column
> #+end_src
>
> I guess that the first one is easier if we want to construct complex variable
> values (which call Emacs Lisp code or such), but...
>

I don't feel that this example causes as much confusion, but if I'm
wrong I am open to change on this front.  Although the only possible
change here would be to remove the second option as the first method of
specifying variables is central to code block management.

>
> Thanks for your comments...
>

Thanks for your feedback, Best -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] org-contacts or bbdb?

[Wes Hardaker]

> On Fri, 21 Oct 2011 10:21:11 +0800, Eric Abrahamsen 
>  said:

EA> As Rasmus mentioned, if you use BBDB you should get version 3, it's
EA> significantly better than the previous version. There's a slow movement
EA> towards better import/export functions, which I think has been one of
EA> the major gripes about BBDB in the past (there are probably more I'm not
EA> aware of).

BBDB is great, though I haven't switched to BBDB3 yet because of
incompatible changes I haven't looked into yet.

I actually would like to use org-contacts because I think the editable
form is significantly nicer than bbdb's.  BBDB is great, but you can't
go mess with the database easily.  EG, with BBDB if one area gets a new
area code you can't go quickly search/replace for all records replacing
111 with 222.  With org-contacts it's a simple search/replace edit.

Note I wrote a bbdb to org-contacts converter:

  http://www.hardakers.net/code/bbdb-to-org-contacts/

But what I really want is a bi-directional sync, of course...

-- 
Wes Hardaker 
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: [O] OPatches for org-generic-export

[Wes Hardaker]

> On Fri, 21 Oct 2011 11:13:24 -0500, "Robert P. Goldman" 
>  said:

RPG> Attached is a set of patches to the org-generic-exporter.  They fix
RPG> a change in the org-preprocess process that means that all uses of
RPG> the org-generic export facility will crash.  They also add
RPG> rudimentary support for trac wiki and tikiwiki export.  Finally, I
RPG> have removed the HTML exporter from the org-generic export.  I
RPG> don't see any reason to struggle to support this, since it is done
RPG> better by the core parts of org-mode.

Glad to see someone tinkering with it!  yay!

FYI, the reason the HTML was in there was for proof of concept more than
anything else.  It was a learning example for those wishing to write
their own exports, as HTML is known by lots of people and demonstrated
what you could do with it.  [especially if you wanted hand-crafted html]
-- 
Wes Hardaker 
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

Re: [O] Private flag or property

[Eric S Fraga]

Karl Voit  writes:

> Hi!
>
> I am still in the process of converting (lots!) of old data into
> Org-mode format.
>
> I stumbled over a private-flag PalmOS datebook used to maintain.
>
> Is there a *common* way of expressing a private flag/property yet?

Not that I know of.

>
> Or is there no pseudo-standard and I should stick to my «:PRIVATE:
> True» property I am thinking of? (Is there a necessity for the
> «True» string in my example (property without value)?

The question is what or how you want to use this flag?  For truly
private entries, I use encryption, with the :crypt: tag.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1
: using Org-mode version 7.7 (release_7.7.408.g7caa7)

[O] [PATCH 3/5] Kill the HTML exporter.

[Robert P. Goldman]

This is done better in core org-mode.
---
 contrib/lisp/org-export-generic.el |   41 
 1 files changed, 0 insertions(+), 41 deletions(-)

diff --git a/contrib/lisp/org-export-generic.el 
b/contrib/lisp/org-export-generic.el
index e3a8680..15afe6a 100644
--- a/contrib/lisp/org-export-generic.el
+++ b/contrib/lisp/org-export-generic.el
@@ -322,47 +322,6 @@ in this way, it will be wrapped."
 
  :body-bullet-list-prefix   ("* " "** " "*** " " " "* ")
  )
-
-;;
-;; minimal html exporter
-;;
-("html"
- ;; simple html output
- :file-suffix  ".html"
- :key-binding   ?h
-
- :header-prefix ""
-
- :title-format  "%s\n\n"
-
- :date-export  t
- :date-format   "Date: %s\n\n"
-
- :toc-exportnil
-
- :body-header-section-numbers 3
-
- :body-section-header-prefix  ("" "" ""
-  "" "" "")
- :body-section-header-format  "%s"
- :body-section-header-suffix  ("\n" "\n" "\n"
-  "\n" "\n" "\n")
-
- :body-section-prefix "\n"
- :body-section-suffix "\n"
-   ;:body-section-prefix 
("\n" "\n" "\n")
-   ;:body-section-suffix 
("\n" "\n" "\n")
-
- :body-line-export-preformated t
- :body-line-format "%s\n"
-
- :body-text-prefix "\n"
- :body-text-suffix "\n"
-
- :body-bullet-list-prefix  (?* ?+ ?-)
-   ;:body-bullet-list-suffix  
(?* ?+ ?-)
- )
-
 ;;
 ;; internet-draft .xml for xml2rfc exporter
 ;;
-- 
1.7.3.5

Re: [O] OPatches for org-generic-export

[Bastien]

Hi Wes,

Wes Hardaker  writes:

> RPG> Attached is a set of patches to the org-generic-exporter.  They fix
> RPG> a change in the org-preprocess process that means that all uses of
> RPG> the org-generic export facility will crash.  They also add
> RPG> rudimentary support for trac wiki and tikiwiki export.  Finally, I
> RPG> have removed the HTML exporter from the org-generic export.  I
> RPG> don't see any reason to struggle to support this, since it is done
> RPG> better by the core parts of org-mode.
>
> Glad to see someone tinkering with it!  yay!

Could you test Robert's patches against latest Org and report 
any problem?  As the author of the generic exporter, you might
spot problems more easily...

Thanks!

-- 
 Bastien

Re: [O] Exporting selected tasks (maybe from agenda view) including their body.

[Bastien]

Hi Dominik,

Dominik Schrempf  writes:

> Is there a possibility to export tasks including their body (text,
> maybe logbook etc.) from the agenda view?

Nope.

> What I would like to do is the following: I have Tasks with a certain
> todo state (e.g. WAITING). I can view all these tasks in an agenda
> view. Now I need to leave my computer and want to print out every task
> showing up in the agenda view (e.g. every task with a WAITING todo
> state) including the bodies of the tasks (the whole text that shows up
> in the org file, maybe without logbook drawers). It should work like
> exporting to HTML (because the latex formulas should be compiled) but
> picking only some tasks of multiple org files. Does such an export
> function exist? If not, how could I achieve this?

I don't think this can easily be done - you would need to go through
each agenda task, find the corresponding Org subtree, copy it into a
master .org file, then export this file.

But I understand the need, and would also love to have a solution for
this. 

Best,

-- 
 Bastien

Re: [O] org-protocol and new frames

[Bastien]

Hi Tom,

Tom Prince  writes:

> Is there any way to get org-protocol to create a new frame, when it
> needs to open a buffer, but otherwise not open one.

Can you give a more detailed example?  What does your Org protocol
look like?

Thanks,

-- 
 Bastien

Re: [O] OPatches for org-generic-export

[Robert Goldman]

On 10/21/11 Oct 21 -12:06 PM, Wes Hardaker wrote:
>> On Fri, 21 Oct 2011 11:13:24 -0500, "Robert P. Goldman" 
>>  said:
> 
> RPG> Attached is a set of patches to the org-generic-exporter.  They fix
> RPG> a change in the org-preprocess process that means that all uses of
> RPG> the org-generic export facility will crash.  They also add
> RPG> rudimentary support for trac wiki and tikiwiki export.  Finally, I
> RPG> have removed the HTML exporter from the org-generic export.  I
> RPG> don't see any reason to struggle to support this, since it is done
> RPG> better by the core parts of org-mode.
> 
> Glad to see someone tinkering with it!  yay!
> 
> FYI, the reason the HTML was in there was for proof of concept more than
> anything else.  It was a learning example for those wishing to write
> their own exports, as HTML is known by lots of people and demonstrated
> what you could do with it.  [especially if you wanted hand-crafted html]

Hm.  Well, we could certainly just skip that patch, and apply only the
others to org-mode, if we want to keep it.

The problem with doing that is that when I am fixing things (e.g., I am
working to make links work with various wiki export formats), I don't
have the energy to maintain the HTML backend.  So it's likely to
bit-rot, which would make it turn into a /bad/ exemplar.

What do you think?

I think also we should try to assemble a single org document with all
kinds of markup that are expected to work, and use that to make tests.
An export facility is actually easy to regression test  I just
haven't gotten around to it.  Do you know if there is such a document
for one of the other exporters that I could piggyback on?

Best,
r

Re: [O] Links to C/C++ source code lines

[Bastien]

Hi Rafal,

Rafal  writes:

> I wrote a small hook for creating org-mode links to C/C++ source code lines 
> in 
> the form of a regexp so the links stay valid even if the source code changes
>
> eg. 
> a source line
> while(ptr < ptr_end)
> has a link
> file:/home/user/src/example.cpp::/while[ \t]*([ \t]*ptr[ \t]*<[ \t]*ptr_end[ 
> \t]
> *)#1/
>
> The number after the hash is a sequence number in case there are more than 
> one 
> such line
>
> If you are interested: http://rafflo.w.interia.pl/org-c-link.el

Looks nice, thanks.  Just wondering: are you aware of the "A.3 Adding
hyperlink types" section in the manual?  You core uses advice instead 
of the `org-add-link-type' function -- is that on purpose?

Thanks!

-- 
 Bastien

Re: [O] OPatches for org-generic-export

[Jambunathan K]

> I think also we should try to assemble a single org document with all
> kinds of markup that are expected to work, and use that to make tests.
> An export facility is actually easy to regression test  I just
> haven't gotten around to it.  Do you know if there is such a document
> for one of the other exporters that I could piggyback on?

http://repo.or.cz/w/org-mode/org-jambu.git/tree/refs/heads/private:/contrib/odt/tests

-- 

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Eric Schulte]

Christian Moe  writes:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by 
> me) #+BABEL header over using properties.
>
> 1. Allowing you to specify multiple buffer-wide options on the same 
> line (keeping things short), in the same colon :syntax as used in a 
> src block header (keeping things consistent and easy to copy back and 
> forth). None of this makes a substantive difference.
>

Understood, the new method will require multiple lines.  Everything is a
trade-off...

>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The 
> following will work:
>
>#+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>#+PROPERTY: var euro=1.3791
>#+PROPERTY: var salestax=.15
>
> If BABEL is dropped for PROPERTY, it would be good for the :var: 
> property to support multiple arguments (comma-separated would be good 
> for consistency with passing arguments through the SRCNAME). E.g.:
>
>#+PROPERTY: var euro=1.3791, salestax=.15
>
> I think I'd like this better in any case.
>

Nice idea.  This same issue with "var" arose when we first started
allowing header arguments to be specified inside subtree properties.
I've just implemented your suggestion so the following are now possible.

#+PROPERTY: var foo=1, bar=2
#+PROPERTY: cache yes

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
: 3

and

#+begin_src emacs-lisp :var foo="this", bar="that"
  (concat foo " " bar)
#+end_src

#+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
: this that

Thanks for the suggestion and I hope the above is a sufficient
replacement for the now-missing #+BABEL: syntax.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> Now, between "srcname" and "source": I'm used to whatever my Yasnippet is
>> entering for me. That's currently "srcname". I don't have a strong opinion,
>> though, to choose one over the other, except that I like Nick's argument with
>> the table analogy.
>>
>>> I agree on [2] "call".
>>
>> I clearly agree on "call" as well.
>
> noted, thanks

I think you'll get unanimity on that one.

>> Here, I'd like to ask: what about "sbe"?  In my own understanding, it's a
>> call, absolutely similar to "call". Is there a technical reason to be forced
>> to differentiate both?  If no, can we use "call" as well instead of "sbe"?
>
> The only difference is that sbe is a function name, and to name a
> function call (a function which will take up that term in the entire
> Emacs-lisp namespace across all applications) seems somewhat pushy.

OK. Point understood. May I suggest to try to find a better name, still?  Once
we're at it, modifying one extra line in the documentation won't hurt.

I don't know what others find, but I've never understood what it meant. OK,
now (since yesterday, in fact), I know it means "source block evaluation", but
that's not really intuitive.

I'd opt for "ob-call" (package name + "call") or something like that, if I
could choose.

>>> I'm confused by [3] so I will say nothing for now, except to ask some
>>> questions: are we talking about what a human would use to label a piece of
>>> data for consumption by a block (including perhaps the future possibilities
>>> of lists and paragraphs that Tom brought up)? what babel would use to label
>>> a results block (possibly so that it could be consumed by another block in a
>>> chain)? both? would that mean that #+tblname would go the way of the dodo
>>> and that tables would be labelled with #+data (or #+object or whatever else
>>> we come up with)?
>>
>> For point 3, Eric, I guess that whichever term is chosen, that does not mean
>> that "results" will change (I mean: when it's a result of a block execution)?

I was expecting you'd always keep "results" for auto-inserted results (after a
code block evaluation). But it makes sense to prefer the one term that will
win.

> I would be happy for results to change to data or tblname (if a table)
> or whatever else is selected.

OK, clear.

>> In other words, if we choose for "object", we still will have the possibility
>> to use "results" (automatically generated) and "object" to refer to something
>> we want to use in another call?
>>
> named data [3] -- "tblname" "resname" "results" "data"
>>
>> I don't specifically like "resname".
>>
>> I would keep "results" for automatically generated "results".
>>
>> I do like "data", but can learn to like "object" as a more generic term,
>> future-proof for coming extensions.
>
> I'll mark you down as undecided for this term. :)

Yep!  I'm open to any suggestion you'll make.

>> Last remark: we could get one step further and wonder if it wouldn't be good
>> to impose a single way to pass variables? We currently have two different
>> mechanisms:
>>
>> #+srcname: convert-date-to-French-format
>> #+begin_src sql :var column=""
>> CONVERT(varchar(10), $column, 103) AS $column
>> #+end_src
>>
>> and
>>
>> #+srcname: convert-date-to-French-format(column="")
>> #+begin_src sql
>> CONVERT(varchar(10), $column, 103) AS $column
>> #+end_src
>>
>> I guess that the first one is easier if we want to construct complex variable
>> values (which call Emacs Lisp code or such), but...
>
> I don't feel that this example causes as much confusion, but if I'm
> wrong I am open to change on this front.  Although the only possible
> change here would be to remove the second option as the first method of
> specifying variables is central to code block management.

Just that I remember both syntaxes weren't handled the same way for error
reporting (remember, when there is no default value: in one case, you can get
the name of the faulty block; in the other, not), and that makes me think is
not as simple as an alias. Hence, your Babel code is or can become different
just because there are different alternatives to write certain things down.

Then, as a user, I always wonder what's the best one?  "For a good error
reporting (with the name of the code block being outputted), which one do I
have to use?" and such questions...

If we only have one way, we can be sure everybody experiences the same things
with the same semantical input.

Another point, that may or may not have much to do with this, is that I don't
have anymore the source name exported in HTML -- dunno when it disappeared,
though. I remember that, at some point, it was due to having, or not, a
default value (at the time, having no default value was still allowed), but
now, even with the default values for every var, I miss those names in the
HTML (for literate programming support, it is quite useful to be able to see
the name of the block along wit

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

"Sebastien Vauban"  writes:

> Hi Torsten,
>
> Torsten Wagner wrote:
>> I tend to  #+results: because it fits more to the entire babel syntax.
>> However, earlier on the mailing list people were pointing out that one
>> is going to change "results" for a unknown source block (that was the
>> reason "data" was introduced) and I think this is a valid
>> argument. Maybe "data" and "results" should be both valid if only to
>> pleasure human thinking. However, if I understood correctly, maybe
>> data could be changed to be more some type of constant? That is,
>> #+data: foo can not be changed by a source code block named foo
>> (because it isn't a "result" but "data") but only by human (as a
>> "data" input). Does this make sense?
>
> Yes, #+results are automatically generated by execution of some code.
>
> But, if you want to start with something, not generated, you had to insert
> yourself a #+results block until the more logical #+data had been introduced.
>
> I like your explanation about the fact that such a manually-entered block is
> "constant".
>

I like "constant" too, but the goals is to remove synonyms, not add
them. :)

Thanks -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] org-mac-protocol no remember window and Symbol's function definition is void: caddr from emacs server

[Bastien]

Hi David,

David Abernethy  writes:

> Waiting for Emacs...
> *ERROR*: Symbol's function definition is void: caddr

That's quite weird.

> Can anyone spot the cause of the problem please?

Sorry, I cannot.   (OT comment: I suggest you switch from using 
remember to using capture.)

-- 
 Bastien

Re: [O] org-contacts or bbdb?

[Sebastien Vauban]

Hi Wes and all,

Wes Hardaker wrote:
>> On Fri, 21 Oct 2011 10:21:11 +0800, Eric Abrahamsen 
>>  said:
>
> EA> As Rasmus mentioned, if you use BBDB you should get version 3, it's
> EA> significantly better than the previous version. There's a slow movement
> EA> towards better import/export functions, which I think has been one of
> EA> the major gripes about BBDB in the past (there are probably more I'm not
> EA> aware of).
>
> BBDB is great, though I haven't switched to BBDB3 yet because of
> incompatible changes I haven't looked into yet.
>
> I actually would like to use org-contacts because I think the editable
> form is significantly nicer than bbdb's.  BBDB is great, but you can't
> go mess with the database easily.  EG, with BBDB if one area gets a new
> area code you can't go quickly search/replace for all records replacing
> 111 with 222.  With org-contacts it's a simple search/replace edit.
>
> Note I wrote a bbdb to org-contacts converter:
>
>   http://www.hardakers.net/code/bbdb-to-org-contacts/
>
> But what I really want is a bi-directional sync, of course...

I share your point of view about editability of org-contacts. I clearly would
like all my data to become Orgified in some way.

Though, I did not do the change from my bbdb (still 2.35) to Org-contacts as,
for me, one thing that really is missing is the ability to recognize emails
and author names: I want to be alerted if my buddy "John Doe" uses a mail I
wasn't aware of, and want to be offered the possibility to add it in my
database.

Same for the same email address, but with a different name.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Standardized code block keywords

[Sebastien Vauban]

Hi Eric and Torsten,

Eric Schulte wrote:
>> We could open an older file and if it isn't working, we could try
>>
>> #+PROPERTY: babel-function-set obsolete
>
> I think that making use of such a feature is almost as onerous as
> changing to the new terms (which is a simple search replace, in fact
> once terms are selected I'll happily share a function on list which can
> be used to convert all old terms in existing Org-mode files).

I also think, for the sake of the efficiency we're trying to achieve, that we
must forget about the past in one "big bang" (v7.8 or whatever). Supporting it
temporarily in v7.8 and not anymore in 7.9 won't really help, IMHO.

Of course, it must be clearly stated that this change will break every old
report. That must be the first visible item of the description of 7.8.

Regarding a function to automate the changes, this is what I used this
afternoon (quite dumb, certainly to be improved):

#+begin_src emacs-lisp
(defun my/org-propertyze-babel-line ()
  (interactive)
  (search-forward-regexp ":")
  (delete-backward-char 2)
  (insert "\n#+PROPERTY:  "))
#+end_src

Put point after `#+BABEL:' and apply it as many times as needed.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

So far I have the following.

code block names
| source  | dye |
| srcname | dokos   |
| srcname | moe |
| srcname | vauban  |
| srcname | wagner  |
| name| goaziou |

call lines
| call | dye |
| call | dokos   |
| call | moe |
| call | vauban  |
| call | wagner  |
| call | goaziou |

data names
| object | dye |
| (data results) | wagner  |
| name   | goaziou |

It seems that srcname is pulling ahead for naming code blocks (to my
surprise) and that call is the clear winner for call lines.  labeling
data is certainly less obvious and has tricky entanglements with other
parts of Org-mode (e.g., tables will likely continue to be named with
tblname).

I'll likely be out of contact for the remainder of the weekend but when
I'm back I'll update tallies and we can see where the consensus stands.
Thanks to everyone who has or will reply, I think the best way to find
the most natural options for these decisions is through surveys and it
is great to have a community so willing to help.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] Date-centric Clocktable

[Bastien]

Hi Rasmus,

Rasmus  writes:

> Is is possible to have a clocktabke with times in the left-most column?
> The people I am doing some work for now prefer it that way for unknown
> reasons. 
>
> This is an example
>
> | date   | Headline| total |
> |+-+---|
> | [2011-08-19 Fri 00:28]--[2011-08-19 Fri 00:51] | Writing mails   |  0:23 |
> | [2011-06-22 Wed 17:00]--[2011-06-22 Wed 17:45] | Data processing |  0:45 |

This is not currently possible as such.  

In the meantime, playing with the :block, :tstart and :tend parameters
can help providing something *not* that far.

HTH (a bit),

-- 
 Bastien

Re: [O] Exporting to Pinboard.in

[Bastien]

Hi Aditya,

Aditya Mandayam  writes:

> Could anyone tell  me how to do this?

Please have a look at Wes generic exporter (in
contrib/lisp/org-export-generic.el) which provides 
a framework for supporting new (simple) export formats.

HTH,

-- 
 Bastien

Re: [O] [RFC] Standardized code block keywords

[Thomas S. Dye]

Eric Schulte  writes:

> t...@tsdye.com (Thomas S. Dye) writes:
>
>> Eric Schulte  writes:
>>
 [1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, 
 #+FUNCTION,
 #+CALL, #+LOB, and SBE, some of which are interchangeable; some
 not. I'd prefer
 deprecating an old form when a better one is found.
>>>
>>> This point of view has been raised previously both on the mailing list
>>> and in the #org-mode IRC chat room.  I think it is time that we decided
>>> as a community what we want to do about the prevalence of code block
>>> synonyms -- we should make this decision before the release of Emacs24
>>> after which syntax will become harder to change.
>>>
>>> There are currently a number of instances of synonymous keywords when
>>> dealing with code blocks, specifically.
>>>
>>>  named code blocks [1] -- "source" "srcname" "function"
>>> calling external functions [2] -- "call" "lob"
>>> named data [3] -- "tblname" "resname" "results" "data"
>>>
>>> Ideally if we limit each of the above to only one alternative we could
>>> simplify the specification of code blocks in Org-mode making them easier
>>> to learn and use and removing some of the mystery around their syntax.
>>>
>>> What does everyone think?
>>>
>>> Are there suggestions for the best names for each code block entity
>>> (either in the list or not in the list)?
>>>
>>> Are there cases where we want to continue to allow synonyms (e.g., in
>>> named data so that "results" can be used for code block results but
>>> "data" can be used for hand-written data)?
>>>
>>> Thanks -- Eric
>>>
>>> Footnotes: 
>>> [1] named code blocks
>>>
>>> #+source: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> #+srcname: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> #+function: foo
>>> #+begin_src emacs-lisp
>>>   'foo
>>> #+end_src
>>>
>>> [2]  calling external functions
>>>
>>> #+call: foo()
>>>
>>> #+lob: foo()
>>>
>>> [3]  named data
>>>
>>> #+data: something
>>> : something
>>> #+results: something
>>> : something
>>>
>>> etc...
>>
>> Hi Eric,
>>
>> named code blocks [1] "source"
>> calling external functions [2] "call"
>> named data [3] "object"
>>
>
> Noted, thanks, your choices for 1 and 2 are my favorite as well.
>
>>
>> My motivation for [3] "object" instead of the suggested alternates is
>> the hope that it will be possible to name things like lists and
>> paragraphs (that aren't results or data) and pass these objects to
>> source code blocks.
>>
>
> I would say that I would consider paragraphs and lists to be "data" as
> well, but I think object is a fine alternative.  Also, lists are already
> a supported data type.
>
> #+data: something
> - 1
> - 2
> - 3
>
> #+begin_src emacs-lisp :var it=something :results list
>   (reverse it)
> #+end_src
>
> #+results:
> - 3
> - 2
> - 1
>
> Thanks for sharing -- Eric
>
>>
>> All the best,
>> Tom

Hi Eric,

Let me help revise the documentation when the dust settles and the
syntax changes are in place.  As it stands now, #+data: doesn't show up
in the index to the manual, and the entry for #+tblname: leads only to
a description of its use in spreadsheets.

I should have known lists are already supported.  Great work!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] [RFC] Standardized code block keywords

[Eric Schulte]

> Just to make it as easy as possible for everyone
> Might it be possible to introduce a small flags like "obsolete" and
> "stable" (standard)
> Old functions, old syntax, etc., might move first to obsolete before
> completely removed...
> We could open an older file and if it isn't working, we could try
>
> #+PROPERTY: babel-function-set obsolete
>

I think that making use of such a feature is almost as onerous as
changing to the new terms (which is a simple search replace, in fact
once terms are selected I'll happily share a function on list which can
be used to convert all old terms in existing Org-mode files).

>
> if it works, we have to modify the code, because obviously the code
> requires changed to be compatible in the future. However, just for the
> moment it is still working. This would give people more time to change
> there code accordingly. As murphy law tells us one will notice that
> the particular file is broken exact 5 minutes before the meeting with
> your boss standing behind you yelling print it, print it  ;)
>
> I know git would be perfect to keep the code base frozen for a certain
> syntax. However, babel is bundled with org-mode which is bundled with
> Emacs. Thus, it might be very difficult to tell people they have to
> use org-babel from git with the tag [org-babel_XX] if they want to use
> there old style files.  AFAIK org-babel does not even come with a own
> version numbering, right?
>
> Alternatively, keep the syntax a little bit longer as it is and create
> warning messages to point users to future changes (not sure how much
> time left for emacs24)
> "Warning: #+lob: in line XX is obsolete, please use #+call: in the
> future. (manual-link)"
>
> To make is short, is is possible to introduce changes "slowly"
>

I fear this would simply serve to introduce more complexity and
confusion.


>
> As for voting:
> [1]
> #+function: would be what I would expect from other programming
> languages. Where an unnamed source code block would be something like
> a lambda function.
> However, "function" as a term is heavily used in many target languages
> too. This makes parsing, reading and discussing a bit difficult. ("I
> called the function foo", "Wait, do you call the org-mode function
> foo, or the python function foo?")
> Thus, I vote for #+srcname similar to #+tblname to make sure about the
> difference between org-babel and the target languages.
>
> [2]
> #+call:, simply because I never can remember "lob" and the acronym is
> something difficult for newbies.
>

noted, thanks

>
> [3]
> I tend to  #+results: because it fits more to the entire babel syntax.
> However, earlier on the mailing list people were pointing out that one
> is going to change "results" for a unknown source block (that was the
> reason "data" was introduced) and I think this is a valid
> argument. Maybe "data" and "results" should be both valid if only to
> pleasure human thinking. However, if I understood correctly, maybe
> data could be changed to be more some type of constant? That is,
> #+data: foo can not be changed by a source code block named foo
> (because it isn't a "result" but "data") but only by human (as a
> "data" input). Does this make sense?
>

yes, I'll mark you down for "data and results", which I think is a
perfectly fine option.

Thanks for sharing -- Eric

>
> Totti
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: [O] [RFC] Standardized code block keywords

[Thorsten]

Hi Eric,

Eric Schulte  writes:

>  named code blocks [1] -- "source" "srcname" "function"
> calling external functions [2] -- "call" "lob"
> named data [3] -- "tblname" "resname" "results" "data"

here my votes:

[1] -- "srcname"
[2] -- "call" 
[3] -- ? "
I would choose either "tblname" or "data", but I do not oversee all the
implications. 

Cheers
-- 
Thorsten

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Nick Dokos]

Eric Schulte  wrote:

> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The 
> > following will work:
> >
> >#+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >#+PROPERTY: var euro=1.3791
> >#+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var: 
> > property to support multiple arguments (comma-separated would be good 
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >#+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
> 
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
> 
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
> #+begin_src emacs-lisp
>   (+ foo bar)
> #+end_src
> 
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
> 
> and
> 
> #+begin_src emacs-lisp :var foo="this", bar="that"
>   (concat foo " " bar)
> #+end_src
> 
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
> 
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
> 

Just to clarify my understanding: on a #+PROPERTY line, you *have* to
say

#+PROPERTY: var a=1, b=2

but in the code block itself, you can say *either*

#+begin_src emacs-lisp :var a=1, b=2
...


*or*

#+begin_src emacs-lisp :var a=1 :var b=2
...

Experimentally, both of these currently work: do you have any plans to
outlaw the last form?

Also, how does the comma-separated list of variable assignments interact
with a language where comma has syntactic significance? I was primarily
thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
construct. AFAICT, that never worked in babel[fn:1], so it may not
matter much, but it may be a good idea to come up with a quoting
mechanism so things like that can be added in the future if necessary.

Thanks,
Nick

Footnotes:

[fn:1] I checked in 7.7 to avoid the recent churn with the following
code block


#+begin_src python :var a='(1,2)'
len(a)
#+end_src

and I get 

,
|   File "", line 3
| a=[1, [\,, 2]]
|  ^
| SyntaxError: unexpected character after line continuation character
`

in the org babel error output buffer.

Re: [O] org-mac-protocol no remember window and Symbol's function definition is void: caddr from emacs server

[Nick Dokos]

Bastien  wrote:

> Hi David,
> 
> David Abernethy  writes:
> 
> > Waiting for Emacs...
> > *ERROR*: Symbol's function definition is void: caddr
> 
> That's quite weird.
> 
> > Can anyone spot the cause of the problem please?
> 
> Sorry, I cannot.   (OT comment: I suggest you switch from using 
> remember to using capture.)
> 

C-h f caddr gives me

,
| caddr is a compiled Lisp function in `cl.el'.
| 
| This function has a compiler macro.
| 
| (caddr X)
| 
| Return the `car' of the `cdr' of the `cdr' of X.
`

so you have to load cl.el[c] I think.

Nick

Re: [O] Include does not work when doing org-export-as-org

[Nick Dokos]

Bastien  wrote:

> Carsten Dominik  writes:
> 
> > You are welcome - and I think it might be good in integrate
> > Nicks function into Org and make it available through the menu
> > or a key.
> 
> Indeed -- IIRC the problem is that Nick cannot submit non-tiny 
> patches :(  I added Nick's code to Worg/org-hacks.org.  Carsten,
> could you apply a patch with a rewrite of Nick's code and the 
> changes in the menu/keymap?  (If Nick doesn't mind, of course.)
> 

I don't mind at all - you can do with it what you will.

Nick

[O] Org-mode Standardized Code Block Keywords

[chris . m . malone]

I've invited you to be an owner of the Google Moderator series "Org-mode  
Standardized Code Block Keywords". You can view and edit this series at  
http://www.google.com/moderator/#16/e=ffe1e

Re: [O] Org-mode Standardized Code Block Keywords

[Chris Malone]

Well…I didn't mean to invite everyone to own it, but rather to invite everyone 
to vote… :-p

Anyway, this should be a good place to tally the votes without filling inboxes.

Chris
On Oct 21, 2011, at 11:30 AM, chris.m.mal...@gmail.com wrote:

> I've invited you to be an owner of the Google Moderator series "Org-mode 
> Standardized Code Block Keywords". You can view and edit this series at 
> http://www.google.com/moderator/#16/e=ffe1e
> 

Re: [O] Current patches to make org-mode run on XEmacs

[Bastien]

Hi Michael,

thanks for these patches.  Next time, could you provide one patch per
mail?  The patchwork server cannot handle multiple patches and it makes
it easier to discuss every patch -- thanks!

Some comments below.

Michael Sperber  writes:

> ... are attached.  I've run with this for a few weeks now, and what I
> use mostly works.  So I would appreciate if these could go into the git
> repo.
>
> Let me draw your attention to this hunk:
>
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -7360,7 +7360,7 @@ would end up with no indentation after the change, 
> nothing at all is done."
>  col)
>(while (re-search-forward
> (concat "\\(" (regexp-opt org-all-time-keywords)
> -   "\\|" "^[ \t]*" org-tsr-regexp-both "*$"
> +   "\\|" "^[ \t]*" org-tsr-regexp-both "$"
> "\\|" "^[ \t]*:[a-zA-Z][a-zA-Z0-9_]*:.*$"
> "\\)") (or drawer-end end) t)
>   (beginning-of-line)
>
> While I needed this to make the code run on XEmacs, it really looks like
> a bug fix to me: The "*" that I deleted makes that part of the
> disjunction match the empty string, and that makes
> `org-fixup-indentation' loop infinitely.

Not sure I understand this fix: can you explain what is the problem 
with XEmacs (without considering the problem with Emacs)?

> --- a/lisp/ob-calc.el
> +++ b/lisp/ob-calc.el
> @@ -28,8 +28,9 @@
>  ;;; Code:
>  (require 'ob)
>  (require 'calc)
> -(require 'calc-store)
> -(unless (featurep 'xemacs) (require 'calc-trail))
> +(unless (featurep 'xemacs) 
> +  (require 'calc-trail)
> +  (require 'calc-store))
>  (eval-when-compile (require 'ob-comint))
>  
>  (defvar org-babel-default-header-args:calc nil

Applied, thanks.

> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index b1fa5f5..7e4da31 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -4306,8 +4306,8 @@ of what a project is and how to check if it stuck, 
> customize the variable
> "\\)\\>"))
>(tags (nth 2 org-stuck-projects))
>(tags-re (if (member "*" tags)
> -   (org-re (concat org-outline-regexp-bol
> -   ".*:[[:alnum:]_@#%]+:[ \t]*$"))
> +   (concat org-outline-regexp-bol
> +   (org-ref ".*:[[:alnum:]_@#%]+:[ \t]*$"))
>   (if tags
>   (concat org-outline-regexp-bol
>   ".*:\\("
> diff --git a/lisp/org-compat.el b/lisp/org-compat.el

I don't understand why (org-re (contact "..." "...")) does not produce
the same result than (contact (org-re "..." "...")) in XEmacs.  Can you
explain me?

> index 3e9c202..d093700 100644
> --- a/lisp/org-compat.el
> +++ b/lisp/org-compat.el
> @@ -251,8 +251,11 @@ Works on both Emacs and XEmacs."
>(defun org-activate-mark ()
>  (when (mark t)
>(setq mark-active t)
> -  (unless transient-mark-mode
> - (setq transient-mark-mode 'lambda)
> +  (when (and (boundp 'transient-mark-mode)
> +  (not transient-mark-mode))
> + (setq transient-mark-mode 'lambda))
> +  (when (boundp 'zmacs-regions)
> + (setq zmacs-regions t)
>  
>  ;; Invisibility compatibility
>  

Applied, thanks.

> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index f795fbd..43752ca 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -1028,7 +1028,8 @@ Pressing `1' will switch between these two options."
> (setq r1 (read-char-exclusive)))
> (error "No enclosing node with LaTeX_CLASS or EXPORT_TITLE or 
> EXPORT_FILE_NAME")
> )
> -(redisplay)
> +(if (fboundp 'redisplay)
> + (redisplay))
>  (and bpos (goto-char bpos))
>  (setq r2 (if (< r1 27) (+ r1 96) r1))
>  (unless (setq ass (assq r2 cmds))

Applied, thanks.

> diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el
> index 04389ef..a3bd9bf 100644
> --- a/lisp/org-footnote.el
> +++ b/lisp/org-footnote.el
> @@ -70,13 +70,13 @@
>;; their definition.
>;;
>;; `org-re' is used for regexp compatibility with XEmacs.
> -  (org-re (concat "\\[\\(?:"
> -   ;; Match inline footnotes.
> -   "fn:\\([-_[:word:]]+\\)?:\\|"
> -   ;; Match other footnotes.
> -   "\\(?:\\([0-9]+\\)\\]\\)\\|"
> -   "\\(fn:[-_[:word:]]+\\)"
> -   "\\)"))
> +  (concat (org-re "\\[\\(?:")
> +   ;; Match inline footnotes.
> +   (org-re "fn:\\([-_[:word:]]+\\)?:\\|")
> +   ;; Match other footnotes.
> +   (org-re "\\(?:\\([0-9]+\\)\\]\\)\\|")
> +   (org-re "\\(fn:[-_[:word:]]+\\)")
> +   (org-re "\\)"))
>"Regular expression for matching footnotes.")
>  
>  (defconst org-footnote-definition-re
> @@ -265,10 +265,9 @@ label, start, end and definition of the footnote 
> otherwise."
> (re-search-backward
>  message-signature-separator ni

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte wrote:

> Christian Moe  writes:
>
> > Hi again,
> >
> > I can quickly think of two advantages of the late lamented (if only by
> > me) #+BABEL header over using properties.
> >
> > 1. Allowing you to specify multiple buffer-wide options on the same
> > line (keeping things short), in the same colon :syntax as used in a
> > src block header (keeping things consistent and easy to copy back and
> > forth). None of this makes a substantive difference.
> >
>
> Understood, the new method will require multiple lines.  Everything is a
> trade-off...
>
> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The
> > following will work:
> >
> >#+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >#+PROPERTY: var euro=1.3791
> >#+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var:
> > property to support multiple arguments (comma-separated would be good
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >#+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
>
> Nice idea.  This same issue with "var" arose when we first started
> allowing header arguments to be specified inside subtree properties.
> I've just implemented your suggestion so the following are now possible.
>
> #+PROPERTY: var foo=1, bar=2
> #+PROPERTY: cache yes
>
> #+begin_src emacs-lisp
>  (+ foo bar)
> #+end_src
>
> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> : 3
>
>
Will

#+PROPERTY: var foo=1
#+PROPERTY: var bar=2

also work, or result in one variable not signed?

Rainer



> and
>
> #+begin_src emacs-lisp :var foo="this", bar="that"
>  (concat foo " " bar)
> #+end_src
>
> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> : this that
>
> Thanks for the suggestion and I hope the above is a sufficient
> replacement for the now-missing #+BABEL: syntax.
>
> Cheers -- Eric
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Rainer M Krug]

On Fri, Oct 21, 2011 at 8:35 PM, Rainer M Krug  wrote:

>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte wrote:
>
>> Christian Moe  writes:
>>
>> > Hi again,
>> >
>> > I can quickly think of two advantages of the late lamented (if only by
>> > me) #+BABEL header over using properties.
>> >
>> > 1. Allowing you to specify multiple buffer-wide options on the same
>> > line (keeping things short), in the same colon :syntax as used in a
>> > src block header (keeping things consistent and easy to copy back and
>> > forth). None of this makes a substantive difference.
>> >
>>
>> Understood, the new method will require multiple lines.  Everything is a
>> trade-off...
>>
>> >
>> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
>> > could make a substantive difference in some applications. The
>> > following will work:
>> >
>> >#+BABEL: :var euro=1.3791 :var salestax=.15
>> >
>> > The following will not, since it tries to set the same property:
>> >
>> >#+PROPERTY: var euro=1.3791
>> >#+PROPERTY: var salestax=.15
>> >
>> > If BABEL is dropped for PROPERTY, it would be good for the :var:
>> > property to support multiple arguments (comma-separated would be good
>> > for consistency with passing arguments through the SRCNAME). E.g.:
>> >
>> >#+PROPERTY: var euro=1.3791, salestax=.15
>> >
>> > I think I'd like this better in any case.
>> >
>>
>> Nice idea.  This same issue with "var" arose when we first started
>> allowing header arguments to be specified inside subtree properties.
>> I've just implemented your suggestion so the following are now possible.
>>
>> #+PROPERTY: var foo=1, bar=2
>> #+PROPERTY: cache yes
>>
>> #+begin_src emacs-lisp
>>  (+ foo bar)
>> #+end_src
>>
>> #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
>> : 3
>>
>>
> Will
>
> #+PROPERTY: var foo=1
> #+PROPERTY: var bar=2
>
> also work, or result in one variable not signed?
>
> Rainer
>

Just to add to it: at the moment I have e.g:

#+BABEL: :var MAINVERSION=0
#+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
#+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name)
org-current-export-file)))
#+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name)
org-current-export-file)) 'up-to-date) 0 13)
#+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"

which would look horrible in one line and a nightmare to edit.

Any suggestions how this cold be changed?

In addition: I would like to have a warning if #+BABEL is present in the org
file, so that one remembers that it has to be changed.

Cheers,

Rainer


>
>
>> and
>>
>> #+begin_src emacs-lisp :var foo="this", bar="that"
>>  (concat foo " " bar)
>> #+end_src
>>
>> #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
>> : this that
>>
>> Thanks for the suggestion and I hope the above is a sufficient
>> replacement for the now-missing #+BABEL: syntax.
>>
>> Cheers -- Eric
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/
>>
>>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax (F):   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

Re: [O] Org-mode Standardized Code Block Keywords

[Jambunathan K]

chris.m.mal...@gmail.com writes:

> I've invited you to be an owner of the Google Moderator series
> "Org-mode Standardized Code Block Keywords". You can view and edit
> this series at http://www.google.com/moderator/#16/e=ffe1e

I generally feel sad whenever some posts a blob via imgur or
pastebin. It takes content offline.

I know gnu.org mailing list will be there for me. Can you assure me
whether that link will continue to work say 5 or 10 years from now when
someone wants to do a post-mortem on why certain decisions were made.

I would be happy if everyone sticks to the gnu mailing list.
-- 

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[Bastien]

Hi Eric and David,

Eric Schulte  writes:

> I suppose the next step here would be to talk to Bastien about setting
> up such a system on the org-mode server.

For the record, I'm all for a server-side setup that will test
latest Org on a regular basis.

Jason, depending on our server resources, would that be feasible
to run regular (cron'ed) tests?  What is the best frequency?

Thanks,

-- 
 Bastien

Re: [O] Org-mode Standardized Code Block Keywords

[Chris Malone]

Hi Jambunathan,

That is a good point, but I wanted to make the option available.  Ignore the 
Google moderator link if you'd rather the discussion stay on the mailing list.

I planned on sending the "results" to the mailing list, perhaps tomorrow, 
anyhow.

Chris

On Oct 21, 2011, at 11:43 AM, Jambunathan K wrote:

> chris.m.mal...@gmail.com writes:
> 
>> I've invited you to be an owner of the Google Moderator series
>> "Org-mode Standardized Code Block Keywords". You can view and edit
>> this series at http://www.google.com/moderator/#16/e=ffe1e
> 
> I generally feel sad whenever some posts a blob via imgur or
> pastebin. It takes content offline.
> 
> I know gnu.org mailing list will be there for me. Can you assure me
> whether that link will continue to work say 5 or 10 years from now when
> someone wants to do a post-mortem on why certain decisions were made.
> 
> I would be happy if everyone sticks to the gnu mailing list.
> -- 

[O] [babel] Globally assigning a value to a variable

[Sebastien Vauban]

#+PROPERTY:  var myvar="original"

* Overview

I would like to test a global variable assignment (just done here above) and
local ones (on the code block itself). It seems that the global value is not
"known". Though, maybe, I don't understand it fully yet.

* Test code

** Using the local var

  #+srcname: test-local
  #+begin_src sh :var myvar="canada-dry"
  echo $myvar
  #+end_src

  #+results: test-local
  : canada-dry

** Using the global var

I'm not passing anymore a local value, hence expecting the "global" value to
be used:

  #+srcname: test-global
  #+begin_src sh :var anothervar="canada-dry"
  echo $myvar
  #+end_src

  #+results: test-global
  (no output)

Am I understanding correctly how it works / should work?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] FYI: Org mode testing framework, Emacs 23 and 22

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> Hi Eric and David,
> Eric Schulte  writes:
>
>> I suppose the next step here would be to talk to Bastien about setting
>> up such a system on the org-mode server.
>
> For the record, I'm all for a server-side setup that will test
> latest Org on a regular basis.
>
> Jason, depending on our server resources, would that be feasible
> to run regular (cron'ed) tests?  What is the best frequency?

Wouldn't the best frequency be: at every commit?

That's not for the minute (maybe even less) it takes to run the 102 tests, I
guess...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Current patches to make org-mode run on XEmacs

[Sebastien Vauban]

Hi Bastien and Michael,

Bastien wrote:
> thanks for these patches.  Next time, could you provide one patch per
> mail?  The patchwork server cannot handle multiple patches and it makes
> it easier to discuss every patch -- thanks!

Just updated Org, and tried to launch my XEmacs 21.5  (beta29) "garbanzo"
[Lucid] (i586-pc-win32, Mule) of Wed Jun 17 2009 on GANDALF-XP.

Loaded org.el and org-install.el, and then tried to open an *.org file,
resulting in this:

--8<---cut here---start->8---
Backtrace follows:

  # bind (inhibit-quit window old-frame target-frame explicit-frame shrink-it)
  byte-code("..." [explicit-frame tem car target-frame buffer window nil 
last-nonminibuf-frame selected-frame get-buffer bufferp wrong-type-argument 
throw done buffer-dedicated-frame frame-live-p window-buffer selected-window 
display-buffer-1 buffer-name assoc switch-to-buffer string-match 0 
get-buffer-window frame-selected-window set-window-buffer frame-property 
minibuffer only window-dedicated-p frame-root-window unsplittable 
get-largest-window visible t window-frame window-height window-width 
window-leftmost-p window-rightmost-p split-window get-lru-window window-parent 
window-previous-child window-next-child window-pixel-edges window-pixel-height 
enlarge-window 2 ((byte-code "Á!«?Â!?Á?" [ssw70245 window-live-p 
select-window] 2)) select-window record-buffer 
shrink-window-if-larger-than-buffer override-frame other not-this-window-p 
special-display-function upper old-frame shrink-it shrink-to-fit dedi 
split-height-threshold window-min-height split-width-threshold 
pre-display-buffer-function display-buffer-function same-window-buffer-names 
pop-up-frames special-display-buffer-names pop-up-frame-function 
window-min-width same-window-regexps special-display-regexps pop-up-windows 
ssw70245] 8)
  # (catch done ...)
  # bind (shrink-to-fit override-frame not-this-window-p buffer)
  display-buffer(# nil nil nil)
  # bind (pre-display-buffer-function buffer)
  show-temp-buffer-in-current-frame(#)
  # bind (buffer)
  display-warning-buffer()
  # (unwind-protect ...)
  # (catch # ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # (unwind-protect ...)
  # bind (inhibit-quit)
  (next-event "[internal]")
  # (condition-case ... . error)
  # (catch top-level ...)

Warning: error: (wrong-type-argument (number-char-or-marker-p nil))
--8<---cut here---end--->8---

It's not clear that something is exploitable in the above bakctrace. My
problem is that XEmacs simply becomes unusable when such a problem occurs.
Dunno why.

Though, FYI, I've never been able to run Org on XEmacs (because of such
problems).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] [RFC] Standardized code block keywords

[Thomas S. Dye]

Eric Schulte  writes:

>>> I'm confused by [3] so I will say nothing for now, except to ask some
>>> questions: are we talking about what a human would use to label a piece
>>> of data for consumption by a block (including perhaps the future
>>> possibilities of lists and paragraphs that Tom brought up)? what babel
>>> would use to label a results block (possibly so that it could be
>>> consumed by another block in a chain)? both? would that mean
>>> that #+tblname would go the way of the dodo and that tables would be
>>> labelled with #+data (or #+object or whatever else we come up with)?
>>
>> +1 (Confused, too)
>>
>
> well, I guess it is good that this discussion has begun if only to clear
> up this lingering uncertainty.
>
>>
>> I wasn't even aware of #+DATA. Does it do anything TBLNAME and SRCNAME
>> don't?
>>
>
> from the prospective of code blocks it is exactly synonymous with
> tblname.  Srcname is different in that it labels code blocks.
>
>>
>> A reason to keep TBLNAME is that it's also used by the spreadsheet
>> remote references. If Babel looked for DATA instead, a table that is
>> both a remote reference for another spreadsheet and a data source for
>> a src block would need both TBLNAME and DATA, which seems redundant.
>>
>
> agreed, I'm thinking that tblname will at least remain an option no
> matter what decision is made.
>
>>
>> As for labeling lists and paragraphs, I recall from the list that
>> Nicolas Goaziou is working on a generalized way to set captions,
>> labels and attributes for various kinds of Org block, as is possible
>> now for tables and images. I thought that sounded promising. I don't
>> know if he planned for block names, too (currently we have tblname but
>> no imgname), but that could make sense. In which case it might be a
>> good idea to coordinate.
>>
>
> Agreed, I was not aware of this work.  Thanks for sharing.  In this vein
> I would like to voice my desire to be able to add captions to code
> blocks, the lack of this feature has bitten me in the past.

Hi Eric,

For LaTeX export, the listings package has support for code block
captions.

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

Re: [O] [babel] Globally assigning a value to a variable

[Nick Dokos]

Sebastien Vauban  wrote:

> #+PROPERTY:  var myvar="original"
> 
> * Overview
> 
> I would like to test a global variable assignment (just done here above) and
> local ones (on the code block itself). It seems that the global value is not
> "known". Though, maybe, I don't understand it fully yet.
> 
> * Test code
> 
> ** Using the local var
> 
>   #+srcname: test-local
>   #+begin_src sh :var myvar="canada-dry"
>   echo $myvar
>   #+end_src
> 
>   #+results: test-local
>   : canada-dry
> 
> ** Using the global var
> 
> I'm not passing anymore a local value, hence expecting the "global" value to
> be used:
> 
>   #+srcname: test-global
>   #+begin_src sh :var anothervar="canada-dry"
>   echo $myvar
>   #+end_src
> 
>   #+results: test-global
>   (no output)
> 
> Am I understanding correctly how it works / should work?
> 

I think so and it works for me. Does C-c C-c on the #+PROPERTY: line and
reevaluating the block help?

Nick

Re: [O] [RFC] Standardized code block keywords

[Viktor Rosenfeld]

Hi Eric,

my preferences are:

- source for code blocks. I think srcname looks ugly (although not as
  ugly as tblname).
- call
- data and results for, well, data and results. With the same semantics
  as Torsten Wagner suggested, i.e. a source block cannot change the
  contents of a data block. It should create a new result block. Data
  should take precedence over result, i.e. only use result blocks for
  input if there is no data block with the name.

Personally, I don't care for tblname and would happilly replace it with
data.

Cheers,
Viktor

Re: [O] [babel] Globally assigning a value to a variable

[Sebastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Sebastien Vauban  wrote:
>> #+PROPERTY:  var myvar="original"
>> 
>> * Overview
>> 
>> I would like to test a global variable assignment (just done here above) and
>> local ones (on the code block itself). It seems that the global value is not
>> "known". Though, maybe, I don't understand it fully yet.
>> 
>> * Test code
>> 
>> ** Using the local var
>> 
>>   #+srcname: test-local
>>   #+begin_src sh :var myvar="canada-dry"
>>   echo $myvar
>>   #+end_src
>> 
>>   #+results: test-local
>>   : canada-dry
>> 
>> ** Using the global var
>> 
>> I'm not passing anymore a local value, hence expecting the "global" value to
>> be used:
>> 
>>   #+srcname: test-global
>>   #+begin_src sh :var anothervar="canada-dry"
>>   echo $myvar
>>   #+end_src
>> 
>>   #+results: test-global
>>   (no output)
>> 
>> Am I understanding correctly how it works / should work?
>
> I think so and it works for me.

Thanks for testing.

> Does C-c C-c on the #+PROPERTY: line and reevaluating the block help?

Of course, I just missed that. Thanks, and sorry for the noise...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [O] Org-mode Standardized Code Block Keywords

[Darlan Cavalcante Moreira]

With many people making suggestions and voting It can be a lot of work for
someone to collect all of the votes. In fact, I was going to suggest using
Doodle for this (http://www.doodle.com/), but Chris was faster with the
google moderator. Anyway, if the final result is sent to the list,
including who voted in what, then we would not depend on the external link
to know why the decision was made.

--
Darlan

At Fri, 21 Oct 2011 11:47:42 -0700,
Chris Malone  wrote:
> 
> Hi Jambunathan,
> 
> That is a good point, but I wanted to make the option available.  Ignore the 
> Google moderator link if you'd rather the discussion stay on the mailing list.
> 
> I planned on sending the "results" to the mailing list, perhaps tomorrow, 
> anyhow.
> 
> Chris
> 
> On Oct 21, 2011, at 11:43 AM, Jambunathan K wrote:
> 
> > chris.m.mal...@gmail.com writes:
> > 
> >> I've invited you to be an owner of the Google Moderator series
> >> "Org-mode Standardized Code Block Keywords". You can view and edit
> >> this series at http://www.google.com/moderator/#16/e=ffe1e
> > 
> > I generally feel sad whenever some posts a blob via imgur or
> > pastebin. It takes content offline.
> > 
> > I know gnu.org mailing list will be there for me. Can you assure me
> > whether that link will continue to work say 5 or 10 years from now when
> > someone wants to do a post-mortem on why certain decisions were made.
> > 
> > I would be happy if everyone sticks to the gnu mailing list.
> > -- 
> 
> 

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

Hi,

Yes, that works nicely, and should solve Rainer's problem.
I haven't been able to think of anything else that can't be handled by 
properties.


And I do think it's a good idea to winnow down the syntax a bit, even 
if things break. I just like to grumble.

:-)

Yours,
Christian

On 10/21/11 7:37 PM, Eric Schulte wrote:

Nice idea.  This same issue with "var" arose when we first started
allowing header arguments to be specified inside subtree properties.
I've just implemented your suggestion so the following are now possible.

#+PROPERTY: var foo=1, bar=2
#+PROPERTY: cache yes

#+begin_src emacs-lisp
   (+ foo bar)
#+end_src

#+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
: 3

and

#+begin_src emacs-lisp :var foo="this", bar="that"
   (concat foo " " bar)
#+end_src

#+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
: this that

Thanks for the suggestion and I hope the above is a sufficient
replacement for the now-missing #+BABEL: syntax.

Cheers -- Eric

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Darlan Cavalcante Moreira]

It's excellent that now babel understands multiple values in the "var"
property (I was one of the people that wanted this), but "There Is One More
Thing".

Would it be feasible to inherit variables from parent sub-trees?
Effectively, I'd like to append new values in lower level sub-trees, but
AFAIK setting the var property in a sub-tree will still replace the value
set in the parent sub-tree.

That is, in the example below the level-2 sub-trees would not have the foo
variable passed to babel.
--8<---cut here---start->8---
* Code with foo
  :PROPERTIES:
  :var:  foo=1
  :END:

** Code only with bar
   :PROPERTIES:
   :var:  bar=2
   :END:
   src_block
** Code only with baz
   :PROPERTIES:
   :var:  baz=3
   :END:
   src_block
--8<---cut here---end--->8---

Maybe a special keyword, such as "inherit" (or "append") could be used to
incorporate variables defined in the parent sub-tree, such that the example
would become
--8<---cut here---start->8---
* Code with foo
  :PROPERTIES:
  :var:  foo=1
  :END:

** Code with foo and bar
   :PROPERTIES:
   :var:  bar=2, inherit
   :END:
   src_block
** Code with foo and baz
   :PROPERTIES:
   :var:  baz=3, inherit
   :END:
   src_block
--8<---cut here---end--->8---

This should not affect global variables and "inherit" would inherit
variables defined only in the parent sub-tree (unless it also contains the
inherit keyword).

As a use case scenario, suppose I need to perform simulations for a few
different scenarios, each with small variations. This would allow me to
define common variables for a scenario in a higher level sub-tree and more
specific variables in the lower level sub-trees.

--
Darlan Cavalcante


At Fri, 21 Oct 2011 22:24:25 +0200,
Christian Moe  wrote:
> 
> Hi,
> 
> Yes, that works nicely, and should solve Rainer's problem.
> I haven't been able to think of anything else that can't be handled by 
> properties.
> 
> And I do think it's a good idea to winnow down the syntax a bit, even 
> if things break. I just like to grumble.
> :-)
> 
> Yours,
> Christian
> 
> On 10/21/11 7:37 PM, Eric Schulte wrote:
> > Nice idea.  This same issue with "var" arose when we first started
> > allowing header arguments to be specified inside subtree properties.
> > I've just implemented your suggestion so the following are now possible.
> >
> > #+PROPERTY: var foo=1, bar=2
> > #+PROPERTY: cache yes
> >
> > #+begin_src emacs-lisp
> >(+ foo bar)
> > #+end_src
> >
> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> > : 3
> >
> > and
> >
> > #+begin_src emacs-lisp :var foo="this", bar="that"
> >(concat foo " " bar)
> > #+end_src
> >
> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> > : this that
> >
> > Thanks for the suggestion and I hope the above is a sufficient
> > replacement for the now-missing #+BABEL: syntax.
> >
> > Cheers -- Eric
> 
> 

[O] BUG: Export images to LaTeX

[Anthony Lander]

Hi List,

I've run into a strange problem with the latest org pull. Exporting inlined 
images with the LaTeX exporter works or not depending on whether I include 
org-jsinfo in org-modules(!). This is with emacs -q on the 24.0.90.1 emacs 
recent release.

Can someone please try to reproduce this to confirm?

Thanks,

-Anthony


My test file is:

* Test
  [[file:test.png]]

Output with org-jsinfo module loaded is as expected:

\begin{document}

\maketitle


\section*{Test}
\label{sec-1}

 \includegraphics[width=.9\linewidth]{test.png}

\end{document}

But without org-jsinfo, I get a (broken) hyperlink instead:


\begin{document}

\maketitle


\section*{Test}
\label{sec-1}

 \href{t}{file:test.png}

\end{document}

Re: [O] Current patches to make org-mode run on XEmacs

[Carsten Dominik]

Hi Michael,

I have checked these in, with the following exceptions:

- Somewhere you have a call to `org-ref', I guess this must be `org-re'
- The special hunk you are mentioning is not longer in org.el,
  I guess it was removed somehow in some other commit...

Hope this makes XEmacs run smoothly with Org.

- Carsten

On 31.8.2011, at 20:12, Michael Sperber wrote:

> 
> ... are attached.  I've run with this for a few weeks now, and what I
> use mostly works.  So I would appreciate if these could go into the git
> repo.
> 
> Let me draw your attention to this hunk:
> 
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -7360,7 +7360,7 @@ would end up with no indentation after the change, 
> nothing at all is done."
>  col)
>   (while (re-search-forward
> (concat "\\(" (regexp-opt org-all-time-keywords)
> -   "\\|" "^[ \t]*" org-tsr-regexp-both "*$"
> +   "\\|" "^[ \t]*" org-tsr-regexp-both "$"
> "\\|" "^[ \t]*:[a-zA-Z][a-zA-Z0-9_]*:.*$"
> "\\)") (or drawer-end end) t)
>   (beginning-of-line)
> 
> While I needed this to make the code run on XEmacs, it really looks like
> a bug fix to me: The "*" that I deleted makes that part of the
> disjunction match the empty string, and that makes
> `org-fixup-indentation' loop infinitely.
> 
> -- 
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla
> diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
> index 45d9441..b246636 100644
> --- a/lisp/ob-calc.el
> +++ b/lisp/ob-calc.el
> @@ -28,8 +28,9 @@
> ;;; Code:
> (require 'ob)
> (require 'calc)
> -(require 'calc-store)
> -(unless (featurep 'xemacs) (require 'calc-trail))
> +(unless (featurep 'xemacs) 
> +  (require 'calc-trail)
> +  (require 'calc-store))
> (eval-when-compile (require 'ob-comint))
> 
> (defvar org-babel-default-header-args:calc nil
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index b1fa5f5..7e4da31 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -4306,8 +4306,8 @@ of what a project is and how to check if it stuck, 
> customize the variable
> "\\)\\>"))
>(tags (nth 2 org-stuck-projects))
>(tags-re (if (member "*" tags)
> -   (org-re (concat org-outline-regexp-bol
> -   ".*:[[:alnum:]_@#%]+:[ \t]*$"))
> +   (concat org-outline-regexp-bol
> +   (org-ref ".*:[[:alnum:]_@#%]+:[ \t]*$"))
>   (if tags
>   (concat org-outline-regexp-bol
>   ".*:\\("
> diff --git a/lisp/org-compat.el b/lisp/org-compat.el
> index 3e9c202..d093700 100644
> --- a/lisp/org-compat.el
> +++ b/lisp/org-compat.el
> @@ -251,8 +251,11 @@ Works on both Emacs and XEmacs."
>   (defun org-activate-mark ()
> (when (mark t)
>   (setq mark-active t)
> -  (unless transient-mark-mode
> - (setq transient-mark-mode 'lambda)
> +  (when (and (boundp 'transient-mark-mode)
> +  (not transient-mark-mode))
> + (setq transient-mark-mode 'lambda))
> +  (when (boundp 'zmacs-regions)
> + (setq zmacs-regions t)
> 
> ;; Invisibility compatibility
> 
> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index f795fbd..43752ca 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -1028,7 +1028,8 @@ Pressing `1' will switch between these two options."
> (setq r1 (read-char-exclusive)))
> (error "No enclosing node with LaTeX_CLASS or EXPORT_TITLE or 
> EXPORT_FILE_NAME")
> )
> -(redisplay)
> +(if (fboundp 'redisplay)
> + (redisplay))
> (and bpos (goto-char bpos))
> (setq r2 (if (< r1 27) (+ r1 96) r1))
> (unless (setq ass (assq r2 cmds))
> diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el
> index 04389ef..a3bd9bf 100644
> --- a/lisp/org-footnote.el
> +++ b/lisp/org-footnote.el
> @@ -70,13 +70,13 @@
>   ;; their definition.
>   ;;
>   ;; `org-re' is used for regexp compatibility with XEmacs.
> -  (org-re (concat "\\[\\(?:"
> -   ;; Match inline footnotes.
> -   "fn:\\([-_[:word:]]+\\)?:\\|"
> -   ;; Match other footnotes.
> -   "\\(?:\\([0-9]+\\)\\]\\)\\|"
> -   "\\(fn:[-_[:word:]]+\\)"
> -   "\\)"))
> +  (concat (org-re "\\[\\(?:")
> +   ;; Match inline footnotes.
> +   (org-re "fn:\\([-_[:word:]]+\\)?:\\|")
> +   ;; Match other footnotes.
> +   (org-re "\\(?:\\([0-9]+\\)\\]\\)\\|")
> +   (org-re "\\(fn:[-_[:word:]]+\\)")
> +   (org-re "\\)"))
>   "Regular expression for matching footnotes.")
> 
> (defconst org-footnote-definition-re
> @@ -265,10 +265,9 @@ label, start, end and definition of the footnote 
> otherwise."
> (re-search-backward
>  message-signature-separator nil t)
>   (or (and (re-search-forward
> -  

Re: [O] Recurring events with exceptions

[Skip Collins]

On Wed, Oct 19, 2011 at 6:02 AM, Eric S Fraga  wrote:
> Yes, I have been informed that we are moving to Outlook/exchange in the
> new year, something I am dreading...  Matthieu Lemerre, on this list
> back in late June (Message-ID: <871uygg1fs@free.fr>), posted a
> (partial?) solution that helped in this regard.  I've not tried that
> solution as I don't have to use Outlook yet.  Search the mailing list.

Lemerre's approach only syncs with the Outlook client, not the
Exchange server. He suggests using RFC-2446 (iCalendar) as a basis for
a more general solution. I think that trying to establish a smoothly
syncing connection between org and exchange by using iCalendar is a
recipe for frustration. This is mostly because Exchange's
implementation of the standard is lacking.

It might be more fruitful to pursue an org interface to Exchange Web
Services, which is favored and privileged by microsoft. A hypothetical
org-ews.el would pass xml messages that look something like:


http://www.w3.org/2001/XMLSchema-instance";
   
xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages";
   
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types";
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
   
  
   
   
  
 

   Dentist Appointment
   The appointment is with Dr.
Smith.
   2009-03-02T17:00:00Z
   2009-03-02T19:00:00Z

 
  
   


Perhaps we could entice Jambunathan to take this on ;-)
His experience getting org to speak xml as a way to interact with
other systems would be invaluable.

Re: [O] Private flag or property

[Karl Voit]

Hi Eric!

* Eric S Fraga  wrote:
> Karl Voit  writes:
>
>> Is there a *common* way of expressing a private flag/property yet?
>
> Not that I know of.

OK.

>> Or is there no pseudo-standard and I should stick to my «:PRIVATE:
>> True» property I am thinking of? (Is there a necessity for the
>> «True» string in my example (property without value)?
>
> The question is what or how you want to use this flag?  For truly
> private entries, I use encryption, with the :crypt: tag.

I know about the :crypt: tag. Very cool stuff, btw.

For now I am not planning to use the private flag at all. I just
maintained *lots* of data with this private flag information and I
do not want to delete it when converting old PalmOS/jPilot datebook
data to Org-mode files.

-- 
Karl Voit

[O] Source blocks for tiny snippets

[suvayu ali]

Hi everyone,

I was wondering what people do when they need to put a few (1 or 2)
lines of code snippets in org files? I like the syntax highlighting one
gets in an org buffer and in HTML export with code blocks. Is there some
work around other than have code blocks for every line I want to
include?

As an example consider this paragraph:

Edit job options for number of events and other configurations
: $ $EDITOR $GAUSSOPTS/.py
The number of events in a job can be customised with the option
: LHCbApp().EvtMax = nEvts
To run the generator only, set the property below.
: Gauss().Phases = ["Generator"]
To turn on full monitoring and dump an ntuple to a root file, include
the opts files as below. It can be customised further to suit the needs.
: importOptions('$GAUSSOPTS/.opts')

In the above example you have a mix of bash and python snippets.

Any thought?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [O] Patch for bug in adjusting time ranges in Agenda

[Niels Giesen]

Same here.

By the way, you don't necessarily have to mark the patch as a TINYCHANGE: I
have signed the papers with the FSF, but I just have problems updating
http://orgmode.org/worg/org-contribute.html.

(problem is: "error: unable to create temporary sha1 filename ./objects/3e:
Permission denied"
I mailed Matt about this a fortnight ago, but haven't heard from him yet).

On Fri, Oct 21, 2011 at 10:54 AM, Christian Egli wrote:

> Hi Carsten
>
> Carsten Dominik  writes:
>
> > I have just checked in a slightly modified patch.
>
> I think there is a problem with this checkin. The variable
> org-agenda-move-date-from-past-immediately-to-today is not defined.
> Should this be a defcustom somewhere?
>
> Debugger entered--Lisp error: (void-variable
> org-agenda-move-date-from-past-immediately-to-today)
>  org-agenda-date-later(1)
>  org-agenda-do-date-later(nil)
>  call-interactively(org-agenda-do-date-later nil nil)
>
> Thanks
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
>
>


-- 
http://pft.github.com

Re: [O] Patch for bug in adjusting time ranges in Agenda

[Carsten Dominik]

On 22.10.2011, at 08:00, Niels Giesen wrote:

> Same here.
> 
> By the way, you don't necessarily have to mark the patch as a TINYCHANGE: I 
> have signed the papers with the FSF, but I just have problems updating 
> http://orgmode.org/worg/org-contribute.html.
> 
> (problem is: "error: unable to create temporary sha1 filename ./objects/3e: 
> Permission denied"
> I mailed Matt about this a fortnight ago, but haven't heard from him yet).

Don't know what the error means, but I have added you!

- Carsten

> 
> On Fri, Oct 21, 2011 at 10:54 AM, Christian Egli  
> wrote:
> Hi Carsten
> 
> Carsten Dominik  writes:
> 
> > I have just checked in a slightly modified patch.
> 
> I think there is a problem with this checkin. The variable
> org-agenda-move-date-from-past-immediately-to-today is not defined.
> Should this be a defcustom somewhere?
> 
> Debugger entered--Lisp error: (void-variable 
> org-agenda-move-date-from-past-immediately-to-today)
>  org-agenda-date-later(1)
>  org-agenda-do-date-later(nil)
>  call-interactively(org-agenda-do-date-later nil nil)
> 
> Thanks
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
> 
> 
> 
> 
> 
> -- 
> http://pft.github.com

Re: [O] Patch for bug in adjusting time ranges in Agenda

[Carsten Dominik]

On 21.10.2011, at 10:54, Christian Egli wrote:

> Hi Carsten
> 
> Carsten Dominik  writes:
> 
>> I have just checked in a slightly modified patch.
> 
> I think there is a problem with this checkin. The variable
> org-agenda-move-date-from-past-immediately-to-today is not defined.
> Should this be a defcustom somewhere?

Yes, I forgot to put that in.  Done now.

- Carsten

> 
> Debugger entered--Lisp error: (void-variable 
> org-agenda-move-date-from-past-immediately-to-today)
>  org-agenda-date-later(1)
>  org-agenda-do-date-later(nil)
>  call-interactively(org-agenda-do-date-later nil nil)
> 
> Thanks
> -- 
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
> 
> 

Re: [O] direct link to mails in gmail

[Niels Giesen]

>
> Since any mail can be found under the All label by definition the
> simplest solution is extracting the message id from the end of
> the current url and then creating a new url pointing to All.
> This URL should always work unless the mail is deleted:
>
> https://mail.google.com/mail/?shva=1#all/
>
>
> So this would work too:

#+LINK: gmail https://mail.google.com/mail/?shva=1#all/

[[gmail:1331f3490dff1205][conversation about gmail links]]

Too bad I have set up Emacs to use emacs-w3m, in which this does not work --
probably the hash part is handled by client-side JavaScript.


-- 
http://pft.github.com