all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Thomas Lord <lord@emf.net>
To: Antoine Levitt <smeuuh@gmail.com>
Cc: rms@gnu.org, pmr@pajato.com, Chong Yidong <cyd@stupidchicken.com>,
	lennart.borgman@gmail.com, joakim@verona.se, emacs-devel@gnu.org,
	monnier@iro.umontreal.ca, raman@users.sourceforge.net,
	phil@shellarchive.co.uk
Subject: Re: An Emacs plug-in for a browser (Firefox?)
Date: Mon, 08 Sep 2008 12:05:51 -0700	[thread overview]
Message-ID: <48C5778F.2020203@emf.net> (raw)
In-Reply-To: <6fa54e4e0809081007l68f1df2ei71450cf3483f2d17@mail.gmail.com>

Antoine Levitt wrote:
> Having browser windows in emacs would also allow allow users to 
> benefit from emacs window capabilities (fuzzy completion with 
> ido-mode, listing/filter with ibuffer, tabs, side-by-side splitting, 
> and basically whatever else folks decide to code in elisp). Classical 
> web browser basically have tabs, and keybindings to next/previous 
> tabs. Emacs would make it much more powerful.
> Besides, as many people noted, it shouldn't be hard to do, since 
> technologies to do so already exist. IMHO, the tough step is getting 
> text and textboxes recognised by emacs, but even without that, it'd 
> still be amazing.
> Good luck to you joakim, and please consider browsers as an equally 
> useful target of embedding as multimedia apps.

It won't work, unfortunately.   It's a lovely fantasy for
a nice system -- I like the sentiment -- but it won't (can't)
work:

Emacs has the concept that two windows can look at the same
buffer.

HTML/DOM/CSS/Javascript are based on the assumption
that only one window exists for a given page.   This
assumption is deeply reflected in the APIs and data structures.

Imagining an Emacs window containing a browser view
of some page, any behavior you define for what C-x 2
(split-window-vertically) does (for example) will have
to be kludgey.   Javascript expects a single window.
Events aren't tagged with a window.   Geometry control,
spread over the DOM and CSS, is often in terms of the
absolute geometry of the One window.   It's really,
really, deeply rooted.

This is one that W3C/ECMA got badly wrong, unfortunately.
There's no way to fix it thoroughly other than several
new W3C/ECMA standards that deprecate several existing
standards with which there won't be upward compatibility.
Basically, standards committees will need to pick a kludge,
describe that in several different standards, and then make
up entirely new and incompatible alternatives to the
kludge.   They really messed up (if you believe that multiple
views on a single model are important).


-t




> 2008/9/8 Chong Yidong <cyd@stupidchicken.com 
> <mailto:cyd@stupidchicken.com>>
>
>     "Richard M. Stallman" <rms@gnu.org <mailto:rms@gnu.org>> writes:
>
>     >     Switching constantly between Emacs and Firefox (e.g., by
>     making Emacs
>     >     open links via a separate Firefox application) is inefficient.
>     >
>     > When you say "switching", what does that refer to?
>     > Are you talking about a UI-level operation?
>
>     Yes.
>
>     > In what sense is it inefficient?
>
>     In the same sense that it's less efficient to perform shell operations
>     in a separate xterm, rather than doing M-! or M-x grep or M-x gdb etc.
>     For instance, it's more cumbersome to arrange to view the browser
>     display and side by side with Emacs, since the browser isn't
>     constrained
>     to an Emacs window.
>
>





  reply	other threads:[~2008-09-08 19:05 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04 22:18 An Emacs plug-in for a browser (Firefox?) Paul Michael Reilly
2008-09-05  0:16 ` David De La Harpe Golden
2008-09-05  0:19 ` David House
2008-09-05  2:42 ` T. V. Raman
2008-09-05  4:53   ` Paul Michael Reilly
2008-09-05  6:44     ` joakim
2008-09-05  8:53       ` Phil Jackson
2008-09-05  9:21         ` joakim
2008-09-05  9:30           ` Lennart Borgman (gmail)
2008-09-05 11:20             ` Antoine Levitt
2008-09-06  7:12               ` Richard M. Stallman
2008-09-06 10:48                 ` Antoine Levitt
2008-09-06 21:04                   ` Richard M. Stallman
2008-09-06 21:36                     ` David Hansen
2008-09-06 21:49                       ` Lennart Borgman (gmail)
2008-09-06 22:25                         ` David Hansen
2008-09-06 22:48                           ` Lennart Borgman (gmail)
2008-09-06 23:08                             ` David Hansen
2008-09-06 22:41                       ` Sean O'Rourke
2008-09-07 23:36                       ` Richard M. Stallman
2008-09-06 16:42                 ` Chong Yidong
2008-09-06 16:58                   ` joakim
2008-09-06 19:42                     ` Chong Yidong
2008-09-06 20:20                     ` David Hansen
2008-09-06 21:54                   ` T. V. Raman
2008-09-06 20:11                 ` Stefan Monnier
2008-09-07 17:39                   ` Richard M. Stallman
2008-09-07 17:49                     ` Lennart Borgman (gmail)
2008-09-07 18:29                     ` Chong Yidong
2008-09-08  9:22                       ` Richard M. Stallman
2008-09-08 12:31                         ` Chong Yidong
2008-09-08 17:07                           ` Antoine Levitt
2008-09-08 19:05                             ` Thomas Lord [this message]
2008-09-08 19:07                               ` Antoine Levitt
2008-09-08 20:27                                 ` Thomas Lord
2008-09-08 20:34                               ` Stefan Monnier
2008-09-08 21:33                                 ` joakim
2008-09-08 21:46                                 ` Thomas Lord
2008-09-09  8:11                               ` Richard M. Stallman
2008-09-08 22:13                           ` Richard M. Stallman
2008-09-07 19:55                     ` Stefan Monnier
2008-09-08  9:22                       ` Richard M. Stallman
2008-09-05 13:33         ` T. V. Raman
2008-09-05 13:32     ` T. V. Raman
2008-09-05 20:40   ` Christian Faulhammer

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=48C5778F.2020203@emf.net \
    --to=lord@emf.net \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=joakim@verona.se \
    --cc=lennart.borgman@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=phil@shellarchive.co.uk \
    --cc=pmr@pajato.com \
    --cc=raman@users.sourceforge.net \
    --cc=rms@gnu.org \
    --cc=smeuuh@gmail.com \
    /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.