bug#24672: 26.0.50; viper-mode + c-mode: "ce" fails in cpp-continued stmt

bug#24672: 26.0.50; viper-mode + c-mode: "ce" fails in cpp-continued stmt

[Jim Meyering]

This is with an emacs binary I built from "master" yesterday.

Reproduce with this:

  printf '%s\n' '#define abcde \\' x > k.c; emacs -q -f viper-mode k.c

Then, hit "n" at the viperize prompt and you'll see this
on the first line:

  #define abcde \

Hit "W" to move the cursor to the "a". Then type "ce(" to
change the 5-byte "abcde" to a "(".  I was surprised to see
the "abcde" still there, and an additional backslash appended:

  #define (abcde \                                \

I expected to see this:

  #define ( \

In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu)
 of 2016-10-10 built on hx.meyering.net
 Repository revision: 8b1be820ce02379c9ebd124703e04eee65779662

Configured using:
 'configure --prefix=/p/p/emacs-2016-10-10.08h35 --without-gpm
  --without-x --with-x-toolkit=no --with-png=no --with-jpeg=no
   --with-sound=no'

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Jim Meyering]

This is a corner case.
When I start in viper mode with this file contents:

  #define z_b\

and then change the "z" to a parenthesis (either one), I get this:

  #define (z_b^I^I^I^I^I\$

[I have represented each TAB as "^I", of course]
Rather surprising to see all of those TAB characters inserted. To
reproduce, run this:

  mkdir ~/empty && printf '#define z_b\\\n' > k.c \
    && HOME=$HOME/empty /bin/emacs -Q -f viper-mode k.c

hit "n", "n", and "5" at the successive prompts, then e.g., "fzs(" to
perform the change and to see the surprising result.

I tried to write a test case to encapsulate the above, but so far have
failed, because when run via the test, viper-mode does what one would
expect.

commit 3309c37d8c42b2fd002b0d965dafc4be3b6d3e44
Author: Jim Meyering <meyering@fb.com>
Date:   Wed Oct 12 08:57:48 2016 -0700

    viper-tests.el: add a test for bug #24672

diff --git a/test/lisp/emulation/viper-tests.el
b/test/lisp/emulation/viper-tests.el
index 2c63b24..85d83aa 100644
--- a/test/lisp/emulation/viper-tests.el
+++ b/test/lisp/emulation/viper-tests.el
@@ -99,6 +99,19 @@ viper-test-undo-kmacro
       ]
      ))))

+(ert-deftest viper-test-insert-paren-on-cpp-continued-line()
+  "Test for bug #24672:
+Insert '#define z_b\', then change the 'z' to a parenthesis (open or closed)"
+  (should
+   (equal
+    "#define (_b\\\n"
+    (viper-test-undo-kmacro
+     [
+      ?i ?# ?d ?e ?f ?i ?n ?e ?  ?z ?_ ?b ?\\ escape
+         ?F ?z ?s ?\( escape
+         ])
+    )))
+
 (ert-deftest viper-test-undo-2 ()
   "Test for VI like undo behavior.

Is there some test set-up I can perform to make that test work like
what I outlined above?

writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Jim Meyering]

This is a corner case.
When I start in viper mode with this file contents:

  #define z_b\

and then change the "z" to a parenthesis (either one), I get this:

  #define (z_b^I^I^I^I^I\$

[I have represented each TAB as "^I", of course]
Rather surprising to see all of those TAB characters inserted. To
reproduce, run this:

  mkdir ~/empty && printf '#define z_b\\\n' > k.c \
    && HOME=$HOME/empty /bin/emacs -Q -f viper-mode k.c

hit "n", "n", and "5" at the successive prompts, then e.g., "fzs(" to
perform the change and to see the surprising result.

I tried to write a test case to encapsulate the above, but so far have
failed, because when run via the test, viper-mode does what one would
expect.

commit 3309c37d8c42b2fd002b0d965dafc4be3b6d3e44
Author: Jim Meyering <meyering@fb.com>
Date:   Wed Oct 12 08:57:48 2016 -0700

    viper-tests.el: add a test for bug #24672

diff --git a/test/lisp/emulation/viper-tests.el
b/test/lisp/emulation/viper-tests.el
index 2c63b24..85d83aa 100644
--- a/test/lisp/emulation/viper-tests.el
+++ b/test/lisp/emulation/viper-tests.el
@@ -99,6 +99,19 @@ viper-test-undo-kmacro
       ]
      ))))

+(ert-deftest viper-test-insert-paren-on-cpp-continued-line()
+  "Test for bug #24672:
+Insert '#define z_b\', then change the 'z' to a parenthesis (open or closed)"
+  (should
+   (equal
+    "#define (_b\\\n"
+    (viper-test-undo-kmacro
+     [
+      ?i ?# ?d ?e ?f ?i ?n ?e ?  ?z ?_ ?b ?\\ escape
+         ?F ?z ?s ?\( escape
+         ])
+    )))
+
 (ert-deftest viper-test-undo-2 ()
   "Test for VI like undo behavior.

Is there some test set-up I can perform to make that test work like
what I outlined above?

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Tue, 25 Oct 2016 22:09:40 -0700
> 
> This is a corner case.
> When I start in viper mode with this file contents:
> 
>   #define z_b\
> 
> and then change the "z" to a parenthesis (either one), I get this:
> 
>   #define (z_b^I^I^I^I^I\$
> 
> [I have represented each TAB as "^I", of course]
> Rather surprising to see all of those TAB characters inserted.

This is standard operation of the Emacs C mode: some characters,
including the left parenthesis, are "electric", in that they invoke
reindentation/reformatting of the current line.  Type "C-h k (" to see
the documentation of that, including links to customization options,
which you can tweak if you don't like the default behavior.

IOW, I don't think this is a bug at all, but intended behavior.

Thanks.

P.S. Please don't cross-post to emacs-devel and the bug list.

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Jim Meyering]

On Wed, Oct 26, 2016 at 4:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Tue, 25 Oct 2016 22:09:40 -0700
>>
>> This is a corner case.
>> When I start in viper mode with this file contents:
>>
>>   #define z_b\
>>
>> and then change the "z" to a parenthesis (either one), I get this:
>>
>>   #define (z_b^I^I^I^I^I\$
>>
>> [I have represented each TAB as "^I", of course]
>> Rather surprising to see all of those TAB characters inserted.
>
> This is standard operation of the Emacs C mode: some characters,
> including the left parenthesis, are "electric", in that they invoke
> reindentation/reformatting of the current line.  Type "C-h k (" to see
> the documentation of that, including links to customization options,
> which you can tweak if you don't like the default behavior.
>
> IOW, I don't think this is a bug at all, but intended behavior.

Thanks for replying.
I can see how the insertion of those TABs may be expected,
but the original bug that caught my eye is that the "z" I wanted
to replace is *not* removed.

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Wed, 26 Oct 2016 07:33:23 -0700
> Cc: 24672@debbugs.gnu.org
> 
> I can see how the insertion of those TABs may be expected,
> but the original bug that caught my eye is that the "z" I wanted
> to replace is *not* removed.

Well, your bug report never said that this was the problem, so how
could I have guessed that?  Do you expect me to know the vi commands
by heart? ;-)

Re: bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Tue, 25 Oct 2016 22:09:40 -0700
> 
> This is a corner case.
> When I start in viper mode with this file contents:
> 
>   #define z_b\
> 
> and then change the "z" to a parenthesis (either one), I get this:
> 
>   #define (z_b^I^I^I^I^I\$
> 
> [I have represented each TAB as "^I", of course]
> Rather surprising to see all of those TAB characters inserted.

I replied on the bug list; please don't cross-post here.

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Tue, 25 Oct 2016 22:09:40 -0700
> 
> +(ert-deftest viper-test-insert-paren-on-cpp-continued-line()
> +  "Test for bug #24672:
> +Insert '#define z_b\', then change the 'z' to a parenthesis (open or closed)"
> +  (should
> +   (equal
> +    "#define (_b\\\n"
> +    (viper-test-undo-kmacro
> +     [
> +      ?i ?# ?d ?e ?f ?i ?n ?e ?  ?z ?_ ?b ?\\ escape
> +         ?F ?z ?s ?\( escape
> +         ])
> +    )))
> +

Is there a reason why the test uses 'F', but the recipe you posted
uses 'f' (lower-case)?  (I know nothing about vi commands.)

bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)

[Jim Meyering]

On Wed, Oct 26, 2016 at 8:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Tue, 25 Oct 2016 22:09:40 -0700
>>
>> +(ert-deftest viper-test-insert-paren-on-cpp-continued-line()
>> +  "Test for bug #24672:
>> +Insert '#define z_b\', then change the 'z' to a parenthesis (open or closed)"
>> +  (should
>> +   (equal
>> +    "#define (_b\\\n"
>> +    (viper-test-undo-kmacro
>> +     [
>> +      ?i ?# ?d ?e ?f ?i ?n ?e ?  ?z ?_ ?b ?\\ escape
>> +         ?F ?z ?s ?\( escape
>> +         ])
>> +    )))
>> +
>
> Is there a reason why the test uses 'F', but the recipe you posted
> uses 'f' (lower-case)?  (I know nothing about vi commands.)

The test case constructs it "live", so after inserting the text into
the buffer, point is at the end of the line. From there, "Fz" (search
backwards for "z") is appropriate. My command-line example opens a
file with that contents already there, and with point at the beginning
of the line, so there I used "fz" search forwards for "z").