Re: [O] org-mode based groupware wiki

[Eric Schulte]

Torsten Wagner <address@hidden> writes:

> Dear Wally,
> Dear Eric,
>
> thanks for the replies and sorry for the long delay. Interesting that
> there is an update on org-ruby just in the middle of my decision
> pathway ;).
> Until know I thought org-ruby is pretty much orphaned and that by time
> it will start to fail on the growing changes done in org-mode.
>
> On the other hand with all the help on the list I got org-ehtml
> working now. It was indeed a missing requirement call (require 'assoc)
> did the job.
> Now I was able to test both gollumn and org-ehtml it puts me into a dilemma.
>

Multiple viable options for Org-mode wikis is a great problem to have.

>
> From user (esp. non-org-user) perspective gollumn seems much more
> attractive. The editor is more user friendly for non-orgers and the
> integrated git versioning is working pretty stable.

See the "Integrating with version control" section of the org-ehtml
README [1].  It provides VC integration with just a couple of lines of
Emacs Lisp which could be added to the webserver's Emacs config.

> Gollumn itself seems to run on the shoulder of giants and keep itself
> rather small.

Org-ehtml is itself just a tiny hack which (I think) neatly combines the
power of the new Org export system, and the power of Elnode running on
top of a full fledged Emacs instance.  Org-ehtml is more than two orders
of magnitude smaller than gollum (judging by compressed source code).

    $ find gollum/lib -type f -exec cat {} \+|bzip2|wc -c 
    749992

    $ find org-ehtml/src -type f -exec cat {} \+|bzip2|wc -c
    6042

> Overall, a quite positive impression. However, it depends on the
> org-ruby package, which still understand only a subset of org-modes
> features. It seems to me somehow a hunting task to keep track with the
> fast pace of the org-mode development. This does not only include new
> features but also slight differences between the original org-mode
> export and the org-ruby parsing. It might be as simple as an extra
> blank here or there, which can be quite troublesome form time to time.
>
> e-html works great too. It is somehow a little bit more a web-based
> editable org-mode, whereas gollumn is a wiki-system which supports
> org-mode. org-html would do a perfect job for myself if I am the only
> user for this wiki. However, I frighten that non-orgers have a harder
> time to use it compare to gollumn. For some reason which I can't
> explain, I feel a bit nervous about running  an emacs session
> continuously on my server to provide a website. Not sure where the
> fear comes from. Maybe it is just because of my bad elisp skills ;)
> Overall, it works now and it does a good job but I can't avoid the
> feeling that all of it might be a bit fragile (as it might brake on
> arbitrarily changes on elnode, emacs, org-mode). However, it has the
> great benefit to be 100% up-to-date with whatever org-mode supports
> now or in the future and the output of a static page would be the same
> as the dynamic page. I even could create PDF versions if needed e.g.
> for static archiving.
>

Understood.  I hope I haven't wasted your time and I appreciated that
you got org-ehtml running.  Gollum is a very mature option, and is
probably your best bet unless you fall into one of the following.

1. need more esoteric features of Org-mode or
2. you like the idea of being able to run arbitrary Emacs Lisp as part
   of the editing process or
3. (like me) you don't have ruby installed on your system and a ruby web
   server seems like a lot of bloat for a wiki

The reason Gollum is so much larger is because it has a large team of
people adding the many handlers for edge cases and extra bells and
whistles which make for a robust tool.

My goal with org-ehtml was to produce a tiny working and (most
importantly) easily hackable core.  I don't have time to really flesh it
out myself, but I was/am hoping that someone interested in doing some
elisp and web programming would/will find it fun to extend the existing
proof-of-concept implementation.  I think it could easily grow into a
full featured Org-mode backed wiki, or online TODO tracker, or online
bug tracking database.

>
> I do not exactly now the intentions for org-ruby. Maybe Wally like to
> elaborate on this. Maybe org-ruby can catch up faster with the new
> exporter features of org-mode now that org-mode gets a more
> standardized syntax.
>
> At the moment, for me the best would be to combine both worlds
> somehow. I notice that gollum allows to define/call new parsers. Would
> it be possible to call emacs and start and html export on changes
> saved in the webbrowser? In other words why not calling emacs directly
> to do the html export? I would assume that the code which has to be
> added to gollum would be minimal and the same would be true for the
> few lines of lisp code to create the html page.
>

This would probably not be difficult.  You'd probably want to start an
EmacsClient instance when the web server boots, and then interact with
it through the command line.

>
> That would allow me to use the non-orger friendly gollumn and get the
> same accurate result as I do with org-ehtml. However, it would only
> call emacs from time to time instead of a constant emacs session
> running.
>

For speed reasons you'd probably still want the constant Emacs session
running, and you may open up many of the same security concerns.

>
> Maybe this (sorry) very long mail helps me to get the best of both
> worlds ;)
>

Thanks for sharing your thoughts, and for urging me to get org-ehtml
back up to date with the new Org-mode and elnode.

Best,

>
> Thanks for help and support
>
> Torsten
>
>
>
>
>
>
> On 16 October 2013 19:52, Waldemar Quevedo <address@hidden> wrote:
>> Hello Torsten,
>>
>>> - Enhance org-ruby?
>> I would be glad to help out in this regard. About the completeness of the
>> implementation of the Org mode ruby parser, it would be very helpful for me
>> to have a set of examples that describe how each one of the features of Org
>> mode Emacs exporter should be rendered in to HTML.
>>
>> I tried to do some work about this some time ago to identify the coverage of
>> Org ruby HTML exporting compared to the Org mode Emacs exporter:
>> https://github.com/wallyqs/org-mode-features/blob/master/features.org
>> https://github.com/bdewey/org-ruby/tree/master/spec/html_examples/
>> Is there a set of examples of all the features from Org mode anywhere?
>>
>> By the way, recently Github has upgraded to the 0.8.1 version of the
>> org-ruby gem, so Org mode rendering to HTML should have improved a lot
>> (previous version they used was 0.5.3 so it took a while for them to
>> evaluate upgrading the gem).
>> https://github.com/github/markup/issues/186#issuecomment-25342870
>>
>> Until I have identified the coverage, my current approach with developing
>> Org ruby is 'on demand', so if you find and issue please submit to the
>> issues tracker on Github: https://github.com/bdewey/org-ruby/issues
>>
>> Cheers,
>>
>> - Wally
>>
>>
>>
>>
>> On Fri, Oct 4, 2013 at 8:57 PM, Torsten Wagner <address@hidden>
>> wrote:
>>>
>>> Hi,
>>> recently I discovered gollumn [1] and was amazed to see that there is a
>>> software which allows non-orgers to work with / read my org-files and which
>>> even use git as the backend to get all save and nice together, even if
>>> working concurrently on the same files.
>>>
>>> I was wondering, because I never read about gollum in this ML and my
>>> search only revealed a very short three year old thread between Bastien and
>>> Eric Schulte. Despite that many of us was asking of possible ways how to use
>>> org as a groupware like environment. I guess this topic was discussed even
>>> more frequently over the last three years.
>>> Unfortunately, the main drawback, the usage of org-ruby [2] as org-mode
>>> parser still remains. I frighten that org-ruby only works on a small subset
>>> of the org-mode syntax and that even this might be a bit out-of-date. As far
>>> as I understood, org-mode in the meantime switched to a new exporter [3] and
>>> we got org-elements [4] and a heavy work towards standardization thanks to
>>> Nicolas Goaziou.
>>>
>>> What would be the best way to get the best out of the gollum idea and the
>>> new org-mode capabilities?
>>>
>>> - Skip gollumn and use (an updated) blorgit [5] (Does it have editor
>>> functionality?) ?
>>> - Enhance org-ruby?
>>> - Write a small script which creates a native html export from org-mode
>>> and hook this into gollumn? However, that would require emacs and org-mode
>>> being installed on the server side.
>>>
>>> For me gollums most important feature would be that people could use their
>>> web-browser and edit org-files. It might not be the most comfortable way of
>>> editing a org-file but a simple adding of a row into a table or rephrasing
>>> or adding a paragraph would be totally possible. It even might help to
>>> introduce people into using emacs and org-mode.
>>>
>>> It would be really nice to have such an easy access to org-files. Even
>>> hard-core orgers might like the idea to e.g. access and lightly modify there
>>> org-files on-the-go via smartphones and tablets without running a full emacs
>>> session. (I am aware of Mobileorg ;) )
>>>
>>> I got a bit into detail here to hopefully kick-off some discussions.
>>>
>>> All the best
>>>
>>> Torsten
>>>
>>>
>>> [1] https://github.com/gollum/gollum
>>> [2] http://orgmode.org/worg/org-tutorials/org-ruby.html
>>> [3] http://orgmode.org/worg/dev/org-export-reference.html
>>> [4] http://orgmode.org/worg/org-api/org-element-api.html
>>> [5] http://orgmode.org/worg/blorgit.html
>>
>>


Footnotes: 
[1]  https://github.com/eschulte/org-ehtml/blob/master/README#L70

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D