Update README, version, and home page urlexternals/w3

3 files changed, 103 insertions, 41 deletions

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
-wmperry+w3@cs.indiana.edu.  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)))