ELPA submission: mathjax.el

ELPA submission: mathjax.el

[Augusto Stoffel]

I would like to add the package residing at the following location to
ELPA:

https://github.com/astoff/mathjax.el

There's no need to clarify the necessary header changes, but I would
like to add a technical comment: the package needs an external program
to be useful (Node) but otherwise bundles all other dependencies.

[paste Chico Buarque meme here]

More specifically, there's a 2.3 MB minified JavaScript file that is
committed to the repo and I will take care to update when the "real"
source (also in the repo, of course) changes.

Also, in case there are any JS experts around, I'd be happy to get hints
on how to make things work with other JS engines.  I have at least 3
others in my machine (2 browsers and Gnome's) but it's unclear to me if
they can be used for random purposes like this one.

Best,
Augusto

Re: ELPA submission: mathjax.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would like to add the package residing at the following location to
  > ELPA:

  > https://github.com/astoff/mathjax.el

As I recall, mathjax does a useful job, but depends on a browser to
run special Javascript code.  It has been some years since I heard
about that -- is my memory right?  If not, could you explain how
things really work?

This raises an issue which is one of the biggest issues in computing
and freedom: how to give users control over the Javascript programs
that run in their browsers.

I have an idea for how perhaps to do that.  I don't know enough
about web browsers and Javascript to be sure whether it can work.
Could you please work with me to explore the possibility?

The first step is to think about how the Mathjax Javascript program
couples to and relates to the Emacs Lisp program.  Could you please
explain how that coupling works now?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 16 Oct 2024 at 23:54, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I would like to add the package residing at the following location to
>   > ELPA:
>
>   > https://github.com/astoff/mathjax.el
>
> As I recall, mathjax does a useful job, but depends on a browser to
> run special Javascript code.  It has been some years since I heard
> about that -- is my memory right?  If not, could you explain how
> things really work?

If it was years ago then it was probably right at the time.  In the
meanwhile, however, standalone JS environments have appeared.
Apparently many people like JS and use it to develop regular programs.

MathJax is just a JS library and it can run in those standalone JS
interpreters to produce images from formulas (in TeX or MathML
notation).  So that's what my package does: it runs one of those
standalone JS interpreter and loads the MathJax library in it.

> This raises an issue which is one of the biggest issues in computing
> and freedom: how to give users control over the Javascript programs
> that run in their browsers.

Just to emphasize: MathJax as well as its JS dependencies and the
standalone JS interpreter are all free software.  So for my package this
is not an issue.

> I have an idea for how perhaps to do that.  I don't know enough
> about web browsers and Javascript to be sure whether it can work.
> Could you please work with me to explore the possibility?
>
> The first step is to think about how the Mathjax Javascript program
> couples to and relates to the Emacs Lisp program.  Could you please
> explain how that coupling works now?

The coupling is via good old pipes, with MathJax running as a subprocess
of Emacs (like a non-interactive Comint, basically).

Re: ELPA submission: mathjax.el

[Philip Kaludercic]

Augusto Stoffel <arstoffel@gmail.com> writes:

> I would like to add the package residing at the following location to
> ELPA:
>
> https://github.com/astoff/mathjax.el
>
> There's no need to clarify the necessary header changes, 

Sorry for the delay, I have added the package to ELPA, but as you know,
it won't be added until you update the Copyright line and add a
"Version" header.

>                                                          but I would
> like to add a technical comment: the package needs an external program
> to be useful (Node) but otherwise bundles all other dependencies.
>
> [paste Chico Buarque meme here]
>
> More specifically, there's a 2.3 MB minified JavaScript file that is
> committed to the repo and I will take care to update when the "real"
> source (also in the repo, of course) changes.

Is there any reason to choose the minified version?  Also, do you know
if you could support KaTeX as well?  AFAIK it is more lightweight
(though the package name might be confusing in that case).

> Also, in case there are any JS experts around, I'd be happy to get hints
> on how to make things work with other JS engines.  I have at least 3
> others in my machine (2 browsers and Gnome's) but it's unclear to me if
> they can be used for random purposes like this one.

I have tried QuickJS, but it didn't work either.  That being said, I am
not a JS expert so what I do I know :)

> Best,
> Augusto
>
>

-- 
	Philip Kaludercic on icterid

Re: ELPA submission: mathjax.el

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> More specifically, there's a 2.3 MB minified JavaScript file that is
>> committed to the repo and I will take care to update when the "real"
>> source (also in the repo, of course) changes.
>
> Is there any reason to choose the minified version?  Also, do you know
> if you could support KaTeX as well?  AFAIK it is more lightweight
> (though the package name might be confusing in that case).

I don't feel comfortable with distributing a 2.3 MB minified JavaScript
file, unless it is generated from source code either as part of the
package build process on GNU ELPA, or during the package installation on
users' machines.

Could we work on resolving that?

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 23 Oct 2024 at 07:02, Stefan Kangas wrote:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> More specifically, there's a 2.3 MB minified JavaScript file that is
>>> committed to the repo and I will take care to update when the "real"
>>> source (also in the repo, of course) changes.
>>
>> Is there any reason to choose the minified version?  Also, do you know
>> if you could support KaTeX as well?  AFAIK it is more lightweight
>> (though the package name might be confusing in that case).
>
> I don't feel comfortable with distributing a 2.3 MB minified JavaScript
> file, unless it is generated from source code either as part of the
> package build process on GNU ELPA,

Ah sure, what you suggest is of course much better -- I didn't think
ELPA might be capable of building stuff.  Either of those would be
possible in my case:

A. If the build environment has Node/npm, all that is needed is to run
make math2svg.js.

B. If the build environment can run containers, I can include a suitable
Dockerfile.

> or during the package installation on users' machines.

This is not an option in my opinion.  It doesn't "just work", instead
requiring the user to execute a build step, and the download is 40 times
larger than the minified JS.

> Could we work on resolving that?

I'd be happy to.  If neither options A. or B. are currently available, I
would say implementing B. is a good approach in general for packages
that require a build step.

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 23 Oct 2024 at 07:23, Philip Kaludercic wrote:

> Also, do you know if you could support KaTeX as well?  AFAIK it is
> more lightweight (though the package name might be confusing in that
> case).

I must confess I made the choice for mathjax out of sheer ignorance of
KaTeX's existence.  Too bad I linked the package name with the backend
library. :-)

> I have tried QuickJS, but it didn't work either.  That being said, I am
> not a JS expert so what I do I know :)

Okay, this looks like an option if we wanted to turn the minified JS
into a binary executable, but this would then be platform-dependent.  I
guess it's not in the plans to make ELPA capable of distributing
binaries... or is it?

Re: ELPA submission: mathjax.el

[Philip Kaludercic]

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Wed, 23 Oct 2024 at 07:02, Stefan Kangas wrote:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> More specifically, there's a 2.3 MB minified JavaScript file that is
>>>> committed to the repo and I will take care to update when the "real"
>>>> source (also in the repo, of course) changes.
>>>
>>> Is there any reason to choose the minified version?  Also, do you know
>>> if you could support KaTeX as well?  AFAIK it is more lightweight
>>> (though the package name might be confusing in that case).
>>
>> I don't feel comfortable with distributing a 2.3 MB minified JavaScript
>> file, unless it is generated from source code either as part of the
>> package build process on GNU ELPA,
>
> Ah sure, what you suggest is of course much better -- I didn't think
> ELPA might be capable of building stuff.  Either of those would be
> possible in my case:
>
> A. If the build environment has Node/npm, all that is needed is to run
> make math2svg.js.

That could be arranged, but it wouldn't be a recent version of node.
But I'd like to double-check with Stefan Monnier (in the CC's) before
proceeding with this.

> B. If the build environment can run containers, I can include a suitable
> Dockerfile.
>
>> or during the package installation on users' machines.
>
> This is not an option in my opinion.  It doesn't "just work", instead
> requiring the user to execute a build step, and the download is 40 times
> larger than the minified JS.

Some systems[0] appear to have mathjax as a package they can install.
In their case, they could load the code they have installed locally.
But I agree that this would incur an annoyance for all other users.

[0] https://pkgs.org/download/mathjax

>> Could we work on resolving that?
>
> I'd be happy to.  If neither options A. or B. are currently available, I
> would say implementing B. is a good approach in general for packages
> that require a build step.

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Wed, 23 Oct 2024 at 07:23, Philip Kaludercic wrote:
>
>> Also, do you know if you could support KaTeX as well?  AFAIK it is
>> more lightweight (though the package name might be confusing in that
>> case).
>
> I must confess I made the choice for mathjax out of sheer ignorance of
> KaTeX's existence.  Too bad I linked the package name with the backend
> library. :-)

If you want, it is not too late to rename the package to "shr-math" or
something like that.

>> I have tried QuickJS, but it didn't work either.  That being said, I am
>> not a JS expert so what I do I know :)
>
> Okay, this looks like an option if we wanted to turn the minified JS
> into a binary executable, but this would then be platform-dependent.  I
> guess it's not in the plans to make ELPA capable of distributing
> binaries... or is it?

No, it is not.  But QuickJS is also usable just as an interpreter.

-- 
	Philip Kaludercic on icterid