Problem exporting code

Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

I'm giving a talk tomorrow on org-mode and R, and I'm having an exporting
problem that's tripping me up.

Usually when I export code/output sections to HTML, they get CSS classes
like "src-R" for R code, "src-perl" for perl code, "example" for output.
 But now they're all "example".  Has anyone seen this?

Having different classes lets me do stuff like this:
http://article.gmane.org/gmane.emacs.orgmode/46301

Maybe it's the new exporter?  I'm using org-mode 7.9.3d.

I can try downgrading, is there a location for older versions of orgmode?

 -Ken

[-- Attachment #2: Type: text/html, Size: 808 bytes --]

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Unfortunately, downgrading to 7.8.11 didn't change the behavior - all code
sections are still exported to HTML as class "example".

I also see that on one machine, using 7.9.2, I get the desired <pre
class="src src-R"> tag for R code export.  I can't figure out what's making
the difference though.


On Sun, Jan 20, 2013 at 5:44 PM, Ken Williams <kenahoo@gmail.com> wrote:

> I'm giving a talk tomorrow on org-mode and R, and I'm having an exporting
> problem that's tripping me up.
>
> Usually when I export code/output sections to HTML, they get CSS classes
> like "src-R" for R code, "src-perl" for perl code, "example" for output.
>  But now they're all "example".  Has anyone seen this?
>
> Having different classes lets me do stuff like this:
> http://article.gmane.org/gmane.emacs.orgmode/46301
>
> Maybe it's the new exporter?  I'm using org-mode 7.9.3d.
>
> I can try downgrading, is there a location for older versions of orgmode?
>
>  -Ken
>

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

Re: Problem exporting code

[Eric S Fraga]

Ken Williams <kenahoo@gmail.com> writes:

> Unfortunately, downgrading to 7.8.11 didn't change the behavior 
> - all code sections are still exported to HTML as class 
> "example". 
> 
> I also see that on one machine, using 7.9.2, I get the desired 
> <pre class="src src-R"> tag for R code export.  I can't figure 
> out what's making the difference though. 

I'm grasping at straws here, having seldom exported to HTML, but 
have you loaded the languages for babel?

,----[ C-h f org-babel-do-load-languages RET ]
| org-babel-do-load-languages is an autoloaded compiled Lisp function in
| `org.el'.
| 
| (org-babel-do-load-languages SYM VALUE)
| 
| Load the languages defined in `org-babel-load-languages'.
`----

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Sun, Jan 20, 2013 at 9:15 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> Ken Williams <kenahoo@gmail.com> writes:
>
>  Unfortunately, downgrading to 7.8.11 didn't change the behavior - all
>> code sections are still exported to HTML as class "example".
>> I also see that on one machine, using 7.9.2, I get the desired <pre
>> class="src src-R"> tag for R code export.  I can't figure out what's making
>> the difference though.
>>
>
> I'm grasping at straws here, having seldom exported to HTML, but have you
> loaded the languages for babel?
>

Yes, I believe that's set up properly, because I can do "C-c C-c" and it
knows how to run my R sections and return the correct values.  Also, when I
"describe org-babel-load-languages", I see:

org-babel-load-languages is a variable defined in `org.el'.
Its value is ((emacs-lisp . t)
 (sh . t)
 (R . t)
 (perl . t))

I'm grasping at straws too, not knowing my way around the elisp code very
well. =)

 -Ken

[-- Attachment #2: Type: text/html, Size: 1901 bytes --]

Re: Problem exporting code

[John Hendy]

On Sun, Jan 20, 2013 at 10:57 PM, Ken Williams <kenahoo@gmail.com> wrote:
>
> On Sun, Jan 20, 2013 at 9:15 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>>
>> Ken Williams <kenahoo@gmail.com> writes:
>>
>>> Unfortunately, downgrading to 7.8.11 didn't change the behavior - all
>>> code sections are still exported to HTML as class "example".
>>> I also see that on one machine, using 7.9.2, I get the desired <pre
>>> class="src src-R"> tag for R code export.  I can't figure out what's making
>>> the difference though.
>>
>>
>> I'm grasping at straws here, having seldom exported to HTML, but have you
>> loaded the languages for babel?
>
>
> Yes, I believe that's set up properly, because I can do "C-c C-c" and it
> knows how to run my R sections and return the correct values.  Also, when I
> "describe org-babel-load-languages", I see:
>
> org-babel-load-languages is a variable defined in `org.el'.
> Its value is ((emacs-lisp . t)
>  (sh . t)
>  (R . t)
>  (perl . t))
>
> I'm grasping at straws too, not knowing my way around the elisp code very
> well. =)

Just tried myself on a file lying around with embedded R code, and I
get "<pre class="src src-R">" for my src blocks.

Can we back up a bit and have you post a minimal config and sample
file? Perhaps the output of =M-x org-version= as well, just to be sure
on where emacs is pulling org code from? You might have done this; my
apologies if so. Been following the thread from a distance as I didn't
have much experience with html/src code export. Just thought I'd chime
in on things I've been asked to do that usually do help the situation.

With a minimal config (like your load directories and the babel
language definitions above), we can try to replicate a bit better.
Emacs configs get long, so it's really hard to know from user to user
what else might be going on.


Thanks!
John

>
>  -Ken

Re: Problem exporting code

[John Hendy]

On Sun, Jan 20, 2013 at 11:36 PM, John Hendy <jw.hendy@gmail.com> wrote:
> On Sun, Jan 20, 2013 at 10:57 PM, Ken Williams <kenahoo@gmail.com> wrote:
>>
>> On Sun, Jan 20, 2013 at 9:15 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>>>
>>> Ken Williams <kenahoo@gmail.com> writes:
>>>
>>>> Unfortunately, downgrading to 7.8.11 didn't change the behavior - all
>>>> code sections are still exported to HTML as class "example".
>>>> I also see that on one machine, using 7.9.2, I get the desired <pre
>>>> class="src src-R"> tag for R code export.  I can't figure out what's making
>>>> the difference though.
>>>
>>>
>>> I'm grasping at straws here, having seldom exported to HTML, but have you
>>> loaded the languages for babel?
>>
>>
>> Yes, I believe that's set up properly, because I can do "C-c C-c" and it
>> knows how to run my R sections and return the correct values.  Also, when I
>> "describe org-babel-load-languages", I see:
>>
>> org-babel-load-languages is a variable defined in `org.el'.
>> Its value is ((emacs-lisp . t)
>>  (sh . t)
>>  (R . t)
>>  (perl . t))
>>
>> I'm grasping at straws too, not knowing my way around the elisp code very
>> well. =)
>
> Just tried myself on a file lying around with embedded R code, and I
> get "<pre class="src src-R">" for my src blocks.
>
> Can we back up a bit and have you post a minimal config and sample
> file? Perhaps the output of =M-x org-version= as well, just to be sure
> on where emacs is pulling org code from? You might have done this; my
> apologies if so. Been following the thread from a distance as I didn't
> have much experience with html/src code export. Just thought I'd chime
> in on things I've been asked to do that usually do help the situation.
>
> With a minimal config (like your load directories and the babel
> language definitions above), we can try to replicate a bit better.
> Emacs configs get long, so it's really hard to know from user to user
> what else might be going on.
>

By the way, I'm on =Org-mode version 7.9.3d
(release_7.9.3d-830-g780b45 @ /home/jwhendy/.elisp/org.git/lisp/)= and
it works for me, so I don't think it's new behavior in 7.9.3. Just
wanted to add that; at least it may save you from trying to hunt down
a magical version that doesn't have the issue :)


John

>
> Thanks!
> John
>
>>
>>  -Ken

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

On Sun, Jan 20, 2013 at 10:57 PM, Ken Williams <kenahoo@gmail.com> wrote:

>
> I'm grasping at straws too, not knowing my way around the elisp code very
> well. =)
>

It looks like the function controlling this behavior is
`org-export-format-source-code-or-example`, in org-exp.el:

                    (if (string-match "<pre\\([^>]*\\)>\n*" rtn)
                        (setq rtn
                              (concat
                               (if caption
                                   (concat
                                    "<div class=\"org-src-container\">"
                                    (format
                                     "<label
class=\"org-src-name\">%s</label>"
                                     caption))
                                 "")
                               (replace-match
                                (format "<pre class=\"src src-%s\">\n" lang)
                                t t rtn)
                               (if caption "</div>" "")))))

So the <pre> tag gets inserted first, then later gets replaced by <pre
class="src src-R"> ?

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 4888 bytes --]

Thanks John.  Here's a small org file:

>>>>>>>>>>>>>>>>>>>>>
#+TITLE: Sample Doc
#+AUTHOR:    Ken Williams
#+EMAIL:     kenahoo@gmail.com
#+DATE:      2013-01-21
#+PROPERTY: results output
#+PROPERTY: exports both
#+LATEX_HEADER: \usepackage{amsmath}


#+begin_src R
5+5
#+end_src

#+RESULTS:
: [1] 10
<<<<<<<<<<<<<<<<<<<<<

The code gets exported to:

>>>>>>>>>>>>>>>>>>>>>
<pre class="example">
5+5
</pre>

<pre class="example">
[1] 10
</pre>
<<<<<<<<<<<<<<<<<<<<<

And here's my config:

>>>>>>>>>>>>>>>>>>>>>
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(current-language-environment "UTF-8")
 '(global-font-lock-mode t nil (font-lock))
 '(inhibit-splash-screen t)
 '(org-alphabetical-lists t)
 '(org-export-html-postamble nil)
 '(org-export-html-preamble-format (quote (("en" "<p
class=\"author\">Author: <a href=\"mailto:%e\">%a</a></p>
<p class=\"date\">Date: %d</p>
"))))
 '(org-src-preserve-indentation t)
 '(show-paren-mode t)
 '(tool-bar-mode nil)
 '(transient-mark-mode t)
 '(user-mail-address "kenahoo@gmail.com"))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(diff-added-face ((t (:foreground "green"))))
 '(diff-changed-face ((t (:foreground "blue" :slant italic :weight bold))))
 '(diff-removed-face ((t (:foreground "red"))))
 )

(setq
   backup-by-copying t      ; don't clobber symlinks
   backup-directory-alist
    '(("." . "/tmp/")))

(add-to-list 'load-path "~/share/emacs/site-lisp/org" load-path)
(require 'org-install)
(add-to-list 'auto-mode-alist '("\\.org$" . org-mode))

(global-set-key (kbd "M--") 'ess-smart-underscore)

(org-babel-do-load-languages
 'org-babel-load-languages
 '((emacs-lisp . t)
   (sh . t)
   (R . t)
   (perl . t)))

(setq org-export-html-style
"<style type=\"text/css\">
    <!--/*--><![CDATA[/*><!--*/
      .src             { background-color: #F5FFF5; position: relative;
overflow: visible; margin-right: auto; }
      .src:before      { position: absolute; top: -15px; background:
#ffffff; padding: 1px; border: 1px solid #000000; font-size: small; }
      .src-sh:before   { content: 'sh'; }
      .src-bash:before { content: 'sh'; }
      .src-R:before    { content: 'R'; }
      .src-perl:before { content: 'Perl'; }
      .src-java:before { content: 'Java'; }
      .src-sql:before  { content: 'SQL'; }
      .example         { background-color: #FFF5F5; }
    /*]]>*/-->
</style>")

(setq org-export-babel-evaluate nil)
(setq org-confirm-babel-evaluate nil)
<<<<<<<<<<<<<<<<<<<<<

 -Ken


On Sun, Jan 20, 2013 at 11:36 PM, John Hendy <jw.hendy@gmail.com> wrote:

> On Sun, Jan 20, 2013 at 10:57 PM, Ken Williams <kenahoo@gmail.com> wrote:
> >
> > On Sun, Jan 20, 2013 at 9:15 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> >>
> >> Ken Williams <kenahoo@gmail.com> writes:
> >>
> >>> Unfortunately, downgrading to 7.8.11 didn't change the behavior - all
> >>> code sections are still exported to HTML as class "example".
> >>> I also see that on one machine, using 7.9.2, I get the desired <pre
> >>> class="src src-R"> tag for R code export.  I can't figure out what's
> making
> >>> the difference though.
> >>
> >>
> >> I'm grasping at straws here, having seldom exported to HTML, but have
> you
> >> loaded the languages for babel?
> >
> >
> > Yes, I believe that's set up properly, because I can do "C-c C-c" and it
> > knows how to run my R sections and return the correct values.  Also,
> when I
> > "describe org-babel-load-languages", I see:
> >
> > org-babel-load-languages is a variable defined in `org.el'.
> > Its value is ((emacs-lisp . t)
> >  (sh . t)
> >  (R . t)
> >  (perl . t))
> >
> > I'm grasping at straws too, not knowing my way around the elisp code very
> > well. =)
>
> Just tried myself on a file lying around with embedded R code, and I
> get "<pre class="src src-R">" for my src blocks.
>
> Can we back up a bit and have you post a minimal config and sample
> file? Perhaps the output of =M-x org-version= as well, just to be sure
> on where emacs is pulling org code from? You might have done this; my
> apologies if so. Been following the thread from a distance as I didn't
> have much experience with html/src code export. Just thought I'd chime
> in on things I've been asked to do that usually do help the situation.
>
> With a minimal config (like your load directories and the babel
> language definitions above), we can try to replicate a bit better.
> Emacs configs get long, so it's really hard to know from user to user
> what else might be going on.
>
>
> Thanks!
> John
>
> >
> >  -Ken
>

[-- Attachment #2: Type: text/html, Size: 9351 bytes --]

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

Argh, forgot my platform details - I'm using:

Either org-mode 7.9.3d or 7.8.11 (same results)
Aquamacs 2.4 (but I saw the same result using Emacs on a Linux box)
Aquamacs is based on GNU Emacs 23.3.50.1.

 -Ken


On Sun, Jan 20, 2013 at 11:36 PM, John Hendy <jw.hendy@gmail.com> wrote:

> On Sun, Jan 20, 2013 at 10:57 PM, Ken Williams <kenahoo@gmail.com> wrote:
> >
> > On Sun, Jan 20, 2013 at 9:15 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> >>
> >> Ken Williams <kenahoo@gmail.com> writes:
> >>
> >>> Unfortunately, downgrading to 7.8.11 didn't change the behavior - all
> >>> code sections are still exported to HTML as class "example".
> >>> I also see that on one machine, using 7.9.2, I get the desired <pre
> >>> class="src src-R"> tag for R code export.  I can't figure out what's
> making
> >>> the difference though.
> >>
> >>
> >> I'm grasping at straws here, having seldom exported to HTML, but have
> you
> >> loaded the languages for babel?
> >
> >
> > Yes, I believe that's set up properly, because I can do "C-c C-c" and it
> > knows how to run my R sections and return the correct values.  Also,
> when I
> > "describe org-babel-load-languages", I see:
> >
> > org-babel-load-languages is a variable defined in `org.el'.
> > Its value is ((emacs-lisp . t)
> >  (sh . t)
> >  (R . t)
> >  (perl . t))
> >
> > I'm grasping at straws too, not knowing my way around the elisp code very
> > well. =)
>
> Just tried myself on a file lying around with embedded R code, and I
> get "<pre class="src src-R">" for my src blocks.
>
> Can we back up a bit and have you post a minimal config and sample
> file? Perhaps the output of =M-x org-version= as well, just to be sure
> on where emacs is pulling org code from? You might have done this; my
> apologies if so. Been following the thread from a distance as I didn't
> have much experience with html/src code export. Just thought I'd chime
> in on things I've been asked to do that usually do help the situation.
>
> With a minimal config (like your load directories and the babel
> language definitions above), we can try to replicate a bit better.
> Emacs configs get long, so it's really hard to know from user to user
> what else might be going on.
>
>
> Thanks!
> John
>
> >
> >  -Ken
>

[-- Attachment #2: Type: text/html, Size: 3249 bytes --]

Re: Problem exporting code

[Eric S Fraga]

Ken Williams <kenahoo@gmail.com> writes:

> Thanks John.  Here's a small org file:

Data point: this works just fine for me with both old and new
exporters.  And I don't even have R installed on this particular system
(hadn't realised until now ;-).

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

I believe I've figured it out.  I must have an old version of 'htmlize'
installed somewhere, I 'edebug' traced through the code and fell through to
this part:

      (when lang
(if (featurep 'xemacs)
    (require 'htmlize)
  (require 'htmlize nil t))
(when (not (fboundp 'htmlize-region-for-paste))
  ;; we do not have htmlize.el, or an old version of it
  (setq lang nil)
  (message
   "htmlize.el 1.34 or later is needed for source code formatting")))

I couldn't manage to set up my load-path to load htmlize 'properly' (is
htmlize not able to be loaded via 'load-path' and 'require'?), but after
downloading htmlize 1.43 and adding the following to my .emacs, I seem to
be in business again:

    (load-file "~/share/emacs/site-lisp/htmlize/htmlize.el")

Thanks everyone.



On Mon, Jan 21, 2013 at 1:39 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> Ken Williams <kenahoo@gmail.com> writes:
>
> > Thanks John.  Here's a small org file:
>
> Data point: this works just fine for me with both old and new
> exporters.  And I don't even have R installed on this particular system
> (hadn't realised until now ;-).
>
> --
> : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
> : in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87
>
>

[-- Attachment #2: Type: text/html, Size: 2456 bytes --]

Re: Problem exporting code

[John Hendy]

On Mon, Jan 21, 2013 at 9:58 AM, Ken Williams <kenahoo@gmail.com> wrote:
> I believe I've figured it out.  I must have an old version of 'htmlize'
> installed somewhere, I 'edebug' traced through the code and fell through to
> this part:
>
>      (when lang
> (if (featurep 'xemacs)
>    (require 'htmlize)
>  (require 'htmlize nil t))
> (when (not (fboundp 'htmlize-region-for-paste))
>  ;; we do not have htmlize.el, or an old version of it
>  (setq lang nil)
>  (message
>   "htmlize.el 1.34 or later is needed for source code formatting")))
>
> I couldn't manage to set up my load-path to load htmlize 'properly' (is
> htmlize not able to be loaded via 'load-path' and 'require'?), but after
> downloading htmlize 1.43 and adding the following to my .emacs, I seem to be
> in business again:

Awesome that you got it going. Do you still have =(require
'org-install)= in your .emacs? ETA: just checked and you do. I checked
as I had an issue with emacs not using the git version of org because
I stupidly had =(require 'org-install)= before my load paths!

The only thing that stuck out to me was this: =(add-to-list 'load-path
"~/share/emacs/site-lisp/org" load-path)=

Is that the proper syntax? Mine (and just checked the org manual)
features this: =(add-to-list 'load-path "~/path/to/orgdir/lisp")=.

I know nil about elisp (see what I did there?), but does that extra
"load-path" at the end of the argument do anything?


Good luck,
John

>
>     (load-file "~/share/emacs/site-lisp/htmlize/htmlize.el")
>
> Thanks everyone.
>
>
>
> On Mon, Jan 21, 2013 at 1:39 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>>
>> Ken Williams <kenahoo@gmail.com> writes:
>>
>> > Thanks John.  Here's a small org file:
>>
>> Data point: this works just fine for me with both old and new
>> exporters.  And I don't even have R installed on this particular system
>> (hadn't realised until now ;-).
>>
>> --
>> : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
>> : in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87
>>
>

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Mon, Jan 21, 2013 at 10:48 AM, John Hendy <jw.hendy@gmail.com> wrote:

>
> Awesome that you got it going. Do you still have =(require
> 'org-install)= in your .emacs? ETA: just checked and you do. I checked
> as I had an issue with emacs not using the git version of org because
> I stupidly had =(require 'org-install)= before my load paths!
>

I do have =(require 'org)= in my .emacs.  I never really know whether I'm
supposed to do 'org or 'org-install, but this seems to get the ball rolling!


>
> The only thing that stuck out to me was this: =(add-to-list 'load-path
> "~/share/emacs/site-lisp/org" load-path)=
>

D'oh!  I changed that from a ham-fisted (setq ...) to an (add-to-list ...)
call, and I forgot to take out the final argument.  Thanks for spotting it.

 -Ken

[-- Attachment #2: Type: text/html, Size: 1399 bytes --]

Re: Problem exporting code

[John Hendy]

On Mon, Jan 21, 2013 at 11:45 AM, Ken Williams <kenahoo@gmail.com> wrote:
>
> On Mon, Jan 21, 2013 at 10:48 AM, John Hendy <jw.hendy@gmail.com> wrote:
>>
>>
>> Awesome that you got it going. Do you still have =(require
>> 'org-install)= in your .emacs? ETA: just checked and you do. I checked
>> as I had an issue with emacs not using the git version of org because
>> I stupidly had =(require 'org-install)= before my load paths!
>
>
> I do have =(require 'org)= in my .emacs.  I never really know whether I'm
> supposed to do 'org or 'org-install, but this seems to get the ball rolling!

I don't think this is needed anymore, and in this thread I thought it
might even cause potential problems, but I could be wrong!
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00030.html

>
>>
>>
>> The only thing that stuck out to me was this: =(add-to-list 'load-path
>> "~/share/emacs/site-lisp/org" load-path)=
>
> D'oh!  I changed that from a ham-fisted (setq ...) to an (add-to-list ...)
> call, and I forgot to take out the final argument.  Thanks for spotting it.
>

It'd be interesting to know how htmlize didn't get updated. Is that
provided via org or your emacs variant? Or it'd also be interesting to
know if there were multiple versions and the wrong one had been pulled
in. Obviously, the main point is that you've got things doing what you
want... but as a sort of meticulous engineering sort, it'd still be
nice to get closure for any future mailing list hunters :)


Best regards,
John

>  -Ken
>

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On Mon, Jan 21, 2013 at 4:16 PM, John Hendy <jw.hendy@gmail.com> wrote:

> On Mon, Jan 21, 2013 at 11:45 AM, Ken Williams <kenahoo@gmail.com> wrote:
> >
> > On Mon, Jan 21, 2013 at 10:48 AM, John Hendy <jw.hendy@gmail.com> wrote:
> >>
> >>
> >> Awesome that you got it going. Do you still have =(require
> >> 'org-install)= in your .emacs? ETA: just checked and you do. I checked
> >> as I had an issue with emacs not using the git version of org because
> >> I stupidly had =(require 'org-install)= before my load paths!
> >
> >
> > I do have =(require 'org)= in my .emacs.  I never really know whether I'm
> > supposed to do 'org or 'org-install, but this seems to get the ball
> rolling!
>
> I don't think this is needed anymore, and in this thread I thought it
> might even cause potential problems, but I could be wrong!
> - http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00030.html
>
> >
> >>
> >>
> >> The only thing that stuck out to me was this: =(add-to-list 'load-path
> >> "~/share/emacs/site-lisp/org" load-path)=
> >
> > D'oh!  I changed that from a ham-fisted (setq ...) to an (add-to-list
> ...)
> > call, and I forgot to take out the final argument.  Thanks for spotting
> it.
> >
>
> It'd be interesting to know how htmlize didn't get updated. Is that
> provided via org or your emacs variant?


In my case, version 1.23a was provided by Aquamacs:

/Applications/Writing/Aquamacs.app/Contents/Resources/lisp/aquamacs/htmlize.el

It's been a while since I've used this machine, so I'd updated to the
latest Aquamacs, but it looks like Aquamacs itself hasn't seen a release in
over a year.  That's probably part of the problem.  I wonder if there's
something else filling the niche these days?

 -Ken

[-- Attachment #2: Type: text/html, Size: 2798 bytes --]

Re: Problem exporting code

[Eric S Fraga]

Ken Williams <kenahoo@gmail.com> writes:

> I believe I've figured it out.  I must have an old version of 'htmlize'
> installed somewhere, I 'edebug' traced through the code and fell through to
> this part:

Glad you sorted it!

> I couldn't manage to set up my load-path to load htmlize 'properly' (is
> htmlize not able to be loaded via 'load-path' and 'require'?), but after
> downloading htmlize 1.43 and adding the following to my .emacs, I seem to
> be in business again:
>
>     (load-file "~/share/emacs/site-lisp/htmlize/htmlize.el")
>
> Thanks everyone.

But htmlize.el (version 1.43 currently) is distributed within org in the
contrib directory.   It would be more straightforward to add

(add-to-list 'load-path "[PATH TO ORG]/contrib/lisp/")

to your configuration.

This does beg the question of whether components in the main org lisp
directory should depend on items in the contrib directory...  but I will
leave that for another day ;-)

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613

Re: Problem exporting code

[Thomas S. Dye]

Aloha Ken,

Ken Williams <kenahoo@gmail.com> writes:

>
> It's been a while since I've used this machine, so I'd updated to the
> latest Aquamacs, but it looks like Aquamacs itself hasn't seen a release in
> over a year.  That's probably part of the problem.  I wonder if there's
> something else filling the niche these days?
>
>  -Ken

You can get emacs binaries for the Mac here:
http://emacsformacosx.com/

or, you can get emacs-app from macports.

I've used both with good results.

hth,
Tom

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

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Mon, Jan 21, 2013 at 5:02 PM, John Hendy <jw.hendy@gmail.com> wrote:

>
> On Jan 21, 2013 4:51 PM, "Ken Williams" <kenahoo@gmail.com> wrote:
> >
> > It's been a while since I've used this machine, so I'd updated to the
> latest Aquamacs, but it looks like Aquamacs itself hasn't seen a release in
> over a year.  That's probably part of the problem.  I wonder if there's
> something else filling the niche these days?
>
> I've been using this:
> - http://vgoulet.act.ulaval.ca/en/emacs/mac/
>

Ah!  I've been using his Emacs for Windows at work, I didn't notice there
was a Mac one too.  Thanks for the pointer.

 -Ken

[-- Attachment #2: Type: text/html, Size: 1218 bytes --]

Re: Problem exporting code

[Thomas S. Dye]

Ken Williams <kenahoo@gmail.com> writes:

> On Mon, Jan 21, 2013 at 5:02 PM, John Hendy <jw.hendy@gmail.com> wrote:
>
>>
>> On Jan 21, 2013 4:51 PM, "Ken Williams" <kenahoo@gmail.com> wrote:
>> >
>> > It's been a while since I've used this machine, so I'd updated to the
>> latest Aquamacs, but it looks like Aquamacs itself hasn't seen a release in
>> over a year.  That's probably part of the problem.  I wonder if there's
>> something else filling the niche these days?
>>
>> I've been using this:
>> - http://vgoulet.act.ulaval.ca/en/emacs/mac/
>>
>
> Ah!  I've been using his Emacs for Windows at work, I didn't notice there
> was a Mac one too.  Thanks for the pointer.
>

Interesting, this Emacs distribution removed Org a few days ago. I'm not
certain why the distributor refers to this as "a rather drastic
measure." From my perspective as a user, whose interests required using
the git version of Org from the beginning, the Emacs distribution of Org
has been nothing but trouble, leading to perplexing (for me) problems
with mixed installs that I would rather have avoided.

I've enjoyed reading the mailing list for the last two or three years
and in that time can only remember a few times that the Org that ships
with Emacs was recommended. Typically, advice on the list recommends
using the git version, instead.

Installation of the git version is *easy* now, even for someone with my
limited skills. I didn't have any luck with the ELPA version when it
first came out, but the ELPA system works great and it seems like an
ideal channel to distribute Org. So, even a user like me has very little
difficulty using a non-Emacs version of Org.

I'm sure there are reasons for wanting Org to be distributed with Emacs.
Would it be OK for me to ask on the list what they are?

All the best,
Tom

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

Re: Problem exporting code

[Bastien]

Hi Thomas and all,

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

> Ken Williams <kenahoo@gmail.com> writes:
>
>>> I've been using this:
>>> - http://vgoulet.act.ulaval.ca/en/emacs/mac/

Thanks for the pointer, I was not aware of this distribution.

> Interesting, this Emacs distribution removed Org a few days ago. 

This is a wrong move.  Also, the NEWS entry in 
http://vgoulet.act.ulaval.ca/pub/emacs/NEWS-mac suggests that Org's
maintainers are recommending to install Org as an external package,
which is a false statement too.

I just wrote to Vincent asking for more details and offering to help
to ease his life as a maintainer for this Emacs distribution.

> I'm not
> certain why the distributor refers to this as "a rather drastic
> measure." From my perspective as a user, whose interests required using
> the git version of Org from the beginning, the Emacs distribution of Org
> has been nothing but trouble, leading to perplexing (for me) problems
> with mixed installs that I would rather have avoided.

The distribution of Org as a built-in package in Emacs is *not* the
problem.

Installing Org through git or through .tar.gz/.zip on top of the Emacs
distribution does not create problems if you follow the instructions
in the manual -- I made a special effort to simplify them.

The real problem is the ELPA distribution, and this problem is due to
the package system not being clever enough to handle both a pre-built
and a add-on package in all configs.

So I'm seriously questioning the value of having Org as an ELPA
package and I'm thinking of removing this possibility until Emacs
package install is fixed (Achim is working on this, but it looks 
like the change will not be in Emacs anytime soon.)

> I've enjoyed reading the mailing list for the last two or three years
> and in that time can only remember a few times that the Org that ships
> with Emacs was recommended. Typically, advice on the list recommends
> using the git version, instead.

The pre-built version is not recommended because it does not need to
be -- it is pre-built :)  When people write to the list, I recommend
them to use the latest .tar.gz/.zip or the Git version because this
version often fix the bug they are suffering from.

> Installation of the git version is *easy* now, even for someone with my
> limited skills. 

Yes, and installing the .tar.gz/.zip file is even easier!

> I didn't have any luck with the ELPA version when it
> first came out, but the ELPA system works great and it seems like an
> ideal channel to distribute Org. So, even a user like me has very little
> difficulty using a non-Emacs version of Org.

There are many things I don't like with the current packaging system:

- The message when downloading is confusing ("package contacting...").

- AFAIK users don't have the choice but to have the .el files
  compiled, which will make backtraces unreadable for bug reporters.

Also, if Org is not in Emacs anymore, users will not be able to add
(org-agenda ...) in their .emacs.el -- they will have to initialize
the package system in .emacs.el before they can call Org functions.
*We* will have to tell them... 

> I'm sure there are reasons for wanting Org to be distributed with Emacs.
> Would it be OK for me to ask on the list what they are?

I don't have figures, but I think Emacs is the first "channel" through
wich people happen to discover Org.  It is advertized on the Emacs
homepage, it is in the Emacs manuals, etc.

Also, I consider outline.el to be completely unusable, and Org is
first an enhanced version of it, which Emacs strongly needs.  I plan
to push so that files in Emacs use org.el when they use outline.el.

I understand this might be tempting to remove Org from Emacs if it
causes installation problems... tempting for long-time power users who
know how to install it, tempting for maintainers who don't want to
deal with the (heavy) burden of sync'ing with Emacs, and tempting for
Emacs maintainers who don't want such a big module in the codebase...
but this would be a wrong move.  The right thing to do is to simplify
Org so that requiring org.el does not take too long, and so that
installing it on top of a pre-built install does not create problems.

If removing the ELPA channel is the way to go temporarily, let's 
think about it seriously!

All best,

-- 
 Bastien

Re: Problem exporting code

[Thorsten Jolitz]

Bastien <bzg@altern.org> writes:

Hi Bastien, 

your post touches two topics that I'm currently dealing with, so here
are two questions with regards to this topics:

(1)
>> I'm not certain why the distributor refers to this as "a rather
>> drastic measure." From my perspective as a user, whose interests
>> required using the git version of Org from the beginning, the Emacs
>> distribution of Org has been nothing but trouble, leading to
>> perplexing (for me) problems with mixed installs that I would rather
>> have avoided.
>
> The distribution of Org as a built-in package in Emacs is *not* the
> problem.
>
> Installing Org through git or through .tar.gz/.zip on top of the Emacs
> distribution does not create problems if you follow the instructions
> in the manual -- I made a special effort to simplify them.

I recently experienced some casual trouble when updating Org-mode from
Git (I simply updated at a moment, when actual org.el wouldn't load due to a
bug that was to be fixed soon fixed soon. Here is the related thread on
the mailing list:

[[gnus:nntp%2Bnews.gmane.org:gmane.emacs.orgmode#87ehhmnqu6.fsf@googlemail.com][Email from Thorsten Jolitz: Re:  {BUG} `org-load-noerror-m]]

In this thread, I was told that I'm causing 'a future train wreck' with
my habit to simply trash the org folder from the Emacs installation and
replace it with a symlink to the git version in my home dir (I had
enough trouble with mixed installs, and this seems to avoid them -
having only the git version, no Elpa and no Emacs version). 

Now I was told there will be troubles with the autoloads, and I would
like to understand better what the possible implications are. I do 'make
autoloads' in the git version of org, so there is a loaddefs.el. There
is of course another loaddefs.el in the Emacs directory that is not
updated when I replace the Emacs org folder with a symlink to the
(slightly different) git version.

Is there really 'big trouble' possible due to this? Should I run 'make
autoloads' in the Emacs installation directory again?

(2)

> Also, I consider outline.el to be completely unusable, and Org is
> first an enhanced version of it, which Emacs strongly needs.  I plan
> to push so that files in Emacs use org.el when they use outline.el.

When I started with Emacs, I had one .emacs init-file that became more
and more chaotic over time (and a real pain for navigation and
maintainment). Then I started to use a multi-file set-up, first Elisp
files, then using .org files via the starter-kit. 

Now I know about M-x occur and recently discovered that
outline-minor-mode enables me to define my own outline-regexps in an .el
file, so I'm back to the start - using one big /.emacs.d/init.el, but
this time with all the outline functionality. 

Here is a short excerpt from the init.el, showing that my
outline-headings just look like outcommented org-headings:

,----------------------------------------------------
| ;; * Recovery from Problems
| 
| ;; ** Debugging
| 
| (when section-debugging (message "99 Debugging...")
| 
| ...
| 
| (message "99 Debugging... Done"))
| 
| ;; Local Variables:
| ;; coding: utf-8
| ;; mode: emacs-lisp
| ;; eval: (outline-minor-mode)
| ...
| ;; outline-regexp: ";; [*]+ "
| ;; End:
`----------------------------------------------------

Except for the extraordinary weird key-bindings of outline-minor-mode
(e.g. C-c @ C-n), that I still did not manage to override (with the
usual Org-mode bindings), I'm very satisfied with this set-up, it gives
me the best of both worlds (full outline functionality and the very
simple and direct approach of having just one init.el).

Why do you consider outline(-minor-mode) as completely unusable? And how
would you replace it in my use case with org(-struct?)? I'm asking just
out of curiosity, and to learn a bit more, there are no urgent problems
to be solved on my side here. 

-- 
cheers,
Thorsten

Re: Problem exporting code

[Bastien]

Hi Thorsten,

Let's assume that you don't use ELPA for installing Org.

When installing a recent Org, either from an archive or from a git
clone, you only need to add the correct load-path, as described in
the manual -- for example:

  (add-to-list 'load-path "~/path/to/orgdir/lisp")

> In this thread, I was told that I'm causing 'a future train wreck' with
> my habit to simply trash the org folder from the Emacs installation and
> replace it with a symlink to the git version in my home dir (I had
> enough trouble with mixed installs, and this seems to avoid them -
> having only the git version, no Elpa and no Emacs version). 

No train will die in your experiments.  :)

But removing Emacs Org is not necessary.

> Now I was told there will be troubles with the autoloads, and I would
> like to understand better what the possible implications are. I do 'make
> autoloads' in the git version of org, so there is a loaddefs.el. There
> is of course another loaddefs.el in the Emacs directory that is not
> updated when I replace the Emacs org folder with a symlink to the
> (slightly different) git version.

The implication of removing Emacs Org is that some Org functions will
still be autoloaded from Emacs loaddefs.el while the autoloads will
not point to the correct, existing, directory.

> Is there really 'big trouble' possible due to this? Should I run 'make
> autoloads' in the Emacs installation directory again?

No.  You should just install Org as an archive or as a git clone, 
and add the correct load-path.  If you forget to add the load-path,
you will simply be using Org from Emacs, that's all.

>> Also, I consider outline.el to be completely unusable, and Org is
>> first an enhanced version of it, which Emacs strongly needs.  I plan
>> to push so that files in Emacs use org.el when they use outline.el.
>
> When I started with Emacs, I had one .emacs init-file that became more
> and more chaotic over time (and a real pain for navigation and
> maintainment). Then I started to use a multi-file set-up, first Elisp
> files, then using .org files via the starter-kit. 
>
> Now I know about M-x occur and recently discovered that
> outline-minor-mode enables me to define my own outline-regexps in an .el
> file, so I'm back to the start - using one big /.emacs.d/init.el, but
> this time with all the outline functionality. 
>
> Here is a short excerpt from the init.el, showing that my
> outline-headings just look like outcommented org-headings:
>
> ,----------------------------------------------------
> | ;; * Recovery from Problems
> | 
> | ;; ** Debugging
> | 
> | (when section-debugging (message "99 Debugging...")
> | 
> | ...
> | 
> | (message "99 Debugging... Done"))
> | 
> | ;; Local Variables:
> | ;; coding: utf-8
> | ;; mode: emacs-lisp
> | ;; eval: (outline-minor-mode)
> | ...
> | ;; outline-regexp: ";; [*]+ "
> | ;; End:
> `----------------------------------------------------
>
> Except for the extraordinary weird key-bindings of outline-minor-mode
> (e.g. C-c @ C-n), that I still did not manage to override (with the
> usual Org-mode bindings), I'm very satisfied with this set-up, it gives
> me the best of both worlds (full outline functionality and the very
> simple and direct approach of having just one init.el).

I simply use this:

(add-hook 'emacs-lisp-mode-hook 'orgstruct-mode)
(global-set-key (kbd "C-M-]") (lambda () (interactive) (org-cycle t)))
(global-set-key (kbd "M-]") (lambda ()
                              (interactive)
                              (ignore-errors
                                 (end-of-defun)
                                 (beginning-of-defun))
                              (org-cycle)))

C-M-] and M-] fold the whole buffer or the current defun.

> Why do you consider outline(-minor-mode) as completely unusable? 

Because of the keybindings.

> And how
> would you replace it in my use case with org(-struct?)? 

See above.

> I'm asking just
> out of curiosity, and to learn a bit more, there are no urgent problems
> to be solved on my side here. 

You're welcome!

-- 
 Bastien

Re: Problem exporting code

[Thorsten Jolitz]

Bastien <bzg@altern.org> writes:

Hi Bastien,

>> I'm asking just out of curiosity, and to learn a bit more, there are
>> no urgent problems to be solved on my side here.
>
> You're welcome!

Thanks for the answer, so there is not really a fundamental problem with
outline-minor-mode nor is it difficult to replace it with org-struct. 

-- 
cheers,
Thorsten

Re: Problem exporting code

[Ken Williams]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Tue, Jan 22, 2013 at 1:49 AM, Bastien <bzg@altern.org> wrote:

> Hi Thomas and all,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
> > Ken Williams <kenahoo@gmail.com> writes:
> >
> >>> I've been using this:
> >>> - http://vgoulet.act.ulaval.ca/en/emacs/mac/
>
> Thanks for the pointer, I was not aware of this distribution.
>
> > Interesting, this Emacs distribution removed Org a few days ago.
>
> This is a wrong move.  Also, the NEWS entry in
> http://vgoulet.act.ulaval.ca/pub/emacs/NEWS-mac suggests that Org's
> maintainers are recommending to install Org as an external package,
> which is a false statement too.
>
> I just wrote to Vincent asking for more details and offering to help
> to ease his life as a maintainer for this Emacs distribution.
>

I also wrote to him and suggested he remove the (require 'org-install)
statement from his default.el, because it was causing warnings for people
who upgrade org. Perhaps it would be better to change it to a conditional
on the version number?

-Ken

[-- Attachment #2: Type: text/html, Size: 2077 bytes --]

Re: Problem exporting code

[Bastien]

Hi Ken,

Ken Williams <kenahoo@gmail.com> writes:

> I also wrote to him and suggested he remove the (require
> 'org-install) statement from his default.el, because it was causing
> warnings for people who upgrade org. 

Indeed.

I've removed the warning from the maint/master branches, 
the file will be silently loaded if people still have
(require 'org-install) in their config.

> Perhaps it would be better to change it to a conditional on the
> version number?

Ideally yes, but relying on version numbers supposes that
the distribution correctly have an org-version.el file.

Since I don't know how Vincent package Org in this distro,
it's not safe to rely on this.

I'm waiting for his answer and report progress, if any.

-- 
 Bastien

Re: Problem exporting code

[Achim Gratz]

Thomas S. Dye writes:
> Interesting, this Emacs distribution removed Org a few days ago. I'm not
> certain why the distributor refers to this as "a rather drastic
> measure." From my perspective as a user, whose interests required using
> the git version of Org from the beginning, the Emacs distribution of Org
> has been nothing but trouble, leading to perplexing (for me) problems
> with mixed installs that I would rather have avoided.

That's not an entirely fair thing to say.  Using an Emacs with a built-in
Org version just makes some problems more prominent that maybe you got
away with in the past.

> Installation of the git version is *easy* now, even for someone with my
> limited skills. I didn't have any luck with the ELPA version when it
> first came out, but the ELPA system works great and it seems like an
> ideal channel to distribute Org. So, even a user like me has very little
> difficulty using a non-Emacs version of Org.

Package manager, ELPA and the way it interacts with Emacs' built-in
packages certainly needs some more work.  Right now things might be a
little more rough than everybody would like.


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: Problem exporting code

[Achim Gratz]

Bastien writes:
> So I'm seriously questioning the value of having Org as an ELPA
> package and I'm thinking of removing this possibility until Emacs
> package install is fixed (Achim is working on this, but it looks 
> like the change will not be in Emacs anytime soon.)

I've to admit that I've had that thought too, but it seems that doing
this would perhaps even lower the attention that Emacs' maintainers give
to that problem.  Until they admit any change into Emacs we could still
work around with advising require and salvage the ELPA users (I still
think we should do it anyway since a number of users will keep using
older Emacs versions).  Yes, it is a hairy hack.


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

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Problem exporting code

[Thomas S. Dye]

Achim Gratz <Stromeko@nexgo.de> writes:

> Thomas S. Dye writes:
>> Interesting, this Emacs distribution removed Org a few days ago. I'm not
>> certain why the distributor refers to this as "a rather drastic
>> measure." From my perspective as a user, whose interests required using
>> the git version of Org from the beginning, the Emacs distribution of Org
>> has been nothing but trouble, leading to perplexing (for me) problems
>> with mixed installs that I would rather have avoided.
>
> That's not an entirely fair thing to say.  Using an Emacs with a built-in
> Org version just makes some problems more prominent that maybe you got
> away with in the past.

Apologies if I was unfair. I just don't know (perhaps out of ignorance)
how the Org that ships with Emacs has been a benefit to me.

I think you and I have different definitions of "problem". From my
user's perspective, something I "get away with," i.e., that doesn't have
an effect on my work and productivity, isn't a problem.

BTW, it was your build system that helped me recognize I had a mixed
install, so I could finally squash some bugs that had pestered and
perplexed me for a long time. What a relief that was!

All the best,
Tom

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

Re: Problem exporting code

[Thorsten Jolitz]

Bastien <bzg@altern.org> writes:

Hi Bastien,

>> Why do you consider outline(-minor-mode) as completely unusable? 
>
> Because of the keybindings.

I found a really nice alternative keymap here: 
http://emacswiki.org/emacs/OutlineMinorMode

 ,----------------------------------------------------------------------------------------------
 | ; Outline-minor-mode key map
 | (define-prefix-command 'cm-map nil "Outline-")
 | ; HIDE
 | (define-key cm-map "q" 'hide-sublevels)    ; Hide everything but the top-level headings
 | (define-key cm-map "t" 'hide-body)         ; Hide everything but headings (all body lines)
 | (define-key cm-map "o" 'hide-other)        ; Hide other branches
 | (define-key cm-map "c" 'hide-entry)        ; Hide this entry's body
 | (define-key cm-map "l" 'hide-leaves)       ; Hide body lines in this entry and sub-entries
 | (define-key cm-map "d" 'hide-subtree)      ; Hide everything in this entry and sub-entries
 | ; SHOW
 | (define-key cm-map "a" 'show-all)          ; Show (expand) everything
 | (define-key cm-map "e" 'show-entry)        ; Show this heading's body
 | (define-key cm-map "i" 'show-children)     ; Show this heading's immediate child sub-headings
 | (define-key cm-map "k" 'show-branches)     ; Show all sub-headings under this heading
 | (define-key cm-map "s" 'show-subtree)      ; Show (expand) everything in this heading & below
 | ; MOVE
 | (define-key cm-map "u" 'outline-up-heading)                ; Up
 | (define-key cm-map "n" 'outline-next-visible-heading)      ; Next
 | (define-key cm-map "p" 'outline-previous-visible-heading)  ; Previous
 | (define-key cm-map "f" 'outline-forward-same-level)        ; Forward - same level
 | (define-key cm-map "b" 'outline-backward-same-level)       ; Backward - same level
 | (global-set-key "\M-o" cm-map)
 `----------------------------------------------------------------------------------------------

-- 
cheers,
Thorsten

Re: Problem exporting code

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> So I'm seriously questioning the value of having Org as an ELPA
>> package and I'm thinking of removing this possibility until Emacs
>> package install is fixed (Achim is working on this, but it looks 
>> like the change will not be in Emacs anytime soon.)
>
> I've to admit that I've had that thought too, but it seems that doing
> this would perhaps even lower the attention that Emacs' maintainers give
> to that problem.  

This is using Org users as hostages, I don't want to do this.

> Until they admit any change into Emacs we could still
> work around with advising require and salvage the ELPA users (I still
> think we should do it anyway since a number of users will keep using
> older Emacs versions).  Yes, it is a hairy hack.

It is :)  We should remove advices, not add other ones, especially if
the hack hides a bigger problem for Emacs.

I will ping the community at large to have a better idea on how such a
change would affect the community.

-- 
 Bastien

Re: Problem exporting code

[Bastien]

Thorsten Jolitz <tjolitz@googlemail.com> writes:

> I found a really nice alternative keymap here: 
> http://emacswiki.org/emacs/OutlineMinorMode

Thanks -- but that's quite bigger than just using Org ;)

-- 
 Bastien

Re: Problem exporting code

[Achim Gratz]

Thomas S. Dye writes:
> I think you and I have different definitions of "problem". From my
> user's perspective, something I "get away with," i.e., that doesn't have
> an effect on my work and productivity, isn't a problem.

That may well be true.  I'm firmly in the "fail fast and crash loudly"
camp.  In other words, if there is a problem, it should make itself
known at the earliest possible moment in a way that makes clear that it
needs to be fixed ASAP.  I encounter many folks that disagree with that
position, but usually only until one of those problems that fail to
clearly announce themselves causes them to lose important work later on.


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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada