Re: [O] new exporter

[Achim Gratz]

Achim Gratz writes:
> This causes the (current-buffer) to expand literally into the byte-code
> (look at the byte-code!) instead of being compiled as a function, which
> obviously isn't going to work.  This does not happen if I either remove
> the cond form or if I wrap the BODY in save-restriction in progn, but I
> haven't done any further investigation if the code still works with that
> change and if maybe there are other places that are similarly struck.

No, that's not right... as long as I compile org-export.el in isolation,
it compiles correctly.  It croaks if I compile either one of
org-e-html.el or org-e-odt.el in the same session.  These are the two
backends that have a (require 'org-export) in them.  SOmething about
this must be altering the environment in a way that throws the
byte-compiler off-course.  Back to the drawing board.  :-(


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [O] new exporter

[Achim Gratz]

Achim Gratz writes:
> As long as I don't compile org-export.el, all tests are now passing.
> Thank you.

I've had a look at the byte-compiled code and traced at least one of
those errors to the following construct in org-export.el(org-export-as):

#BEGIN_SRC emacs_lisp
…
  (save-excursion
(save-restriction
  ;; Narrow buffer to an appropriate region or subtree for
  ;; parsing.  If parsing subtree, be sure to remove main headline
  ;; too.
  (cond ((org-region-active-p)
 (narrow-to-region (region-beginning) (region-end)))
(subtreep
 (org-narrow-to-subtree)
 (goto-char (point-min))
 (forward-line)
 (narrow-to-region (point) (point-max
  ;; 1. Get export environment from original buffer.  Store
  ;;original footnotes definitions in communication channel as
  ;;they might not be accessible anymore in a narrowed parse
  ;;tree.  Also install user's and developer's filters.
  (let ((info (org-export-install-filters
   (org-export-get-environment backend subtreep ext-plist)))
;; 2. Get parse tree.  Buffer isn't parsed directly.
;;Instead, a temporary copy is created, where include
;;keywords are expanded and code blocks are evaluated.
(tree (let ((buf (or (buffer-file-name (buffer-base-buffer))
 (current-buffer
…
#END_SRC

This causes the (current-buffer) to expand literally into the byte-code
(look at the byte-code!) instead of being compiled as a function, which
obviously isn't going to work.  This does not happen if I either remove
the cond form or if I wrap the BODY in save-restriction in progn, but I
haven't done any further investigation if the code still works with that
change and if maybe there are other places that are similarly struck.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: [O] Is Org mode gonna break on emacs 24.50.1x ?

[Achim Gratz]

Baptiste Fouques writes:
> * lisp/emacs-lisp/cl.el (flet): Don't autoload.
>
> Makes  my  org not  working  in  several  places (babel,  coupling  with
> remenber,  …).  I  think  that the  point in  using  'flet' has  appears
> several times in this group. It seems to become more crucial here.

All the files using flet (and other cl macros) should have an

  (eval-when-compile (require 'cl))

before first use, so whether or not flet is autoloaded should be a moot
point.  If they don't, it's a bug in org.  If they do and it still
doesn't work, the bug may be in org, but more likely in Emacs.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

[O] Exporting to groff...

[Luis Anaya]

Hi:

Being that groff is not available in org mode (at least by default, I 
decided to give it a try and write a driver to export Org files into 
groff with the use of the -mm macros. 

Being that I'm not familiar with many of the facilities in Org mode, 
I am modifying the org-latex.el to write groff markups. 

In its current incarnation it exports the titles, content and basic
support for tables

You can see the resultant output at:  http://ppl.ug/1_8pA3lpXWA/

Really messy code currently in http://github.com/papoanaya/emacs_utils

Regards,

-- 
Luis Anaya
papo anaya aroba hot mail punto com
"Do not use 100 words if you can say it in 10" - Yamamoto Tsunetomo

Re: [O] Is Org mode gonna break on emacs 24.50.1x ?

[Vladimir Lomov]

Hello,
** Baptiste Fouques [2012-06-25 17:38:22 +0200]:

> Hi,

> thanks all for org.

> I  wonder  whether org-mode  is  going  to  break  badly on  next  emacs
> cleanup.

IMHO, yes, see my message under topic 'Export and tangling is broken for
Emacs rev. 108681+' (actually it should be 'Export and tangling are
broken...')
http://article.gmane.org/gmane.emacs.orgmode/57278

> ---
> commit 1e211d886c96420904ad197cfee7fce7ae7b9d83 (HEAD, refs/heads/master)
> Author: Stefan Monnier 
> Date:   Fri Jun 22 09:42:38 2012 -0400

> …
> * lisp/emacs-lisp/cl.el (flet): Don't autoload.
> …
> ---

This is bzr rev. 108681

> Makes  my  org not  working  in  several  places (babel,  coupling  with
> remenber,  …).  I  think  that the  point in  using  'flet' has  appears
> several times in this group. It seems to become more crucial here.

> Don't think that the problem of emacs, but org …

> Thanks.

I'll wait the Org developers response.

---
WBR, Vladimir Lomov

-- 
I would like to urinate in an OVULAR, porcelain pool --

Re: [O] **: Re: [dev] About a beamer back-end

[Andreas Leha]

Hi,

[...]

>>> I'm wondering, though, how you support the special case of "beamer frame
>>> level" set to 0, where we need to add the tag "B_frame" (in fact, the
>>> property) to show where the frame really begins.

thanks for that tip!  This, I didn't know, but I'll use as standard now.

I never understood why there is actually the need for
the beamer_frame_level, as there is the B_frame anyway.  The
beamer_frame_level becomes annoying frequently, when there are sections
with sub-sections and sections without.

[...]

Regards,
Andreas

[O] Is Org mode gonna break on emacs 24.50.1x ?

[Baptiste Fouques]

Hi,

thanks all for org.

I  wonder  whether org-mode  is  going  to  break  badly on  next  emacs
cleanup.

---
commit 1e211d886c96420904ad197cfee7fce7ae7b9d83 (HEAD, refs/heads/master)
Author: Stefan Monnier 
Date:   Fri Jun 22 09:42:38 2012 -0400

…
* lisp/emacs-lisp/cl.el (flet): Don't autoload.
…
---

Makes  my  org not  working  in  several  places (babel,  coupling  with
remenber,  …).  I  think  that the  point in  using  'flet' has  appears
several times in this group. It seems to become more crucial here.

Don't think that the problem of emacs, but org …

Thanks.

-- 
~^v^~ Bat

[O] Conditionally archiving to subtree or archive file (depending on parent ARCHIVE property)

[Christopher Allan Webber]

Hi all,

I've written a snippet of elisp which I'm finding very helpful.  I've
replaced the archive keybinding with it.  Basically, I found that when I
had something like this:

#+BEGIN_SRC org
  * Task tree
:PROPERTIES:
:ARCHIVE: %s_archive::* Task tree
:END:

  ** TODO Some task
  *** TODO Some subtask
  *** DONE Another subtask
  
  ** DONE This is done
#+END_SRC

... on something like "This is done", I'd want that whole tree moved to
the archive file.  On something like "some task", if I eventually
finished the whole tree, I wanted it moved to the archive file, but if I
had subtasks within that subtree, I might want to move them out of the
way, but not have them disappear from the bigger subtask... that would
be confusing!  So I wanted them to move to the archive subtree so I
could clean up that bigger TODO structure, like so:


#+BEGIN_SRC org
  * Task tree
:PROPERTIES:
:ARCHIVE: %s_archive::* Task tree
:END:

  ** TODO Some task
  *** TODO Some subtask
  *** Archive   :ARCHIVE:
   DONE Another subtask
#+END_SRC


But I wanted this logic to happen automatically.  So I wrote some
trivial elisp to do this.  Maybe someone else will find it helpful?

#+BEGIN_SRC emacs-lisp
;; This software is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

(defun org-archive-subtree-depending-on-property ()
  "Conditionally archive the subtree to a file or archive sibling
If the parent subtree has an ARCHIVE property, archive to a file.
Otherwise, archive to an archive sibling.
"
  (interactive)
  (let* ((current-level (org-current-level))
 (parent-archive-property
  (if current-level
  (save-excursion
(org-up-heading-safe)
(org-entry-get (point) "ARCHIVE")
(cond
 ; If there is no current level, do nothing
 ((not current-level) nil)
 ; If we're at the first level, subtree archive it
 ((or (eq current-level 1)
  (not parent-archive-property))
  (let ((org-archive-default-command 'org-archive-to-archive-sibling))
(org-archive-subtree-default-with-confirmation)))
 ; Otherwise, archive to a file
 (t
   (let ((org-archive-default-command 'org-archive-subtree))
 (org-archive-subtree-default-with-confirmation))
#+END_SRC

Re: [O] Problem with repeating tasks

[Bernt Hansen]

Hi Renger,

This example repeats fine for me here.

Org-mode version 7.8.11 (release_7.8.11-88-g802fc6 @
/home/bernt/git/org-mode/lisp/)
GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11
on raven, modified by Debian

Regards,
Bernt

Renger van Nieuwkoop  writes:

> Hi
>  
> I use repeating tasks and this worked fine with me. Since a few days, if I 
> change the status from TODO to DONE, the Status is not automatically set back 
> to
> TODO again, and the task does not repeat anymore.
>  
> Here is an example
>  
> ** DONE [#C] Zeitungen verräumen
> SCHEDULED: <2012-06-23 Sa +1w>
> - State "DONE"   from "TODO"   [2012-06-25 Mo 15:32]
>:PROPERTIES:
>:Effort:   0:10
>:LAST_REPEAT: [2012-05-28 Mo 16:15]
>:ID:   6c11b453-94fc-4e7e-97bc-0c420325fcef
>:END:
>  
> I might have changed something in my Emacs settings, but I have no clue what 
> this is causing.
>  
> Help would be appreciated.
>
> Thanks
> Renger
>  
> 
> Modelworks
> Gewerbestrasse 15
> 3600 Thun – Switzerland
> +41 79 818 53 73
> i...@modelworks.ch
> blog.modelworks.ch

Re: [O] Org Mode TOOD two way sync tool

[Christopher Allan Webber]

Christopher Allan Webber  writes:

> Ah, I've stopped using that theme!  But it was a small extension to
> color-theme-snow.  Here it is. :)

FYI, the theme I use now is naquadah-theme, which I *highly* recommend.

http://git.naquadah.org/?p=naquadah-theme.git;a=summary

[O] Problem with repeating tasks

[Renger van Nieuwkoop]

Hi

I use repeating tasks and this worked fine with me. Since a few days, if I 
change the status from TODO to DONE, the Status is not automatically set back 
to TODO again, and the task does not repeat anymore.

Here is an example

** DONE [#C] Zeitungen verräumen
SCHEDULED: <2012-06-23 Sa +1w>
- State "DONE"   from "TODO"   [2012-06-25 Mo 15:32]
   :PROPERTIES:
   :Effort:   0:10
   :LAST_REPEAT: [2012-05-28 Mo 16:15]
   :ID:   6c11b453-94fc-4e7e-97bc-0c420325fcef
   :END:

I might have changed something in my Emacs settings, but I have no clue what 
this is causing.

Help would be appreciated.

Thanks
Renger


Modelworks
Gewerbestrasse 15
3600 Thun - Switzerland
+41 79 818 53 73
i...@modelworks.ch
blog.modelworks.ch

[O] bug#11774: org-mode causes undo boundaries to be lost

[Toby Cubitt]

On Sun, Jun 24, 2012 at 11:52:41PM +0200, Toby Cubitt wrote:
> On Sun, Jun 24, 2012 at 11:39:08PM +0200, Bastien wrote:
> > Hi Toby,
> > 
> > Toby Cubitt  writes:
> > 
> > > For some unknown reason, org-mode is causing the undo boundary between
> > > the (2 . 4) and (1 . 2) entries to be removed from `buffer-undo-list'.
> > 
> > Can you try again with
> > 
> >   (setq org-self-insert-cluster-for-undo nil)
> > 
> > and report?
> 
> Yup, that fixes the problem.
> 
> I don't fully understand the purpose of
> `org-self-insert-cluster-for-undo', given that the Emacs command loop
> already groups consecutive undo entries together, but presumably it
> enables a more aggressive form of clustering.
>
[snip]
>
> I could try to work around this in undo-tree-mode, but it seems to me
> that org-mode shouldn't be throwing away an undo boundary that comes
> before an entry which definitely shouldn't be clustered with anything
> (namely the undo-tree-canary symbol, which is meaningless to org-mode).

I've now added a work-around for this in undo-tree-mode (currently only
in git, but I'll push to ELPA once it's sufficiently tested).

I'm still not entirely convinced that the boundary discarding logic in
org-self-insert-command is correct. For example, if I do the following:

1. Type some text at some location in an org-mode buffer
2. Move to another location very far away
   (without invoking any commands other than point motion)
3. Type some more text

then org-self-insert-cluster-for-undo collapses the undo changesets for
these two changes into one. Undoing then reverts both sets of changes at
once, even though those changes might be so far apart that they aren't
both visible at the same time in the buffer.

That seems very undesirable to me.

But as I can work around it in undo-tree-mode, I'll leave it up to
Bastien to decide whether or not this feature needs reworking in
org-mode.

Best,
Toby
-- 
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain

email: ts...@cantab.net
web:   www.dr-qubit.org

[O] Export and tangling is broken for Emacs rev. 108681+

[Vladimir Lomov]

Hello,
as topic states, below example and extact messages copied from *Messages* buffer

--- 8< ---

#+TITLE: Example
#+AUTHOR: Vladimir Lomov
#+DESCRIPTION: This example shows a problem with Org mode and Emacs 108681
#+OPTIONS: LaTeX:dvipng ^:{} toc:nil num:nil

* Example of code

#+NAME: example
#+BEGIN_SRC sh :tangle ex1-example :shebang "#!/bin/bash"
echo "Hello, World"
#+END_SRC

When 'tangling' from Org document using =C-c C-v t= the minibuffer (echo area) 
shows
#+BEGIN_EXAMPLE
byte-code: Symbol's function definition is void: ap
#+END_EXAMPLE

When exporting to HTML using =C-c C-e h= in minibuffer I see
#+BEGIN_EXAMPLE
org-export-preprocess-string: Symbol's function definition is void: interblock
#+END_EXAMPLE

--- 8< ---

P.S. I'm not familiar with emacs-lisp at all, but according to messages
and bzr log I suspect the problem with bytecomp.el.

Also, please note that GTK3 build is broken for revs. from 108687 til
108698, repaired in 108699.

---
WBR, Vladimir Lomov

-- 
Just once I would like to persuade the audience not to wear any article of
blue denim.  If only they could see themselves in a pair of brown corduroys
like mine instead of this awful, boring blue denim.  I don't enjoy the sky
or sea as much as I used to because of this Levi character.  If Jesus Christ
came back today, He and I would get into our brown corduroys and go to the
nearest jean store and overturn the racks of blue denim.  Then we'd get
crucified in the morning.
-- Ian Anderson, of Jethro Tull

Re: [O] Org Mode TOOD two way sync tool

[Christopher Allan Webber]

Sriram Karra  writes:

> On Sun, Jun 24, 2012 at 10:37 PM, Christopher Allan Webber 
>  wrote:
>
> Hey Aurélien,
>
> This is great.  I formerly worked on something similar:
>
> 
> http://labs.creativecommons.org/2010/11/10/bridging-public-bugtrackers-and-local-tasklists/
>
>  Nice color-theme, there. If you use color-theme.el, can you share it?
> Otherwise, what's your config?
>
> -Karra

Ah, I've stopped using that theme!  But it was a small extension to
color-theme-snow.  Here it is. :)

#+begin_src emacs-lisp
;; This software is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

(defun color-theme-snow-better ()
  "Because `color-theme-snow' is so awesome, except for when it isn't."
  (interactive)
  (color-theme-snow)
  (let ((color-theme-is-cumulative t))
(color-theme-install
 '(color-theme-snow-better
   ((background-color . "snow2")
(background-mode . light)
(border-color . "black")
(cursor-color . "cadet blue")
(foreground-color . "black")
(mouse-color . "black"))
   (emacs-wiki-link-face ((t (:bold t :underline "BlueViolet" :foreground 
"BlueViolet"
   (muse-link-face ((t (:bold t :underline "BlueViolet" :foreground 
"BlueViolet"
   (info-xref ((t (:bold t :foreground "BlueViolet"
   (region ((t (:background "light steel blue"
   (cursor ((t (:background "cadet blue"
   (fringe ((t (:background "white"
   (planner-high-priority-task-face ((t (:foreground "red"
   (planner-medium-priority-task-face ((t (:foreground "green"
   (planner-low-priority-task-face ((t (:foreground "blue"
   (planner-canceled-task-face ((t (:foreground "gray" :strike-through t
   (org-todo ((t (:foreground "red2" :bold t
   (org-done ((t (:foreground "SpringGreen3" :bold t
   (org-special-keyword ((t (:foreground "sienna"
   (org-column ((t (:background "gray85"
   (erc-input-face ((t (:foreground "brown"
   (erc-notice-face ((t (:foreground "SlateBlue" :bold t
   (erc-current-nick-face ((t (:foreground "DarkTurquoise" :bold t
   (erc-prompt-face ((t (:foreground "Black" :bold t :background 
"lightBlue2"
   (planner-note-headline-face ((t (:bold t :foreground "azure3"
#+end_src

Re: [O] Org Mode TOOD two way sync tool

[Sriram Karra]

On Sun, Jun 24, 2012 at 10:37 PM, Christopher Allan Webber <
cweb...@dustycloud.org> wrote:

> Hey Aurélien,
>
> This is great.  I formerly worked on something similar:
>
>
> http://labs.creativecommons.org/2010/11/10/bridging-public-bugtrackers-and-local-tasklists/


 Nice color-theme, there. If you use color-theme.el, can you share it?
Otherwise, what's your config?

-Karra

Re: [O] Org Mode TOOD two way sync tool

[Aurélien Aptel]

On Sun, Jun 24, 2012 at 7:07 PM, Christopher Allan Webber
 wrote:
> http://labs.creativecommons.org/2010/11/10/bridging-public-bugtrackers-and-local-tasklists/

Yes I've already read your post while researching for my project :)

> I'd be interested to see if you come up with a generic solution that
> could have mapppings for multiple bugtrackers, and that could sync with
> bugtracking states so if the bug gets closed, the TODO does also, or at
> least that it warns as such, etc.

You'll be pleased to know that org-sync already does 2-way sync and
works with Github and bitbucket atm. There is a generic
library/multiple backend system in place.

You might be interested in my project page on worg [1] or this
announcement I made some time ago (which has a small tutorial) [2].

1: 
http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/org-sync/backends.html
2: http://lists.gnu.org/archive/html/emacs-orgmode/2012-06/msg00169.html

Re: [O] aide

[Olaf.Hamann]

Am 25.06.2012 12:31, schrieb Jambunathan K:

"Olaf.Hamann"  writes:


After that M-x org-export-as-odt does not display the zip-Error any
more, but stops with 'Unable to create odt file (1)' in my case.


When this happens, the "*Messages*" buffer usually contains the error
string emitted by zip.  Please look at the messages buffer for possible
remedies.


Thank you for that. Messages buffer offers that gzip does not understand -X.

So using gzip in that way was no good idea.

Apologies to all for the spam ^^

Re: [O] aide

[Jambunathan K]

"Olaf.Hamann"  writes:

> After that M-x org-export-as-odt does not display the zip-Error any
> more, but stops with 'Unable to create odt file (1)' in my case.

When this happens, the "*Messages*" buffer usually contains the error
string emitted by zip.  Please look at the messages buffer for possible
remedies.
-- 

Re: [O] aide

[Jambunathan K]

"Olaf.Hamann"  writes:

> I downloaded the Gzip binary from
> http://gnuwin32.sourceforge.net/packages/gzip.htm.
> I opened the zip-file with a graphical unzip-program  (like Winzip or
> 7zip or Totalcommander or so).
>
> Then I put only gzip.exe into Windows/system32 directory and renamed
> it to zip.exe

I don't think you can do that.  Some references I found.  Curious minds
can do more R&D :-)

, From http://en.wikipedia.org/wiki/Gzip
| gzip is normally used to compress just single files.[4] Compressed
| archives are typically created by assembling collections of files into a
| single tar archive, and then compressing that archive with gzip. The
| final .tar.gz or .tgz file is usually called a "tarball".[5]
| 
| Gzip is not to be confused with the ZIP archive format, which also uses
| DEFLATE. The ZIP format can hold collections of files without an
| external archiver, but is less compact than compressed tarballs holding
| the same data, because it compresses files individually and cannot take
| advantage of redundancy between files (solid compression).
`

, From zip's manual page
| zip is a compression and file packaging utility for Unix, VMS, MSDOS,
| OS/2, Windows 9x/NT/XP, Minix, Atari, Macintosh, Amiga, and Acorn RISC
| OS.  It is analogous to a combination of the Unix commands tar(1) and
| compress(1) and is compatible with PKZIP (Phil Katz's ZIP for MSDOS
| systems).
`


-- 

Re: [O] aide

[Jambunathan K]

For zip on Windows use,

[1] http://en.wikipedia.org/wiki/Info-ZIP or 
[2] http://gnuwin32.sourceforge.net/packages/zip.htm
[2] You can also install Cygwin.

Also see
[1] http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg00485.html
[2] http://orgmode.org/worg/org-faq.html#sec-18-18

Btw, mailing list and worg + faq are good places to start when one needs
extra help with Org.

> Am 24.06.2012 20:53, schrieb Bastien:
>>
>> Sylvie is using Windows and she tries to export to ODT (for further
>> conversion to PDF).
>>
>> Apparently, the executable "Zip operator" is needed.

-- 

Re: [O] aide

[Olaf.Hamann]

Hello Sylvie,

I never used odt-export before and I can reproduce your problem.
I'm using MS Windows and Emacs 24.1.50 with orgmode 7.8.10.

It looks like, that org-export expects a Windows command line tool 
called 'zip'.
I downloaded the Gzip binary from 
http://gnuwin32.sourceforge.net/packages/gzip.htm.
I opened the zip-file with a graphical unzip-program  (like Winzip or 
7zip or Totalcommander or so).


Then I put only gzip.exe into Windows/system32 directory and renamed it 
to zip.exe


After that M-x org-export-as-odt does not display the zip-Error any 
more, but stops with 'Unable to create odt file (1)' in my case.


So I do not know whether this zip-workaround does not work or if there 
are additional requirements to satisfy.


Regards,
O.



Am 24.06.2012 20:53, schrieb Bastien:


Sylvie is using Windows and she tries to export to ODT (for further
conversion to PDF).

Apparently, the executable "Zip operator" is needed.

Re: [O] Invalid function: with-parsed-tramp-file-name with Perl

[Loris Bennett]

Nick Dokos  writes:

> Loris Bennett  wrote:
>
>> Nick Dokos  writes:
>> 
>> > Loris Bennett  wrote:
>> >
>> >> Hi,
>> >> 
>> >> When I try to run a Perl script remotely via ":dir", I get the following
>> >> error:
>> >> 
>> >> ,-
>> >> | org-babel-local-file-name: Invalid function: with-parsed-tramp-file-name
>> >> `-
>> >> 
>> >> However, using the same remote host I can successfully run both R and
>> >> bash scripts.
>> >> 
>> >> There was a thread couple of years ago where this function cropped up: 
>> >> 
>> >> http://lists.gnu.org/archive/html/emacs-orgmode/2010-09/msg01712.html
>> >> 
>> >> but there seemed to be no real resolution and it occurred with version
>> >> 7.01trans and a bleeding edge emacs 24.  I am using Org 7.8.11 with
>> >> Emacs 23.2.1.
>> >> 
>> >> Any ideas?
>> >> 
>> >
>> > Try adding
>> >
>> > (require 'tramp)
>> >
>> > in your .emacs somewhere (probably before you load org but it should
>> > not be too sensitive). Does that solve it?
>> 
>> No, unfortunately not.  I get the same error.
>
> Maybe it has something to do with the declaration in ob.el then (line 43):
>
> (declare-function with-parsed-tramp-file-name "tramp" (filename var &rest 
> body))
>
> with-parsed-tramp-file-name is a macro, not a function. Can you try commenting
> out that line in ob.el and checking again? Not sure what mayhem will ensue, 
> but
> who knows?

If I comment the line out and compile, I get the warning:

,--
| In end of data:
| ob.el:2487:1:Warning: the function `with-parsed-tramp-file-name' is not known
| to be defined.
`--

but the remote Perl code now runs fine.

Thanks for the help.

Loris

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de