Revision: miles@gnu.org--gnu-2004/emacs--unicode--0--patch-15

Merge from emacs--cvs-trunk--0

Patches applied:

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-218
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-220
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-221
   Restore deleted tagline in etc/TUTORIAL.ru

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-222
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-228
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-229
   Remove TeX output files from the archive

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-230
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-247
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-248
   src/lisp.h (CYCLE_CHECK): Macro moved from xfaces.c

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-249
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-256
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-258
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-263
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-264
   Update from CVS: lispref/display.texi: emacs -> Emacs.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-265
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-274
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-275
   Update from CVS: man/makefile.w32-in: Revert last change

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-276
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-295
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-296
   Allow restarting an existing debugger session that's exited

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-297
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-299
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-300
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-327
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-328
   Update from CVS: src/.gdbinit (xsymbol): Fix last change.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-329
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-344
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-345
   Tweak source regexps so that building in place won't cause problems

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-346
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-351
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-352
   Update from CVS: lisp/flymake.el: New file.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-353
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-361
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-362
   Support " [...]" style defaults in minibuffer-electric-default-mode

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-363
   (read-number): Use canonical format for default in prompt.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-364
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-367
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-368
   Improve display-supports-face-attributes-p on non-ttys

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-369
   Rewrite face-differs-from-default-p

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-370
   Move `display-supports-face-attributes-p' entirely into C code

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-371
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-372
   Simplify face-differs-from-default-p; don't consider :stipple.

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-373
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-374
   (tty_supports_face_attributes_p): Ensure attributes differ from default

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-375
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-376
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-377
   (Fdisplay_supports_face_attributes_p): Work around bootstrapping problem

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-378
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-380
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-381
   Face merging cleanups

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-382
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-384
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-385
   src/xfaces.c (push_named_merge_point): Return 0 if a cycle is detected

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-386
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-395
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-396
   Tweak arch tagging to make build/install-in-place less annoying

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-397
   Work around vc-arch problems when building eshell

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-398
   Tweak permissions

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-399
   Tweak directory permissions

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-400
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-401
   More build-in-place tweaking of arch tagging

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-402
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-403
   Yet more build-in-place tweaking of arch tagging

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-404
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-409
   Update from CVS

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-410
   Make sure image types are initialized for lookup too

 * miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-411
 - miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-416
   Update from CVS

2 files changed, 53 insertions, 0 deletions

diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH
new file mode 100644
index 00000000000..2c343e53f15
--- /dev/null
+++ b/admin/notes/BRANCH
@@ -0,0 +1,18 @@
+This file describes the CVS branch in which it is maintained.
+Everything below the line is branch-specific.
+________________________________________________________________________
+
+This is the "HEAD" branch, otherwise known as the "trunk".  Its primary
+purpose is to accumulate changes that are not yet partitioned into a
+specific (versioned) release.  When people say "use CVS emacs", this is
+the branch they are talking about.  Likewise, a "cvs checkout" without
+the "-r" option results in this branch.
+
+The plans for this branch are not specified; Emacs hackers add to it
+relatively free of constraint (aside from proper legal / accounting
+practices), although sometimes there is related discussion on the
+emacs-devel mailing list.
+
+The closure process for this branch is undocumented; concepts such as
+"freeze", "release", or "integration with the trunk" are not applicable
+to this branch.
diff --git a/admin/notes/exit-value b/admin/notes/exit-value
new file mode 100644
index 00000000000..e59bb614b9b
--- /dev/null
+++ b/admin/notes/exit-value
@@ -0,0 +1,35 @@
+ttn 2004-05-09
+
+The exit value of a program returning to the shell on unixoid systems is
+typically 0 for success, and non-0 (such as 1) for failure.  For vms it is
+odd (1,3,5...) for success, even (0,2,4...) for failure.
+
+This holds from the point of view of the "shell" (in quotes because vms has a
+different dispatch model that is not explained further here).
+
+From the point of view of the program, nowadays stdlib.h on both type of
+systems provides macros `EXIT_SUCCESS' and `EXIT_FAILURE' that should DTRT.
+
+NB: The numerical values of these macros DO NOT need to fulfill the the exit
+value requirements outlined in the first paragraph!  That is the job of the
+`exit' function.  Thus, this kind of construct shows misunderstanding:
+
+   #ifdef VMS
+      exit (1);
+   #else
+      exit (0);
+   #endif
+
+Values aside from EXIT_SUCCESS and EXIT_FAILURE are tricky.
+
+
+
+ttn 2004-05-12
+
+Values aside from EXIT_SUCCESS and EXIT_FAILURE can be used to indicate
+finer gradations of failure.  If this is the only information available
+to the caller, clamping such values to EXIT_FAILURE loses information.
+If there are other ways to indicate the problem to the caller (such as
+a message to stderr) it may be ok to clamp.  In all cases, it is the
+relationship between the program and its caller that must be examined.
+[Insert ZAMM quote here.]