Commit 723d0cfb authored by adriana's avatar adriana

Import with [PATCH sourceforge] Initial HTML fixes, new PSGML site validation...

Import with [PATCH sourceforge] Initial HTML fixes, new PSGML site validation <>

branch : adriana
parent 2f1bd43f2904
XEmacs projects to be encouraged
Ben Wing; HTML-ized by jsja
<h1>XEmacs projects to be encouraged</h1>
<p>This file lists highly interesting XEmacs-related work, being done
outside of the standard XEmacs community, which should be actively
encouraged and brought into the fold.
<ol type="1">
<li>EIEIO - Eric Ludlam
<a href=""></a>
<li>Write up of all the various profiling experiments, in detail, so
that there is collective memory concerning what has been done, so that
people in the future trying to do profiling will have a large source
of info about how to do this.
\ No newline at end of file
MULE plan
Ben Wing; HTML-ized by jsja
<h1>MULE Plan</h1>
<p>Here is a more detailed list of Mule-related projects that we will be
working on. They are more or less ordered according to how we will
proceed, but it's not exact. In particular, there will probably be
time overlap among adjacent projects.
<ol type="1">
<li>Modify the internal/external conversion macros to allow for MS
Windows support.
<li>Modify the buffer macros to allow for more than one internal
representation, e.g. fixed width and variable width.
<li>Review the existing Mule code, especially the lisp code, for code
quality issues and improve the cleanliness of it. Also work on
creating a specification for the Mule API.
<li>Write some more automated mule tests.
<li>Integrate Tomohiko's UTF-2000 code, fixing it up so that nothing
is broken when the UTF-2000 configure option is not enabled.
<li>Fix up the MS Windows code to be Mule-correct, so that you can
compile with Mule support under MS windows and have a working XEmacs,
at least just with Latin-1.
<li>Implement a scheme to guarantee no corruption of files, even with
an incorrect coding system - in particular, guarantee no corruption of
binary files.
<li>Make the text property support in XEmacs robust with respect to
string and text operations, so that the `no corruption' support in the
previous entry works properly, even if a lot of cutting and pasting is
<li>Improve the handling of auto-detection so that, when there is any
possibility at all of mistake, the user is informed of the detected
encoding and given the choice of choosing other possibilities.
<li>Improve the support for different language environments in XEmacs,
for example, the priority of coding systems used in auto-detection
should properly reflect the language environment. This probably
necessitates rethinking the current `coding system priority' scheme.
<li>Do quality work to improve the existing UTF-2000 implementation.
<li>Implement preliminary support for 8-bit fixed width
representation. First, we will only implement 7-bit support, and will
fall back to variable width as soon as any non-ASCII character is
encountered. Then we will improve the support to handle an arbitrary
character set in the upper half of the 8-bit space.
<li>Investigate any remaining hurdles to making
<code>--with-mule</code> be the default configure option.
Important package-related changes
Ben Wing; HTML-ized by jsja
<h1>Important package-related changes</h1>
<p>This file details changes that make the package system no longer an
unmitigated disaster. This way, at the very least, people can
essentially ignore the package system and not get bitten horribly the
way they currently do.
<ol type="1">
<li>A single tarball containing absolutely everything and named
xemacs-21.2.68.tar.gz. This must contain absolutely everything,
including all of the packages, and in the proper directory structure,
so that the paradigm for <code>untar; configure; make; make
install</code> just works.
<li>Fixed startup slowdown when all packages are installed so that
there is absolutely no penalty to having them all installed. This may
be hard.
<li>All files on the ftp site should be accessible through http.
<li>Put symlinks into the distribution directory to the appropriate
files in the package directory.
<li>Eliminate the confusing SUMO name, choosing a much more obvious
name such as all-packages.
<li>There should be no separation of mule and non-mule packages.
<li>Having 2 packages that conflict with each other should be
completely disallowed.
<li>Fix vc and ps-print so that there is only ONE version.
<li>Fix up all of the READMEs on the distribution site to make it
abundantly clear what needs to be obtained, where to get it, and how
to install it, especially with regards to packages.
\ No newline at end of file
Lisp callbacks from critical areas of the C code
Ben Wing; HTML-ized by jsja
<h1>Lisp callbacks from critical areas of the C code</h1>
<p>There are many places in the XEmacs C code where Lisp functions are
called, usually because the Lisp function is acting as a callback,
hook, process filter, or the like. The lisp code is often called in
places where some lisp operations are dangerous. Currently there are
a lot of ad-hoc schemes implemented to try to prevent these dangerous
operations from causing problems. I've added a lot of them myself,
for example, the call*_trapping_errors() functions. Other places,
such as the pre-gc- and post-gc-hooks, do their own ad hoc processing.
I'm proposing a scheme that would generalize all of this ad hoc code
and allow Lisp code to be called in all sorts of sensitive areas of
the C code, including even within redisplay.
<p>Basically, we define a set of operations that are disallowable
because they are dangerous. We essentially assign a bit flag to all
of these operations. Whenever any sensitive C code wants to call Lisp
code, instead of using the standard call* functions, it uses a new set
of functions, call*_critical, which takes an extra parameter, which is
a bit mask specifying the set of operations which are disallowed. The
basic operations of these functions is simply to set a global variable
corresponding to the bit mask (more specifically, the functions store
the previous value of this global variable in an unwind_protect, and
use bitwise-or to combine the previous value with the new bit mask
that was passed in). (Actually, we should first implement a slightly
lower level function which is called enter_sensitive_code_section(),
which simply sets up the global variable and the unwind_protect(), and
returns a specbind() value, but doesn't actually call any Lisp code.
There is a corresponding function exit_sensitive_code_section(), which
takes the specbind value as an argument, and unwinds the
unwind_protect. The call*_sensitive functions are trivially
implemented in terms of these lower level functions.)
<p>Corresponding to each of these entries is the C name of the bit
<p>The sets of dangerous operations which can be prohibited are:
<dt>garbage collection. When this flag is set, and the garbage
collection threshold is reached, garbage collection simply doesn't
happen. It will happen at the next opportunity that it is allowed.
Similarly, explicitly calling the Lisp function garbage-collect
simply does nothing.
<dt>signalling an error. When enter_sensitive_code_section() is
called, with the bit flag corresponding to this prohibited
operation. When this bit flag is passed to
enter_sensitive_code_section(), a catch is set up which catches all
errors, signals a warning with warn_when_safe(), and then simply
continues. This is exactly the same behavior you now get with the
call_*_trapping_errors() functions. (there should also be some way
of specifying a warning level and class here, similar to the
call_*_trapping_errors() functions. This is not completely
important, however, because a standard warning level and class could
simply be chosen.)
<dt>This flag prohibits deletion of any permanent object (i.e. any
object that does not automatically disappear when created, such as
buffers, frames, devices, windows, etc...) unless they were created
after this bit flag was set. This would be implemented using a list
which stores all of the permanent objects created after this bit
flag was set. This list is reset to its previous value when the
call to exit_sensitive_code_section() occurs. The motivation here
is to allow Lisp callbacks to create their own temporary buffers or
frames, and later delete them, but not allow any other permanent
objects to be deleted, because C code might be working with them,
and not expect them to change.
<dt>This flag disallows modifications to the text, extent or any
other properties of any buffers except those created after this flag
was set, just like in the previous entry.
<dt>This bit flag inhibits any redisplay-related operations from
happening, more specifically, any entry into the redisplay-related
code. This includes, for example, the Lisp functions sit-for,
force-redisplay, force-cursor-redisplay, window-end with certain
arguments to it, and various other functions. When this flag is set,
instead of entering the redisplay code, the calling function should
simply make sure not to enter the redisplay code, (for example, in
the case of window-end), or postpone the redisplay until such a time
when it's safe (for example, with sit-for and force-redisplay).
<dt>This flag prohibits any modifications to faces, glyphs,
specifiers, extents, or any other settings that will affect the way
that any window is displayed.
<p> The idea here is that it will finally be safe to call Lisp code
from nearly any part of the C code, simply by setting any combination
of restricted operation bit flags. This even includes from within
redisplay. (in such a case, all of the bit flags need to be set). The
reason that I thought of this is that some coding system translations
might cause Lisp code to be invoked and C code often invokes these
translations in sensitive places.
Redoing translation macros
Ben Wing; HTML-ized by jsja
<h1>Redoing translation macros</h1>
<p>Currently the translation macros (the macros with names such as
<code>GET_C_STRING_CTEXT_DATA_ALLOCA</code>) have names that are
difficult to parse or remember, and are not all that general. In the
process of reviewing the Windows code so that it could be muleized, I
discovered that these macros need to be extended in various ways to
allow for the Windows code to be easily muleized.
<p>Since the macros needed to be changed anyways, I figured it would
be a good time to redo them properly. I propose new macros which have
names like this:
<p>A and C represent the source of the data, and B and D represent the
sink of the data.
<p>All of these macros call either the functions
<code>convert_to_external_format</code> or
<code>convert_to_internal_format</code> internally, with some
massaging of the arguments.
<p>All of these macros take the following arguments:
<li>First, one or two arguments indicating the source of the data.
<li>Second, an argument indicating the coding system. (In order to
avoid an excessive number of macros, we no longer provide separate
macros for specific coding systems.)
<li>Third, one or two arguments indicating the sink of the data.
<li>Fourth, optionally, arguments indicating the error behavior and
the warning class (these arguments are only present in the _1
versions of the macros). The other, shorter named macros are
trivial interfaces onto these macros with the error behavior being
ERROR_ME_WARN, with the warning class being Vstandard_warning_class.
<p>&lt;A&gt; can be one of the following:
<li><code>LISP</code> (which means a Lisp string) Takes one
argument, a Lisp Object.
<li><code>LSTREAM</code> (which indicates an lstream) Takes one
argument, an lstream. The data is read from the lstream until EOF
is reached.
<li><code>DATA</code> (which indicates a raw memory area) Takes two
arguments, a pointer and a length in bytes. (You must never use
this if the source of the data is a Lisp string, because of the
possibility of relocation during garbage collection.)
<p>&lt;B&gt; can be one of the following:
<li><code>ALLOCA</code> (which means that the resulting data is
stored in alloca()ed memory. Two arguments should be specified, a
pointer and a length, which should be lvalues.)
<li><code>MALLOC</code> (which means that the resulting data is
stored in malloc()ed memory. Two arguments should be specified, a
pointer and a length. The memory must be free()d by the caller.
<li><code>OPAQUE</code> (which means the resulting data is stored in
an opaque Lisp Object. This takes one argument, a lvalue Lisp
<li><code>LSTREAM</code>. The data is written to an lstream.
<p>&lt;C&gt; can be one of the :
(just like &lt;A&gt; above)
<p>&lt;D&gt; can be one of
<li><code>LISP</code> This means a Lisp String.
<li><code>BUFFER</code> The resulting data is inserted into a buffer at the
buffer's value of point.
<li><code>LSTREAM</code> The data is written to the lstream.
<p>Note that I have eliminated the <code>FORMAT</code> argument of
previous macros, and replaced it with a coding system. This was made
possible by coding system aliases. In place of old `format's, we use
a `virtual coding system', which is aliased to the actual coding
<p>The value of the coding system argument can be anything that is
legal input to <code>get_coding_system</code>, i.e. a symbol or a
coding system object.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment