From: tftorrey@tftorrey.com (T.F. Torrey)
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bleeding edge in elpa
Date: Mon, 09 Mar 2015 00:31:34 -0700 [thread overview]
Message-ID: <871tkyvd7t.fsf@jack.tftorrey.com> (raw)
In-Reply-To: <87ioeb9s9i.fsf@gmx.us> (message from Rasmus on Sun, 08 Mar 2015 20:57:29 +0100)
Hello again,
Rasmus <rasmus@gmx.us> 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,
Terry
--
T.F. Torrey
next prev parent reply other threads:[~2015-03-09 8:14 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull
2015-03-07 14:47 ` Xavier Maillard
2015-03-07 16:09 ` Nikolai Weibull
2015-03-08 5:48 ` Xavier Maillard
2015-03-09 9:08 ` Sebastien Vauban
2015-03-09 16:24 ` T.F. Torrey
2015-03-07 15:40 ` Grant Rettke
2015-03-07 21:44 ` T.F. Torrey
2015-03-08 1:32 ` Nicolas Girard
2015-03-08 14:17 ` Aaron Ecay
2015-03-08 17:24 ` Nikolai Weibull
2015-03-08 17:59 ` Achim Gratz
2015-03-08 18:34 ` Nikolai Weibull
2015-03-08 18:59 ` Rasmus
2015-03-09 6:48 ` T.F. Torrey
2015-03-10 1:57 ` Aaron Ecay
2015-03-10 21:30 ` T.F. Torrey
2015-03-11 2:51 ` Aaron Ecay
2015-03-11 19:18 ` T.F. Torrey
2015-03-11 19:59 ` Nick Dokos
2015-03-09 7:53 ` T.F. Torrey
2015-03-09 18:24 ` Achim Gratz
2015-03-09 19:21 ` T.F. Torrey
2015-03-10 11:01 ` Alexis
2015-03-10 15:21 ` Grant Rettke
2015-03-08 18:09 ` T.F. Torrey
2015-03-08 19:57 ` Rasmus
2015-03-08 20:20 ` Achim Gratz
2015-03-08 20:27 ` Rasmus
2015-03-08 20:36 ` Achim Gratz
2015-03-09 8:13 ` T.F. Torrey
2015-03-09 7:31 ` T.F. Torrey [this message]
2015-03-10 2:01 ` Richard Y. Kim
2015-03-10 6:29 ` Achim Gratz
2015-03-10 21:21 ` T.F. Torrey
2015-03-10 20:20 ` T.F. Torrey
2015-08-05 0:00 ` Bastien Guerry
2015-03-10 10:51 ` Steinar Bang
2015-03-10 17:11 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871tkyvd7t.fsf@jack.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).