* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
2016-10-12 3:59 bug#24672: 26.0.50; viper-mode + c-mode: "ce" fails in cpp-continued stmt Jim Meyering
@ 2016-10-26 5:09 ` Jim Meyering
0 siblings, 0 replies; 6+ messages in thread
From: Jim Meyering @ 2016-10-26 5:09 UTC (permalink / raw)
To: emacs-devel, 24672
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?
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
[not found] <CA+8g5KGMrDHWQywkP-OsZoEVEVreWHTOwajFjVeB4ugeu-6pog@mail.gmail.com>
@ 2016-10-26 11:51 ` Eli Zaretskii
2016-10-26 14:33 ` Jim Meyering
2016-10-26 15:03 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2016-10-26 11:51 UTC (permalink / raw)
To: Jim Meyering; +Cc: 24672
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
2016-10-26 11:51 ` bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive) Eli Zaretskii
@ 2016-10-26 14:33 ` Jim Meyering
2016-10-26 15:02 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Jim Meyering @ 2016-10-26 14:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24672
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
2016-10-26 14:33 ` Jim Meyering
@ 2016-10-26 15:02 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2016-10-26 15:02 UTC (permalink / raw)
To: Jim Meyering; +Cc: 24672
> 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? ;-)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
[not found] <CA+8g5KGMrDHWQywkP-OsZoEVEVreWHTOwajFjVeB4ugeu-6pog@mail.gmail.com>
2016-10-26 11:51 ` bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive) Eli Zaretskii
@ 2016-10-26 15:03 ` Eli Zaretskii
2016-10-26 15:37 ` Jim Meyering
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2016-10-26 15:03 UTC (permalink / raw)
To: Jim Meyering; +Cc: 24672
> 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.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive)
2016-10-26 15:03 ` Eli Zaretskii
@ 2016-10-26 15:37 ` Jim Meyering
0 siblings, 0 replies; 6+ messages in thread
From: Jim Meyering @ 2016-10-26 15:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24672
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").
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-26 15:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CA+8g5KGMrDHWQywkP-OsZoEVEVreWHTOwajFjVeB4ugeu-6pog@mail.gmail.com>
2016-10-26 11:51 ` bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive) Eli Zaretskii
2016-10-26 14:33 ` Jim Meyering
2016-10-26 15:02 ` Eli Zaretskii
2016-10-26 15:03 ` Eli Zaretskii
2016-10-26 15:37 ` Jim Meyering
2016-10-12 3:59 bug#24672: 26.0.50; viper-mode + c-mode: "ce" fails in cpp-continued stmt Jim Meyering
2016-10-26 5:09 ` bug#24672: writing a test for Bug#24672 (viper mode malfunction while inserting a paren in continued cpp directive) Jim Meyering
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).