viper-mode + font-lock-mode malfunction on C continuation line

viper-mode + font-lock-mode malfunction on C continuation line

[Jim Meyering]

Hello,

I use emacs in viper-mode and font-lock-mode and have been very happy
with that set-up for ages.  I was surprised to see it malfunction
today in a tiny corner case.

Here's a minimal test case:

  printf '#define f(x,s) \\\n' > /tmp/k.c
  emacs -Q -f viper-mode -f font-lock-mode /tmp/k.c

Hit "n" to get past the viper-mode prompt,
then "fx" to position the cursor on the "x".

Here's the interesting part.  The cursor is on the "x"
and say you want to change "x,s" to ",":

  #define f(x,s) \
            ^

One way to do that is via "3s", then hit "," and "ESC".
That is supposed to leave you with this:

  #define f(,)						\

But it mistakenly produces this:

  #define f(,x,s)					\

That I choose to include "," in the replacement string is critical.
Without that, it works fine.  It also works fine if you don't use
font-lock-mode.

This was using the very latest, just built from emacs.git.
Here's the most recent commit:

    commit 8622626c89699b7c756a9359d0c88b5eace76f52
    Author: Gnus developers <>
    Date:   Sat Oct 16 01:55:08 2010 +0000

        Merge changes made in Gnus trunk.

        nnimap.el: Use nnheader-message throughout.
        gnus.el: Autoload gnus-html-show-images.
        mml.el (mml-generate-mime-1): Add `mml-enable-flow' variable to add a possibility to disable format=flow encoding when using hard newlines.
        gnus-diary.el (gnus-diary-check-message): Fix gnus-completing-read call.
        gnus-sum.el (gnus-summary-refer-thread): unconditionally ignore duplicates.