About implementing libre.js/el in Emacs

About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1.1: Type: text/plain, Size: 1104 bytes --]

Hi,

As RMS recently pointed out, we should have something like Libre.js
for our JavaScript Webkit Xwidgets in emacs.
I plan to implement that idea, but I have some design choices and
would like to hear inputs from you guys.

There are two obvious options to achieve this:
1) Implement (part of) the Web Extension API
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API <https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API>
and let libre.js runs as-is in Emacs.
2) reimplement libre.js as libre.el

Both will require adding primitives to Emacs C source to expose
urlRequest events, etc.

Option 1, besides enabling libre.js, can also bring numerous existing
cross-browser extensions to Emacs, if we finally support a large enough
portion of the Web Extension API. However those extensions are
all written in JS and JS is worse than Elisp.

Option 2 might require as much work as option 1, but without the additional
benefit (or drawback?) of bringing other JS extensions.

What do you think?

Best,
Qiantan

qhong@mit.edu




[-- Attachment #1.2: Type: text/html, Size: 4060 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[Paul Eggert]

On 8/29/20 12:14 PM, Qiantan Hong wrote:
> Option 1, besides enabling libre.js, can also bring numerous existing
> cross-browser extensions to Emacs, if we finally support a large enough
> portion of the Web Extension API. However those extensions are
> all written in JS and JS is worse than Elisp.
> 
> Option 2 might require as much work as option 1, but without the additional
> benefit (or drawback?) of bringing other JS extensions.

I'd suggest Option 1 as providing more bang for the buck. I think the FSF tech 
staff is looking at LibreJS; see 
<https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration>.

Re: About implementing libre.js/el in Emacs

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Just curious - in what ways is JS worse then Elisp?

I agree Option 1 would give more bang for your buck - at least initially.

On Sun, 30 Aug 2020 at 07:11, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 8/29/20 12:14 PM, Qiantan Hong wrote:
> > Option 1, besides enabling libre.js, can also bring numerous existing
> > cross-browser extensions to Emacs, if we finally support a large enough
> > portion of the Web Extension API. However those extensions are
> > all written in JS and JS is worse than Elisp.
> >
> > Option 2 might require as much work as option 1, but without the
> additional
> > benefit (or drawback?) of bringing other JS extensions.
>
> I'd suggest Option 1 as providing more bang for the buck. I think the FSF
> tech
> staff is looking at LibreJS; see
> <
> https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration
> >.
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 1588 bytes --]

Re: About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]


> On Aug 29, 2020, at 10:26 PM, Tim Cross <theophilusx@gmail.com> wrote:
> 
> Just curious - in what ways is JS worse then Elisp? 
There’re lots of other arguments, e.g. homoiconicity, typing (js does lots of
unreasonable type casts)… but in this context, I think the most important
point is that Emacs and Emacs Lisp give one of the most flexible and
self-descriptive programming system. If something is implemented in
Emacs lisp, we get M-x apropos, describe-function, describe-variable,
they can be overrode by just eval-defun, and can be advised. Customizing
or extending it is painless and trivial. However, those things become
much harder if the package is implemented in JS.

> I agree Option 1 would give more bang for your buck - at least initially. 
> 
I’ll take that. I imagine while implementing Web Extensions API for js
it will be trivial to also bring those to Elisp too, so finally we not only
have those JS browser plugins to run but can also develop plugins
in Elisp.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

OK, I don't see one as being worse than the other. They are different and
have different benefits/drawbacks.

WRT developing plugins in elisp, I wonder if using the Google Closure
Compiler (Apache 2.0 License) could be useful. This is what Clojurescript
does, allowing you to develop in Clojure Lisp and the output being
optimised JS code. However, not sure how much demand there would be for
writing browser (or node) extensions in elisp. While it is nice to write in
lisp to develop JS, Clojurescript has already provided that wheel and it is
quite mature.

On Sun, 30 Aug 2020 at 12:45, Qiantan Hong <qhong@mit.edu> wrote:

>
> > On Aug 29, 2020, at 10:26 PM, Tim Cross <theophilusx@gmail.com> wrote:
> >
> > Just curious - in what ways is JS worse then Elisp?
> There’re lots of other arguments, e.g. homoiconicity, typing (js does lots
> of
> unreasonable type casts)… but in this context, I think the most important
> point is that Emacs and Emacs Lisp give one of the most flexible and
> self-descriptive programming system. If something is implemented in
> Emacs lisp, we get M-x apropos, describe-function, describe-variable,
> they can be overrode by just eval-defun, and can be advised. Customizing
> or extending it is painless and trivial. However, those things become
> much harder if the package is implemented in JS.
>
> > I agree Option 1 would give more bang for your buck - at least
> initially.
> >
> I’ll take that. I imagine while implementing Web Extensions API for js
> it will be trivial to also bring those to Elisp too, so finally we not only
> have those JS browser plugins to run but can also develop plugins
> in Elisp.



-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2302 bytes --]

Re: About implementing libre.js/el in Emacs

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1928 bytes --]

Qiantan Hong <qhong@mit.edu> writes:


1+ for the elisp side.

Here are a few more things to think about:

Looking forward or Looking Back?

Most of the Web's "web apps" are written in JS, but I suspect much of
that will also fall outside the bounds of what RMS calls "ethical JS".

At the same time, having  a "web in emacs extension language" might
allow us to imagine, invent, and create a whole new class of
collaborative interactions that the so-called mainstream Web might never
think of or create -- and in that sense, a prototyping/extension
language that aligns with elisp might serve us better.

In thi scontext, I'd also like to point at the Nyxt browser which uses
parenscript  (Lisp that compiles down to JS) as an  another example of
using Lisp to script the Web.

https://common-lisp.net/project/parenscript/
>> On Aug 29, 2020, at 10:26 PM, Tim Cross <theophilusx@gmail.com> wrote:
>> 
>> Just curious - in what ways is JS worse then Elisp? 
> There¡¯re lots of other arguments, e.g. homoiconicity, typing (js does lots of
> unreasonable type casts)¡­ but in this context, I think the most important
> point is that Emacs and Emacs Lisp give one of the most flexible and
> self-descriptive programming system. If something is implemented in
> Emacs lisp, we get M-x apropos, describe-function, describe-variable,
> they can be overrode by just eval-defun, and can be advised. Customizing
> or extending it is painless and trivial. However, those things become
> much harder if the package is implemented in JS.
>
>> I agree Option 1 would give more bang for your buck - at least initially. 
>> 
> I¡¯ll take that. I imagine while implementing Web Extensions API for js
> it will be trivial to also bring those to Elisp too, so finally we not only
> have those JS browser plugins to run but can also develop plugins
> in Elisp.
>

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: About implementing libre.js/el in Emacs

[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. ]]]

  > At the same time, having  a "web in emacs extension language" might
  > allow us to imagine, invent, and create a whole new class of
  > collaborative interactions

That phrase is evocative, but it isn't concrete.  It could mean many
things.  To me, it suggests the idea of a web site that people
interact with through a particular Emacs Lisp program.  Is that what
you mean?

If a web site intends users to run some specific Emacs Lisp program,
the way to do this and respect the users' freedom is to release
that program like any other free software package.  That way, users
can make and use modified versions.  Users and distros can release
and maintain their versions, too.

But I don't see that this has anything to do with the question
of Emacs and Javascript.  Javascript plays no role in it.

If you mean something else, could you describe it more clearly?

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

Re: About implementing libre.js/el in Emacs

[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. ]]]

  > Both will require adding primitives to Emacs C source to expose
  > urlRequest events, etc.

Can someone explain how those events work?  What do theese events do?
What code generates them?

Why does it function that way, rather than by calling Lisp directly?

  > Option 1, besides enabling libre.js, can also bring numerous existing
  > cross-browser extensions to Emacs, if we finally support a large enough
  > portion of the Web Extension API. However those extensions are
  > all written in JS and JS is worse than Elisp.

This is a bad idea, at the deepest level, because it means supporting
Emacs extensibility in two separate ways, with separate
implementations.  That would make Emacs far more complex.

We should not support Emacs extensibility in Javascript.

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

Re: About implementing libre.js/el in Emacs

[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. ]]]

Tim Cross <theophilusx@gmail.com> asked

  > Just curious - in what ways is JS worse then Elisp?

That is something most of us know -- but let's not
go down this tangent on the list.  Please explain this
off the list.

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

Re: About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]


> On Aug 30, 2020, at 11:53 PM, Richard Stallman <rms@gnu.org> wrote:
> 
>> At the same time, having  a "web in emacs extension language" might
>> allow us to imagine, invent, and create a whole new class of
>> collaborative interactions
> 
> That phrase is evocative, but it isn't concrete.  It could mean many
> things.  To me, it suggests the idea of a web site that people
> interact with through a particular Emacs Lisp program.  Is that what
> you mean?

My understanding of Elisp as web extension language is nothing close
to compiling Elisp to Javascript. This brings little advantage
of Elisp — roughly summarized as “a reflexive programming
environment. We lose the ability to dynamically and interactively
extending the program if we have to run compilation/translation
on Elisp to get JS and then feed to the Webkit.

>  it suggests the idea of a web site that people
> interact with through a particular Emacs Lisp program.  Is that what
> you mean?

Does this mean basically a website serving Emacs Lisp program?
That’s good, or more conservatively, serving HTML documents
with embedded Emacs Lisp code (basically as a replacement for
JS), so while the website can have UI designed for Emacs, 
when user access it from other browser/program they still get the contents.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]


>> Option 1, besides enabling libre.js, can also bring numerous existing
>> cross-browser extensions to Emacs, if we finally support a large enough
>> portion of the Web Extension API. However those extensions are
>> all written in JS and JS is worse than Elisp.
> 
> This is a bad idea, at the deepest level, because it means supporting
> Emacs extensibility in two separate ways, with separate
> implementations.  That would make Emacs far more complex.
> 
> We should not support Emacs extensibility in Javascript.
> 
I highly agree with that, however currently numerous browser extensions
are already implemented completely in Javascript, including LibreJS.

Maybe another option is to have the other way around, implement
a JavaScript to Elisp translator, and support Emacs Lisp version of 
those web extension APIs. Then we can run the translator on librejs
to get librejs.el as a starting point.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[Stefan Monnier]

> Does this mean basically a website serving Emacs Lisp program?

We could call it "please hack me"?


        Stefan

Re: About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]



> On Aug 31, 2020, at 12:15 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> Does this mean basically a website serving Emacs Lisp program?
> 
> We could call it "please hack me"?
> 
> 
>        Stefan
> 
So true.. read the code before M-x eval-webpage !

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]



> On Aug 30, 2020, at 11:57 PM, Richard Stallman <rms@gnu.org> 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. ]]]
> 
>> Both will require adding primitives to Emacs C source to expose
>> urlRequest events, etc.
> 
> Can someone explain how those events work?  What do theese events do?
> What code generates them?
> 
> Why does it function that way, rather than by calling Lisp directly?

They are event (technically GTK signals) coming from WebkitGTK.
WebkitGTK emit those event at some interesting moments, e.g.
before a HTTP request is about to be sent. Librejs use Javascript
handlers to intercept requests, analyze scripts and block the bad
ones. This relies on the browser wrapping those event and expose
the interface to JS.

If we decide to let Librejs run in its JS form then we’ll have to do
what those browsers do.

We can also have Librejs.el. In this case there’s a technique concern
though, since WebkitGTK require the send-request signal
to be blocked *synchronously* when executing the signal callback,
we can’t do it the usual way that push a event into emacs’s
input event queue, we have to evaluate Emacs Lisp during
a GTK signal callback. Is this safe from, e.g., deadlock issues?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: About implementing libre.js/el in Emacs

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1337 bytes --]

Richard Stallman <rms@gnu.org> writes:


I was thinking more of manipulating DOM (Document Object Model)
structures via elisp code rther than JS> [[[ 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. ]]]
>
>   > At the same time, having  a "web in emacs extension language" might
>   > allow us to imagine, invent, and create a whole new class of
>   > collaborative interactions
>
> That phrase is evocative, but it isn't concrete.  It could mean many
> things.  To me, it suggests the idea of a web site that people
> interact with through a particular Emacs Lisp program.  Is that what
> you mean?
>
> If a web site intends users to run some specific Emacs Lisp program,
> the way to do this and respect the users' freedom is to release
> that program like any other free software package.  That way, users
> can make and use modified versions.  Users and distros can release
> and maintain their versions, too.
>
> But I don't see that this has anything to do with the question
> of Emacs and Javascript.  Javascript plays no role in it.
>
> If you mean something else, could you describe it more clearly?

-- 
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: About implementing libre.js/el in Emacs

[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 was thinking more of manipulating DOM (Document Object Model)
  > structures via elisp code rther than JS>

That seems reasonable to me.

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

Re: About implementing libre.js/el in Emacs

[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 highly agree with that, however currently numerous browser extensions
  > are already implemented completely in Javascript, including LibreJS.

That is true, but it is secondary.  There are things bigger and deeper
at stake here: keeping Emacs fundamentally clean, and avoiding the
extremely unwise practice of running programs right off other people's
web sites.

  > Maybe another option is to have the other way around, implement
  > a JavaScript to Elisp translator, and support Emacs Lisp version of 
  > those web extension APIs. Then we can run the translator on librejs
  > to get librejs.el as a starting point.

Ideally this would operate on Javascript source code only, and would
generate something that would not actually be ready to run, but would
be a starting point for writing a real Emacs Lisp program.

That way, people would not tempted to run compiled (*) Javascript programs
straight off web pages.

* Obfuscating or compacting Javascript is a form of compilation, for
  these purposes.




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