Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the jekyll-org plugin to the whitelist #335

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
7 participants
@stig
Copy link

commented Oct 11, 2016

Add a plugin that makes it possible to use Org-mode for writing blog posts with GitHub Pages, without separate build steps & checking in generated HTML. The plugin used is a thin shim over the org-ruby module that GitHub already uses to render README.org files, so I am hoping that allowing it also for GitHub Pages won't be too much of a stretch.

Here's an example post using Org-mode properties:

#+title: Blogging with Jekyll-Org
#+layout: post
#+tags: Emacs

This is an example of blogging with =jekyll-org=. Note that both =YAML=
frontmatter and Org properties are supported.

The equivalent post using YAML frontmatter would look like this:


---
title: Blogging with Jekyll-Org
layout: post
tags: Emacs

---

This is an example of blogging with =jekyll-org=. Note that both =YAML=
frontmatter and Org properties are supported.
@benbalter

This comment has been minimized.

Copy link
Contributor

commented Oct 13, 2016

@stig can you talk a bit more about why Org mode is an important feature for GitHub Pages (other than personal preference)? We recently removed non-Kramdown markup implementations in an effort to make the publishing experience more straighforward.

@stig

This comment has been minimized.

Copy link
Author

commented Oct 13, 2016

Hi @benbalter,

I missed that textile support is being dropped and thought the Kramdown work was just about consolidating on a single Markdown implementation.

Obviously using Orgmode is my preference, I won't try to deny that! :-) But, I'm certainly not the only one. There's a myriad of ways people have tried to solve the "problem", e.g.

Common for all of them is that they have to somehow check in generated HTML. Some use a different _org subdir, that generates .html files in _posts, others use a different branch, and yet others don't bother checking in the original file. (That's me this week.)

Since gists and READMEs already supports Orgmode via the org-ruby module I thought you might be open to allowing it for GitHub Pages too. Is it the right thing for GitHub Pages to add support for? I don't presume to know, I'll let you decide.

@zv

This comment has been minimized.

Copy link

commented Oct 14, 2016

I personally generate a static site from Org files that is ultimately hosted on GH pages but I have my reservations about this.

Notably, how unevenly Org's markup features are supported by org-ruby and how the existing 'patterns' of Org projects could breakdown. I could still stick with my existing workflow of generating HTML files, but the existence of a new choice would be confusing to novices and largely superfluous to powerusers. In general, org-ruby faces some limitations not present in Org/OX, which makes this even less appetizing for some users.

Forgive me if I'm steering this too far afield, but I think it's important to note that Org itself features an excellent publishing platform. Simplifying the publishing process for Github Pages within Org's documentation (or the program itself) would be the most profitable use of everyone's time. This also has the advantage of homogenizing the procedures that Org users adhere to, making life easier for developers and end-users alike.

I think this is an interesting effort, and I could imagine some use-case emerging here, but my (perhaps dim) view is that any effort to integrate Org-markup into the Github-sanctioned Jekyll ecosystem would probably leave all affected communities unsatisfied.

@stig

This comment has been minimized.

Copy link
Author

commented Jan 12, 2017

Can I have a yay or nay please? Happy to update it if you would want this feature, but otherwise please just close it. I don't want this lingering indefinitely and clogging up my list of open PRs. That just causes me more overhead every time I look through that list.

@benbalter

This comment has been minimized.

Copy link
Contributor

commented Jan 12, 2017

@parkr @jldec any thoughts here?

@titaniumbones

This comment has been minimized.

Copy link

commented Jan 22, 2017

Here's why I think this is an important feature: org-mode supports a variety of complex features that markdown doesn't. Scientists and others who use org-mode in their work rely on those features in a systematic way. In this sense, org users are not a scattered set of individuals, but a coherent population with closely-aligned workflows and tools. In my view, there's value in supporting this community, in part because org continues to demonstrate an important minoritarian way of working in the open, with open tools, literate programming ,etc. Markdown is great, but having a different model helps to shed light on both its virtues and its deficiencies -- and that alone is an important service. Github is (obviously) the most important community of open code development in the world. It will benefit by continuing to have a close relationship with org-mode programmers!

Add the jekyll-org plugin to the whitelist
Add a plugin that makes it possible to use Orgmode for writing blog
posts with GitHub Pages, without separate build steps & checking in
generated HTML. The plugin used is a thin shim over the org-ruby module
that GitHub already uses to render README.org files, so I am hoping that
allowing it also for GitHub Pages won't be too much of a stretch.

,----[ _posts/2016-10-11-jekyll-org.org ]
| #+title: Blogging with Jekyll-Org
| #+layout: post
| #+tags: Emacs
|
| This is an example of blogging with =jekyll-org=. Note that both =YAML=
| frontmatter and Org properties are supported.
`----

The equivalent post using YAML frontmatter would look like this:

,----[ _posts/2016-10-11-jekyll-org.org ]
| ---
| title: Blogging with Jekyll-Org
| layout: post
| tags: Emacs
| ---
|
| This is an example of blogging with =jekyll-org=. Note that both =YAML=
| frontmatter and Org properties are supported.
`----
@stig

This comment has been minimized.

Copy link
Author

commented Jan 31, 2017

Hello! Have you reached any decision regarding this? A simple "no we are not interested" is absolutely acceptable and will let me close it and stop me wasting time following up loose threads every so often. If I hear nothing for another week I'll close it myself.

If anyone else is interested in continuing to carry the torch for this, feel free to clone this PR from your own repo. It is so trivial & obvious, there's no copyright or licensing issues. I just don't feel like I'm getting any useful feedback here, and don't want to sink any more time into it.

@stig

This comment has been minimized.

Copy link
Author

commented Feb 14, 2017

Alright, I guess you're not interested.

@stig stig closed this Feb 14, 2017

@slashsbin

This comment has been minimized.

Copy link

commented Mar 10, 2017

Hello!
Please reconsider adding OrgMode support.

@bzg

This comment has been minimized.

Copy link

commented Jul 3, 2017

Thanks @stig for bringing this up.

@benbalter @parkr @jldec can we reconsider this?

I'm the Org-mode maintainer and I confirm many users would use this.

@zv you said:

Simplifying the publishing process for Github Pages within Org's documentation (or the program itself) would be the most profitable use of everyone's time.

Can you expand a bit on this? I'm all for enhancing the in-house publishing capacities of Org-mode.

Thanks!

@lzhoucs

This comment has been minimized.

Copy link

commented May 24, 2018

+1 on please reconsider supporting org-mode.

Without knowing this ticket exist, I once posted on stackoverflow a similar question.

Even if org-ruby is limited, it doesn't mean it can't be enhanced in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.