[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bleeding edge in elpa

From: T.F. Torrey
Subject: Re: [O] Bleeding edge in elpa
Date: Mon, 09 Mar 2015 00:31:34 -0700

Hello again,

Rasmus <address@hidden> writes:

>> I want to collaborate on Org files with my wife and parents,
>     ^^^^^^^
> Do you?  It sounds cool!

It's complicated.

I've convinced my parents to begin writing memoir-type books, and my
wife works in non-profit, where good books are always good solutions.  I
push them toward using plain text files for the benefits we all know,
and because I can turn the files into epub books, Kindle books, and PDF
print books using my custom Org export code.

I would love to introduce them to the awesomeness of Org.  I think they
could work in Emacs, and I'm sure they could handle updating things via
ELPA, but I'm also pretty sure that the sight of git would send them
screaming all the way back to Microsoft Word.

At the same time, I don't want to use or write my custom code for an old
version of Org, and the files produced by the maint and master versions
of Org are slightly incompatible.

So.  The current process is for them to use Markdown formatting in their
plain-text files.  At least these can be converted with a quick script
(and Calibre's ebook-convert) to epub, Kindle, and pdf versions.  These
are okay, but not great.  For "final" versions, I will need to convert
the Markdown down Org using Pandoc, then do the pretty exports using my
Manuscript package.  This is not a solution.  This is a labor-intensive,
error-prone hack.

I would so much prefer to get them into Emacs and Org.  And I could, if
the master version was availble through ELPA.

>> In a real-world situation, I want to collaborate on Org files with my
>> wife and parents, and I want to use the current best version of Org
>> (which has significant improvements to #+INCLUDE that I use), but I do
>> not want to try to install git on their Windows machines,
> I agree.  I have the same problem when I build documents (via CI) on a
> remote Debian server where I don't want to mess around with anything more
> than what comes with Emacs by default.

This is another great use-case for an ELPA version of the git master.

>> Serious Org users are already forced to install and run git to use the
>> master version, and whatever the dangers, the practice is almost
>> completely without problems.  A "bleeding edge" ELPA would merely make
>> that simpler.
> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple
> of other packages will move to GNU ELPA and thus separate release channels
> (these packages will still be bundled with Emacs).  This means we can push
> out new versions easily, making more frequent releases more attractive.
> Again, if you want to help out with preparing releases just let the list
> and Bastien now.

I'm looking forward to this new arrangement (though it will be
interesting when, AFAIK, Gnus still doesn't have a workflow through
ELPA).  However, I don't see how this will make it easier to push out
new stable releases.  That still has the inherent problem that making
something called a "stable" version takes a lot of human effort.

I wonder how much effort it would take to copy onto my own machine the
scripts on the server that package the git maint version into an ELPA
version, and modify them to package master instead.  Probably not much.
I could host that on my own server, or maybe upload it to Melpa.  I
think I will look into that.

All the best,
T.F. Torrey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]