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

Previous Next

To reply to this bug, email your comments to 24672 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; viper-mode + c-mode: "ce" fails in cpp-continued stmt
Date: Tue, 11 Oct 2016 20:59:05 -0700

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'

Message #8 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: emacs-devel <emacs-devel <at> gnu.org>, 24672 <at> debbugs.gnu.org
Subject: writing a test for Bug#24672 (viper mode malfunction while inserting
 a paren in continued cpp directive)
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. 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 <at> 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?

Message #11 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 24672 <at> debbugs.gnu.org
Subject: Re: writing a test for Bug#24672 (viper mode malfunction while
 inserting a paren in continued cpp directive)
Date: Wed, 26 Oct 2016 14:51:38 +0300

> From: Jim Meyering <jim <at> 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.

Message #14 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24672 <at> debbugs.gnu.org
Subject: Re: writing a test for Bug#24672 (viper mode malfunction while
 inserting a paren in continued cpp directive)
Date: Wed, 26 Oct 2016 07:33:23 -0700

On Wed, Oct 26, 2016 at 4:51 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Jim Meyering <jim <at> 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.

Message #17 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 24672 <at> debbugs.gnu.org
Subject: Re: writing a test for Bug#24672 (viper mode malfunction while
 inserting a paren in continued cpp directive)
Date: Wed, 26 Oct 2016 18:02:45 +0300

> From: Jim Meyering <jim <at> meyering.net>
> Date: Wed, 26 Oct 2016 07:33:23 -0700
> Cc: 24672 <at> 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? ;-)

Message #20 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Meyering <jim <at> meyering.net>
Cc: 24672 <at> debbugs.gnu.org
Subject: Re: writing a test for Bug#24672 (viper mode malfunction while
 inserting a paren in continued cpp directive)
Date: Wed, 26 Oct 2016 18:03:53 +0300

> From: Jim Meyering <jim <at> 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.)

Message #23 received at 24672 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24672 <at> debbugs.gnu.org
Subject: Re: writing a test for Bug#24672 (viper mode malfunction while
 inserting a paren in continued cpp directive)
Date: Wed, 26 Oct 2016 08:37:26 -0700

On Wed, Oct 26, 2016 at 8:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Jim Meyering <jim <at> 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").

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.