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

[Adam Porter <adam@alphapapa.net>]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> With Org/ox-html, it's the same thing. Ox-html is part of Emacs
> core. So it cannot rely on htmlize.el.

1.  Why not?  I just git-blamed this line in ox-html.el:

  (declare-function htmlize-region "ext:htmlize" (beg end))

It's from February, 2012.  That's 6 and a half years, at least, that
that code has been present.  Why are we suddenly concerned about it?

2.  Is Org part of "Emacs core"?  I didn't think that was how "Emacs
core" was defined, but I may be wrong.  It is officially part of Emacs,
of course.  So is there a distinction between "part of Emacs" and "Emacs
core"?  If so, is there a difference in policy for those two categories,
and is that policy written anywhere?  Are there any other "time bombs"
in Org that we should be concerned about?

3.  Yesterday, RMS posted this:

> The deep problem with the reference to htmlize is that it blurs the
> distinction between Emacs itself and Lisp code that is not part of
> Emacs.  We need to highlight that distinction, not blur it.

a.  That is not the originally stated problem.

b.  I don't understand how htmlize blurs the distinction between Emacs
itself and other lisp code.  htmlize is not distributed with Emacs nor
Org, and it must be manually retrieved from a third-party repository.
Isn't that very much distinct from Emacs itself?  Doesn't telling users
that they must download and install it separately highlight that
distinction?

4.  I'm certainly in favor of using built-in libraries as much as
possible.  If htmlfontify is a better or equivalent solution, and
someone's willing to write the code and ensure there are no regressions,
that would be great, because it would save users from having to manually
install other packages to get expected functionality.

5.  Having a passing familiarity with the complexity of the Org code
base, I am concerned about the potential for regressions in
functionality and usability.  I'm also a bit disappointed to see this
burden potentially thrust upon Nicolas and other Org maintainers, to
replace working code that's existed for over 6 years, for little-to-no
technical reason.  Their time available for working on Org is very
valuable.