Re: [O] Problem exporting code

[Thorsten Jolitz]

Bastien <address@hidden> 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:address@hidden 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