emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELPA submission: mathjax.el


From: Philip Kaludercic
Subject: Re: ELPA submission: mathjax.el
Date: Wed, 23 Oct 2024 19:04:11 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]