HTML5 the new lisp ?

HTML5 the new lisp ?

[Sander Boer]

Hi,

I know it makes no sense to compare a markup language to a functional
language, but think of it, HTML5 is the first point of contact of most
people when it comes to computing, much like the early days of computing
when lisp was the first language people came into contact with.

More to the point, the reason I bring this up in this group is the fact that I find myself
wondering what emacs would *mean* when it would embrace HTML5 as a
fundamental integrated platform.

HTML5 is being heralded as the app platform of the coming years, with
mobile computing taking the lead as the main Internet connecting device.

But personally, I would like to see a good rendering engine, imagine
what gnus would look like. Come to think of it, imagine how ubiquitous
HTML5 emails would be in the (near) future - sure, it will also come
with its own unique set of security concerns, but I seriously wonder if
text-only email will cut it. ah, hold on with ye flames, after a brief
stint with HTML signatures, I find myself gravitating towards
text-only. But that is mainly because HTML in its present incarnation in
emails is too volatile, but one must admit that volatility is hardly a
reason that it will *never* work.

Also, auctex, man what would that look like ?
Or what about HTML5 games ? Gnus vs. Penguins , Angry Emus ?

I noticed Joakim Verona implemented a webkit widget and I was wondering
how this is received in the land of Fangorn  ?
I propose a step deeper, a C-level implementation. 

It is an absurd idea, but is it not through initial absurdity that
unimaginable possibilities become unlocked ?
Are we not Man, is absurdity not our privilege ?

-- 
Sander Boer
......................................................................
A visit to a strange place will bring fresh work.

Re: HTML5 the new lisp ?

[Thien-Thi Nguyen]

() "Sander Boer" <sanderboer@yahoo.com>
() Sun, 31 Jul 2011 22:25:20 +0200

   Are we not Man, is absurdity not our privilege ?

You are to be congratulated for not using the word "rich"
anywhere in your post!

Re: HTML5 the new lisp ?

[joakim]

"Sander Boer" <sanderboer@yahoo.com> writes:

> Hi,
>
> I know it makes no sense to compare a markup language to a functional
> language, but think of it, HTML5 is the first point of contact of most
> people when it comes to computing, much like the early days of computing
> when lisp was the first language people came into contact with.
>
> More to the point, the reason I bring this up in this group is the fact that I find myself
> wondering what emacs would *mean* when it would embrace HTML5 as a
> fundamental integrated platform.
>
> HTML5 is being heralded as the app platform of the coming years, with
> mobile computing taking the lead as the main Internet connecting device.
>
> But personally, I would like to see a good rendering engine, imagine
> what gnus would look like. Come to think of it, imagine how ubiquitous
> HTML5 emails would be in the (near) future - sure, it will also come
> with its own unique set of security concerns, but I seriously wonder if
> text-only email will cut it. ah, hold on with ye flames, after a brief
> stint with HTML signatures, I find myself gravitating towards
> text-only. But that is mainly because HTML in its present incarnation in
> emails is too volatile, but one must admit that volatility is hardly a
> reason that it will *never* work.
>
> Also, auctex, man what would that look like ?
> Or what about HTML5 games ? Gnus vs. Penguins , Angry Emus ?
>
> I noticed Joakim Verona implemented a webkit widget and I was wondering
> how this is received in the land of Fangorn  ?
> I propose a step deeper, a C-level implementation. 
>
> It is an absurd idea, but is it not through initial absurdity that
> unimaginable possibilities become unlocked ?
> Are we not Man, is absurdity not our privilege ?

I'm not really sure what you are talking about but if you want to play
with Emacs and HTML5 it is possible in a primitive way with the
xwidget branch. You can create a webkit area in an Emacs buffer and
manipulate it by injecting javascript fragments in it.

I would like to achieve a better elisp/DOM bridge for my purposes but
I'm procrastinating it because it's not obvious how to do it in an
interesting way. (Either by machine generating DOM bindings with
Cedet/SRecode, or by making some form of adapter compatible with
xml-parse-region)

Anyway, if some of this HTML5 enthusiasm could be directed into the
furtherance of the xwidget branch, that would be splendiferous :)

-- 
Joakim Verona

Re: HTML5 the new lisp ?

[Dimitri Fontaine]

joakim@verona.se writes:
> I'm not really sure what you are talking about but if you want to play
> with Emacs and HTML5 it is possible in a primitive way with the
> xwidget branch. You can create a webkit area in an Emacs buffer and
> manipulate it by injecting javascript fragments in it.
>
> I would like to achieve a better elisp/DOM bridge for my purposes but
> I'm procrastinating it because it's not obvious how to do it in an
> interesting way.

The idea that grows in my head is to have all the emacs rendering done
using webkit.  That means seamless integration of multimedia components
into our beloved text based environment, and I think it would only be
good news.

Regards,
-- 
dim

Re: HTML5 the new lisp ?

[Lars Ingebrigtsen]

Dimitri Fontaine <dim@tapoueh.org> writes:

> The idea that grows in my head is to have all the emacs rendering done
> using webkit.

I think a more fruitful path would be to make the Emacs rendering engine
stronger so that we could allow real wysiwyg editing as well as nice
HTML rendering.

Of course, I'm not volunteering to rewrite the Emacs rendering engine.
:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: HTML5 the new lisp ?

[joakim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Dimitri Fontaine <dim@tapoueh.org> writes:
>
>> The idea that grows in my head is to have all the emacs rendering done
>> using webkit.
>
> I think a more fruitful path would be to make the Emacs rendering engine
> stronger so that we could allow real wysiwyg editing as well as nice
> HTML rendering.
>
> Of course, I'm not volunteering to rewrite the Emacs rendering engine.
> :-)

Well. The current display engine is not too bad at what it does. It
caters to a lot of usecases. Extending it to allow embedding of more
object types as is done in the Xwidget branch is IMHO a logical extension.

Extending the Emacs display engine so it allows for all aspects of all
webstandards is not reasonable. Improving it so that SHR for instance
can do a better job is another matter and quite reasonable.

Making a new port of Emacs to the HTML5 canvas might also be
reasonable. OTOH the gains and ease of doing this should not be
overstated. For instance, when I implemented the pretty basic Emacs
paradigm of splitting Emacs windows in two for the webkit xwidget, I had
to do a lot of GTK level hacking, rendering to offscreen bitmaps and
copying to multiple on-screen destinations. I haven't seen any mainstream
browser do this in fact. So, a html5 canvas is still just a canvas even
if its new and shiny and doesn't automatically give us all the stuff we
take for granted with Emacs.

-- 
Joakim Verona

Re: HTML5 the new lisp ?

[Andreas Röhler]

Am 01.08.2011 15:50, schrieb joakim@verona.se:
> Lars Ingebrigtsen<larsi@gnus.org>  writes:
>
>> Dimitri Fontaine<dim@tapoueh.org>  writes:
>>
>>> The idea that grows in my head is to have all the emacs rendering done
>>> using webkit.
>>
>> I think a more fruitful path would be to make the Emacs rendering engine
>> stronger so that we could allow real wysiwyg editing as well as nice
>> HTML rendering.
>>
>> Of course, I'm not volunteering to rewrite the Emacs rendering engine.
>> :-)
>
> Well. The current display engine is not too bad at what it does. It
> caters to a lot of usecases. Extending it to allow embedding of more
> object types as is done in the Xwidget branch is IMHO a logical extension.
>
> Extending the Emacs display engine so it allows for all aspects of all
> webstandards is not reasonable. Improving it so that SHR for instance
> can do a better job is another matter and quite reasonable.
>
> Making a new port of Emacs to the HTML5 canvas might also be
> reasonable. OTOH the gains and ease of doing this should not be
> overstated. For instance, when I implemented the pretty basic Emacs
> paradigm of splitting Emacs windows in two for the webkit xwidget, I had
> to do a lot of GTK level hacking, rendering to offscreen bitmaps and
> copying to multiple on-screen destinations. I haven't seen any mainstream
> browser do this in fact. So, a html5 canvas is still just a canvas even
> if its new and shiny and doesn't automatically give us all the stuff we
> take for granted with Emacs.
>

Hi,

tried to check out that way:

bzr branch bzr://bzr.savannah.gnu.org/emacs/xwidget

got

bzr: ERROR: Connection closed: Unexpected end of message. Please check 
connectivity and permissions, and report a bug if problems persist.

Net is ok, sending this mail thereupon,

any idea?

Thanks,

Andreas

Re: HTML5 the new lisp ?

[Antoine Levitt]

02/08/11 13:09, Andreas Röhler
>
> Hi,
>
> tried to check out that way:
>
> bzr branch bzr://bzr.savannah.gnu.org/emacs/xwidget
>
> got
>
> bzr: ERROR: Connection closed: Unexpected end of message. Please check
> connectivity and permissions, and report a bug if problems persist.
>
> Net is ok, sending this mail thereupon,
>
> any idea?
>
> Thanks,
>
> Andreas

See the thread "Emacs bzr access problems" on this list.

What would a 21st centruy text render engine do -was: Re: HTML5 the new lisp ?

[Sander Boer]

>>>>> "JV" == joakim  <joakim@verona.se> writes:

...[38 lines removed]...
    JV| 
    JV| I'm not really sure what you are talking about but if you want
    JV| to play with Emacs and HTML5 it is possible in a primitive way
    JV| with the xwidget branch. You can create a webkit area in an
    JV| Emacs buffer and manipulate it by injecting javascript fragments
    JV| in it.
    JV| 
    JV| I would like to achieve a better elisp/DOM bridge for my
    JV| purposes but I'm procrastinating it because it's not obvious how
    JV| to do it in an interesting way. (Either by machine generating
    JV| DOM bindings with Cedet/SRecode, or by making some form of
    JV| adapter compatible with xml-parse-region)
    JV| 
    JV| Anyway, if some of this HTML5 enthusiasm could be directed into
    JV| the furtherance of the xwidget branch, that would be
    JV| splendiferous :)
    JV| 
    JV| -- Joakim Verona
    JV| 
    JV| 
    JV| 

Dear Joakim,
I'm taking a top-down approach to this idea ("what does it all mean? ")
because I am, as you might have guessed, code-agnostic as in pretty n00b.
My n00b-ness notwithstanding, I am convinced that your work can unlock
unlimited potential for emacs as a platform.

As such I am rallying support for your effort and trying to engage a
discussion on what a good implementation paradigm could be.

Your approach to let's call it an opt-in canvas is a great way to
implement a feature that can be perceived as an add-on, making it easier
to dismiss.
The discussion on whether the basic rendering engine of emacs is in need
of close inspection is still valid and I wonder where the points of
resistance are. Surely, the difficulty of (core) implementation can be
overcome if there is widespread acceptance of its necessity.  

What would a 21st century  text render engine do ? 
1. look gorgeous (how does one domesticate a mix of variable width and
mono spaced fonts) 
2.  provide a platform that caters to GUIs as well as terminals 

Where @1 can be dismissed as subjective and we land ourselves in a
'public acceptance' discussion, I would like to start off by simply
stating that a aesthetics contribute to quality of life.
Also, from a coding point of view, there is something to be said for
coding on a platform that will be the platform of most Internet
connected devices. 
Comments in variable width fonts anyone ? with hyper-links ? in-code
bug-tracker ? in-code collaboration ?!

@2 however touches the core of the text-rendering paradigm as it is now
and I feel it is an unnecessary duality that takes the weakest platform
(terminals) as its starting point. I know that did not happen by choice
but by progressing from a term-based environment to a GUI based
environment. Today's emacs acts and feels like an upgraded terminal app.
I feel the opposite approach must be investigated, where one would
'downgrade' a GUI app to fit a terminal environment, much akin to the
term browsers we like so much.

-- 
Sander Boer