Commits

Anonymous committed e1f221a

Normalize HTML tags to lower-case

Comments (0)

Files changed (1)

Architecting-XEmacs/compat-package.content

 
 %main%
 
-<CENTER><H1>Elisp Compatibility Package</H1></CENTER>
+<center><h1>Elisp Compatibility Package</h1></center>
 
-<P><B>Owner: </B> ???</P>
-<P><B>Effort: </B> ???</P>
-<P><B>Dependencies: </B> ???</P>
-<P><B>Abstract:  </B> ???</P>
+            <p><strong>Owner:</strong>  ???</p>
+            <p><strong>Effort:</strong> ???</p>
+            <p><strong>Dependencies:</strong> ???</p>
+            <p><strong>Abstract:</strong> ???</p>
 
-<P>A while ago I created a package called Sysdep, which aimed to be a
+<p>A while ago I created a package called Sysdep, which aimed to be a
 forward compatibility package for Elisp.  The idea was that instead of
 having to write your package using the oldest version of Emacs that
 you wanted to support, you could use the newest XEmacs API, and then
 was good, but its design wasn't perfect, and it wasn't widely adopted.
 I propose a new package called Compat that corrects the design flaws
 in Sysdep, and hopefully will be adopted by most of the major
-packages.</P>
+packages.</p>
 
-<P>In addition, this package will provide macros that can be used to
+<p>In addition, this package will provide macros that can be used to
 bracket code as necessary to disable byte compiler warnings generated
 as a result of supporting the APIs of different versions of Emacs; or
 rather the Compat package strives to provide useful constructs to make
 understandable Elisp that supports both older and newer APIs, and has
 no byte compiler warnings.  Currently many warnings are unavoidable,
 and as a result, they are simply ignored, which also causes a lot of
-legitimate warnings to be ignored.</P>
+legitimate warnings to be ignored.</p>
 
-<P>The approach taken by the Sysdep package to make sure that the
+<p>The approach taken by the Sysdep package to make sure that the
 newest API was always supported was fairly simple: when the Sysdep
 package was loaded, it checked for the existence of new API functions,
 and if they weren't defined, it defined them in terms of older API
 by checking for the existence of certain functions within that API.
 In addition, the Sysdep package did not scale well because it defined
 all of the functions that it supported, regardless of whether or not
-they were used.</P>
+they were used.</p>
 
-<P>The Compat package remedies the first problem by ensuring that the
+<p>The Compat package remedies the first problem by ensuring that the
 new APIs are defined only within the lexical scope of the packages
 that actually make use of the Compat package.  It remedies the second
 problem by ensuring that only definitions of functions that are
 actually used are loaded.  This all works roughly according to the
-following scheme:</P>
+following scheme:</p>
 
-<OL>
+<ol>
 
-<LI><P>Part of the Compat package is a module called the Compat
+<li><p>Part of the Compat package is a module called the Compat
 generator.  This module is actually run as an additional step during
 byte compilation of a package that uses Compat.  This can happen
 either through the makefile or through the use of an
-<CODE>eval-when-compile</CODE> call within the package code itself.
+<code>eval-when-compile</code> call within the package code itself.
 What the generator does is scan all of the Lisp code in the package,
 determine which function calls are made that the Compat package knows
-about, and generates custom <CODE>compat</CODE> code that
+about, and generates custom <code>compat</code> code that
 conditionally defines just these functions when the package is loaded.
-The custom <CODE>compat</CODE> code can either be written to a
+The custom <code>compat</code> code can either be written to a
 separate Lisp file (for use with multi-file packages), or inserted
 into the beginning of the Lisp file of a single file package.  (In the
 latter case, the package indicates where this generated code should go
 through the use of magic comments that mark the beginning and end of
 the section.  Some will say that doing this trick is bad juju, but I
 have done this sort of thing before, and it works very well in
-practice).</P>
+practice).</p></li>
 
-<LI><P>The functions in the custom <CODE>compat</CODE> code have their
+<li><p>The functions in the custom <code>compat</code> code have their
 names prefixed with both the name of the package and the word
-<CODE>compat</CODE>, ensuring that there will be no name space
+<code>compat</code>, ensuring that there will be no name space
 conflicts with other functions in the same package, or with other
-packages that make use of the Compat package.</P>
+packages that make use of the Compat package.</p></li>
 
-<LI><P>The actual definitions of the functions in the custom
-<CODE>compat</CODE> code are determined at run time.  When the
+<li><p>The actual definitions of the functions in the custom
+<code>compat</code> code are determined at run time.  When the
 equivalent API already exists, the wrapper functions are simply
 defined directly in terms of the actual functions, so that the only
 run time overhead from using the Compat package is one additional
 avoided by retrieving the definitions of the actual functions and
 supplying them as the definitions of the wrapper functions.  However,
 this appears to me to not be completely safe.  For example, it might
-have bad interactions with the advice package).</P>
+have bad interactions with the advice package).</p></li>
 
-<LI><P>The code that wants to make use of the custom
-<CODE>compat</CODE> code is bracketed by a call to the construct
-<CODE>compat-execute</CODE>.  What this actually does is lexically
+<li><p>The code that wants to make use of the custom
+<code>compat</code> code is bracketed by a call to the construct
+<code>compat-execute</code>.  What this actually does is lexically
 bind all of the function names that are being redefined with macro
 functions by using the Common Lisp macro macrolet.  (The definition of
 this macro is in the CL package, but in order for things to work on
 all platforms, the definition of this macro will presumably have to be
-copied and inserted into the custom <CODE>compat</CODE> code).</P>
+copied and inserted into the custom <code>compat</code> code).</p></li>
 
-</OL>
+</ol>
 
-<P>In addition, the Compat package should define the macro
-<CODE>compat-if-fboundp</CODE>.  Similar macros such as
-<CODE>compile-when-fboundp</CODE> and
-<CODE>compile-case-fboundp</CODE> could be defined using similar
-principles).  The <CODE>compat-if-fboundp</CODE> macro behaves just
-like an <CODE>(if (fboundp ...) ...)</CODE> clause when executed, but
+<p>In addition, the Compat package should define the macro
+<code>compat-if-fboundp</code>.  Similar macros such as
+<code>compile-when-fboundp</code> and
+<code>compile-case-fboundp</code> could be defined using similar
+principles).  The <code>compat-if-fboundp</code> macro behaves just
+like an <code>(if (fboundp ...) ...)</code> clause when executed, but
 in addition, when it's compiled, it ensures that the code inside the
-<CODE>if-true</CODE> sub-block will not cause any byte compiler
+<code>if-true</code> sub-block will not cause any byte compiler
 warnings about the function in question being unbound.  I think that
 the way to implement this would be to make
-<CODE>compat-if-fboundp</CODE> be a macro that does what it's supposed
+<code>compat-if-fboundp</code> be a macro that does what it's supposed
 to do, but which defines its own byte code handler, which ensures that
 the particular warning in question will be suppressed.  (Actually
 ensuring that just the warning in question is suppressed, and not any
 others, might be rather tricky.  It certainly requires further
-thought).</P>
+thought).</p>
 
-<P>Note: An alternative way of avoiding both warnings about unbound
+<p>Note: An alternative way of avoiding both warnings about unbound
 functions and warnings about obsolete functions is to just call the
-function in question by using <CODE>funcall</CODE>, instead of calling
+function in question by using <code>funcall</code>, instead of calling
 the function directly.  This seems rather inelegant to me, though,
 and doesn't make it obvious why the function is being called in such a
 roundabout manner.  Perhaps the Compat package should also provide a
-macro <CODE>compat-funcall</CODE>, which works exactly like
-<CODE>funcall</CODE>, but which indicates to anyone reading the code
-why the code is expressed in such a fashion.</P>
+macro <code>compat-funcall</code>, which works exactly like
+<code>funcall</code>, but which indicates to anyone reading the code
+why the code is expressed in such a fashion.</p>
 
-<P>If you're wondering how to implement the part of the Compat
+<p>If you're wondering how to implement the part of the Compat
 generator where it scans Lisp code to find function calls for
 functions that it wants to do something about, I think the best way is
-to simply process the code using the Lisp function <CODE>read</CODE>
+to simply process the code using the Lisp function <code>read</code>
 and recursively descend any lists looking for function names as the
 first element of any list encountered.  This might extract out a few
 more functions than are actually called, but it is almost certainly
 safer than doing anything trickier like byte compiling the code, and
 attempting to look for function calls in the result.  (It could also
 be argued that the names of the functions should be extracted, not
-only from the first element of lists, but anywhere <CODE>symbol</CODE>
+only from the first element of lists, but anywhere <code>symbol</code>
 occurs.  For example, to catch places where a function is called using
-<CODE>funcall</CODE> or <CODE>apply</CODE>.  However, such uses of
+<code>funcall</code> or <code>apply</code>.  However, such uses of
 functions would not be affected by the surrounding macrolet call, and
-so there doesn't appear to be any point in extracting them).</P>
+so there doesn't appear to be any point in extracting them).</p>
 
-<HR> <ADDRESS><A HREF="http://www.666.com/ben/">Ben Wing</A></ADDRESS>
-
+<hr> <address><a href="http://www.666.com/ben/">Ben Wing</a></address>