all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Andreas Röhler" <andreas.roehler@online.de>
To: joakim@verona.se
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: HTML5 the new lisp ?
Date: Tue, 02 Aug 2011 13:09:18 +0200	[thread overview]
Message-ID: <4E37DADE.60003@online.de> (raw)
In-Reply-To: <m3y5zdnsuw.fsf@verona.se>

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



  reply	other threads:[~2011-08-02 11:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-31 20:25 HTML5 the new lisp ? Sander Boer
2011-07-31 20:42 ` Thien-Thi Nguyen
2011-07-31 22:26 ` joakim
2011-08-01 11:58   ` Dimitri Fontaine
2011-08-01 12:14     ` Lars Ingebrigtsen
2011-08-01 13:50       ` joakim
2011-08-02 11:09         ` Andreas Röhler [this message]
2011-08-02 11:19           ` Antoine Levitt
2011-08-02 10:40   ` What would a 21st centruy text render engine do -was: " Sander Boer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E37DADE.60003@online.de \
    --to=andreas.roehler@online.de \
    --cc=emacs-devel@gnu.org \
    --cc=joakim@verona.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.