emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Google Summer of Code -- 3 Org projects for our first participat


From: Eric Schulte
Subject: Re: [O] Google Summer of Code -- 3 Org projects for our first participation!
Date: Fri, 04 May 2012 17:04:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Neil Smithline <address@hidden> writes:

> Bastien,
>
> I've been looking at the bugpile Worg page (very nice page - good work
> Thorsten or whomever) and don't see why you say:
>
>> I don't see how github could use such
>> a setup to produce HTML files from Org (unless github runs an Emacs
>> batch query for exporting HTML... which seems very unlikely - and
>> wrong by design anyway.
>
> I understand that Emacs is a bit of a behemoth in terms of CPU when
> being started and always in terms of memory. That being said, why does
> it seem "wrong by design" to have Github running an Emacs server and
> sending Org --> HTML jobs to it with emacsclient?
>

I think this issue is unrelated to the bugpile proposal.  As you mention
all that is required to export Org-mode files to HTML is a daemon emacs
process and emacsclient.

My guess (although this is really a question for the people at github)
is that adding Emacs to their web software stack is simply too heavy
weight (in terms of processing time and complexity) of a tool for simple
file export.

As one example of the complexity involved; imagine I push up a .org file
to github which includes an embedded code block with shell code and the
":exports results" header argument.  Unless the github admins have
turned off code block execution, such a document would allow me to
execute arbitrary shell code on their servers with the permissions of
whoever created the emacs daemon.

>
> Just a head's up, once you answer the above question, I'm going to ask
> you what can be done to fix the problem :-)
>

I would be happy to see full support for Org-mode->html export on
github, but I'd be surprised if you could convince the github admins
that the payoff is worth the cost.

Best,

>
> Neil
>
>
>
> Neil Smithline
> http://www.neilsmithline.com
> Proud GNU Emacs user since 1986, v. 18.24.
>
> On 4/26 03:57 , Bastien wrote:
>> Hi Neil,
>>
>> Neil Smithline <address@hidden> writes:
>>
>>> I've run into this problem dealing with the weak presentation of Org Mode
>>> files on Github. Github uses the Ruby gem org-ruby
>>> (https://github.com/bdewey/org-ruby) to convert .org files to HTML. I've
>>> added a feature or two to org-ruby but really feel that trying to
>>> completely re-implement Org Mode in a Ruby gem is a losing battle.
>>
>> What will help org-ruby (and github's support of org files) is to
>> stabilize the syntax of .org files as much as possible.  We are
>> currently working in this direction.
>>
>> org-ruby's main job is to convert .org files into HTML or textile files.
>>
>>> If I understand the project correctly, a working iOrg could be used to
>>> support Github's rendering of .org files. Github could just drop the use of
>>> org-ruby and use iOrg as an external converter for formatting .org files.
>>
>> As I understand it, iOrg will convert .org files to HTML using the
>> internal Org's HTML exporter.  I don't see how github could use such
>> a setup to produce HTML files from Org (unless github runs an Emacs
>> batch query for exporting HTML... which seems very unlikely - and
>> wrong by design anyway.
>>
>> Let's see how iOrg evolves but let's stick to the bugpile for now.
>>
>> If the list can specifically help about org-ruby issues, let's help!
>>
>> All best,
>>
>>> PS: And the answer is "Yes. I am aware that vehemently suggesting a project
>>> is equivalent to offering to help with it." :-D
>>
>> Good :)
>>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



reply via email to

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