Re: [O] bug#32722: bug#32722: 26.1; Org-publish depend on non-free platform ?

[Nick Dokos]

Adam Porter <address@hidden> writes:

> I'm not an expert on this package nor this situation, however, looking
> at the htmlize.el file shows:
>
>     ;; Copyright (C) 1997-2003,2005,2006,2009,2011,2012,2014,2017,2018
>
> So it would appear that the package has existed longer than either
> GitHub or Org.  I'm guessing that its author moved its primary repo to
> GitHub after Org started using it.
>
> In hindsight, perhaps it would have been better to move htmlize into
> Emacs before adding it to Org proper.  But many things are clearer in
> hindsight.
>
> Regardless of where it is hosted, htmlize.el is Free Software, and it's
> an optional addon to Org.  We can encourage its author to add it to
> Emacs proper, or to ELPA.  But surely it's not necessary to censor the
> mention of "GitHub" in the manual; it's simply a fact that GitHub exists
> and that htmlize.el is currently hosted there.  It would seem
> unreasonable for the Org maintainers to have reacted to htmlize.el's
> moving to GitHub by removing htmlize.el support while it remains Free
> Software, yet that's the logical conclusion of this argument.
>

I had exactly the same reaction.

> So please do not remove support for this package because of where its
> repo happens to be hosted at the moment.  That would be a major
> regression, and it would not be in users' best interests.  It would not
> be fair to remove a major feature used by thousands of users and demand
> that "someone" (since there is no one ultimately responsible) rewrite
> large parts of ox-html.el to fix it.  It would at least seem fair for
> those insisting on the change to do the necessary work.
>

I don't usually +1 replies but I wanted to chime in my agreement with
Adam here.  Thanks for taking the time to put your (and my!) thoughts
into words.

If Github is indeed the sticking point, why can't it (the htmlize
repo) be cloned on the same server as org-mode (possibly as its own
repo, possibly as a git submodule)? It's not a fast moving target: a
handful or two of commits per year. The doc can then avoid the Gihub
ref (although it does seem silly to pretend that Github does not
exist).

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler