Google Summer of Code -- 3 Org projects for our first participation!

Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

Dear all,

we will have 3 students hacking Org thanks to Google and the GSoC 
program.  The list of all accepted projects can be checked here:

  http://www.google-melange.com/gsoc/projects/list/google/gsoc2012

Congratulations to Thorsten, Aurélien and Andrew who made it!
And special thanks to Thorsten, who really pushed me into this.

Here is a short description of these projects:

Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
Org-mode (Thorsten)

  The Bugpile project has two goals: 1. Develop a bugtracker (called
  Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
  dVCS. 2. As part of the engineering process, abstract out a
  web-framework (called iOrg) based on these GNU Emacs technologies. A
  web-framework written in Elisp, with Org files used for database
  functionality, is a new approach that enables interactive web
  applications built on top of GNU Emacs. Bugpile is an example
  application, but useful in itself.

Org-mode – Let Org-mode synchronize with online bug-tracking and
todo-list services (Aurélien)

  There's currently no convenient way to manage services like Redmine,
  Bugzilla or GitHub issue tracking system in Org-mode. Org-mode already
  handles TODO-list pretty well, but there's no synchronization
  functionality for TODO-list services such as Toodledo or Google
  Tasks. The goal of the project is to let Org-mode import and export to
  these kind of services in a generic way so that new services can be
  added easily later on.

Emacs-Orgmode Git merge tool for Org Files (Andrew Young)

  The purpose of the project is to create a specialized Git merge driver
  for plain text Org-Mode formatted files. A merge driver is a program
  which will combine two versions of a file based off of a common
  ancestor into a single file, marking conflicting changes within. A
  specialized merge driver for Org-Mode files will be able to leverage
  the structure to understand the effects of modifications on the
  integrity of sections. The merge driver will solidify Org-Mode as a
  tool for collaborative work.

Eric Schulte will mentor Thorsten's project and I will mentor Aurélien's
and Andrew's ones, with the help of Nicolas and Carsten.

This is an exciting time for Org: no doubt that having people paid for
hacking Org on a full-time basis will boost our favorite software.

This is an exciting time for me as a maintainer and future mentor:
no doubt that I will *learn* a lot, from both a technical and a human
point of view - as usual.  Now that my age and pseudo-marital position
make me come home with a baguette every evening, it will be good to feel 
like a student again :)

Thanks to all for your long-lasting commitment and support.

Happy orging,

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Carsten Dominik]

All three projects?????!!!!!

This is truely amazing.  Wow.

- Carsten

On Apr 24, 2012, at 7:55 AM, Bastien wrote:

> Dear all,
> 
> we will have 3 students hacking Org thanks to Google and the GSoC 
> program.  The list of all accepted projects can be checked here:
> 
>  http://www.google-melange.com/gsoc/projects/list/google/gsoc2012
> 
> Congratulations to Thorsten, Aurélien and Andrew who made it!
> And special thanks to Thorsten, who really pushed me into this.
> 
> Here is a short description of these projects:
> 
> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
> Org-mode (Thorsten)
> 
>  The Bugpile project has two goals: 1. Develop a bugtracker (called
>  Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>  dVCS. 2. As part of the engineering process, abstract out a
>  web-framework (called iOrg) based on these GNU Emacs technologies. A
>  web-framework written in Elisp, with Org files used for database
>  functionality, is a new approach that enables interactive web
>  applications built on top of GNU Emacs. Bugpile is an example
>  application, but useful in itself.
> 
> Org-mode – Let Org-mode synchronize with online bug-tracking and
> todo-list services (Aurélien)
> 
>  There's currently no convenient way to manage services like Redmine,
>  Bugzilla or GitHub issue tracking system in Org-mode. Org-mode already
>  handles TODO-list pretty well, but there's no synchronization
>  functionality for TODO-list services such as Toodledo or Google
>  Tasks. The goal of the project is to let Org-mode import and export to
>  these kind of services in a generic way so that new services can be
>  added easily later on.
> 
> Emacs-Orgmode Git merge tool for Org Files (Andrew Young)
> 
>  The purpose of the project is to create a specialized Git merge driver
>  for plain text Org-Mode formatted files. A merge driver is a program
>  which will combine two versions of a file based off of a common
>  ancestor into a single file, marking conflicting changes within. A
>  specialized merge driver for Org-Mode files will be able to leverage
>  the structure to understand the effects of modifications on the
>  integrity of sections. The merge driver will solidify Org-Mode as a
>  tool for collaborative work.
> 
> Eric Schulte will mentor Thorsten's project and I will mentor Aurélien's
> and Andrew's ones, with the help of Nicolas and Carsten.
> 
> This is an exciting time for Org: no doubt that having people paid for
> hacking Org on a full-time basis will boost our favorite software.
> 
> This is an exciting time for me as a maintainer and future mentor:
> no doubt that I will *learn* a lot, from both a technical and a human
> point of view - as usual.  Now that my age and pseudo-marital position
> make me come home with a baguette every evening, it will be good to feel 
> like a student again :)
> 
> Thanks to all for your long-lasting commitment and support.
> 
> Happy orging,
> 
> -- 
> Bastien
> 
> 

- Carsten

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Ian Barton]

> we will have 3 students hacking Org thanks to Google and the GSoC
> program.  The list of all accepted projects can be checked here:
>
>    http://www.google-melange.com/gsoc/projects/list/google/gsoc2012
>
> Congratulations to Thorsten, Aurélien and Andrew who made it!
> And special thanks to Thorsten, who really pushed me into this.
>
> Here is a short description of these projects:
>
> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
> Org-mode (Thorsten)
>
>    The Bugpile project has two goals: 1. Develop a bugtracker (called
>    Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>    dVCS. 2. As part of the engineering process, abstract out a
>    web-framework (called iOrg) based on these GNU Emacs technologies. A
>    web-framework written in Elisp, with Org files used for database
>    functionality, is a new approach that enables interactive web
>    applications built on top of GNU Emacs. Bugpile is an example
>    application, but useful in itself.
>

Great news!

For the dim witted (me) can you explain if Bugpile is meant to be a bug 
tracker specifically for tracking bugs in Emacs and org, or can it be 
used as a generic bug tracker for any project.

Ian.

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Thorsten]

Ian Barton <lists@wilkesley.net> writes:

>> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
>> Org-mode (Thorsten)
>>
>>    The Bugpile project has two goals: 1. Develop a bugtracker (called
>>    Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>>    dVCS. 2. As part of the engineering process, abstract out a
>>    web-framework (called iOrg) based on these GNU Emacs technologies. A
>>    web-framework written in Elisp, with Org files used for database
>>    functionality, is a new approach that enables interactive web
>>    applications built on top of GNU Emacs. Bugpile is an example
>>    application, but useful in itself.
>>
>
> Great news!
>
> For the dim witted (me) can you explain if Bugpile is meant to be a
> bug tracker specifically for tracking bugs in Emacs and org, or can it
> be used as a generic bug tracker for any project.

Thats a very interesting question, since there are two somehow
conflicting goals involved. 

The original project idea was to extend Org-mode for a more interactive
kind of web-programming, i.e. having buttons and forms on your webpages
and a kind of database in the background that stores changing state, and
some logic that reacts to user action (instead of just publishing static
web content).

Bugpile is kind of a (useful) pilot project for this idea, and during its
development an Emacs/Org-mode based web-framework (iOrg=interactive Org)
should emerge. 

Because this is about interactive web programming, bugpile should be
rather generic and accessible for anybody - they don't need Emacs, they
can use the web UI. A web-based bugtracker is nothing new, one could
just choose one out of several free tools on the market. The exciting
thing is being able to write one based on Org-mode and other Emacs
libraries like Elnode, i.e. developing the web-frameworg iOrg. 

On the other hand, Emacs user don't like to use web-interfaces, they
want to use Emacs to interact with the application. Thus the USP of
bugpile could be that it is not only written on top of Emacs, but can be
efficiently used from inside Emacs. 

Since time is limited, the main goal of the project is to develop the
iOrg webframework and the generic webbased bugtracker bugpile as a
tangible pilot project/ proof of concept. An optional, but highly
desirable additional output would be a Magit-like bugpile-mode for
Emacs. But I would prefer to keep it optional to limit the scope of my
GSoC project. 

This is still not defined, I would be happy about some community
feedback, and will of course discuss with my mentor(s).

-- 
cheers,
Thorsten

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Rasmus]

> we will have 3 students hacking Org thanks to Google and the GSoC 
> program.  The list of all accepted projects can be checked here:

Cool!  Good job!

> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
> Org-mode (Thorsten)

Interesting.

> Org-mode – Let Org-mode synchronize with online bug-tracking and
> todo-list services (Aurélien)

Something even more generic might be desirable.  For example, to some
(me), it might be more desirable to sync to a calendar-like service, as
oppose to a TODO like service.

> Emacs-Orgmode Git merge tool for Org Files (Andrew Young)

Interesting.  How would such a driver differentiate between normal git?
Would it be more intelligent in merging or?

> Now that my age and pseudo-marital position make me come home with a
> baguette every evening

:)

–Rasmus

-- 
C is for Cookie

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Richard Riley]

Bastien <bzg@gnu.org> writes:

> Dear all,
>
> we will have 3 students hacking Org thanks to Google and the GSoC 
> program.  The list of all accepted projects can be checked here:
>
>   http://www.google-melange.com/gsoc/projects/list/google/gsoc2012
>
> Congratulations to Thorsten, Aurélien and Andrew who made it!
> And special thanks to Thorsten, who really pushed me into this.

Really cool. org-mode just keeps growing while still keeping its core
simplicity. By far the biggest use I have now is as a simple journal
logger! If I may, and just for the future, what I'd really like to see
is a working org mode and google integration with gnus
integration. Possibly via googlecl which I used yonks ago for a googlecl
based blogger.com blog facility direct from org-files (still working
well enough and is in github (org-googlecl). I know there are some
proofs of concept already there but performance and usability were
pretty rudimentaty. bbdb's days are pretty much up in this day of
smartphone and "everyone integrates with google" ;) This integration
would obviously (!?!) integrate with google calendars which is then
already well catered for on just about any mobile device.

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Andrew Young]

Hi,

Thank you Bastien for working so hard to get Org-mode 3 slots, I know
most other Gnu projects only received one slot.  I'm really excited to
be able to work on this project!

Thank you to every one else involved as well!

Best,
Andrew

On Tue, Apr 24, 2012 at 7:29 AM, Richard Riley <rileyrg@gmail.com> wrote:
> Bastien <bzg@gnu.org> writes:
>
>> Dear all,
>>
>> we will have 3 students hacking Org thanks to Google and the GSoC
>> program.  The list of all accepted projects can be checked here:
>>
>>   http://www.google-melange.com/gsoc/projects/list/google/gsoc2012
>>
>> Congratulations to Thorsten, Aurélien and Andrew who made it!
>> And special thanks to Thorsten, who really pushed me into this.
>
> Really cool. org-mode just keeps growing while still keeping its core
> simplicity. By far the biggest use I have now is as a simple journal
> logger! If I may, and just for the future, what I'd really like to see
> is a working org mode and google integration with gnus
> integration. Possibly via googlecl which I used yonks ago for a googlecl
> based blogger.com blog facility direct from org-files (still working
> well enough and is in github (org-googlecl). I know there are some
> proofs of concept already there but performance and usability were
> pretty rudimentaty. bbdb's days are pretty much up in this day of
> smartphone and "everyone integrates with google" ;) This integration
> would obviously (!?!) integrate with google calendars which is then
> already well catered for on just about any mobile device.
>
>
>
>

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Achim Gratz]

Rasmus writes:
>> Emacs-Orgmode Git merge tool for Org Files (Andrew Young)
>
> Interesting.  How would such a driver differentiate between normal git?

You can add any number of merge drivers to your git config.  A merge
driver is supposed to know about the expected content of the file types
it gets registered for and be indeed more clever about merging than the
standard merge algorithms.  In particular it needs to know some syntax
rules and the semantics of the elements described by that syntax.

Let's say you want a merge driver for Changelogs: the standard merge
will always produce merge conflicts if two changes are made
independently as both changes start at the same point in the ancestor.
A merge driver for these knows that the entries in a changelog (the
syntax says how these should look) are independent of each other and
should be sorted by date (that's the semantics).  So as long as both
changes only add to the Changelog, no merge conflict occurs: the two
hunks will get applied in the correct succession.


HTH,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Rasmus]

Achim Gratz <Stromeko@nexgo.de> writes:

> Rasmus writes:
>>> Emacs-Orgmode Git merge tool for Org Files (Andrew Young)
>>
>> Interesting.  How would such a driver differentiate between normal
>> git?
>
> You can add any number of merge drivers to your git config.  A merge
> driver is supposed to know about the expected content of the file
> types
> it gets registered for and be indeed more clever about merging than
> the
> standard merge algorithms.  

Sounds like a real win for cooperative writing.  Teaching people
'correct' VC behavior (in particular conflict resolution) is often more
challenging than, say, LaTeX/R/whatever.

This could be huge.

Would the `final' code be part of Org or Git-upstream?  I am guessing
the latter for robustness.

–Rasmus

-- 
Don't panic!!!

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

This is way cool! Recently I have been deeply irritated by the lack of a 
functional server for Emacs Org Mode.

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.

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.

At the risk of being flamed to a cinder, I'll say that I think that 
using iOrg to support .org files on Github would be a better pilot 
project than Bugpile.

Besides my personal interest in better Github support for .org, I think 
that the Github project will be generally useful.

Also, from the tone of postings, it sounds like the Bugpile project is 
not well specified. Being that Thorsten only has a summer to do the 
work, I think it will be hard to create a Bugpile specification and 
implementation and an iOrg specification and implementation in just one 
summer.

As Github already has a specification for external markup converters 
(see https://github.com/github/markup), there is no need for writing any 
spec. For the first release of iOrg (ie: this summer's work), the iOrg 
implementation can be simplified to providing .org support for Github.

If things go well, I imagine that Thorsten would be very happy to finish 
the summer with his iOrg a part of Github.

Just my two cents,

Neil

PS: And the answer is "Yes. I am aware that vehemently suggesting a 
project is equivalent to offering to help with it." :-D

I can help with the .org/Github side of the project though I'm sure 
others know more about the implementation of Org Mode than me. If 
needed, I could also help manage interactions between Thorsten and 
Github as I'm sure that Github will have some requirements before they 
accept a pull request into their repository.

As far as Emacs internals, it's been 25 years since I last looked at the 
C source for Emacs so there must be better folk than I. In any case, any 
Emacs internal work that must be done for iOrg existed prior to my 
suggestion. In other words, it ain't my problem ;-)


Neil Smithline
http://www.neilsmithline.com
Proud GNU Emacs user since 1986, v. 18.24.


On 4/24 04:12 , Thorsten wrote:
> Ian Barton <lists@wilkesley.net> writes:
>
>>> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
>>> Org-mode (Thorsten)
>>>
>>>     The Bugpile project has two goals: 1. Develop a bugtracker (called
>>>     Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>>>     dVCS. 2. As part of the engineering process, abstract out a
>>>     web-framework (called iOrg) based on these GNU Emacs technologies. A
>>>     web-framework written in Elisp, with Org files used for database
>>>     functionality, is a new approach that enables interactive web
>>>     applications built on top of GNU Emacs. Bugpile is an example
>>>     application, but useful in itself.
>>>
>>
>> Great news!
>>
>> For the dim witted (me) can you explain if Bugpile is meant to be a
>> bug tracker specifically for tracking bugs in Emacs and org, or can it
>> be used as a generic bug tracker for any project.
>
> Thats a very interesting question, since there are two somehow
> conflicting goals involved.
>
> The original project idea was to extend Org-mode for a more interactive
> kind of web-programming, i.e. having buttons and forms on your webpages
> and a kind of database in the background that stores changing state, and
> some logic that reacts to user action (instead of just publishing static
> web content).
>
> Bugpile is kind of a (useful) pilot project for this idea, and during its
> development an Emacs/Org-mode based web-framework (iOrg=interactive Org)
> should emerge.
>
> Because this is about interactive web programming, bugpile should be
> rather generic and accessible for anybody - they don't need Emacs, they
> can use the web UI. A web-based bugtracker is nothing new, one could
> just choose one out of several free tools on the market. The exciting
> thing is being able to write one based on Org-mode and other Emacs
> libraries like Elnode, i.e. developing the web-frameworg iOrg.
>
> On the other hand, Emacs user don't like to use web-interfaces, they
> want to use Emacs to interact with the application. Thus the USP of
> bugpile could be that it is not only written on top of Emacs, but can be
> efficiently used from inside Emacs.
>
> Since time is limited, the main goal of the project is to develop the
> iOrg webframework and the generic webbased bugtracker bugpile as a
> tangible pilot project/ proof of concept. An optional, but highly
> desirable additional output would be a Magit-like bugpile-mode for
> Emacs. But I would prefer to keep it optional to limit the scope of my
> GSoC project.
>
> This is still not defined, I would be happy about some community
> feedback, and will of course discuss with my mentor(s).
>

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Thorsten Jolitz]

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

Hi Neil, 

> This is way cool! Recently I have been deeply irritated by the lack of
> a functional server for Emacs Org Mode.
>
> 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.
>
> 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.
>
> At the risk of being flamed to a cinder, I'll say that I think that
> using iOrg to support .org files on Github would be a better pilot
> project than Bugpile.

I figured out too that the best way to watch org files on github is raw
mode, so I think this is a very interesting and useful proposal. But its
a bit late for this year ;)

I like the bugpile project, and as I understood it, the bugtracker might
actually be used for Org-mode development if it fits the needs of the
Org-mode hackers. 

Since this years application was such an success with 3 projects
accepted, Org-mode might well try it again in 2013. 
What do you think about putting your proposal on the ideas page for GSoC
2013 (which I could rapidly push to Worg) with you as potential
mentor/co-mentor? 

Then it would not get lost, and interested students could apply next
year (if you can cope with githubs rendering of org files so long). And
there would be much more time to outline and coordinate the project. 

> Besides my personal interest in better Github support for .org, I
> think that the Github project will be generally useful.
>
> Also, from the tone of postings, it sounds like the Bugpile project is
> not well specified. Being that Thorsten only has a summer to do the
> work, I think it will be hard to create a Bugpile specification and
> implementation and an iOrg specification and implementation in just
> one summer.
>
> As Github already has a specification for external markup converters
> (see https://github.com/github/markup), there is no need for writing
> any spec. For the first release of iOrg (ie: this summer's work), the
> iOrg implementation can be simplified to providing .org support for
> Github.
>
> If things go well, I imagine that Thorsten would be very happy to
> finish the summer with his iOrg a part of Github.

Definitely a very interesting idea, but I'm already quite 'invested in
the bugpile project, and imagine I finish the summer as the author of a
bugtracker actually used by a quite big and dynamic GNU project like Org-mode.

> Just my two cents,
>
> Neil
>
> PS: And the answer is "Yes. I am aware that vehemently suggesting a
> project is equivalent to offering to help with it." :-D
>
> I can help with the .org/Github side of the project though I'm sure
> others know more about the implementation of Org Mode than me. If
> needed, I could also help manage interactions between Thorsten and
> Github as I'm sure that Github will have some requirements before they
> accept a pull request into their repository.
>
> As far as Emacs internals, it's been 25 years since I last looked at
> the C source for Emacs so there must be better folk than I. In any
> case, any Emacs internal work that must be done for iOrg existed prior
> to my suggestion. In other words, it ain't my problem ;-)
>
>
> Neil Smithline
> http://www.neilsmithline.com
> Proud GNU Emacs user since 1986, v. 18.24.
>
>
> On 4/24 04:12 , Thorsten wrote:
>> Ian Barton <lists@wilkesley.net> writes:
>>
>>>> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
>>>> Org-mode (Thorsten)
>>>>
>>>>     The Bugpile project has two goals: 1. Develop a bugtracker (called
>>>>     Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>>>>     dVCS. 2. As part of the engineering process, abstract out a
>>>>     web-framework (called iOrg) based on these GNU Emacs technologies. A
>>>>     web-framework written in Elisp, with Org files used for database
>>>>     functionality, is a new approach that enables interactive web
>>>>     applications built on top of GNU Emacs. Bugpile is an example
>>>>     application, but useful in itself.
>>>>
>>>
>>> Great news!
>>>
>>> For the dim witted (me) can you explain if Bugpile is meant to be a
>>> bug tracker specifically for tracking bugs in Emacs and org, or can it
>>> be used as a generic bug tracker for any project.
>>
>> Thats a very interesting question, since there are two somehow
>> conflicting goals involved.
>>
>> The original project idea was to extend Org-mode for a more interactive
>> kind of web-programming, i.e. having buttons and forms on your webpages
>> and a kind of database in the background that stores changing state, and
>> some logic that reacts to user action (instead of just publishing static
>> web content).
>>
>> Bugpile is kind of a (useful) pilot project for this idea, and during its
>> development an Emacs/Org-mode based web-framework (iOrg=interactive Org)
>> should emerge.
>>
>> Because this is about interactive web programming, bugpile should be
>> rather generic and accessible for anybody - they don't need Emacs, they
>> can use the web UI. A web-based bugtracker is nothing new, one could
>> just choose one out of several free tools on the market. The exciting
>> thing is being able to write one based on Org-mode and other Emacs
>> libraries like Elnode, i.e. developing the web-frameworg iOrg.
>>
>> On the other hand, Emacs user don't like to use web-interfaces, they
>> want to use Emacs to interact with the application. Thus the USP of
>> bugpile could be that it is not only written on top of Emacs, but can be
>> efficiently used from inside Emacs.
>>
>> Since time is limited, the main goal of the project is to develop the
>> iOrg webframework and the generic webbased bugtracker bugpile as a
>> tangible pilot project/ proof of concept. An optional, but highly
>> desirable additional output would be a Magit-like bugpile-mode for
>> Emacs. But I would prefer to keep it optional to limit the scope of my
>> GSoC project.
>>
>> This is still not defined, I would be happy about some community
>> feedback, and will of course discuss with my mentor(s).

-- 
cheers,
Thorsten

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

Hi Neil,

Neil Smithline <emacs-orgmode@neilsmithline.com> 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 :)

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

Hi Rasmus,

Rasmus <rasmus@gmx.us> writes:

> This could be huge.
>
> Would the `final' code be part of Org or Git-upstream?

It will land in the UTILITIES/ directory of Org distribution 
and be available for download on orgmode.org, with docs on Worg.

It will certainly be tested then used in the Worg git repo.

And Github users who maintain a README using Org will surely
appreciate such a tool.

> I am guessing the latter for robustness.

It might be a good candidate for the git contrib directory,
let's see.

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

Thanks for the response Thorsten. I didn't understand how much of the 
project was included in the GSOC proposal. From the tone of Bastien's 
email I thought that bugpile was unlikely to be completed in the summer. 
I'm glad to hear that you think you'll be able to finish it. I'm sure 
you'll do a great job and have fun over the summer no matter what, but 
it is always nice to be able to point at something real and say "I made 
that."

Even when I asked the question I thought the chances of a change were 
fairly low. It was too late in the process to coopt the summer co-op (no 
apology - that pun was too good to pass up :-D.

Neil

Neil Smithline
http://www.neilsmithline.com
Proud GNU Emacs user since 1986, v. 18.24.

On 4/26 03:48 , Thorsten Jolitz wrote:
> Neil Smithline <emacs-orgmode@neilsmithline.com> writes:
>
> Hi Neil,
>
>> This is way cool! Recently I have been deeply irritated by the lack of
>> a functional server for Emacs Org Mode.
>>
>> 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.
>>
>> 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.
>>
>> At the risk of being flamed to a cinder, I'll say that I think that
>> using iOrg to support .org files on Github would be a better pilot
>> project than Bugpile.
> I figured out too that the best way to watch org files on github is raw
> mode, so I think this is a very interesting and useful proposal. But its
> a bit late for this year ;)
>
> I like the bugpile project, and as I understood it, the bugtracker might
> actually be used for Org-mode development if it fits the needs of the
> Org-mode hackers.
>
> Since this years application was such an success with 3 projects
> accepted, Org-mode might well try it again in 2013.
> What do you think about putting your proposal on the ideas page for GSoC
> 2013 (which I could rapidly push to Worg) with you as potential
> mentor/co-mentor?
>
> Then it would not get lost, and interested students could apply next
> year (if you can cope with githubs rendering of org files so long). And
> there would be much more time to outline and coordinate the project.
>
>> Besides my personal interest in better Github support for .org, I
>> think that the Github project will be generally useful.
>>
>> Also, from the tone of postings, it sounds like the Bugpile project is
>> not well specified. Being that Thorsten only has a summer to do the
>> work, I think it will be hard to create a Bugpile specification and
>> implementation and an iOrg specification and implementation in just
>> one summer.
>>
>> As Github already has a specification for external markup converters
>> (see https://github.com/github/markup), there is no need for writing
>> any spec. For the first release of iOrg (ie: this summer's work), the
>> iOrg implementation can be simplified to providing .org support for
>> Github.
>>
>> If things go well, I imagine that Thorsten would be very happy to
>> finish the summer with his iOrg a part of Github.
> Definitely a very interesting idea, but I'm already quite 'invested in
> the bugpile project, and imagine I finish the summer as the author of a
> bugtracker actually used by a quite big and dynamic GNU project like Org-mode.
>
>> Just my two cents,
>>
>> Neil
>>
>> PS: And the answer is "Yes. I am aware that vehemently suggesting a
>> project is equivalent to offering to help with it." :-D
>>
>> I can help with the .org/Github side of the project though I'm sure
>> others know more about the implementation of Org Mode than me. If
>> needed, I could also help manage interactions between Thorsten and
>> Github as I'm sure that Github will have some requirements before they
>> accept a pull request into their repository.
>>
>> As far as Emacs internals, it's been 25 years since I last looked at
>> the C source for Emacs so there must be better folk than I. In any
>> case, any Emacs internal work that must be done for iOrg existed prior
>> to my suggestion. In other words, it ain't my problem ;-)
>>
>>
>> Neil Smithline
>> http://www.neilsmithline.com
>> Proud GNU Emacs user since 1986, v. 18.24.
>>
>>
>> On 4/24 04:12 , Thorsten wrote:
>>> Ian Barton <lists@wilkesley.net> writes:
>>>
>>>>> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
>>>>> Org-mode (Thorsten)
>>>>>
>>>>>      The Bugpile project has two goals: 1. Develop a bugtracker (called
>>>>>      Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>>>>>      dVCS. 2. As part of the engineering process, abstract out a
>>>>>      web-framework (called iOrg) based on these GNU Emacs technologies. A
>>>>>      web-framework written in Elisp, with Org files used for database
>>>>>      functionality, is a new approach that enables interactive web
>>>>>      applications built on top of GNU Emacs. Bugpile is an example
>>>>>      application, but useful in itself.
>>>>>
>>>> Great news!
>>>>
>>>> For the dim witted (me) can you explain if Bugpile is meant to be a
>>>> bug tracker specifically for tracking bugs in Emacs and org, or can it
>>>> be used as a generic bug tracker for any project.
>>> Thats a very interesting question, since there are two somehow
>>> conflicting goals involved.
>>>
>>> The original project idea was to extend Org-mode for a more interactive
>>> kind of web-programming, i.e. having buttons and forms on your webpages
>>> and a kind of database in the background that stores changing state, and
>>> some logic that reacts to user action (instead of just publishing static
>>> web content).
>>>
>>> Bugpile is kind of a (useful) pilot project for this idea, and during its
>>> development an Emacs/Org-mode based web-framework (iOrg=interactive Org)
>>> should emerge.
>>>
>>> Because this is about interactive web programming, bugpile should be
>>> rather generic and accessible for anybody - they don't need Emacs, they
>>> can use the web UI. A web-based bugtracker is nothing new, one could
>>> just choose one out of several free tools on the market. The exciting
>>> thing is being able to write one based on Org-mode and other Emacs
>>> libraries like Elnode, i.e. developing the web-frameworg iOrg.
>>>
>>> On the other hand, Emacs user don't like to use web-interfaces, they
>>> want to use Emacs to interact with the application. Thus the USP of
>>> bugpile could be that it is not only written on top of Emacs, but can be
>>> efficiently used from inside Emacs.
>>>
>>> Since time is limited, the main goal of the project is to develop the
>>> iOrg webframework and the generic webbased bugtracker bugpile as a
>>> tangible pilot project/ proof of concept. An optional, but highly
>>> desirable additional output would be a Magit-like bugpile-mode for
>>> Emacs. But I would prefer to keep it optional to limit the scope of my
>>> GSoC project.
>>>
>>> This is still not defined, I would be happy about some community
>>> feedback, and will of course discuss with my mentor(s).

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

I think I'm lacking sufficient information to fully understand the 
situation (that's just a secret code for saying I'm confused).

 From your original email about GSOC:

On 4/24 01:55 , Bastien wrote:
 > As part of the engineering process, abstract out a
 > web-framework (called iOrg) based on these GNU Emacs technologies. A
 > web-framework written in Elisp, with Org files used for database
 > functionality, is a new approach that enables interactive web
 > applications built on top of GNU Emacs. Bugpile is an example
 > application, but useful in itself.

To me, that sounds like iOrg will be an Emacs web server or an Emacs 
plugin to a web server or something like that.

In reply to my email you wrote:

On 4/26 03:57 , Bastien wrote:
 > 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.

To me, that sounds like iOrg will not be appropriate to be part of a web 
server.

Hence, I'm confused. My guess is that I'm confused about the exact 
nature of iOrg as I was surprised that someone was going to turn Emacs 
into something appropriate to be part of a Github web server. Even 
factoring in a large college hacker coding multiplier, three months 
seemed too short to me. That was part, albeit the smaller part, of my 
motivation for trying to put aside bugpile in favor of just iOrg.

I will follow-up with my thoughts about the org-ruby gem in a separate 
email.

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 <emacs-orgmode@neilsmithline.com> 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 :)
>

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

On 4/26 03:57 , Bastien wrote:
> 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.

The org-ruby gem is really in its infancy with regards to processing Org 
Mode. For example, I added support for converting a line with just 
"-----" to an HTML <hr/> tag. So now it supports horizontal rules but it 
still doesn't support centering of text.

 > If the list can specifically help about org-ruby issues, let's help!

A quick hack to provide better support would be to add support to the 
org-ruby gem to process HTML in a .org file. While not the cleanest of 
solutions, being able to process HTML will allow work-arounds for many 
missing features.

But it would be much better if the org-ruby gem could process a larger 
subset of Org Mode directives. But this isn't as easy as it sounds.

The gem is a reasonably well-written parser that is organized to allow 
pluggable backends. I kind of like it. But it is really, really tiny. 
(See the end of this email for details about the size).

I think the basic parser framework is too simplistic to support much 
more of Org. No fault to the gem; it was written to be no more complex 
than it had to be to do what it does.

In the end, my thought is that I'm not sure if it is better to extend 
the org-ruby gem or to do something totally different (I don't know what).

In the end, I think the way that the best way the list could help 
improve Github's support of Org files would be to provide two things:

1) Come up with a prioritized list of features that would be nice to be 
supported by Github. This may just be the most used features of Org Mode 
or it may be something special to how Org Mode is used in Github. I'm 
not sure.

2) Have a few people look at the org-ruby gem and then brainstorm about 
the best way to proceed. This would either require people who know Ruby 
or more experienced software engineers. I modified the gem and learned 
Ruby by reading the source for this gem and occasionally looking 
something up in a reference manual. But I'd bet I've been coding longer 
than list members such as Thorsten have been alive.

I really don't know enough about the culture of the Org Mode developers 
to know if this is possible or not. The alternative is that I can just 
keep adding features as I need them and think I can implement them.

As I said in my initial email:

 >> PS: And the answer is "Yes. I am aware that vehemently suggesting a 
project
 >> is equivalent to offering to help with it." :-D

Neil

ORG-RUBY LINES OF CODE

Here's a wc output on the gem's source code with tests and other 
non-functional parts omitted:

      110     394    3392 headline.rb
      246     793    8521 html_output_buffer.rb
      345     691   18139 html_symbol_replace.rb
      258     839    7877 line.rb
      241     909    8318 output_buffer.rb
      370    1189   12363 parser.rb
      192     843    7020 regexp_helper.rb
      102     320    2919 textile_output_buffer.rb
      346     695   16882 textile_symbol_replace.rb
       29      49     498 tilt.rb
     2239    6722   85929 total

If you subtract out the two dedicated textile files, the org-ruby gem 
has fewer than 10% of the lines that org.el alone has. The comparison 
isn't wholly fair as org.el has many more public functions than org-ruby 
and, correspondingly, org.el has significantly more lines of documentation.




Neil Smithline
http://www.neilsmithline.com
Proud GNU Emacs user since 1986, v. 18.24.

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

Hi Neil,

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

> In the end, I think the way that the best way the list could help improve
> Github's support of Org files would be to provide two things:
>
> 1) Come up with a prioritized list of features that would be nice to be
> supported by Github. This may just be the most used features of Org Mode or
> it may be something special to how Org Mode is used in Github. I'm not
> sure.

This is a good idea.  We could start a page on Worg for this -- if you
want to edit Worg, please send me your public key in private and I'll
give you access.

When you're done with a preliminary list of yours, perhaps inviting the
github developers could boost both the brainstorming and the development
of org-ruby.

> 2) Have a few people look at the org-ruby gem and then brainstorm about the
> best way to proceed. This would either require people who know Ruby or more
> experienced software engineers. I modified the gem and learned Ruby by
> reading the source for this gem and occasionally looking something up in a
> reference manual. But I'd bet I've been coding longer than list members
> such as Thorsten have been alive.

If there are Ruby hackers around, that might work.

But since org-ruby is widely used by a (big?) company like github,
perhaps this company could lead such effort.

> I really don't know enough about the culture of the Org Mode developers to
> know if this is possible or not. The alternative is that I can just keep
> adding features as I need them and think I can implement them.

That would be nice.

One thing to be aware of: there is an ongoing work by Nicolas to write a
parser (see org-element.el in contrib/lisp/ from the git repo).  It is
already quite useful -- and used in the new exporters (e.g. org-e-latex.el)

One nice side-effect of having this parser is that we will be able to 
document the syntax of Org files more clearly.  Actually, org-element.el
*is* such a description, but we need to make it widely available as a 
documentation page (on Worg).

Thanks,

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

I Neil,

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

> I think I'm lacking sufficient information to fully understand the
> situation (that's just a secret code for saying I'm confused).

here is a lengthy description for iOrg:

http://orgmode.org/worg/org-contrib/gsoc2012/student-projects/bugpile/i.html

This is just a *plan*, nothing is coded yet, and this plan might
evolve as code will be written.

HTH,

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Eric Schulte]

Neil Smithline <emacs-orgmode@neilsmithline.com> 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 <emacs-orgmode@neilsmithline.com> 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/

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

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?

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 :-)

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 <emacs-orgmode@neilsmithline.com> 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 :)
>

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

 On Sun, Apr 29, 2012 at 4:22 AM, Bastien <bzg@gnu.org> wrote:

>
> One thing to be aware of: there is an ongoing work by Nicolas to write a
> parser (see org-element.el in contrib/lisp/ from the git repo).  It is
> already quite useful -- and used in the new exporters (e.g. org-e-latex.el)
>
> One nice side-effect of having this parser is that we will be able to
> document the syntax of Org files more clearly.  Actually, org-element.el
> *is* such a description, but we need to make it widely available as a
> documentation page (on Worg).
>

Bastien,

I've looked at org-element.el and don't really see how it will make writing
other Org Mode to HTML converter easier. org-element.el is, well it's
elisp. Very elispy. No surprise but I'm not sure that it can easily be
converted to another language.

Is Nicolas working from a grammar? I think an Org Mode grammar will make
writing parsers much easier. Perhaps I'm just old-school but I think that
generating an Org Mode to HTML converter in another language would be
dramatically simplified by an Org Mode grammar semantic annotations.

Neil

PS: I've been looking at Org Mode utilities in various languages and none
of them seem to handle any sizable portion of Org Mode to HTML conversion.
It seems that there is little for us to use as a starting point.

[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bastien]

Hi Neil,

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

> I've looked at org-element.el and don't really see how it will make
> writing other Org Mode to HTML converter easier. org-element.el is,
> well it's elisp. Very elispy. No surprise but I'm not sure that it
> can easily be converted to another language.
>
> Is Nicolas working from a grammar? I think an Org Mode grammar will
> make writing parsers much easier. Perhaps I'm just old-school but I
> think that generating an Org Mode to HTML converter in another
> language would be dramatically simplified by an Org Mode grammar
> semantic annotations.

You're not old-school at all :)

Maybe I wasn't explicit enough.

1. There is already a new Org>HTML exporter, written by Jambunathan.
   Try adding contrib/lisp/ to your load path, then

   (require 'org-export)
   (require 'org-e-html) 

   then M-x org-export-dispatch RET h

   See the result.

2. This new Org>HTML exporter is based on contrib/lisp/org-export.el and
   contrib/lisp/org-element.el.  The latter is responsible for parsing
   elements of an org-mode buffer based on a clear syntax, the former
   implements a generic export engine.

So yes, things are going into the direction of having a better grammar
for Org, Nicolas and Jambunathan already build parsers for LaTeX and
HTML using this grammar, and we will implement new parsers that way.

Thanks,

-- 
 Bastien

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Nicolas Goaziou]

Hello,

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

> I've looked at org-element.el and don't really see how it will make writing
> other Org Mode to HTML converter easier. org-element.el is, well it's
> elisp. Very elispy. No surprise but I'm not sure that it can easily be
> converted to another language.
>
> Is Nicolas working from a grammar?

Since org-element can parse 98%[1] of Org syntax, there must be
a grammar defined somewhere. When I started org-element, there was no
structural definition of Org syntax (there wasn't even a full list of
syntactic objects). Now, org-element is the grammar embodied in elisp.

Alas, I have no plan to formalize it. Though, I agree that it would be
a great thing to have in order to implement equivalent parsers in other
languages.

If someone wants to study org-element and extract a formal grammar out
of it, I will gladly help him in the process.

Otherwise, you can use the intermediary representation of an Org
document. org-element can produce the representation and read the
representation to produce an Org document.

#+begin_src emacs-lisp
(org-element-interpret-data
 '(org-data
   nil
   (headline
    (:level 1 :title ("It works") :priority ?A :todo-keyword "TODO" :tags ("test"))
    (section
     nil
     (center-block
      nil
      (paragraph nil "Really"))))))
#+end_src 

Thus, you may only need to write converters from that representation to
another syntax (like HTML). That's the purpose of org-export and its
back-ends.


Regards,

[1] I still don't know what to do with "under\_line": there is no
`kludge' object type so far (!).

-- 
Nicolas Goaziou

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Bernt Hansen]

Bastien <bzg@gnu.org> writes:

> 1. There is already a new Org>HTML exporter, written by Jambunathan.
>    Try adding contrib/lisp/ to your load path, then
>
>    (require 'org-export)
>    (require 'org-e-html) 
>
>    then M-x org-export-dispatch RET h
>
>    See the result.

There are a bunch of org-e-html-* variables similar to org-export-html-*
variables that the new exporter uses.  You need to set the appropriate
org-e-html variables to get results similar to the old exporter.

-Bernt

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Neil Smithline]

GIMP just came out with a major release. The extensive release notes 
(http://bit.ly/JlxQrL) are littered with statements such as:
     This feature was originally developed during Google
     Summer of Code 2008 and heavily improved since.

While I'm hoping we can turn GSoC work into production in less than 4 
years, the GIMP release notes have left me even more psyched about our 
three GSoCers!

Go guys! (At least I think you're all guys :-)

Neil Smithline
http://www.neilsmithline.com
Proud GNU Emacs user since 1986, v. 18.24.


On 4/24 01:55 , Bastien wrote:
> Dear all,
>
> we will have 3 students hacking Org thanks to Google and the GSoC
> program.  The list of all accepted projects can be checked here:
>
>    http://www.google-melange.com/gsoc/projects/list/google/gsoc2012
>
> Congratulations to Thorsten, Aurélien and Andrew who made it!
> And special thanks to Thorsten, who really pushed me into this.
>
> Here is a short description of these projects:
>
> Bugpile - a bugtracker for GNU Emacs Org-mode written in Elisp and
> Org-mode (Thorsten)
>
>    The Bugpile project has two goals: 1. Develop a bugtracker (called
>    Bugpile) for GNU Emacs Org-mode, using Elisp, Elnode, Org-mode, and a
>    dVCS. 2. As part of the engineering process, abstract out a
>    web-framework (called iOrg) based on these GNU Emacs technologies. A
>    web-framework written in Elisp, with Org files used for database
>    functionality, is a new approach that enables interactive web
>    applications built on top of GNU Emacs. Bugpile is an example
>    application, but useful in itself.
>
> Org-mode – Let Org-mode synchronize with online bug-tracking and
> todo-list services (Aurélien)
>
>    There's currently no convenient way to manage services like Redmine,
>    Bugzilla or GitHub issue tracking system in Org-mode. Org-mode already
>    handles TODO-list pretty well, but there's no synchronization
>    functionality for TODO-list services such as Toodledo or Google
>    Tasks. The goal of the project is to let Org-mode import and export to
>    these kind of services in a generic way so that new services can be
>    added easily later on.
>
> Emacs-Orgmode Git merge tool for Org Files (Andrew Young)
>
>    The purpose of the project is to create a specialized Git merge driver
>    for plain text Org-Mode formatted files. A merge driver is a program
>    which will combine two versions of a file based off of a common
>    ancestor into a single file, marking conflicting changes within. A
>    specialized merge driver for Org-Mode files will be able to leverage
>    the structure to understand the effects of modifications on the
>    integrity of sections. The merge driver will solidify Org-Mode as a
>    tool for collaborative work.
>
> Eric Schulte will mentor Thorsten's project and I will mentor Aurélien's
> and Andrew's ones, with the help of Nicolas and Carsten.
>
> This is an exciting time for Org: no doubt that having people paid for
> hacking Org on a full-time basis will boost our favorite software.
>
> This is an exciting time for me as a maintainer and future mentor:
> no doubt that I will *learn* a lot, from both a technical and a human
> point of view - as usual.  Now that my age and pseudo-marital position
> make me come home with a baguette every evening, it will be good to feel
> like a student again :)
>
> Thanks to all for your long-lasting commitment and support.
>
> Happy orging,
>

Re: Google Summer of Code -- 3 Org projects for our first participation!

[Thorsten Jolitz]

Neil Smithline <emacs-orgmode@neilsmithline.com> writes:

> While I'm hoping we can turn GSoC work into production in less than 4
> years, the GIMP release notes have left me even more psyched about our
> three GSoCers!
>
> Go guys! (At least I think you're all guys :-)

Thanks for your interest and support!
The first time I heard about GSoC was trying out ENSIME
(https://github.com/aemoncannon/ensime), an enhanced Scala mode for
Emacs written during a GSoC and apparently used by some of the Scala
gurus. A really nice project too. 

-- 
cheers,
Thorsten