Merge from trunk.

7 files changed, 343 insertions, 37 deletions

diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index 7d5e85a3ae0..7947b17973b 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -8,7 +8,8 @@ This is 95% of all you will ever need to know.
 
 ** How do I report a bug?
 Use M-x report-emacs-bug, or send mail to bug-gnu-emacs@gnu.org.
-If you want to Cc someone, use an "X-Debbugs-CC" header instead.
+If you want to Cc someone, use an "X-Debbugs-CC" header (or
+pseudo-header, see below) instead.
 
 ** How do I comment on a bug?
 Reply to a mail on the bug-gnu-emacs list in the normal way.
@@ -52,8 +53,8 @@ i) Your report will be assigned a number and generate an automatic reply.
 ii) Optionally, you can set some database parameters when you first
 report a bug (see "Setting bug parameters" below).
 
-iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
-see below).
+iii) If you want to CC: someone, use X-Debbugs-CC: (note this only
+applies to _new_ reports, not followups).
 
 Once your report is filed and assigned a number, it is sent out to the
 bug mailing list.  In some cases, it may be appropriate to just file a
@@ -92,18 +93,21 @@ but create duplicates and errors.  (It is possible, but unlikely, that
 you might want to have a dialog with the owner address, outside of
 normal bug reporting.)
 
-** When reporting a bug, to send a Cc to another address
+** When reporting a new bug, to send a Cc to another address
 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
 Instead, use "X-Debbugs-CC:".  This ensures the Cc address will get a
 mail with the bug report number in.  If you do not do this, each reply
-in the subsequent discussion will end up creating a new bug.
-This is annoying.
+in the subsequent discussion might end up creating a new bug.
+This is annoying.  (So annoying that a form of message-id tracking has
+been implemented to hopefully stop this happening, but it is still
+better to use X-Debbugs-CC.)
 
-(So annoying that a form of message-id tracking has been implemented
-to hopefully stop this happening, but it is still better to use X-Debbugs-CC.)
+Like any X-Debbugs- header, this one can also be specified in the
+pseudo-header (see below), if your mail client does not let you add
+"X-" headers.
 
 If a new report contains X-Debbugs-CC in the input, this is
-converted to a real Cc header in the output.  (See Bug#1720).
+converted to a real Cc header in the output.  (See Bug#1780,5384)
 It is also merged into the Resent-CC header (see below).
 
 ** How does Debbugs send out mails?
@@ -218,8 +222,8 @@ Package: emacs
 Version: 23.0.60
 Severity: minor
 
-This can also include tags.  Some things (e.g. submitter) don't seem to
-work here.
+This can also include tags, or any X-Debbugs- setting.
+Some things (e.g. submitter) don't seem to work here.
 
 Otherwise, send mail to the control server, control@debbugs.gnu.org.
 At the start of the message body, supply the desired commands, one per
@@ -270,32 +274,35 @@ to a bug.  There are two differences between normal tags and user tags:
 1) Anyone can define any valid usertag they like.  In contrast, only a
 limited, predefined set of normal tags are available (see above).
 
-2) A usertag is associated with a specific email address.
+2) A usertag is associated with a specific user.  This is normally
+an email address (with an "@" sign and least 4 characters after the "@"),
+but on debbugs.gnu.org, the definition is less strict - anything with
+5 or more alphanumeric characters will work.  For personal tags,
+using an email address is still recommended.  Please only use the
+"emacs" user, or other short users, for "official" tags.
 
-You set usertags in the same way as tags, by talking to the control
-server.  One difference is that you can also specify the associated
-email address.  If you don't explicitly specify an address, then it
-will use the one from which you send the control message. The address
-must have the form of an email address (with an "@" sign and least 4
-characters after the "@").
+You set usertags in the same way as tags, by talking to the control server.
+One difference is that you can also specify the associated user.
+If you don't explicitly specify a user, then it will use the email
+address from which you send the control message.
 
 *** Setting usertags
 
 a) In a control message:
 
-user bug-gnu-emacs@gnu.org
+user emacs      # or email@example.com
 usertags 1234 any-tag-you-like
 
 This will add a usertag "any-tag-you-like" to bug 1234.  The tag will
-be associated with the address "bug-gnu-emacs@gnu.org".  If you omit
-the first line, the tag will be associated with your email address.
+be associated with the user "emacs".  If you omit the first line,
+the tag will be associated with your email address.
 
 The syntax of the usertags command is the same as that of tags (eg wrt
 the optional [=+-] argument).
 
 b) In an initial submission, in the pseudo-header:
 
-User: bug-gnu-emacs@gnu.org
+User: emacs
 Usertags: a-new-tag
 
 Again, the "User" is optional.
@@ -312,7 +319,7 @@ http://debbugs.gnu.org/cgi/pkgindex.cgi?indexon=users
 
 **** To find all bugs usertagged by a given email address:
 
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs
 
 (Supposedly, the "users" field can be a comma-separated list of more
 than one email address, but it does not seem to work for me.)
@@ -322,7 +329,7 @@ than one email address, but it does not seem to work for me.)
 This works just like a normal tags search, but with the addition of a
 "users" field.  Eg:
 
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=calendar
 
 *** To merge bugs:
 Eg when bad replies create a bunch of new bugs for the same report.
@@ -610,7 +617,7 @@ An /etc/aliases entry redirects it to the real emacs-bug-tracker address.
 All discarded messages are stored in /var/lib/mailman/spam.
 If a non-spam message accidentally gets discarded, just do:
 
-cat /var/lib/mailman/spam/not-really-spam.msg | /usr/lib/debbugs/receive
+/usr/lib/debbugs/receive < /var/lib/mailman/spam/not-really-spam.msg
 chown Debian-debbugs:Debian-debbugs /var/lib/debbugs/spool/incoming/*
 ... check it works ...
 mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
@@ -618,6 +625,18 @@ mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
 Also check that the sender was not added to the auto-discard/reject list
 in the debbugs-submit Mailman interface.
 
+If you don't have the actual mail, just the mailman moderation mail
+version of it, you need to extract the original mail, and add the
+following headers:
+
+1) The leading envelope From line.
+2) Message-ID (get it from /var/log/mailman/vette).
+3) X-Debbugs-Envelope-To: xxx
+For a new report, xxx = submit; for a control message, xxx = control;
+for a reply to bug#123, xxx = 123
+
+Then pipe it to receive as above.
+
 ** Administrivia
 
 The debbugs-submit list should have the administrivia option off,
diff --git a/admin/notes/bzr b/admin/notes/bzr
index 50eaf3710ee..8f7d0d94fa8 100644
--- a/admin/notes/bzr
+++ b/admin/notes/bzr
@@ -182,6 +182,71 @@ where revision N+1 is the one where file was removed.
 You could also try `bzr add --file-ids-from', if you have a copy of
 another branch where file still exists.
 
+* Undoing a commit (uncommitting)
+
+It is possible to undo/remove a bzr commit (ie, to uncommit).
+Only do this if you really, really, need to.  For example, if you
+somehow made a commit that triggers a bug in bzr itself.
+Don't do it because you made a typo in a commit or the log.
+
+If you do need to do this, do it as soon as possible, because the
+longer you leave it, the more work is involved.
+
+0. First, tell emacs-devel that you are going to do this, and suggest
+people not commit anything to the affected branch for the duration.
+
+In the following, replace USER with your Savannah username, and
+BRANCH with the name of the branch.
+Let's assume that revno 100 is the bad commit, and that there have
+been two more commits after that (because nothing is ever easy).
+
+1. Ensure your copy of the branch is up-to-date (for a bound
+branch, bzr up; for an unbound branch, bzr pull) and has no local
+changes (bzr st).
+
+2. Make a record of the commits you are going to undo:
+bzr diff -c 102 > /tmp/102.diff
+etc
+
+Also record the commit message, author, and any --fixes information.
+
+3. Most Emacs branches are set up to prevent just this kind of thing.
+So we need to disable that protection:
+
+bzr config append_revisions_only=False \
+  -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/
+
+4. Undo the commits:
+bzr uncommit -r -4
+
+This will show the commits it is going to undo, and prompt you to confirm.
+
+5. If using an unbound branch:
+bzr push --overwrite
+
+6. Now, replay the commits you just undid (obviously, fix whatever it
+was in the bad commit that caused the problem):
+
+patch -p0 < /tmp/100.diff
+bzr commit --author ... --fixes ... -F /tmp/100.log
+etc
+
+7. If using an unbound branch:
+bzr push
+
+8. Finally, re-enable the branch protection:
+bzr config append_revisions_only=True \
+  -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/
+
+9. Tell emacs-devel that it is ok to use the branch again.
+Anyone with local changes should back them up before doing anything.
+
+For a bound branch, bzr up will convert any of the undone commits to a
+pending merge. Just bzr revert these away.
+
+For an unbound branch, bzr pull will complain about diverged branches
+and refuse to do anything.  Use bzr pull --overwrite.
+
 * Loggerhead
 
 Loggerhead is the bzr tool for viewing a repository over http (similar
@@ -202,3 +267,97 @@ For example, on RHEL6 I needed:
   yum --enablerepo=epel install python-simpletal
 
 Then point your web-browser to http://127.0.0.1:8080/ .
+
+* Bisecting
+
+This is a semi-automated way to find the revision that introduced a bug.
+
+First, get the bzr bisect plugin if you do not have it already:
+
+  cd ~/.bazaar/plugins
+  bzr branch lp:bzr-bisect bisect
+
+`bzr help bisect' should work now.
+
+It's probably simplest to make a new copy of the branch to work in
+from this point onwards.
+
+Identify the last known "good" revision where the relevant issue is
+NOT present (e.g. maybe Emacs 24.1).  Let's say this is revision 1000.
+
+  bzr bisect start
+  bzr bisect no -r 1000
+
+At this point, bzr will switch to the mid-point of revision 1000 and
+the current revision.  If you know that the issue was definitely
+present in some specific revision (say 2000), you can use:
+
+  bzr bisect yes -r 2000
+
+Now bzr switches to revision 1500.
+
+Now test whether the issue is present.  You might need to rebuild
+Emacs to do this, or if you know the problem is in a specific Lisp
+file, you might be able to get away with just loading that one file in
+current Emacs.
+
+If the issue is present, use
+
+  bzr bisect yes
+
+If it is not, use
+
+  bzr bisect no
+
+Repeat until you zero-in on the specific revision.
+
+When finished, use
+
+  bzr bisect reset
+
+or simply delete the entire branch if you created it just for this.
+
+* Commit emails
+
+** Old method: bzr-hookless-email
+https://launchpad.net/bzr-hookless-email
+
+Runs hourly via cron.  Must ask Savannah admins to enable/disable it
+for each branch.  Stores the last revision that it mailed as
+last_revision_mailed in branch.conf on the server.  Breaks with bzr 2.6:
+
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00000.html
+
+Fix from https://bugs.launchpad.net/bzr-hookless-email/+bug/988195
+only partially works.  Breaks again on every merge commit:
+
+https://lists.ubuntu.com/archives/bazaar/2013q2/075520.html
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00024.html
+
+You can force it to skip the merge commit by changing the value for
+last_revision_mailed, eg:
+
+bzr config last_revision_mailed=xfq.free@gmail.com-20130603233720-u1aumaxvf3o0rlai -d bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/trunk/
+
+** New method: bzr-email plugin
+https://launchpad.net/bzr-email
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00007.html
+
+Runs on commit.  Projects can enable it themselves by using `bzr
+config' to set post_commit_to option for a branch.  See `bzr help email'
+(if you have the plugin installed) for other options.
+
+Note: if you have the bzr-email plugin installed locally, then when
+you commit to the Emacs repository it will also try to send a commit
+email from your local machine.  If your machine is not configured to
+send external mail, this will just fail.  In any case, you may prefer
+to either remove the plugin from your machine, or disable it for Emacs
+branches.  You can do this either by editing branch.conf in your Emacs
+branches, to override the server setting (untested; not sure this
+works), or by adding an entry to ~/.bazaar/locations.conf:
+
+  [bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/*/]
+  post_commit_to = ""
+
+You have to use locations.conf rather than bazaar.conf because the
+latter has a lower priority than branch.conf.
diff --git a/admin/notes/copyright b/admin/notes/copyright
index 72b7d7e2d23..3a404b69678 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -1,4 +1,4 @@
-Copyright (C) 2007-2012  Free Software Foundation, Inc.
+Copyright (C) 2007-2013 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
@@ -380,7 +380,7 @@ Makefile.in does now.
 src/gmalloc.c
   - contains numerous copyrights from the GNU C library. Leave them alone.
 
-src/ndir.h
+nt/inc/dirent.h
   - see comments below. This file is OK to be released with Emacs
   22, but we may want to revisit it afterwards.
 
@@ -429,7 +429,7 @@ admin/check-doc-strings
   File says it's in the public domain, but that might not make it so.
 
 etc/e/eterm-color.ti
-src/ndir.h
+nt/inc/dirent.h
   On legal advice from Matt Norwood, the following comment was added
   to these files in Feb/Mar 2007:
 
diff --git a/admin/notes/font-backend b/admin/notes/font-backend
index ec2dc11345b..cdf2001580d 100644
--- a/admin/notes/font-backend
+++ b/admin/notes/font-backend
@@ -1,4 +1,4 @@
-Copyright (C) 2002-2012  Free Software Foundation, Inc.
+Copyright (C) 2002-2013 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
diff --git a/admin/notes/lel-TODO b/admin/notes/lel-TODO
index 139aa09e919..2c6d86a4ffd 100644
--- a/admin/notes/lel-TODO
+++ b/admin/notes/lel-TODO
@@ -1,6 +1,6 @@
 Some lisp/emacs-lisp/ Features and Where They Are Documented
 
-Copyright (C) 2007-2012 Free Software Foundation, Inc.
+Copyright (C) 2007-2013 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
diff --git a/admin/notes/multi-tty b/admin/notes/multi-tty
index 5408b9a3d00..c4edd3abc93 100644
--- a/admin/notes/multi-tty
+++ b/admin/notes/multi-tty
@@ -1,6 +1,6 @@
 -*- coding: utf-8; mode: text; -*-
 
-Copyright (C) 2007-2012  Free Software Foundation, Inc.
+Copyright (C) 2007-2013 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 From README.multi-tty in the multi-tty branch.
diff --git a/admin/notes/unicode b/admin/notes/unicode
index dda6ec4cc93..6db5bb7d05c 100644
--- a/admin/notes/unicode
+++ b/admin/notes/unicode
@@ -1,6 +1,6 @@
-                                            -*-mode: text; coding: latin-1;-*-
+                                            -*-mode: text; coding: utf-8;-*-
 
-Copyright (C) 2002-2012 Free Software Foundation, Inc.
+Copyright (C) 2002-2013 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 Problems, fixmes and other unicode-related issues
@@ -12,9 +12,9 @@ regard to completeness.
 
  * SINGLE_BYTE_CHAR_P returns true for Latin-1 characters, which has
    undesirable effects.  E.g.:
-   (multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
-   (multibyte-string-p (concat [?£])) => nil
-   (text-char-description ?£) => "M-#"
+   (multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
+   (multibyte-string-p (concat [?£])) => nil
+   (text-char-description ?£) => "M-#"
 
         These examples are all fixed by the change of 2002-10-14, but
         there still exist questionable SINGLE_BYTE_CHAR_P in the
@@ -77,7 +77,7 @@ regard to completeness.
    spelling and calendar, but that's not a Unicode issue.)
 
  * Handle Unicode combining characters usefully, e.g. diacritics, and
-   handle more scripts specifically (à la Devanagari).  There are
+   handle more scripts specifically (à la Devanagari).  There are
    issues with canonicalization.
 
  * We need tabular input methods, e.g. for maths symbols.  (Not
@@ -98,6 +98,134 @@ regard to completeness.
  * Old auto-save files, and similar files, such as Gnus drafts,
    containing non-ASCII characters probably won't be re-read correctly.
 
+
+Source file encoding
+--------------------
+
+Most Emacs source files are encoded in UTF-8 (or in ASCII, which is a
+subset), but there are a few exceptions, listed below.  Perhaps
+someday many of these files will be converted to UTF-8, for
+convenience when using tools like 'grep -r', but this might need
+nontrivial changes to the build process.
+
+ * chinese-big5
+
+     These are verbatim copies of files taken from external sources.
+     They haven't been converted to UTF-8.
+
+        leim/CXTERM-DIC/4Corner.tit
+        leim/CXTERM-DIC/ARRAY30.tit
+        leim/CXTERM-DIC/ECDICT.tit
+        leim/CXTERM-DIC/ETZY.tit
+        leim/CXTERM-DIC/PY-b5.tit
+        leim/CXTERM-DIC/Punct-b5.tit
+        leim/CXTERM-DIC/QJ-b5.tit
+        leim/CXTERM-DIC/ZOZY.tit
+        leim/MISC-DIC/CTLau-b5.html
+        leim/MISC-DIC/cangjie-table.b5
+
+ * chinese-iso-8bit
+
+     These are verbatim copies of files taken from external sources.
+     They haven't been converted to UTF-8.
+
+        leim/CXTERM-DIC/CCDOSPY.tit
+        leim/CXTERM-DIC/Punct.tit
+        leim/CXTERM-DIC/QJ.tit
+        leim/CXTERM-DIC/SW.tit
+        leim/CXTERM-DIC/TONEPY.tit
+        leim/MISC-DIC/pinyin.map
+        leim/MISC-DIC/CTLau.html
+        leim/MISC-DIC/ziranma.cin
+
+ * cp850
+
+     This file contains non-ASCII characters in unibyte strings.  When
+     editing a keyboard layout it's more convenient to see 'é' than
+     '\202', and the MS-DOS compiler requires the single byte if a
+     backslash escape is not being used.
+
+        src/msdos.c
+
+ * iso-2022-cn-ext
+
+     This file is externally generated from leim/MISC-DIC/cangjie-table.b5
+     by Big5->CNS converter.  It hasn't been converted to UTF-8.
+
+        leim/MISC-DIC/cangjie-table.cns
+
+ * iso-latin-2
+
+     These files are processed by csplain, a program that requires
+     Latin-2 input.  In 2012 the csplain maintainers started
+     recommending UTF-8, but these files haven't been converted yet.
+
+        etc/refcards/cs-dired-ref.tex
+        etc/refcards/cs-refcard.tex
+        etc/refcards/cs-survival.tex
+        etc/refcards/sk-dired-ref.tex
+        etc/refcards/sk-refcard.tex
+        etc/refcards/sk-survival.tex
+
+ * japanese-iso-8bit
+
+     SKK-JISYO.L is a verbatim copy of a file taken from an external source.
+     It hasn't been converted to UTF-8.
+
+        leim/SKK-DIC/SKK-JISYO.L
+
+ * japanese-shift-jis
+
+     This is a verbatim copy of a file taken from an external source.
+     It hasn't been converted to UTF-8.
+
+        admin/charsets/mapfiles/cns2ucsdkw.txt
+
+ * no-conversion
+
+     This file purposely contains arbitrary bytes interspersed within text,
+     to test whether the Emacs distribution is corrupted.
+
+        lib-src/testfile
+
+ * iso-2022-7bit
+
+     This file switches between CJK charsets, which is not encoded in UTF-8.
+
+        etc/HELLO
+
+     Each of these files contains just one CJK charset, but Emacs
+     currently has no easy way to specify set-charset-priority on a
+     per-file basis, so converting any of these files to UTF-8 might
+     change the file's appearance when viewed by an Emacs that is
+     operating in some other language environment.
+
+        etc/tutorials/TUTORIAL.ja
+        leim/quail/cyril-jis.el
+        leim/quail/hanja-jis.el
+        leim/quail/japanese.el
+        leim/quail/py-punct.el
+        leim/quail/pypunct-b5.el
+        lisp/international/ja-dic-cnv.el
+        lisp/international/ja-dic-utl.el
+        lisp/international/kinsoku.el
+        lisp/international/kkc.el
+        lisp/international/titdic-cnv.el
+        lisp/language/japan-util.el
+        lisp/language/japanese.el
+        lisp/term/x-win.el
+
+ * utf-8-emacs
+
+     These files contain characters that cannot be encoded in UTF-8.
+
+        leim/quail/tibetan.el
+        leim/quail/ethiopic.el
+        lisp/international/titdic-cnv.el
+        lisp/language/tibetan.el
+        lisp/language/tibet-util.el
+        lisp/language/ind-util.el
+
 
 This file is part of GNU Emacs.