bug#4560: 23.1.50; (string-match "string" nil) error when typing `M-x help RET'

Something seems to have changed in the way string-match works with its
second argument is nil.  By typing `M-x help RET' I expected to see the
same prompt that is displayed by <f1>, but instead of that a snapshot of
Emacs built from the Git mirror of the repository throws me into the
debugger at:

    Debugger entered--Lisp error: (wrong-type-argument stringp nil)
      string-match("%THIS-KEY%" nil)
      help()
      call-interactively(help t nil)
      execute-extended-command(nil)
      call-interactively(execute-extended-command nil nil)

The last changeset I have in my local Git clone is:

    commit f6829d72c1b405d6c43caa554c2123f41917e358
    Author: Chong Yidong <cyd <at> stupidchicken.com>
    Date:   Fri Sep 25 22:04:07 2009 +0000

        * files.el (safe-local-eval-forms): Allow time-stamp in
        before-save-hook (Bug#4554).

I'm updating a local mirror of the CVS repository now to check if this
is an artifact of the Git mirror.  In the meantime, does this seem like
a bug in `M-x help' or like something we recently changed in the
behavior of `string-match'?

In GNU Emacs 23.1.50.1 (i386-unknown-freebsd9.0, GTK+ Version 2.16.6)
 of 2009-09-26 on kobe
configured using `configure  '--prefix=/opt/emacs' '--with-x' '--with-x-toolkit=gtk' '--with-xpm'

bug#4549: 23.1.50; copy-overlay is not mentioned in the Emacs Lisp Reference Manual

The copy-overlay function is not mentioned in the Emacs Lisp Reference
Manual. I attached a patch for display.texi.

Regards,
David

bug#4548: 23.1.50; hideshow.el - hs-show-block does not run hs-show-hook

In hideshow.el, there is a hook 'hs-show-hook' which should be run
whenever some text is shown again (i.e., unfolded).

However, the command hs-show-block does not run this hook; a (trivial)
patch which will fix this is attached.

Regards,
David

bug#4519: 23.1.50; GDB MI problems: mi_cmd_stack_info_frame: No arguments required

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

When running gdb via M-x gdb on some code of mine, I end up in a state
where it becomes no longer responsive to 'C-c C-s' or 'C-c C-n'
commands.

More specifically, I started running gdb by typing M-x gdb.  Arguments
were:
gdb -i=mi /home/mwd/bin/rwcut 

From here I typed "start --python-file /tmp/foo.py --help", and then
stepped through my code using 'C-c C-s' and 'C-c C-n'.  At one point,
after 'C-c C-n', where a library was being dynamically loaded, I get the
following output in my *gdb-rwcut* buffer:

[Thread debugging using libthread_db enabled]
[New Thread 0xb7f786c0 (LWP 5633)]
(gdb) mi_cmd_stack_info_frame: No arguments required

At this point, gud no longer syncs with gdb (does not follow along in
source files).  

The debug log below contains information up to this point, plus typing
'C-c C-n' once beyond the point where the above erroneous condition
begins.

gdb information:
GNU gdb Fedora (6.8-37.el5)

bug#4515: 23.1.50; Reverting changes on versioned file does not revert vc modeline status

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

When a modified versioned file is edited in such a way that the
modifications undoes previous changes to the file, after saving it the
VC-dired buffer for the working copy is automatically updated showing
that the status of the file is "up to date", but the VC modeline for the
buffer that visits the file does not change and keeps indicating that
the file state is "locally modified".

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.1.50/etc/DEBUG for instructions.

In GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2009-09-06 on qcore
Windowing system distributor `The X.Org Foundation', version 11.0.10600000
configured using `configure  '--with-x-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil

bug#4524: 23.1.50; Fullscreen mode layout fixed (Reopen of bug#4363)

In fullscreen mode, there is no way to configure the following (from the
original bug#4363):

 Using --without-toolkit-scroll-bars with the scrollbar on the left, the
 window should be shifted a couple of pixels to the left.  This helps to
 avoid the unclickable and irritating no man's land between the left
 screen border and the clickable scrollbar.  Otherwise using the
 scrollbar is more difficult as mouse movements must be very precise
 horizontally - vertical precision would suffice.  What I do here is
 either to use a negative geometry to avoid that space or I manually
 reposition that window.

Note that I am happy to find some clean (.emacs.el) way to do this.

In GNU Emacs 23.1.50.2 (i686-pc-linux-gnu, X toolkit)
 of 2009-09-10 on gupu2
Windowing system distributor `The X.Org Foundation', version 11.0.10603000
configured using `configure  '--without-toolkit-scroll-bars' '--prefix' '/opt/gupu/emacs-git''
/

bug#4523: 23.1.50; Cannot set Motif Hints (Reopen of bug#4363)

--text follows this line--

There is no way to set Motif Hints like the nodecoration hint which is
needed to go fullscreen with the qvwm windowmanager.  I need this for
older IGEL-X-Terminals were qvwm is preinstalled.

Unfortunatly Emacs still needs "manual" customization going into
C-sources and guessing where those hints should be put.  That is not
everybody's turf.  I try to avoid that myself delaying upgrades by
years.  Last time I upgraded was 2002/2003.  Everytime the relevant
files change a bit so it takes time to adjust.  I wonder how other
people do that.

At least some "better defined" way as simply patching sources manually
would be nice.  Maybe there is no need to put Motif hints by default.
But it would be very helpful to avoid any customization that goes
beyond .emacs.el editing.

bug#4492: 23.1.50; Cocoa Emacs crashes with being used with Daemon mode

bug#4509: Line spacing not correct for some fonts.

I noticed that in Emacs 23.1, even with line-spacing 'nil', there
often is some additional space between two lines. It seems it depends on
the used font how much additional space is inserted.

For testing this, simply insert one of the 'box drawing' unicode
characters, for example by evaluating

(ucs-insert #x2503)

which inserts the 'heavy vertical' unicode character. With the default
line-spacing set to 'nil', I would expect these characters to seamlessly
connect when repeated in the following lines, but they often don't. 

It works with the default font used on my system, which is

-unknown-DejaVu Sans Mono-normal-normal-normal-*-19-*-*-*-m-0-iso10646-1

However, when I switch to Terminus, i.e., 

-xos4-Terminus-normal-normal-normal-*-14-*-*-*-c-80-iso10646-1

I see 1 pixel of space between the characters. Same happens with some
truetype fonts, e.g, 

-unknown-Kochi Gothic-normal-normal-normal-*-19-*-*-*-*-0-iso10646-1

I tested this on different machines to make sure it isn't some issue
with the font setup on my machine. Also, I tested the box drawing
characters from the Terminus font with 'gedit', and they do connect
there.

Regards,
David

In GNU Emacs 23.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-09-09 on kafka
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
configured using `configure  '--prefix=/opt/cedemacs''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o e <tab> <backspace> r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

bug#4484: 23.1.50; Null Byte Yank on Mac OS X

bug#4482: 23.1.50; "Mode Line" in the Emacs manual "Needs Work"(TM)

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This node of the manual has several problems:

 . It does not mention the "@" character that is put in the mode line
   of emacsclient frames.

 . It does not explain what do I>, I+, and I@ input method indications
   mean.  The cross-reference to the "Input Methods" node does not
   help, because this issue is not explained there, either (nor should
   it be, IMO).

 . The differences between text-mode and GUI terminals are mentioned
   in a way that is hard to read.  I would suggest to rewrite the text
   using an @itemize list, with a separate @item for each indicator
   that can be in the mode line, and for those that can only appear on
   text-mode terminals, say just that.

 . For a user on a text-mode terminal, where a mouse cannot be used to
   have the value that corresponds to the indicator spelled out, it
   would be good to mention variables that hold those values, so that
   the user could evaluate them when she needs that.  For example, the
   mnemonics for the various coding-systems can be seen by evaluating
   buffer-file-coding-system etc.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
d:/gnu/emacs/etc/DEBUG for instructions.

In GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600)
 of 2009-09-18 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x <backspace> <backspace> C-u C-h i g n <tab> <backspace> 
<backspace> i n f <tab> e m a <tab> <return> i m o 
d e SPC l i n e <return> M-x r e p o r t - e m a <tab> 
<return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
call-interactively: Text is read-only [2 times]
Quit
Found `mode line' in Concept Index.  (14 total; use `,' for next)

Load-path shadows:
None found.