bug#3823: skip-chars-forward "[:space:]" does not work if used after forward-comment

[Lenny Foner <foner@media.mit.edu>]

This bug just nailed me too.  The original report was in Emacs 23, but
I'm running 22, and it doesn't work here, either, so it's obviously
been broken a long time.  Here's a toy function I was in the middle
of writing, as part of making Meta-. more to my liking:

(defun bmd-beginning-of-function-including-comments ()
  "Positions point at the start of any comments preceding the current function.
Assumes it starts at the very beginning of a definition, as Meta-. will leave us.
This is defined as all non-code lines before the current function, until we find
either another line of code, or the beginning of the buffer.  If we wind up at
the beginning of the buffer, we stop there.  If we find another line of code,
we then skip forward over any whitespace after that code, so as to land at the
first line of comments but not on any whitespace before them.  (This means that
we will skip backwards over any number of interspersed blank lines and comments
but will not waste screen real estate on a blank line when we're done.)  Narrowing
is considered, so the beginning of the buffer really means the beginning of the
accessible portion if narrowing is in effect."
  (interactive)
  (forward-comment (- (buffer-size)))
  (unless (= (point) (point-min))
    (forward-line 1)
    ;; NOTE!  Trying to use "[:space:]" instead of the regexp below DOES NOT WORK!
    ;; It only works if some other (interactive?) commands have -intervened- after the forward-comment!
    ;; Someone else has apparently tripped over this; c.f. http://debbugs.gnu.org/db/38/3823.html
    (skip-chars-forward " \t\r\n")))

This works if I use M-: to evaluate each of the forward-comment,
forward-line, and skip-chars-forward by hand, but not in the function;
after wasting a bunch of time trying to figure out if I was nuts or
Emacs was, I found this report, whose workaround works for me.

So much for trying to be elegant and actually -use- the defined syntax
classes...  Feh.  I presume that forward-comment is leaving the syntax
tables messed up in some way that gets fixed by the command-loop, or
something weird like that.

My configuration:

In GNU Emacs 22.2.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2009-11-10 on yellow, modified by Ubuntu
configured using `configure  '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs22:/etc/emacs:/usr/local/share/emacs/22.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.2/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: C
  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: en_US.UTF-8
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  dynamic-completion-mode: t
  show-paren-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t