[O] Org from ELPA question

[Stelian Iancu]

Hi all,

Org and Emacs newbie here.

Using GNU Emacs 24.0.91.1 (x86_64-apple-darwin, NS
apple-appkit-1038.36) of 2011-11-20 on bob.porkrind.org and Org from
ELPA updated yesterday.

I am encountering the problem with org-capture described here:
http://article.gmane.org/gmane.emacs.orgmode/48584

After upgrading org yesterday, I can see that org-compat.el defines
indeed the function org-pop-to-buffer-same-window.

M-x locate-library tells me the following for org-compat:

Library is file ~/.emacs.d/elpa/org-2023/org-compat.elc

So it seems that the correct one is seen. However, after require-ing
org-compat, the function from above is still not known. Any ideas why?

Thanks!

S.

Re: [O] BUG org-bibtex error for importing bibtex conference entries

[Nick Dokos]

Torsten Wagner  wrote:

> Hi,
> I was going to convert my bibtex file into an org-mode file.
> I receive an error message for conference entries.
> E.g.
> I can read in by org-bibtex-read
> 
> @CONFERENCE{foo11,
>   author = {foo, A. and faa, B},
>   title = {This is the title},
>   booktitle = {Proceeding of the 5th Org-mode conference},
>   year = {2011},
>   month = Jul,
>   day = {4--5},
>   conference_name = {org-mode V},
>   keywords = {published},
>   location = {Somewhere, org-land},
>   presentation = {Oral}
> }
> 

I think the problem is in the reading: after org-bibtex-read,
*org-bibtex-entries* is still nil. I presume that's why
org-bibtex-write fails.

> However, org-bibtex-write results in the following output
> 
> *
> and a debug error-log [1]:
> 
> By changing the bibtex type to e.g., INPROCEEDINGS  the import works correct.
> I tried to debug this but I can't see why it works for inproceedings
> and not for conference.
> 

... and after org-bibtex-read in this case, *org-bibtex-entries* is not
nil.

org-bibtex-read calls bibtex-parse-entry and that one returns nil
on the conference entry above: are you sure it's a legal bibtex type?
Or maybe bibtex-parse-entry just does not know about it and needs
fixing.

Nick

> As a side note, I noticed that the importer is rather quite about
> errors. If I try to import an mal-formated BibTeX entry I often
> receive an result for which some keyword-entries are simply missing.
> E.g. try
> 
> @INPROCEEDINGS{foo11,
>   author = {foo, A. and faa, B},
>   title = {This is the title},
>   booktitle = {Proceeding of the 5th Org-mode conference},
>   year = {2011},
>   month = Jul,
>   day = (4--5),
>   conference_name = {org-mode V},
>   keywords = {published},
>   location = {Somewhere, org-land},
>   presentation = {Oral}
> }
> note the round instead of curl brackets around day. An import will
> skip silently everything behind the month line.
> Wouldn't it make more sens to issue a warning whenever the parser has
> trouble to read something? I noticed that the beamer.el from
> beamer-mode is involved in parsing. Thus, I have no idea whether
> org-mode is capable to notice such a problem. You might argue that
> BibTeX is specifies the correct syntax very well, but many other tools
> export and import to BibTeX too and an error in these programs might
> still allow them to import nd export entries with wrong syntax, a
> import in org-mode however, could result finally in fatal data loose.
> Thus, I vote for an error or warning message whenever there is
> something which requires human attentions.
> As for now, I have to carefully check, that all entries moved into the
> org-mode file, which is a bit tiring and error prone.
> 
> All the best
> 
> Torsten
> 
> 
> 
> [1] Debug log:
> 
> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil)
>   insert(nil)
>   (progn (fset (quote togtag) (function* (lambda (tag) (block togtag
> (org-toggle-tag tag (quote on)) (org-insert-heading) (insert (val
> :title)) (org-bibtex-put "TITLE" (val :title)) (org-bibtex-put
> org-bibtex-type-property-name (downcase (val :type))) (dolist (pair
> entry) (case (car pair) (:title nil) (:type nil) (:key (org-bibtex-put
> org-bibtex-key-property (cdr pair))) (:keywords (if
> org-bibtex-tags-are-keywords (mapc (lambda (kw) (togtag ...))
> (split-string (cdr pair) ", *")) (org-bibtex-put (car pair) (cdr
> pair (otherwise (org-bibtex-put (car pair) (cdr pair) (mapc
> (function togtag) org-bibtex-tags))
>   (unwind-protect (progn (fset (quote togtag) (function* (lambda (tag)
> (block togtag (org-toggle-tag tag (quote on)) (org-insert-heading)
> (insert (val :title)) (org-bibtex-put "TITLE" (val :title))
> (org-bibtex-put org-bibtex-type-property-name (downcase (val :type)))
> (dolist (pair entry) (case (car pair) (:title nil) (:type nil) (:key
> (org-bibtex-put org-bibtex-key-property (cdr pair))) (:keywords (if
> org-bibtex-tags-are-keywords (mapc (lambda ... ...) (split-string ...
> ", *")) (org-bibtex-put (car pair) (cdr pair (otherwise
> (org-bibtex-put (car pair) (cdr pair) (mapc (function togtag)
> org-bibtex-tags)) (if --cl-letf-bound-- (fset (quote togtag)
> --cl-letf-save--) (fmakunbound (quote togtag
>   (let* ((--cl-letf-bound-- (fboundp (quote togtag)))
> (--cl-letf-save-- (and --cl-letf-bound-- (symbol-function (quote
> togtag) (unwind-protect (progn (fset (quote togtag) (function*
> (lambda (tag) (block togtag (org-toggle-tag tag ...)
> (org-insert-heading) (insert (val :title)) (org-bibtex-put "TITLE"
> (val :title)) (org-bibtex-put org-bibtex-type-property-name (downcase
> (val :type))) (dolist (pair entry) (case (car pair) (:title nil)
> (:type nil) (:key (org-bibtex-put org-bibtex-key-property (cdr pair)))
> (:keywords (if org-bibtex-tags-are-keywords (mapc ... ...)
> (org-bibtex-put ... ...))) (otherwise (org-bibtex-put (car pair) (cdr
> pair) (mapc (function togtag) org-bibtex-tags)) (if
> --cl-letf-bound-- (fse

Re: [O] Org from ELPA question

[Nick Dokos]

Stelian Iancu  wrote:

> Hi all,
> 
> Org and Emacs newbie here.
> 
> Using GNU Emacs 24.0.91.1 (x86_64-apple-darwin, NS
> apple-appkit-1038.36) of 2011-11-20 on bob.porkrind.org and Org from
> ELPA updated yesterday.
> 
> I am encountering the problem with org-capture described here:
> http://article.gmane.org/gmane.emacs.orgmode/48584
> 
> After upgrading org yesterday, I can see that org-compat.el defines
> indeed the function org-pop-to-buffer-same-window.
> 
> M-x locate-library tells me the following for org-compat:
> 
> Library is file ~/.emacs.d/elpa/org-2023/org-compat.elc
> 
> So it seems that the correct one is seen. However, after require-ing
> org-compat, the function from above is still not known. Any ideas why?
> 

Probably because you did not compile the new .el files: it's picking up
the old .elc file which still exists. Check the modification times of
org-compat.el and org-compat.elc to make sure.

Somebody else will have to tell you how to fix it though (whether the
above is correct or not): I've never played with ELPA packages.

Nick

Re: [O] Org from ELPA question

[Stelian Iancu]

On Thu, Nov 24, 2011 at 09:17, Nick Dokos  wrote:
> Stelian Iancu  wrote:
>
>> Hi all,
>>
>> Org and Emacs newbie here.
>>
>> Using GNU Emacs 24.0.91.1 (x86_64-apple-darwin, NS
>> apple-appkit-1038.36) of 2011-11-20 on bob.porkrind.org and Org from
>> ELPA updated yesterday.
>>
>> I am encountering the problem with org-capture described here:
>> http://article.gmane.org/gmane.emacs.orgmode/48584
>>
>> After upgrading org yesterday, I can see that org-compat.el defines
>> indeed the function org-pop-to-buffer-same-window.
>>
>> M-x locate-library tells me the following for org-compat:
>>
>> Library is file ~/.emacs.d/elpa/org-2023/org-compat.elc
>>
>> So it seems that the correct one is seen. However, after require-ing
>> org-compat, the function from above is still not known. Any ideas why?
>>
>
> Probably because you did not compile the new .el files: it's picking up
> the old .elc file which still exists. Check the modification times of
> org-compat.el and org-compat.elc to make sure.
>
> Somebody else will have to tell you how to fix it though (whether the
> above is correct or not): I've never played with ELPA packages.
>

Thanks for the suggestion, but I don't think that's it. I checked and
the modification time of the .elc is newer.

Also, I was thinking that since load-library shows me the ELPA one, it
should be all good.

Thanks,
S.

Re: [O] BUG org-bibtex error for importing bibtex conference entries

[Torsten Wagner]

On 11/24/2011 05:09 PM, Nick Dokos wrote:

Torsten Wagner  wrote:


Hi,
I was going to convert my bibtex file into an org-mode file.
I receive an error message for conference entries.
E.g.
I can read in by org-bibtex-read

@CONFERENCE{foo11,
   author = {foo, A. and faa, B},
   title = {This is the title},
   booktitle = {Proceeding of the 5th Org-mode conference},
   year = {2011},
   month = Jul,
   day = {4--5},
   conference_name = {org-mode V},
   keywords = {published},
   location = {Somewhere, org-land},
   presentation = {Oral}
}



I think the problem is in the reading: after org-bibtex-read,
*org-bibtex-entries* is still nil. I presume that's why
org-bibtex-write fails.



Yes it seems to be a problem within the bibtex-mode of emacs. I will try 
to send this upstream.
However, I just learned that there is no difference between CONFERENCE 
and INPROCEEDINGS.

A search and replace in my BibTeX file should solve the problem for now.

Thanks for looking into it

Torsten

[O] org2info, docu workflow

[Andreas Röhler]

Hi,

having to write a docu which should be transferred into info and other 
formats, what the recommended workflow would be in this case?


Exists an exporter from org into info?

Thanks,

Andreas

--
http://launchpad.net/python-mode
http://launchpad.net/s-x-emacs-werkstatt/

[O] Support for Bird-style Literate Haskell

[Jean-Marie Gaillourdet]

Hi everybody,

I'd be interested to use org syntax in the comments of a literate haskell file. 
I know and use occasionally org-babel. Though, this question is not about 
org-babel. I am merely interested in telling org-mode to leave the code parts 
of a literate Haskell file alone, i.e. similar to code blocks in org-mode. I 
have no propblem with switching between org-mode and literate-haskell-mode 
depending on what I am currently editing. I am not interested in org-babel 
because I don't want to have a separate weaving step in my build system.

In case you don't know: Literate Haskell files (ending with .lhs) come in two 
flavors: bird style and latex style. In bird style every line is a comment 
unless it has '>' in the first column. And in latex style code blocks are 
surround with \begin{code} and \end{code}. Haskell implementations do not care 
what is in the non-code parts. So, I'd like to use org markup and especially 
the editing features of org-mode. I'd prefer to work in bird-style and 
latex-style would be fine as well.

Do you have any ideas/pointers how to achieve that?

Thanks for your help!

Cheers, 
 Jean

[O] [bug] `Org-list-end-marker' displayed in exported documents

[Sebastien Vauban]

#+TITLE: ECM for Org-list-end-marker
#+DATE:  2011-11-24
#+PROPERTY:  eval yes

* Overview

When exporting the following test case to either HTML or PDF, we get
=ORG-LIST-END-MARKER= displayed instead of the list of code blocks.

Maybe this is still not the correct way to publish a list of code blocks, but
what we get seems as well wrong to me.

* Test case

** How many blocks?

There are:

#+begin_src emacs-lisp :exports results
(org-babel-lob-ingest (buffer-file-name))
#+end_src

#+results:
: 1

blocks.

** Which blocks?

The following code is certainly not sufficient, but would aim at providing
some index to named code blocks (linkable, if possible).

#+begin_src emacs-lisp :results list
  (mapcar #'list (reverse (org-babel-src-block-names)))
#+end_src

#+results:
- (#("defvar-now" 0 10 (fontified t org-category "mc-lob" face org-meta-line 
font-lock-fontified t)))

** Example of block

Define date variable =now=:

#+name: defvar-now
#+begin_src sql
DECLARE @now smalldatetime
-- implementation is not important in this context!
#+end_src

Best regards,
  Seb

-- 
Sebastien Vauban

[O] 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Jambunathan K]

There have been constant flow of issues from users who install daily org
tar balls from GNU ELPA.

The problem concerns itself with the defmacros that are introduced in
the *daily* tar but are *unavailable* in the *emacs* core. At the end of
the package installation these new macros never get recognized as macros
and gets compiled in as function calls. This triggers crashes at a later
stage.

Note that there are no such defmacro issues that get reported from users
who install org from git repo using conventional make and make install.

The crux of the issue is this:

1. While building via Makefile, there is an implicit dependency that is
*enforced* via make rules and files with macro definitions are compiled
ahead of their consumers.

2. While building from ELPA, the compilation order seems to be
alphabetical. So the files get compiled bass ackwards. For example,
org-macs.el gets compiled after org-agenda.el.

In summary, there needs to be a way to specify the order in which files
are compiled in a multifile tar.

A supplementary question to (2):

During the package compilation, when encountering (require
'some-org-library-with-macros) does the library get loaded from *within*
the tarball or from the *emacs core*.

I hope this description is sufficient. I can cite actual posts from
orgmode mailing list if additional information is needed.

Re: [O] Org from ELPA question

[Jambunathan K]

Filed as an umbrella bug -
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125. 

Stelian you are cced in the bug report. I hope you can provide
additional info as needed by the maintainers.

Note: All the previous users were happy with the workarounds and never
stuck around enough to reason the issue through to it's logical
completion.
-- 

Re: [O] Org from ELPA question

[Stelian Iancu]

Thanks Jambunathan, I will surely follow-up there.

I also have a workaround for now, by just defining that function in my
own config file, but I am not happy with it. So I will give as much
assistance as I can so that the issue is fixed.

Br,
Stelian

On Thu, Nov 24, 2011 at 13:23, Jambunathan K  wrote:
>
> Filed as an umbrella bug -
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125.
>
> Stelian you are cced in the bug report. I hope you can provide
> additional info as needed by the maintainers.
>
> Note: All the previous users were happy with the workarounds and never
> stuck around enough to reason the issue through to it's logical
> completion.
> --
>

Re: [O] TABLES: Remove/add cell

[Daniel Martins]

Great Michael!!!

One vote for being part of the core of org-mode!!! (with org-table
rtanspose as well)

Daniel

2011/11/23 Michael Brand :
> Hi Gustav and Daniel
>
> 2011/9/30 Gustav Wikström :
>> How do I add or remove a single cell in a table?
>> Example:
>> I have the following table:
>> |        1 |        1 |
>> |        2 |        3 |
>> |        3 |        4 |
>> |        4 |          |
>> Now I want to add an empty cell in @2$2 (below the heading) and thus move
>> the following cells in column 2 down one step.
>> After:
>> |        1 |        1 |
>> |        2 |          |
>> |        3 |        3 |
>> |        4 |        4 |
>
> 2011/9/30 Michael Brand :
>> [...] transpose [...]
>> and split it into two (or three) tables:
>>
>> | a | b | c | d |
>>
>> | 1 | 3 | 4 |   |
>>
>> (| e | f | g | h |)
>>
>> Then you can use the very convenient editing functions of Org table on
>> the second part of the table,
>
> to move the empty field in front of "3"
>
> | a | b | c | d |
>
> | 1 |  | 3 | 4 |
>
> | e | f | g | h |
>
>> join the parts together
>
> | a | b | c | d |
> | 1 |   | 3 | 4 |
> | e | f | g | h |
>
>> and transpose again.
>
> By coincidence just today I had the same need to move or rotate
> columns left/right, without affecting the other rows above and below.
> Because I need this repeatedly I wrote two in-row functions derived
> from org-table-move-column, without the need anymore of splitting and
> joining the table like above.
>
> It supports only the direction left/right. The direction up/down
> Gustav asked for would be harder to implement but as a workaround you
> can still transpose
> http://orgmode.org/worg/org-hacks.html#transpose-table
> and use the in-row left/right.
>
> from another thread:
> On Mon, Nov 21, 2011 at 14:31, Daniel Martins  wrote:
>> The feature of remove/add cell is quite important. Should be a feature
>> request.
>
> If I understand right and only for left/right, the in-row functions
> cover that too:
> - remove: first blank the field with "C-c Space"
>  (org-table-blank-field) and then rotate in-row left
> - add: rotate in-row right and replace the field content, before this
>  step append new columns if required
>
> For more see
> "Change the column sequence in one row only" on Worg hacks:
> http://orgmode.org/worg/org-hacks.html#column-sequence-in-row
>
> Michael
>

Re: [O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Eli Zaretskii]

> From: Jambunathan K 
> Date: Thu, 24 Nov 2011 17:42:38 +0530
> Cc: emacs-orgmode@gnu.org, Stelian Iancu 
> 
> 1. While building via Makefile, there is an implicit dependency that is
> *enforced* via make rules and files with macro definitions are compiled
> ahead of their consumers.

That's not true: there are no dependencies defined in lisp/Makefile.in
in the Emacs source tree for Lisp files, with a very few exceptions.
Org Mode files certainly have no dependency rules in lisp/Makefile.in.
So the question why the problem does not happen while compiling Org in
Emacs remains.

> 2. While building from ELPA, the compilation order seems to be
> alphabetical. So the files get compiled bass ackwards. For example,
> org-macs.el gets compiled after org-agenda.el.
> 
> In summary, there needs to be a way to specify the order in which files
> are compiled in a multifile tar.

This was discussed several time, in the context of recompiling
multiple Lisp files while building Emacs, and the decision till now
was to ignore the issue.  While at least in principle one could write
a Lisp program that would analyze the various `require' and `load'
calls (possibly as side effect of byte compilation, like GCC does),
and generate Makefile rules with correct prerequisites, this is a
non-trivial project.

One simple band-aid is to remove all the *.elc files before
byte-compiling after resync.  This prolongs the compilation, but the
results are predictably correct.

> A supplementary question to (2):
> 
> During the package compilation, when encountering (require
> 'some-org-library-with-macros) does the library get loaded from *within*
> the tarball or from the *emacs core*.

Whichever is found first along load-path, I think.  See `openp'.

Re: [O] Journal versus clock tables: Opposing requirements?

[Eric S Fraga]

Olaf Dietsche  writes:

> Tommy Kelly  writes:
>
>>> OK, that might be what I need then. I thought clock tables grouped
>>> things by headings, not by tags. I'll have a look at the manual.

[...]

> #+BEGIN: clocktable :maxlevel 2 :scope file :tags "health"
> Clock summary at [2011-11-08 Di 09:57]
>
> | Headline | Time   |
> |--+|
> | *Total time* | *0:20* |
> |--+|
> | Exercises| 0:20   |
> #+END: clocktable

I've lost the rest of this thread and I don't actually know who to
attribute the original statement above...

In any case, I would like to have entries in the clock report by tag as
opposed to headline (as alluded to above).  Is this actually possible?
My logging approach is to have descriptive headings (the specific task
undertaken) with tags indicating the type of activity (teaching,
research, admin, personal).  I need a breakdown of my time spent in each
category in one table. 

I realise I can do N tables, one for each tag, but this is not
particularly useful for me.  It'll do but if there's a nicer solution,
I'll take it!

The documentation refers to a :formatter entry, but I am not sure
whether this is relevant as it says that this is for formatting an
entry.  My problem is that I want tag based entries, not how they are
formatted?

Apologies if I've missed something obvious in the manual!

Thanks,
eric

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

[O] Specify the end of a heading even when there's still some content after it

[Emmanuel Di Pretoro]

Hi,

Is there a way to ask to org-mode to add something before the
\end{document} of a LaTeX export?

I've set up a specific org-export-latex-class to use the limap package (a
specific LaTeX package to produce Information Mapping-style document) and I
would like to add a \printbibliography at the end of this document. If I
use the following :
#+begin_src org
  * References
  \printbibliography
#+end_src

The LaTeX export produce the folliowing :
#+begin_src latex
  \begin{Map}{References}
  \printbibliography
  \end{Map}
#+end_src

Which is normal from the point of vue of org-mode. Unfortunately,
\printbibliography doesn't play well with the limap package. So my solution
is to end my LaTeX file by
#+begin_src latex
  \section{References}
  \printbibliography
#+end_src

When I add these lines in my org file, these are integrated into the last
heading. So, is there a way to tell org-mode that the last heading is
finished, and that these two lines must be inserted before the
\end{document}?

Thanks in advance,

Emmanuel Di Pretoro

[O] [babel] Loosing my latin...

[Sebastien Vauban]

Hello,

While this code block gets evaluated as expected...

#+begin_src emacs-lisp :var foo=11 bar=22
  (+ foo bar)
#+end_src

#+results:
: 33

It's not the same with the 2 following ones: variables `bar' and `baz' are
said to be void.

** NOK With property

#+property: var bar=44
#+begin_src emacs-lisp
  (+ bar bar)
#+end_src

** NOK With headers

#+headers: var baz=55
#+begin_src emacs-lisp
  (+ baz baz)
#+end_src

Am I missing something really obvious??[1]

Best regards,
  Seb

Footnotes:

[1] Org-mode version 7.7 (release_7.7.600.gb331.dirty), up-to-date at the time
of writing this.

-- 
Sebastien Vauban

Re: [O] Estimate ranges in column view

[Sebastien Vauban]

Hello,

"Sebastien Vauban" wrote:
> Carsten Dominik wrote:
>> On Jun 22, 2010, at 4:36 AM, Michael Gauland wrote:
>>> Here is a patch for a new 'est+' summary type, including corresponding
>>> changes for xemacs and the manual. I've done basic testing on the GNU emacs
>>> version, but not the xemacs code.
>>>
>>> [...]
>>>
>>> +@{est+@}@r{Add low-high estimates.}
>>>
>>> [...]
>>>
>>> +For example, suppose you had ten tasks, each of which was estimated at 0.5
>>> +to 2 days of work. Straight addition produces an estimate of 5 to 20 days,
>>> +representing what to expect if everything goes either extremely well or
>>> +extremely poorly. In contrast, 'est+' estimates the full job more
>>> +realistically, at 10-15 days.
>
> Though, if we take 2 tasks, with an estimation of:
>
> - exactly 1 day for task 1, and
> - between 0.5 day (min) and 0.75 day (max) for task 2,
>
> we get an estimation of 2 days for both together...
>
> #+BEGIN: columnview :hlines 1 :maxlevel 2
> | Task  |   Estim. |
> |---+--|
> | * Development |  2-2 |
> | ** Task 1 |1 |
> | ** Task 2 | 0.5-0.75 |
> #+END:
>
>>> +(defun org-estimate-print (e &optional fmt)
>>> +  "Prepare a string representation of an estimate, as two numbers with a
>>> -' in between them."
>>> +  (if (null fmt) (set 'fmt "%.0f"))
>>> +  (format "%s" (mapconcat (lambda (n) (format fmt n))  e "-")))
>
> That's because of the rounding to the closest integer, done in the above
> function.
>
> Shouldn't we allow for 1 or 2 decimals?
>
> Or is there a possible way to guess what the best rounding could be?

Another note: wouldn't it better to just write "2" when both bounds (min and
max) are equal, that is *not* displaying an estimate of "2-2"?

Best regards,
  Seb

-- 
Sebastien Vauban

[O] [PATCH] org-babel-exp-lob-one-liners should not parse the entire buffer.

[Jérémy Compostella]

All,

I'm currently generating a road book for a trip from different Org-Mode
file and other data. It results in a 13 thousands lines Org-Mode file
and I have some performance issues. Using the ELP package, I isolated
the two main bottlenecks.

1. One is in org-odt : the org-odt-write-manifest-file function is
   called once and takes 5.546672 seconds to write a 167 lines file. I
   rewrote this function and now it takes 0.01606 seconds to write the
   same file. As usually for this package, I directly send the patch to
   the org-odt author.
2. The other is in ob-exp : the org-babel-exp-lob-one-liners parse to
   the end of the buffer instead of the region given as arguments. On my
   "big" file it results in 50 seconds execution of the
   org-babel-exp-lob-one-liners function. With the patch it only takes
   0.871 seconds.

Please merge it or review it.

Regards,

Jeremy
-- 
Sent from my Emacs
>From 86bd70539203443679fd55788db2a598529135d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Compostella?= 
Date: Thu, 24 Nov 2011 16:20:00 +0100
Subject: [PATCH] org-babel-exp-lob-one-liners should not parse the entire
 buffer.

The org-babel-exp-lob-one-liners search "call" pattern through the entire
buffer instead of the region given as arguments.
---
 lisp/ob-exp.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index f2e20a0..de3a4c8 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -167,7 +167,7 @@ options are taken from `org-babel-default-header-args'."
   (save-excursion
 (goto-char start)
 (while (and (< (point) end)
-		(re-search-forward org-babel-lob-one-liner-regexp nil t))
+		(re-search-forward org-babel-lob-one-liner-regexp end t))
   (unless (org-babel-in-example-or-verbatim)
 	(let* ((lob-info (org-babel-lob-get-info))
 	   (inlinep (match-string 11))
-- 
1.7.5.4

Re: [O] [babel] Loosing my latin...

[Nick Dokos]

Sebastien Vauban  wrote:

> Hello,
> 
> While this code block gets evaluated as expected...
> 
> #+begin_src emacs-lisp :var foo=11 bar=22
>   (+ foo bar)
> #+end_src
> 
> #+results:
> : 33
> 
> It's not the same with the 2 following ones: variables `bar' and `baz' are
> said to be void.
> 
> ** NOK With property
> 
> #+property: var bar=44
> #+begin_src emacs-lisp
>   (+ bar bar)
> #+end_src
> 

This one worked after C-c C-c on the property line.

> ** NOK With headers
> 
> 
> #+begin_src emacs-lisp
>   (+ baz baz)
> #+end_src
> 

This one didn't - but it worked like this:

#+headers: :var baz=55

even with a singular "header" - doing this in a hurry, so I'm not sure
if that's an accident of history left behind, or whether it would happen
in a fresh session as well.

Nick

> Am I missing something really obvious??[1]
> 
> Best regards,
>   Seb
> 
> Footnotes:
> 
> [1] Org-mode version 7.7 (release_7.7.600.gb331.dirty), up-to-date at the time
> of writing this.
> 
> -- 
> Sebastien Vauban
> 
> 

Re: [O] odt export to google-docs problem continues

[Jambunathan K]

Rustom Mody  writes:

> On Fri, Nov 18, 2011 at 11:21 AM, Jambunathan K <
> kjambunat...@gmail.com> wrote:
>
> Suvayu/Rustom
>
> suvayu ali  writes:
>
> > Hi Jambunathan,
> >
> > On Thu, Nov 17, 2011 at 11:06, Jambunathan K <
> kjambunat...@gmail.com> wrote:
> >> Can anyone else reproduce this?
> >
> > I can replicate this. The odt file exported by org-odt is not
> accepted
> > by google docs even though libreoffice opens it without
> problems.
> > However it I open it with libreoffice and say edit and save,
> google
> > docs then accepts the new file.
>
> With my some experimentation, I am able to reproduce it now. I
> have this
> in my .emacs.
>
> ,
> | (setq org-export-odt-prettify-xml t)
>
>
> Well now google docs accepts but libreoffice itself says "file is
> corrupt shall I repair?"
> If I take the odt file directly made by exporter direcly in
> googledocs there are lots of spurious spaces eg between bullets and
> the first word.
>
> If I push it through libreoffice and resave then googledocs does a
> better job of displaying

I am not sure what the issue could be. I will have the issue in the
background for now. 

The good thing is atleast a workaround is available.

Jambunathan K.

Re: [O] Bug: org-todo-yesterday doesn't work from agenda buffer [7.7 (release_7.7.548.g9a442.dirty)]

[Dave Abrahams]

on Wed Nov 23 2011, Bernt Hansen  wrote:

> Dave Abrahams  writes:
>
>>
>> Debugger entered--Lisp error: (error "Before first headline at position 1142 
>> in buffer *Org Agenda*")
>>   signal(error ("Before first headline at position 1142 in buffer *Org 
>> Agenda*"))
>>   error("Before first headline at position %d in buffer %s" 1142 #> *Org Agenda*>)
>
> There's another function to use from the agenda:
> org-agenda-todo-yesterday

Thanks for pointing that out, silly as it is.

> PS. I posted a patch for your clocking error 3 days ago but forgot to CC
> you on it so I guess you missed it.

Yes, I did.  And then I submitted my own patch. :-P

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: [O] org2info, docu workflow

[Thomas S. Dye]

Aloha Andreas,

FWIW, I looked into this a while back and couldn't find an easy path
from org to info.  Caveat emptor, absence of evidence isn't evidence of
absence.  Others on the list probably have a better handle on this.

The most promising path seemed to be export to docbook, but I couldn't get
the docbook to info step working with what seemed at the time reasonable
effort so gave it up.  If you have other target formats, as well, then
docbook might be a possibility.

All the best,
Tom

Andreas Röhler  writes:

> Hi,
>
> having to write a docu which should be transferred into info and other
> formats, what the recommended workflow would be in this case?
>
> Exists an exporter from org into info?
>
> Thanks,
>
> Andreas
>
> --
> http://launchpad.net/python-mode
> http://launchpad.net/s-x-emacs-werkstatt/
>
>
>
>
>

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

Re: [O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Jambunathan K]

> Org Mode files certainly have no dependency rules in lisp/Makefile.in.

The Makefile - in devel repo of Orgmode - does define rules. Read on ...

> So the question why the problem does not happen while compiling Org in
> Emacs remains.

I believe the way the files are compiled makes a substantial difference.

When compiling with makefiles:

The compilation happens with *minimal* emacs and in batch mode.

--8<---cut here---start->8---
BATCH=$(EMACS) -batch -q -no-site-file -eval
  "(setq load-path (cons (expand-file-name \"./lisp/\") 
  (cons \"$(lispdir)\" load-path)))"
--8<---cut here---end--->8---

As can be seen above, any (require 'something) of macro files in the
compiled elisp file has to be loaded from the development version
itself.

Furthermore there are dependencies like this in the Makefile:

--8<---cut here---start->8---
lisp/org.elc:   lisp/org-macs.el lisp/org-compat.el lisp/org-faces.el
lisp/org-agenda.elc:lisp/org.el
--8<---cut here---end--->8---

(I believe removing the dependencies from the Makefiles will still do
the right thing because of the require directives in the compiled files
will load the development version and not the system version)

When compiling with package manager, the compilation happens from within
a running Emacs session and very likely the "old" Org files are already
loaded in to the runtime "inadvertently" by the user either by looking
at the org agenda for the day or may be by just viewing an Org file or
by the plain old (require 'org-whatever) out of habit in .emacs. 

While reporting macro issues, users never say whether they were already
running Org when they were trying to fetch and compile a new Org. They
think it is immaterial. I believe it matters

If "old" org and hence "old" org-macs is already loaded in the
environment when the package is installed, any subsequent (require
'something) will be essentially no-ops. (Can you confirm this?)

What ideally should happen is that during package compilation, a require
should *forcibly* load from the compiled package and not merely check
for availability of a feature symbol.

>> 2. While building from ELPA, the compilation order seems to be
>> alphabetical. So the files get compiled bass ackwards. For example,
>> org-macs.el gets compiled after org-agenda.el.
>> 
>> In summary, there needs to be a way to specify the order in which files
>> are compiled in a multifile tar.
>
> This was discussed several time, in the context of recompiling
> multiple Lisp files while building Emacs, and the decision till now
> was to ignore the issue.  While at least in principle one could write
> a Lisp program that would analyze the various `require' and `load'
> calls (possibly as side effect of byte compilation, like GCC does),
> and generate Makefile rules with correct prerequisites, this is a
> non-trivial project.

I have tried giving an explanation in the earlier paragraph.

> One simple band-aid is to remove all the *.elc files before
> byte-compiling after resync.  This prolongs the compilation, but the
> results are predictably correct.

We are talking of "automatic" compilation by package manager. What you
say applies to hand compilation via makefiles.

>> A supplementary question to (2):
>> 
>> During the package compilation, when encountering (require
>> 'some-org-library-with-macros) does the library get loaded from *within*
>> the tarball or from the *emacs core*.
>
> Whichever is found first along load-path, I think.  See `openp'.

What does package manager do?
-- 

Re: [O] [PATCH] org-babel-exp-lob-one-liners should not parse the entire buffer.

[Jambunathan K]

> All,
>
> I'm currently generating a road book for a trip from different Org-Mode
> file and other data. It results in a 13 thousands lines Org-Mode file
> and I have some performance issues. Using the ELP package, I isolated
> the two main bottlenecks.
>
> 1. One is in org-odt : the org-odt-write-manifest-file function is
>called once and takes 5.546672 seconds to write a 167 lines file. I
>rewrote this function and now it takes 0.01606 seconds to write the
>same file. As usually for this package, I directly send the patch to
>the org-odt author.

I think it is multiple write-region that takes the toll. I have pushed a
variation of your original fix which minimizes the number of lines
originally modified by you.

I have acknowledged you as the author in the commit message (even though
I appear as the author)

> As usually for this package, I directly send the patch to the org-odt
> author.

Btw, you can post your patches to the list. I am a regular on this list.

Jambunathan K.
-- 

[O] HTML5 Backend

[Pavel Panchekha]

I'd like to add a backend that renders org-mode to spiffy new HTML5.
 Presumably this would exist together with the existing XHTML backend
(maybe eventually replacing it, I guess).  I've looked around and can't
find anything describing the internals of Org-mode; are there any starting
points, or should I just crack open the code?  Anything particularly
non-obvious to keep in mind while writing the HTML5 backend?

- Pavel Panchekha

[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Glenn Morris]

Jambunathan K wrote:

> When compiling with package manager, the compilation happens from within
> a running Emacs session and very likely the "old" Org files are already
> loaded in to the runtime "inadvertently" by the user either by looking
> at the org agenda for the day or may be by just viewing an Org file or
> by the plain old (require 'org-whatever) out of habit in .emacs. 

There's your problem. The only way to reliably compile, especially
something where an old version might already be loaded, is to use a
fresh Emacs instance. There's no reason the "package manager" could not
spawn a separate Emacs in batch-mode as a sub-job to do the compilation.

cc-mode tries to have some voodoo to get around this, but please, please
don't go down that road.

I guess nobody ever expected the package manager to be used to load a
different version of something that was already in Emacs.

Re: [O] [PATCH] org-babel-exp-lob-one-liners should not parse the entire buffer.

[Jérémy Compostella]

Jambunathan K  writes:
>> All,
>>
>> I'm currently generating a road book for a trip from different Org-Mode
>> file and other data. It results in a 13 thousands lines Org-Mode file
>> and I have some performance issues. Using the ELP package, I isolated
>> the two main bottlenecks.
>>
>> 1. One is in org-odt : the org-odt-write-manifest-file function is
>>called once and takes 5.546672 seconds to write a 167 lines file. I
>>rewrote this function and now it takes 0.01606 seconds to write the
>>same file. As usually for this package, I directly send the patch to
>>the org-odt author.
>
> I think it is multiple write-region that takes the toll.
I do agree.

> I have pushed a variation of your original fix which minimizes the
> number of lines originally modified by you.
>
> I have acknowledged you as the author in the commit message (even though
> I appear as the author)
Fine.

>> As usually for this package, I directly send the patch to the org-odt
>> author.
>
> Btw, you can post your patches to the list. I am a regular on this list.
OK.
> Jambunathan K.

What about the second patch ? I'm very interested in seeing it merged. 

Jeremy
-- 
Sent from my Emacs

Re: [O] HTML5 Backend

[Thomas S. Dye]

Aloha Pavel,

You might want to wait for Nicolas Goaziou to finish writing a generic
exporter and LaTeX backend on top of contrib/org-element.el.  See his
announcement to this list a few days ago.

All the best,
Tom

Pavel Panchekha  writes:

> I'd like to add a backend that renders org-mode to spiffy new HTML5.
>  Presumably this would exist together with the existing XHTML backend
> (maybe eventually replacing it, I guess).  I've looked around and can't
> find anything describing the internals of Org-mode; are there any starting
> points, or should I just crack open the code?  Anything particularly
> non-obvious to keep in mind while writing the HTML5 backend?
>
> - Pavel Panchekha
> I'd like to add a backend that renders org-mode to spiffy new HTML5.  
> Presumably this would exist together with the existing XHTML backend (maybe 
> eventually replacing it, I guess).  I've looked around and can't find 
> anything describing the internals of Org-mode; are there any starting points, 
> or should I just crack open the code?  Anything particularly non-obvious to 
> keep in mind while writing the HTML5 backend?
>
> - Pavel Panchekha
>

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

Re: [O] HTML5 Backend

[Pavel Panchekha]

Oh, thanks for the heads-up. I don't read the list too closely, and hadn't
caught that.
On Nov 24, 2011 2:48 PM, "Thomas S. Dye"  wrote:

> Aloha Pavel,
>
> You might want to wait for Nicolas Goaziou to finish writing a generic
> exporter and LaTeX backend on top of contrib/org-element.el.  See his
> announcement to this list a few days ago.
>
> All the best,
> Tom
>
> Pavel Panchekha  writes:
>
> > I'd like to add a backend that renders org-mode to spiffy new HTML5.
> >  Presumably this would exist together with the existing XHTML backend
> > (maybe eventually replacing it, I guess).  I've looked around and can't
> > find anything describing the internals of Org-mode; are there any
> starting
> > points, or should I just crack open the code?  Anything particularly
> > non-obvious to keep in mind while writing the HTML5 backend?
> >
> > - Pavel Panchekha
> > I'd like to add a backend that renders org-mode to spiffy new HTML5.
>  Presumably this would exist together with the existing XHTML backend
> (maybe eventually replacing it, I guess).  I've looked around and
> can't find anything describing the internals of Org-mode; are there any
> starting points, or should I just crack open the code?  Anything
> particularly non-obvious to keep in mind while writing the HTML5 backend?
> >
> > - Pavel Panchekha
> >
>
> --
> Thomas S. Dye
> http://www.tsdye.com
>

[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Glenn Morris]

Glenn Morris wrote:

> fresh Emacs instance. There's no reason the "package manager" could not
> spawn a separate Emacs in batch-mode as a sub-job to do the compilation.

Very lightly tested version:

*** lisp/emacs-lisp/package.el  2011-11-20 03:48:53 +
--- lisp/emacs-lisp/package.el  2011-11-24 19:48:49 +
***
*** 595,600 
--- 595,612 
(error "Package does not untar cleanly into directory %s/" dir
(tar-untar-buffer))
  
+ (defun package-compile (directory)
+   "Compile the Lisp files in DIRECTORY."
+   (with-current-buffer (get-buffer-create "*package-compile*")
+ (goto-char (point-max))
+ (pop-to-buffer (current-buffer))
+ (or (zerop (call-process "emacs" nil t t "--batch" "--eval"
+(format
+ "(progn (setq load-path (cons \"%s\" load-path))
+ (batch-byte-recompile-directory 0))" 
directory)
+directory))
+   (error "Compiling the package gave an error"
+ 
  (defun package-unpack (name version)
(let* ((dirname (concat (symbol-name name) "-" version))
 (pkg-dir (expand-file-name dirname package-user-dir)))
***
*** 603,610 
  (let* ((default-directory (file-name-as-directory package-user-dir)))
(package-untar-buffer dirname)
(package-generate-autoloads (symbol-name name) pkg-dir)
!   (let ((load-path (cons pkg-dir load-path)))
!   (byte-recompile-directory pkg-dir 0 t)
  
  (defun package--write-file-no-coding (file-name)
(let ((buffer-file-coding-system 'no-conversion))
--- 615,621 
  (let* ((default-directory (file-name-as-directory package-user-dir)))
(package-untar-buffer dirname)
(package-generate-autoloads (symbol-name name) pkg-dir)
!   (package-compile pkg-dir
  
  (defun package--write-file-no-coding (file-name)
(let ((buffer-file-coding-system 'no-conversion))
***
*** 645,652 
 pkg-file
 nil nil nil 'excl))
(package-generate-autoloads file-name pkg-dir)
!   (let ((load-path (cons pkg-dir load-path)))
!   (byte-recompile-directory pkg-dir 0 t)
  
  (defmacro package--with-work-buffer (location file &rest body)
"Run BODY in a buffer containing the contents of FILE at LOCATION.
--- 656,662 
 pkg-file
 nil nil nil 'excl))
(package-generate-autoloads file-name pkg-dir)
!   (package-compile pkg-dir
  
  (defmacro package--with-work-buffer (location file &rest body)
"Run BODY in a buffer containing the contents of FILE at LOCATION.

Re: [O] [babel] Loosing my latin...

[Sebastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Sebastien Vauban  wrote:
>> While this code block gets evaluated as expected [...]
>> It's not the same with the 2 following ones: variables `bar' and `baz' are
>> said to be void.
>> 
>> ** NOK With property
>> 
>> #+property: var bar=44
>> #+begin_src emacs-lisp
>>   (+ bar bar)
>> #+end_src
>
> This one worked after C-c C-c on the property line.

I did C-c C-c on the property line -- before sending. It still does not work.

Even with the property line outside of the subtrees[1], that is at the top
level of the file, it still does not work after a C-c C-c...

>> ** NOK With headers
>> 
>> 
>> #+begin_src emacs-lisp
>>   (+ baz baz)
>> #+end_src
>
> This one didn't - but it worked like this:
>
> #+headers: :var baz=55

Of course. Thanks for testing and reporting back!

The `:' is a must in front of the `var' keyword, in this case, as if it was on
the `#+begin' line.

> even with a singular "header" - doing this in a hurry, so I'm not sure
> if that's an accident of history left behind, or whether it would happen
> in a fresh session as well.

>> Am I missing something really obvious??[1]

It seems I did miss something quite obvious for the last case. Still unclear
why the second does not work for me.

Thanks for your time.

Best regards,
  Seb

Footnotes:

[1] I fear what I did was not allowed. Though, it worked for you!?

-- 
Sebastien Vauban

[O] [odt] [PATCH] Anchoring image to a page

[Jambunathan K]

Jeremy

> What about the second patch ? I'm very interested in seeing it
> merged. 

I did a quick run of the attached patch (authored by you). 

When I do this:

#+ATTR_ODT: :anchor page
  [[./org-mode-unicorn.png]]

I see that the image is anchored to the page as expected. But the moment
I attach a caption and label to it like this:

#+CAPTION: caption
#+LABEL: label
#+ATTR_ODT: :anchor page
  [[./org-mode-unicorn.png]]

the image is no longer anchored to the page. I need to make additional
modifications to achieve the desired effect for captioned images. (Let
me do this modification myself.)

I am wondering what your use case is. For example, when someone does
this:

#+ATTR_ODT: :anchor page
  [[./org-mode-unicorn.png]]

some text 

#+ATTR_ODT: :anchor page
  [[./org-mode-unicorn.png]]

what do you think should be the desired behaviour. Practically, I see
that the images get super-posed one on top of the other on the same page
(i.e, effectively I see only one image). I am wondering what the trick
is to embed multiple page anchored images in the document.

>From 213cfc2a9c44a93639afe460fe2f8dbee793bcd1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Compostella?= 
Date: Fri, 18 Nov 2011 16:39:17 +0100
Subject: [PATCH] org-odt.el: Add page anchor image type support.

This patch enables :
- The possibility to select the image anchor type with the ATTR_ODT tag
- The "page" anchor type
This patch is very useful to get "floating pictures".
---
 contrib/lisp/org-odt.el |   15 +--
 contrib/odt/styles/OrgOdtStyles.xml |5 +
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/contrib/lisp/org-odt.el b/contrib/lisp/org-odt.el
index 81abf5d..1d60b13 100644
--- a/contrib/lisp/org-odt.el
+++ b/contrib/lisp/org-odt.el
@@ -1495,12 +1495,12 @@ ATTR is a string of other attributes of the a element."
 	   (latex-frag (org-find-text-property-in-string
 			  'org-latex-src src))
 	   (category (and latex-frag "__DvipngImage__"))
-	   (embed-as (or embed-as
-			 (if latex-frag
-			 (or (org-find-text-property-in-string
-  'org-latex-src-embed-type src) 'character)
-			   'paragraph)))
 	   (attr-plist (org-lparse-get-block-params attr))
+	   (embed-as (cond (embed-as)
+			   (latex-frag (or (org-find-text-property-in-string
+	 'org-latex-src-embed-type src) 'character))
+			   ((plist-get attr-plist :anchor))
+			   ('paragraph)))
 	   (size (org-odt-image-size-from-file
 		  src (plist-get attr-plist :width)
 		  (plist-get attr-plist :height)
@@ -1514,6 +1514,7 @@ ATTR is a string of other attributes of the a element."
 	(case embed-as
 	  (paragraph (org-odt-format-entity "DisplayImage" href width height))
 	  (character (org-odt-format-entity "InlineImage" href width height))
+	  (page (org-odt-format-entity "PageImage" href width height))
 	  (t (error "Unknown value for embed-as %S" embed-as
(t
 	(org-odt-format-entity
@@ -1565,6 +1566,7 @@ ATTR is a string of other attributes of the a element."
 (defvar org-odt-entity-frame-styles
   '(("InlineImage" "__Figure__" ("OrgInlineImage" nil "as-char"))
 ("DisplayImage" "__Figure__" ("OrgDisplayImage" nil "paragraph"))
+("PageImage" "__Figure__" ("OrgPageImage" nil "page"))
 ("CaptionedDisplayImage" "__Figure__"
  ("OrgCaptionedImage"
   " style:rel-width=\"100%\" style:rel-height=\"scale\"" "paragraph")
@@ -1619,7 +1621,8 @@ ATTR is a string of other attributes of the a element."
 
 (defvar org-export-odt-default-image-sizes-alist
   '(("character" . (5 . 0.4))
-("paragraph" . (5 . 5)))
+("paragraph" . (5 . 5))
+("page" . (5 . 5)))
   "Hardcoded image dimensions one for each of the anchor
   methods.")
 
diff --git a/contrib/odt/styles/OrgOdtStyles.xml b/contrib/odt/styles/OrgOdtStyles.xml
index 5ec868a..df4f3f4 100644
--- a/contrib/odt/styles/OrgOdtStyles.xml
+++ b/contrib/odt/styles/OrgOdtStyles.xml
@@ -375,6 +375,11 @@

   
 
+  
+  
+   
+  
+
   
   

-- 
1.7.5.4


-- 

Re: [O] Org from ELPA question

[Achim Gratz]

Jambunathan K  writes:
> Filed as an umbrella bug -
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125. 

I believe both the reason and the cure you suggest there are not
entirely correct, even though it might be generally nice to be able to
specifiy the order of things.  I have been having no issues when
compiling org-mode using the same method that package-manager uses (that
is in a single process and in alphabetical order).

There are some requisites for doing that correctly, which I might not
have fully comprehended: 1) there must not be any stale .elc files
around since Emacs would prefer these over the newer .el files and get
lost.  Similarly, 2) the source directory must be first in loadpath,
otherwise Emacs might pick up pre-existing sources (or compiled files)
that are packaged with Emacs.  Lastly, 3) at least for macros, Emacs
must not have a different definition in-core already before the compile
starts because then it will never look for the newer definiton in the
source file (or too late).

I keep 1) fulfilled in the makefile by nuking all .elc files before
starting the compile, 2) by specifying the loadpath directly at the
command line and 3) by specifying -Q to the Emacs process that does the
compilation.  So far I haven't found any ill effects of doing that, but
please feel free to check out my Makefile fork.  I'll have to check if I
already used that method to compile the latest version of org-mode I use
at work since that one gets much more use...

I don't know how the last condition can be fulfilled in
package manager without starting a new Emacs process, but perhaps it is
possible.  Before settling on this make process I have been
unsuccessfully trying to automatically unravel the interdependencies
between org-mode source files.  Aside from not having found any tools
that deliver dependencies in a way that would be useful for make, it
also can not really work since there are some circular dependencies in
the sources.


HTH,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] [odt] [PATCH] Anchoring image to a page

[Jérémy Compostella]

Jambunathan K  writes:

> Jeremy
>
>> What about the second patch ? I'm very interested in seeing it
>> merged. 
>
> I did a quick run of the attached patch (authored by you). 
>
> When I do this:
>
> #+ATTR_ODT: :anchor page
>   [[./org-mode-unicorn.png]]
>
> I see that the image is anchored to the page as expected. But the moment
> I attach a caption and label to it like this:
>
> #+CAPTION: caption
> #+LABEL: label
> #+ATTR_ODT: :anchor page
>   [[./org-mode-unicorn.png]]
>
> the image is no longer anchored to the page. I need to make additional
> modifications to achieve the desired effect for captioned images. (Let
> me do this modification myself.)
OK.

> I am wondering what your use case is. For example, when someone does
> this:
>
> #+ATTR_ODT: :anchor page
>   [[./org-mode-unicorn.png]]
>
> some text 
>
> #+ATTR_ODT: :anchor page
>   [[./org-mode-unicorn.png]]
>
> what do you think should be the desired behaviour. Practically, I see
> that the images get super-posed one on top of the other on the same page
> (i.e, effectively I see only one image). I am wondering what the trick
> is to embed multiple page anchored images in the document.
You get the "correct" behavior :) The trick is : you write text and text
and text. Sometimes, you want to add a picture but you don't want a page
break. For example, you want to add a big illustration. To render
correctly, the picture needs its own page but you don't want to break
the page. In this case you need to anchor the picture to the "page". I
made an example based on the road book I'm working on :
http://www.jerryland.fr/tatw/WorldTrip.odt. Quick example visible on
pages 20 and 23. For information, the first map inclusion was at the
beginning of 2.1.1 and the second map inclusion at the beginning of
2.3.1.

Obviously if you anchor consecutively two pictures to the "same page",
you could be disappointed by the result but it's an issue you have to
address with some others parameters which I do not know actually.

Finally the patch I was talking about is not this one but the one
attached to http://comments.gmane.org/gmane.emacs.orgmode/49548. I
really need it because this bug lead to at least 50 seconds more to
generate my ODT file.

> From 213cfc2a9c44a93639afe460fe2f8dbee793bcd1 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Compostella?= 
> 
> Date: Fri, 18 Nov 2011 16:39:17 +0100
> Subject: [PATCH] org-odt.el: Add page anchor image type support.
>
> This patch enables :
> - The possibility to select the image anchor type with the ATTR_ODT tag
> - The "page" anchor type
> This patch is very useful to get "floating pictures".
> ---
>  contrib/lisp/org-odt.el |   15 +--
>  contrib/odt/styles/OrgOdtStyles.xml |5 +
>  2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/lisp/org-odt.el b/contrib/lisp/org-odt.el
> index 81abf5d..1d60b13 100644
> --- a/contrib/lisp/org-odt.el
> +++ b/contrib/lisp/org-odt.el
> @@ -1495,12 +1495,12 @@ ATTR is a string of other attributes of the a 
> element."
>  (latex-frag (org-find-text-property-in-string
> 'org-latex-src src))
>  (category (and latex-frag "__DvipngImage__"))
> -(embed-as (or embed-as
> -  (if latex-frag
> -  (or (org-find-text-property-in-string
> -   'org-latex-src-embed-type src) 'character)
> -'paragraph)))
>  (attr-plist (org-lparse-get-block-params attr))
> +(embed-as (cond (embed-as)
> +(latex-frag (or (org-find-text-property-in-string
> +  'org-latex-src-embed-type src) 
> 'character))
> +((plist-get attr-plist :anchor))
> +('paragraph)))
>  (size (org-odt-image-size-from-file
> src (plist-get attr-plist :width)
> (plist-get attr-plist :height)
> @@ -1514,6 +1514,7 @@ ATTR is a string of other attributes of the a element."
>   (case embed-as
> (paragraph (org-odt-format-entity "DisplayImage" href width height))
> (character (org-odt-format-entity "InlineImage" href width height))
> +   (page (org-odt-format-entity "PageImage" href width height))
> (t (error "Unknown value for embed-as %S" embed-as
> (t
>   (org-odt-format-entity
> @@ -1565,6 +1566,7 @@ ATTR is a string of other attributes of the a element."
>  (defvar org-odt-entity-frame-styles
>'(("InlineImage" "__Figure__" ("OrgInlineImage" nil "as-char"))
>  ("DisplayImage" "__Figure__" ("OrgDisplayImage" nil "paragraph"))
> +("PageImage" "__Figure__" ("OrgPageImage" nil "page"))
>  ("CaptionedDisplayImage" "__Figure__"
>   ("OrgCaptionedImage"
>" style:rel-width=\"100%\" style:rel-height=\"scale\"" "paragraph")
> @@ -1619,7 +1621,8 @@ ATTR is a string of other attributes of the a element."
>  
>  

Re: [O] Journal versus clock tables: Opposing requirements?

[Olaf Dietsche]

Eric S Fraga  writes:

> Olaf Dietsche  writes:
>
>> Tommy Kelly  writes:
>>
 OK, that might be what I need then. I thought clock tables grouped
 things by headings, not by tags. I'll have a look at the manual.
>
> [...]
>
>> #+BEGIN: clocktable :maxlevel 2 :scope file :tags "health"
>> Clock summary at [2011-11-08 Di 09:57]
>>
>> | Headline | Time   |
>> |--+|
>> | *Total time* | *0:20* |
>> |--+|
>> | Exercises| 0:20   |
>> #+END: clocktable
>
> I've lost the rest of this thread and I don't actually know who to
> attribute the original statement above...

Do you mean
?

> In any case, I would like to have entries in the clock report by tag as
> opposed to headline (as alluded to above).  Is this actually possible?
> My logging approach is to have descriptive headings (the specific task
> undertaken) with tags indicating the type of activity (teaching,
> research, admin, personal).  I need a breakdown of my time spent in each
> category in one table. 
>
> I realise I can do N tables, one for each tag, but this is not
> particularly useful for me.  It'll do but if there's a nicer solution,
> I'll take it!
>
> The documentation refers to a :formatter entry, but I am not sure
> whether this is relevant as it says that this is for formatting an
> entry.  My problem is that I want tag based entries, not how they are
> formatted?
>
> Apologies if I've missed something obvious in the manual!

Regards, Olaf

[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Stelian Iancu]

On Thu, Nov 24, 2011 at 20:09, Glenn Morris  wrote:
> Jambunathan K wrote:
>
>> When compiling with package manager, the compilation happens from within
>> a running Emacs session and very likely the "old" Org files are already
>> loaded in to the runtime "inadvertently" by the user either by looking
>> at the org agenda for the day or may be by just viewing an Org file or
>> by the plain old (require 'org-whatever) out of habit in .emacs.
>
> There's your problem. The only way to reliably compile, especially
> something where an old version might already be loaded, is to use a
> fresh Emacs instance. There's no reason the "package manager" could not
> spawn a separate Emacs in batch-mode as a sub-job to do the compilation.
>
> cc-mode tries to have some voodoo to get around this, but please, please
> don't go down that road.
>
> I guess nobody ever expected the package manager to be used to load a
> different version of something that was already in Emacs.
>

I am sorry to be asking a stupid question, but then, wouldn't restart
Emacs fix the issue and have the new compiled org files loaded? In my
case, that didn't seem to happen either (even though load-library
showed org-compat to be from ELPA).

[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Glenn Morris]

Stelian Iancu wrote:

> I am sorry to be asking a stupid question, but then, wouldn't restart
> Emacs fix the issue and have the new compiled org files loaded?

No, because the files get compiled with a mix of old and new code
loaded, so the compiled files are probably messed up. Restarting Emacs
would not help with that. (You'll definitely need to restart Emacs if
you had one version of Org loaded and want to switch to another.)

[O] bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation

[Jambunathan K]

Stelian

> I am sorry to be asking a stupid question, but then, wouldn't restart
> Emacs fix the issue and have the new compiled org files loaded? In my
> case, that didn't seem to happen either (even though load-library
> showed org-compat to be from ELPA).

locate-library doesn't show what is *already* loaded. It will only shows
what *will* be loaded. 

The most important thing during package compilation is this: Make sure
there is no running instance of Org in any form. If this condition is
not satisfied then to-be-installed files will be compiled with old
definitions of macro. This is not what we want. We want the new files to
be compiled with new macro definitions.

Do things work for you when you start a *minimal* Emacs and *then* do
M-x list-packages -> install? You don't have to apply Glenn's patch to
get the desired behaviour (I am assuming here that you are probably not
that comfortable working with patches).

Jambunathan K.
-- 

[O] Quick and dirty code blocks: eepitch

[Eduardo Ochs]

Hello list,

I just discovered org-babel-screen... I haven't done my org-homework
yet, but I can't resist making an announcement: the package
eepitch.el, at

  http://angg.twu.net/eev-current/eepitch.el.html
  http://angg.twu.net/eev-current/eepitch.el
  http://angg.twu.net/eev-current/eepitch.readme.html

has some goals in common with org-babel - eepitch also lets us script
external programs from Emacs - but it does that in a very different
style from org. In eepitch the emphasys is in the simplicity of the
implementation - its core is less than 200 lines, it runs on plain
Emacs, it uses only two keybindings, support for a new language can
usually be implemented in just one or two lines of Lisp, and "eepitch
code blocks" can appear in any file and be used in any mode (by the
way, I've been using them in org files for ages). Eepitch's approach
has several downsides, of course - one of them is that eepitch code
blocks will look UGLY to org users, as I never worked on ways of
fontifying them... I will try to implement an org-babel language for
eepitch code blocks (this is part of my homework).

Oh, by the way: org-babel-screen was inspired by the ancestor of
eepitch...

  http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-screen.html
  http://angg.twu.net/eev-current/anim/channels.anim.html

Cheers, :-)
  Eduardo Ochs
  eduardoo...@gmail.com
  http://angg.twu.net/

Re: [O] Quick and dirty code blocks: eepitch

[Rustom Mody]

Hi Eduardo

I always thought eev to be a very interesting idea but could never get it
to work.
If eepitch is sufficiently decoupled from eev (and documented) I may try
again...


Rusi

Re: [O] org2info, docu workflow

[Andreas Röhler]

Am 24.11.2011 18:13, schrieb Thomas S. Dye:

Aloha Andreas,

FWIW, I looked into this a while back and couldn't find an easy path
from org to info.  Caveat emptor, absence of evidence isn't evidence of
absence.  Others on the list probably have a better handle on this.

The most promising path seemed to be export to docbook,



Hi,

thanks, that's the direction it went here. Even thinking on the long run 
writing in docbook from the scratch might be faster than from org or 
reST, as from inside an ML must not care for formatting, while tagging 
might be automated.



 but I couldn't get

the docbook to info step working with what seemed at the time reasonable
effort


Seeing a whole bunch of tools docbook2... (some tex) still hopefully.


Andreas

Re: [O] [babel] Loosing my latin...

[Nick Dokos]

Sebastien Vauban  wrote:

> >> #+property: var bar=44
> >> #+begin_src emacs-lisp
> >>   (+ bar bar)
> >> #+end_src
> >
> > This one worked after C-c C-c on the property line.
> 
> I did C-c C-c on the property line -- before sending. It still does not work.
> 
> Even with the property line outside of the subtrees[1], that is at the top
> level of the file, it still does not work after a C-c C-c...
> 

Do C-h v org-file-properties RET before and after the C-c C-c:
afterwards I get

,
| org-file-properties is a variable defined in `org.el'.
| Its value is (("var" . "bar=44"))
| 
| Local in buffer seb.org; global value is nil
| 
|   Automatically becomes buffer-local when set in any fashion.
| 
| Documentation:
| List of property/value pairs that can be inherited by any entry.
| Valid for the current buffer.
| This variable is populated from #+PROPERTY lines.
`

What do you get?

Nick