[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ELPA-diffs] ELPA branch, externals/w3, updated. 32676aeae568f936fa27247
From: |
Stefan Monnier |
Subject: |
[ELPA-diffs] ELPA branch, externals/w3, updated. 32676aeae568f936fa2724741d8d3330bd689a7d |
Date: |
Sun, 25 Aug 2013 22:16:53 +0000 |
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "ELPA".
The branch, externals/w3 has been updated
via 32676aeae568f936fa2724741d8d3330bd689a7d (commit)
from 1ba24a1bb49e1d9be7e6539cf857c08566d58575 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 32676aeae568f936fa2724741d8d3330bd689a7d
Author: Stefan Monnier <address@hidden>
Date: Sun Aug 25 18:16:09 2013 -0400
Update README, version, and home page url
diff --git a/README b/README
index a332285..e15a397 100644
--- a/README
+++ b/README
@@ -1,39 +1,12 @@
-This directory tree holds version $State: p4.0pre.47 $ of Emacs/W3, the fully
-customizable, largely undocumented web browser for Emacs.
-
-You may encounter bugs in this release. If you do, please report
-them; your bug reports are valuable contributions to Emacs/W3, since
-they allow us to notice and fix problems on machines we don't have, or
-in code we don't use often. See the file BUGS for more information on
-how to report bugs.
-
-The file INSTALL in this directory says how to bring up Emacs/W3 on
-Unix, once you have loaded the entire subtree of this directory.
-
-Note that the Emacs/W3 installation procedure has changed since
-version 2.x; you will probably want to read the file INSTALL even if
-you have installed Emacs/W3 before. The new procedure is intended to
-simplify installation, and make it easier to upgrade in the future.
-
-Reports of bugs in Emacs/W3 should be sent to the mailing list
address@hidden See the "Reporting Bugs" section of the
-Emacs/W3 manual for more information on how to report bugs. See the
-"More Help" section of the Emacs/W3 manual for more information on
-mailing lists relating to Emacs/W3.
-
-The file `configure' is a shell script to acclimate Emacs to the
-oddities of your processor and operating system. It creates the file
-`Makefile' (a script for the `make' program), which automates the
-process of building and installing Emacs. See INSTALL for more
-detailed information.
-
-There are several subdirectories:
-
-`etc' holds miscellaneous architecture-independent data files
-`lisp' holds the lisp code for Emacs/W3
-`texi' holds the documentation tree for Emacs/W3
-`contrib' holds user-contributed utilities that are not officially supported
-
-This version requires either Emacs 20.3 or later, or XEmacs 20.4 or
-later. For Emacs, at least 20.4 is recommended since 20.3 (the first
-release of Mule 4) was somewhat buggy.
+Emacs/W3 is a web browser written entirely in Emacs Lisp. As such, it has
+unique strengths and drawbacks. The strengths are related to its integration
+with Emacs; the drawbacks are that it is relatively slow and sometimes
+blocks your editing session. Development has been dormant for a couple of
+years, so expect bugs due to bit rot.
+Please report bugs via M-x report-emacs-bug.
+
+This is a very rough pass at the web site (by the original author) just to
+get some thoughts down and accessible to more people. The project page @
+Savannah has a fairly detailed task list. A brief description of each
+component and a list of questions and/or resources related to it may be
+found in the following documents.
diff --git a/TODO b/TODO
index f18ea85..121eeee 100644
--- a/TODO
+++ b/TODO
@@ -75,3 +75,92 @@ FEATURES (5.0)
- implement <spacer> from netscape 3.0b5
- Handle math environment using the calc library
- Better integration with the parser
+
+######### Notes from the old web site: ######################################
+
+* HTML & XML Parsers
+
+Any web browser must be able to parse HTML, and XML becoming more and more
+important. This component would provide a pair of parsers (or a generic
+SGML parser that can deal with both subsets) that output a consistent parse
+tree. This would be the foundation for the DOM work (see below).
+
+ How to deal with old-style HTML, or HTML that does not conform to the
+ DTD? Should we key off of the existence of a valid DOCTYPE and
+ use a strict parser, and fall back to something based off of the current
+ w3-parse.el code for DOCTYPE-less documents? Or always use the same
+ heuristics to guess what the author really meant?
+ Do we really need two separate parsers for HTML and XML? PSGML can parse
+ well-formed HTML or any XML document (which is by definition
+ well-formed, or the parser can gleefully choke it to death).
+ Can PSGML be persuaded to do what we want? It seems that using the
+ existing API (sgml-top-element, sgml-element-next, sgml-element-content)
+ would be feasible. On the plus side, this would allow the DOM to work on
+ arbitrary SGML documents (LinuxDoc or DocBook anyone?).
+ Should the parsers be able to deal with streaming data? It would be
+ theoretically possible to parse the document as it comes in off the
+ network. Do we really care?
+
+* Document Object Model (DOM)
+
+This would involve writing a DOM binding for Emacs Lisp.
+
+ The Document Object Model is a platform- and language-neutral interface
+ that will allow programs and scripts to dynamically access and update
+ the content, structure and style of documents. The document can be
+ further processed and the results of that processing can be incorporated
+ back into the presented page.
+
+This binding would present the standard objects and methods to a programmer,
+doing any necessary conversion from the DOM to the underlying
+parse representation.
+
+Packages like the Gnus web-based backends could use URL + PARSER + DOM to do
+all of their work instead of requiring all of Emacs/W3, which they generally
+care very little about. This could also be used by Emacspeak to do better
+table reading, etc. It could even do something really ambitious and not
+render the document visually at all. SGML/HTML/XML to Postscript using the
+DOM would be tractable as well.
+
+ Is anyone currently working on a DOM binding for Lisp or Scheme? Could
+ base the design of the bindings off of that work. There is a Common Lisp
+ Binding that looks fairly complete.
+ Can work on the specification of the bindings before finishing the
+ parser work, but actual implementation would depend greatly on how the
+ parser works.
+ What level of conformance to actually shoot for? What things in the DOM
+ recommendation would be strictly impossible in Emacs?
+ How realistic is it to expect changes made thru the DOM to immediately
+ reflect themselves in an Emacs buffer?
+
+* Stylesheet system
+
+In order for any of this to actually be SEEN by the end user, display
+properties must be associated with the parse tree. This
+requires a stylesheet parser (CSS at the very least, XSL would be nice). See
+the W3C Style Area for more information on stylesheets.
+
+This component would really just be a parser and an API to get all the style
+information associated with a NODE from the DOM. This will be used by the
+display engine to actually draw text on the screen.
+
+ What level of CSS should we target?
+ Getting ALL of the style information associated from a DOM node should
+ be much simpler than the current css.el code.
+
+* Display engine
+
+The final component would bring all the various pieces together and actually
+look like a web browser to the outside world. This would take a Document
+object from the DOM and an associated stylesheet and scribble all over
+the buffer.
+
+The current code in w3-display.el is very close to working strictly
+from a stylesheet. The lone exception is support for tables, but the patches
+to make tables work strictly off the stylesheet would be straighforward.
+
+There could even be more than one... one tuned for speed that VM and Gnus
+could use that would be really fast, but not do tables or other
+time-intensive features, and one that would be the full-blown web browser.
+
+ How to reflect changes to the document after drawing has finished?
diff --git a/w3.el b/w3.el
index d521dbb..310a9a6 100644
--- a/w3.el
+++ b/w3.el
@@ -3,7 +3,7 @@
;; Copyright (c) 1996-2001, 2007-2008, 2013 Free Software Foundation, Inc.
;; Author: William Perry and many more
-;; Version: 4.0.48
+;; Version: 4.0.49
;; Keywords: faces, help, comm, news, mail, processes, mouse, hypermedia
;; This file is part of GNU Emacs.
@@ -1828,7 +1828,7 @@ Emacs."
(or w3-default-homepage
(setq w3-default-homepage
(or (getenv "WWW_HOME")
- "http://www.gnu.org/software/w3/")))
+ "http://elpa.gnu.org/packages/w3.html")))
(run-hooks 'w3-load-hook)))
-----------------------------------------------------------------------
Summary of changes:
README | 51 ++++++++----------------------------
TODO | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
w3.el | 4 +-
3 files changed, 103 insertions(+), 41 deletions(-)
hooks/post-receive
--
ELPA
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [ELPA-diffs] ELPA branch, externals/w3, updated. 32676aeae568f936fa2724741d8d3330bd689a7d,
Stefan Monnier <=