xemacs-beta: man/internals/internals.texi comparison

comparison man/internals/internals.texi @ 2182:c91543697b09

[xemacs-hg @ 2004-07-19 08:24:24 by stephent] manual improvements <87n01w9zi9.fsf@tleepslib.sk.tsukuba.ac.jp>

author	stephent
date	Mon, 19 Jul 2004 08:24:28 +0000
parents	97a3d9ad40e2
children	e13775448cf0

comparison

equal deleted inserted replaced

-:5baae9bff30e
+:c91543697b09
 @item
 Speed up redisplay.
 @item
 Speed up syntax highlighting.  It was suggested that ``maybe moving some
 of the syntax highlighting capabilities into C would make a
-difference.''  Wrong idea, I think.  When processing one large file a
+difference.''  Wrong idea, I think.  When processing one 400kB file a
 particular low-level routine was being called 40 @emph{million} times
 simply for @emph{one} call to @code{newline-and-indent}.  Syntax
 highlighting needs to be rewritten to use a reliable, fast parser, then
 to trust the pre-parsed structure, and only do re-highlighting locally
 to a text change.  Modern machines are fast enough to implement such
 @item
 All @file{.c} files should @code{#include <config.h>} first.  Almost all
 @file{.c} files should @code{#include "lisp.h"} second.
 @item
-Generated header files should be included using the @code{#include <...>} syntax,
+Generated header files should be included using the @samp{#include <...>}
-not the @code{#include "..."} syntax.  The generated headers are:
+syntax, not the @samp{#include "..."} syntax.  The generated headers are:
 @file{config.h sheap-adjust.h paths.h Emacs.ad.h}
-The basic rule is that you should assume builds using @code{--srcdir}
+The basic rule is that you should assume builds using @samp{--srcdir}
-and the @code{#include <...>} syntax needs to be used when the
+and the @samp{#include <...>} syntax needs to be used when the
 to-be-included generated file is in a potentially different directory
-@emph{at compile time}.  The non-obvious C rule is that @code{#include "..."}
+@emph{at compile time}.  The non-obvious C rule is that
-means to search for the included file in the same directory as the
+@samp{#include "..."} means to search for the included file in the same
-including file, @emph{not} in the current directory.
+directory as the including file, @emph{not} in the current directory.
+Normally this is not a problem but when building with @samp{--srcdir},
-@item
+@file{make} will search the @samp{VPATH} for you, while the C compiler
-Header files should @emph{not} include @code{<config.h>} and
+knows nothing about it.
-@code{"lisp.h"}.  It is the responsibility of the @file{.c} files that
+@item
+Header files should @emph{not} include @samp{<config.h>} and
+@samp{"lisp.h"}.  It is the responsibility of the @file{.c} files that
 use it to do so.
 @end itemize
 @cindex Lisp object types, creating
 the syntax scanner to recognize that this is a multi-character
 delimiter.  The @samp{newline} character is given (single-character)
 ``comment-end'' @emph{class} and the ``style b first character of end
 sequence'' @emph{flag}.  The ``comment-end'' class allows the scanner to
 determine that no second character is needed to terminate the comment.
+There used to be a syntax class @samp{Sextword}.  A character of
+@samp{Sextword} class is a word-constituent but a word boundary may
+exist between two such characters.  Ken'ichi HANDA <handa@@etl.go.jp>
+explains the purpose of the Sextword syntax category:
+@quotation
+Japanese words are not separated by spaces, which makes finding word
+boundaries very difficult.  Theoretically it's impossible without
+using natural language processing techniques.  But, by defining
+pseudo-words as below (much simplified for letting you understand it
+easily) for Japanese, we can have a convenient forward-word function
+for Japanese.
+@display
+A Japanese word is a sequence of characters that consists of
+zero or more Kanji characters followed by zero or more
+Hiragana characters.
+@end display
+Then, the problem is that now we can't say that a sequence of
+word-constituents makes up a word.  For instance, both Hiragana "A"
+and Kanji "KAN" are word-constituents but the sequence of these two
+letters can't be a single word.
+So, we introduced Sextword for Japanese letters.
+@end quotation
+There seems to have been some controversy about this category, as it has
+been removed, readded, and removed again.  Currently neither GNU Emacs
+(21.3.99) nor XEmacs (21.5.17) seems to use it.
 @example
 casefiddle.c
 @end example
 mule-ccl.c
 mule-charset.c
 mule-charset.h
 file-coding.c
 file-coding.h
+mule-coding.c
 mule-mcpath.c
 mule-mcpath.h
 mule-wnnfns.c
 mule.c
 @end example
 possibly from multiple character sets, using a stream of bytes or words,
 and defines (e.g.) which escape sequences are used to specify particular
 character sets, how the indices for a character are converted into bytes
 (sometimes this involves setting the high bit; sometimes complicated
 rearranging of the values takes place, as in the Shift-JIS encoding),
-etc.
+etc.  It also contains some generic coding system implementations, such
+as the binary (no-conversion) coding system and a sample gzip coding system.
+@file{mule-coding.c} contains the implementations of text coding systems.
 @file{mule-ccl.c} provides the CCL (Code Conversion Language)
 interpreter.  CCL is similar in spirit to Lisp byte code and is used to
 implement converters for custom encodings.
 completely non-working.  Instead, @code{pathname-coding-system} is used
 to specify conversions of names of files and directories.  The standard
 C I/O functions like @samp{open()} are wrapped so that conversion occurs
 automatically.
-@file{mule.c} provides a few miscellaneous things that should probably
+@file{mule.c} contains a few miscellaneous things.  It currently seems
-be elsewhere.
+to be unused and probably should be removed.
 @example
 intl.c
 md5-tests.el
 mule-tests.el
 regexp-tests.el
 symbol-tests.el
 syntax-tests.el
+tag-tests.el
+weak-tests.el
 @end example
 @file{test-harness.el} defines the macros @code{Assert},
 @code{Check-Error}, @code{Check-Error-Message}, and
 @code{Check-Message}.  The other files are test files, testing various
 In XEmacs, glyphs represent the uninstantiated state of graphical
 elements, i.e. they hold all the information necessary to produce an
 image on-screen but the image need not exist at this stage, and multiple
 screen images can be instantiated from a single glyph.
+@c #### find a place for this discussion
+@c The decision to make image specifiers a separate type is debatable.
+@c In fact, the design decision to create a separate image specifier
+@c type, rather than make glyphs themselves be specifiers, is
+@c debatable---the other properties of glyphs are rarely used and could
+@c conceivably have been incorporated into the glyph's instantiator.
+@c The rarely used glyph types (buffer, pointer, icon) could also have
+@c been incorporated into the instantiator.
 Glyphs are lazily instantiated by calling one of the glyph
 functions. This usually occurs within redisplay when
 @code{Fglyph_height} is called. Instantiation causes an image-instance
 to be created and cached. This cache is on a per-device basis for all glyphs
 except widget-glyphs, and on a per-window basis for widgets-glyphs.  The

Mercurial > hg > xemacs-beta

comparison man/internals/internals.texi @ 2182:c91543697b09