view README @ 872:79c6ff3eef26

[xemacs-hg @ 2002-06-20 21:18:01 by ben] font changes etc.; some 21.4 changes mule/mule-msw-init-late.el: Specify charset->windows-registry conversion. mule/mule-x-init.el: Delete extra mule font additions here. Put them in faces.c. cl-macs.el: Document better. font-lock.el: Move Lisp function regexp to lisp-mode.el. lisp-mode.el: Various indentation fixes: Handle flet functions better. Handle argument lists in defuns and flets. Handle quoted lists, e.g. property lists -- don't indent like function calls. Distinguish between lambdas and other lists. lisp-mode.el: Handle this form. faces.el, font-menu.el, font.el, gtk-faces.el, msw-faces.el, msw-font-menu.el, x-faces.el, x-init.el: Major overhaul of face-handling code: -- Fix lots of bogus code in msw-faces.el, msw-font-menu.el, font-menu.el that was "truenaming" font specs -- i.e. in the process of frobbing a particular field in a general user-specified font spec with wildcarded fields, sticking in particular values for all the remaining wildcarded fields. This bug was rampant everywhere except in x-faces.el (the oldest and only correctly written code). This also means that we need to work with font names at all times and not font instances, because a font instance is essentially a truenamed font. -- Total rewrite of extremely junky code in msw-faces.el. Work with names as well as font instances, and return names; stop truenaming when canonicalizing and frobbing; fix handling of the combined style field, i.e. weight/slant (also fixed in font.el). -- Totally rewrite the frobbing functions in faces.el. This time, we frob all the instantiators rather than just computing a single instance value and working backwards. That way, e.g., `bold' will work for all charsets that have bold available, rather than only for whatever charset was part of the computed font instance (another example of the truename virus). Also fix up code to look at the fallbacks (all of them) when no global value present, so we don't need to put something in the global value. Intelligently handle a request to frob a buffer locale, rather than signalling an error. When frobbing instantiators, try hard to figure out what device type is associated with them, and frob each according to its own proper device type. Correctly handle inheritance vectors given as instantiators. Preserve existing tags when putting back frobbed instantiators. Extract out general specifier-frobbing code into specifier.el. Document everything cleanly. Do lots of other things better, etc. -- Don't duplicatively set a global specification for the default font -- it's already in the fallback and we no longer need a default global specification present. Delete various code in x-faces.el and msw-faces.el that duplicated the lists of fonts in faces.c. -- init-global-faces was not being called at all under MS Windows! Major bogosity. That caused device-specific values to get stuck into all the fonts, making it very hard to change them -- setting global specs caused nothing to happen. -- Correct weight names in font.el. -- Lots more font fixups in objects*.c. Printer.el: Warning fix. specifier.el: Add more args to map-specifier. Add various "heuristic" specifier functions to aid in creation of specifier-munging code such as in faces.el. subr.el: New functions. lwlib.c: Fix warning. config.inc.samp: Clean up, add args to control fastcall (not yet supported! the changes needed are in another ws of mine), profile support, vc6 support, union-type. xemacs.dsp, xemacs.mak: Semi-major overhaul. Fix bug where dump-id was always getting recomputed, forcing a redump even when nothing changed. Add support for fastcall. Support edit-and-continue (on by default) with vc6. Use incremental linking when doing a debug compilation. Add support for profiling. Consolidate the various debug flags. Partial support for "batch-compiling" -- compiling many files on a single invocation of the compiler. Doesn't seem to help that much for me, so it's not finished or enabled by default. Remove HAVE_MSW_C_DIRED, we always do. Correct some sloppy use of directories. s/cygwin32.h: Allow pdump to work under Cygwin (mmap is broken, so need to undefine HAVE_MMAP). s/win32-common.h, s/windowsnt.h: Support for fastcall. Add WIN32_ANY for identifying all Win32 variants (Cygwin, native, MinGW). Both of these are properly used in another ws. alloc.c, balloon-x.c, buffer.c, bytecode.c, callint.c, cm.c, cmdloop.c, cmds.c, console-gtk.c, console-gtk.h, console-msw.c, console-msw.h, console-stream.c, console-stream.h, console-tty.c, console-tty.h, console-x.c, console-x.h, console.c, console.h, device-gtk.c, device-msw.c, device-tty.c, device-x.c, device.c, device.h, devslots.h, dialog-gtk.c, dialog-msw.c, dialog-x.c, dialog.c, dired-msw.c, editfns.c, emacs.c, event-Xt.c, event-gtk.c, event-msw.c, event-stream.c, event-tty.c, event-unixoid.c, events.c, extents.c, extents.h, faces.c, fileio.c, fns.c, frame-gtk.c, frame-msw.c, frame-tty.c, frame-x.c, frame.c, frame.h, glyphs-eimage.c, glyphs-gtk.c, glyphs-msw.c, glyphs-widget.c, glyphs-x.c, glyphs.c, glyphs.h, gui-gtk.c, gui-msw.c, gui-x.c, gui.c, gutter.c, input-method-xlib.c, intl-encap-win32.c, intl-win32.c, keymap.c, lisp.h, macros.c, menubar-gtk.c, menubar-msw.c, menubar-x.c, menubar.c, menubar.h, minibuf.c, mule-charset.c, nt.c, objects-gtk.c, objects-gtk.h, objects-msw.c, objects-msw.h, objects-tty.c, objects-tty.h, objects-x.c, objects-x.h, objects.c, objects.h, postgresql.c, print.c, process.h, redisplay-gtk.c, redisplay-msw.c, redisplay-output.c, redisplay-tty.c, redisplay-x.c, redisplay.c, redisplay.h, scrollbar-gtk.c, scrollbar-msw.c, scrollbar-x.c, scrollbar.c, select-gtk.c, select-msw.c, select-x.c, select.c, signal.c, sound.c, specifier.c, symbols.c, syntax.c, sysdep.c, syssignal.h, syswindows.h, toolbar-common.c, toolbar-gtk.c, toolbar-msw.c, toolbar-x.c, toolbar.c, unicode.c, window.c, window.h: The following are the major changes made: (1) Separation of various header files into an external and an internal version, similar to the existing separation of process.h and procimpl.h. Eventually this should be done for all Lisp objects. The external version has the same name as currently; the internal adds -impl. The external file has XFOO() macros for objects, but the structure is opaque and defined only in the internal file. It's now reasonable to move all prototypes in lisp.h into the appropriate external file, and this should be done. Currently, separation has been done on extents.h, objects*.h, console.h, device.h, frame.h, and window.h. For c/d/f/w, the most basic properties are available in the external header file, with the macros resolving to functions. In the internal header file, the macros are redefined to directly access the structure. Also, the global MARK_FOO_CHANGED macros have been made into functions so that they can be accessed without needing to include lots of -impl headers -- they are used in almost exclusively in non-time-critical functions, and take up enough time that the function overhead will be negligible. Similarly, the function overhead from making the basic properties mentioned above into functions is negligible, and code that does heavy accessing of c/d/f/w structures inevitably ends up needing the internal header files, anyway. (2) More face changes. -- Major rewrite of objects-msw.c. Now handles wildcard specs properly, rather than "truenaming" (or even worse, signalling an error, which previously happened with some of the fallbacks if you tried to use them in make-font-instance!). -- Split charset matching of fonts into two stages -- one to find a font specifically designed for a particular charset (by examining its registry), the second to find a Unicode font that can support the charset. This needs to proceed as two complete, separate instantiations in order to work properly (otherwise many of the fonts in the HELLO page look wrong). This should also make it easy to support iso10646 (Unicode) fonts under X. -- All default values for fonts are now completely specified in the fallbacks. Stuff from mule-x-init.el has all been moved here, merged with the existing specs, and totally rethought so you get sensible results. (HELLO now looks much better!). -- Generalize the "default X/GTK device" stuff into a per-device-type "default device". -- Add mswindows-{set-}charset-registry. In time, charset<->code-page conversion functions will be removed. -- Wrap protective code around calls to compute device specifier tags, and do this computation before calling the face initialization code because the latter may need these tags to be correctly updated. (3) Other changes. EmacsFrame.c, glyphs-msw.c, eval.c, gui-x.c, intl-encap-win32.c, search.c, signal.c, toolbar-msw.c, unicode.c: Warning fixes. config.h.in: #undefs meant to be frobbed by configure *MUST* go inside of #ifndef WIN32_NO_CONFIGURE, and everything else *MUST* go outside! eval.c: Let detailed backtraces be detailed. specifier.c: Don't override user's print-string-length/print-length settings. glyphs.c: New function image-instance-instantiator. config.h.in, sysdep.c: Changes for fastcall. sysdep.c, nt.c: Fix up a previous botched patch that tried to add support for both EEXIST and EACCES. IF THE BOTCHED PATCH WENT INTO 21.4, THIS FIXUP NEEDS TO GO IN, TOO. search.c: Fix *evil* crash due to incorrect synching of syntax-cache code with 21.1. THIS SHOULD GO INTO 21.4.
author ben
date Thu, 20 Jun 2002 21:19:10 +0000
parents eba92770173a
children 715eed24e30e
line wrap: on
line source

This directory tree holds version 21.5 of XEmacs.



*** What is XEmacs?

XEmacs is a powerful, highly customizable open source text editor and
application development system, with full GUI support.  It is protected
under the GNU Public License and related to other versions of Emacs, in
particular GNU Emacs.  Its emphasis is on modern graphical user
interface support and an open software development model, similar to
Linux.  XEmacs has an active development community numbering in the
hundreds (and thousands of active beta testers on top of this), and runs
on all versions of MS Windows, on Linux, and on nearly every other
version of Unix in existence.  Support for XEmacs has been supplied by
Sun Microsystems, University of Illinois, Lucid, ETL/Electrotechnical
Laboratory, Amdahl Corporation, BeOpen, and others, as well as the
unpaid time of a great number of individual developers.



*** What platforms does it run on?

  -- MS Windows (It has been tested on NT, 2000, 95, 98, and ME; you
                 can also compile Cygwin and MinGW versions.)
  -- Unix (It is regularly tested on Linux, Solaris, SunOS, HP/UX,
           FreeBSD, OpenBSD, BSD/OS aka BSDI, Tru64 aka DEC/OSF, SCO5,
           and probably others.  It should work on all versions of Unix
           created in the last 10 years or so, perhaps with a bit of
           work on more obscure platforms to correct bit-rot.  It uses
           a sophisticated configuration system to auto-detect zillions
           of features that are implemented differently in different
           versions of Unix, so it will probably work on your vendor's
           version, possibly with a bit of tweaking, even if we've
           never heard of it.)
  -- MacOS/X (As an X Windows application.  Unfortunately there is no
              support currently for MacOS-specific features.)

  There is also a port of XEmacs 19.14 (an older version, circa 1996)
  for all versions of MacOS, with extensive support for MacOS-specific
  features.  See the FAQ for more details.

  There are rumors of an in-progress port to OS/2.  See the FAQ.

  XEmacs will probably never work on MS/DOS or Windows 3.1, and we're
  not particularly interested in patches for these platforms, as they
  would introduce huge amounts of code clutter due to the woefully
  underfeatured nature of these systems. (See GNU Emacs for a port to
  MS/DOS.)



*** Where's the FAQ?

Look at `man/xemacs-faq.texi'.

For the very latest version, see
http://cvs.xemacs.org/cgi-bin/cvswebxe/xemacs/man/xemacs-faq.texi.



*** Where's the latest version?

For up-to-date information on XEmacs, see http://www.xemacs.org.

To download XEmacs, see http://ftp.xemacs.org/ or
ftp://ftp.xemacs.org/pub/xemacs/.

For the latest experimental sources, see http://cvs.xemacs.org/, which
gives instructions on how to get started with CVS access.

There are numerous mailing lists for discussion of XEmacs.  The
current description of these lists can be found at
http://www.xemacs.org/Lists/, or see `etc/MAILINGLISTS'.  General
discussion of bugs, new features, etc. takes place on
xemacs-beta@xemacs.org.



*** How do I build and install XEmacs?

See the file `etc/NEWS' for information on new features and other
user-visible changes since the last version of XEmacs.

The file `INSTALL' in this directory says how to bring up XEmacs on
Unix and Cygwin, once you have loaded the entire subtree of this
directory.

See the file `nt/README' for instructions on building XEmacs for
Microsoft Windows.

The file 'README.packages' will guide you in the installation of
(essential) add on packages.



*** How do I deal with bugs or with problems building, installing, or running?

The file `PROBLEMS' contains information on many common problems that
occur in building, installing and running XEmacs.

Reports of bugs in XEmacs should be sent to xemacs-beta@xemacs.org.
You can also post to the newsgroup comp.emacs.xemacs (or equivalentlt,
send to the mailing list xemacs@xemacs.org), but it is less likely
that the developers will see it in a timely fashion.  See the "Bugs"
section of the XEmacs manual for more information on how to report
bugs.  (The file `BUGS' in this directory explains how you can find
and read that section using the Info files that come with XEmacs.)
See `etc/MAILINGLISTS' for more information on mailing lists relating
to XEmacs.


*** How do I get started developing XEmacs?

First, get yourself set up under CVS so that you can access the CVS
repositories containing the XEmacs sources and the XEmacs packages.

Next, set up your layout.  This is important, as a good layout will
facilitate getting things done efficiently, while a bad layout will could
lead to disaster, as you can't figure out which code is the most recent,
which can be thrown away, etc.  We suggest the following layout: (feel free
to make changes)

-- Everything goes under /src/xemacs (use a different directory if you
   want).  From now, instead of saying /src/xemacs, we use <xsrc-top>, to
   make it easier in case someone picked a different directory.

-- Package source is in <xsrc-top>/package-src.

-- Installed packages go under <xsrc-top>/xemacs-packages, and
   <xsrc-top>/mule-packages.

-- A "workspace" is a complete copy of the sources, in which you do work of
   a particular kind.  Workspaces can be differentiated by which branch of
   the source tree they extend off of -- usually either the stable or
   experimental, unless other branches have been created (for example, Ben
   created a branch for his Mule work because (1) the project was long-term
   and involved an enormous number of changes, (2) people wanted to be able
   to look at what his work in progress, and (3) he wanted to be able to
   check things in and in general use source-code control, since it was a
   long-term project).  Workspaces are also differentiated in what their
   purpose is -- general working workspace, workspace for particular
   projects, workspace keeping the latest copy of the code in one of the
   branches without mods, etc.

-- Various workspaces are subdirectories under <xsrc-top>, e.g.:

   -- <xsrc-top>/working (the workspace you're actively working on,
      periodically synched up with the latest trunk)

   -- <xsrc-top>/stable (for making changes to the stable version of
      XEmacs, which sits on a branch)

   -- <xsrc-top>/unsigned-removal (a workspace for a specific, difficult
      task that's going to affect lots of source and take a long time, and
      so best done in its own workspace without the interference of other
      work you're doing.  Also, you can commit just this one large change,
      separate from all the other changes).

   -- <xsrc-top>/latest (a copy of the latest sources on the trunk,
      i.e. the experimental version of XEmacs, with no patches in it;
      either update it periodically, by hand, or set up a cron job to do it
      automatically).  Set it up so it can be built, and build it so you
      have a working XEmacs. (Building it might also go into the cron job.)

      This workspace serves a number of purposes:
      -- 1. You always have a recent version of XEmacs you can compare
            against when something you're working on breaks.  It's true
            that you can do this with cvs diff, but when you need to do
            some serious investigation, this method just fails.
      -- 2. You (almost) always have a working, up-to-date executable that
            can be used when your executable is crashing and you need to
            keep developing it, or when you need an `xemacs' to build
            packages, etc.
      -- 3. When creating new workspaces, you can just copy the `latest'
            workspace using GNU cp -a.  You have all the .elc's built,
            everything else probably configured, any spare files in place
            (e.g. some annoying xpm.dll under Windows, etc.).

   -- <xsrc-top>/latest-stable/ (equivalent to <xsrc-top>/latest/, but
      for the Stable branch of XEmacs, rather than the Experimental branch
      of XEmacs).  This may or may not be necessary depending on how much
      development you do of the stable branch.

-- <xsrc-top>/xemacsweb is a workspace for working on the XEmacs web site.

-- <xsrc-top>/in-patches for patches received from email and saved to files.

-- <xsrc-top>/out-patches for locally-generated patches to be sent to
   xemacs-patches@xemacs.org.  Less useful now that the patcher util has been
   developed.

-- <xsrc-top>/build, for build trees when compiling and testing XEmacs with
   various configuration options turned off and on.  The scripts in
   xemacs-builds/ben (see below) can be used to automate building XEmacs
   workspaces with many different configuration options and automatically
   filtering out the normal output so that you see only the abnormal
   output.

-- <xsrc-top>/xemacs-builds, for the xemacs-builds module, which you need
   to check out separately in CVS.  This contains scripts used for building
   XEmacs, automating and simplifying using CVS, etc.  Under various
   people's directories are their own build and other scripts.  The
   currently most-maintained scripts are under ben/, where there are easily
   configurable scripts that can be used to easily build any workspace
   (esp. if you've more or less followed the layout presented above)
   unattended, with one or more configuration states (there's a
   pre-determined list of the most useful, but it's easy to change).  The
   output is filtered and split up in various ways so that you can identify
   which output came from where, and you can see the output either full or
   with all "normal" output except occasional status messages filtered so
   that you only see the abnormal ones.

*** What's the basic layout of the code?

The file `configure' is a shell script to acclimate XEmacs to the
oddities of your processor and operating system.  It will create a
file named `Makefile' (a script for the `make' program), which helps
automate the process of building and installing emacs.  See INSTALL
for more detailed information.

The file `configure.in' is the input used by the autoconf program to
construct the `configure' script.  Since XEmacs has configuration
requirements that autoconf can't meet, `configure.in' uses an unholy
marriage of custom-baked configuration code and autoconf macros; it
may be wise to avoid rebuilding `configure' from `configure.in' when
possible.

The file `Makefile.in' is a template used by `configure' to create
`Makefile'.

There are several subdirectories:

`src' holds the C code for XEmacs (the XEmacs Lisp interpreter and its
    primitives, the redisplay code, and some basic editing functions).
`lisp' holds the XEmacs Lisp code for XEmacs (most everything else).
`lib-src' holds the source code for some utility programs for use by
    or with XEmacs, like movemail and etags.
`etc' holds miscellaneous architecture-independent data files
    XEmacs uses, like the tutorial text and the Zippy the Pinhead quote
    database.  The contents of the `lisp', `info' and `man'
    subdirectories are architecture-independent too.
`lwlib' holds the C code for the X toolkit objects used by XEmacs.
`info' holds the Info documentation tree for XEmacs.
`man' holds the source code for the XEmacs online documentation.
`nt' holds files used compiling XEmacs under Microsoft Windows.