Re: Problem exporting code

[Bastien <bzg@altern.org>]

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