From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master bb591f139f: Enhance CC Mode's fontification, etc., of unterminated strings. Date: Wed, 23 May 2018 20:46:19 +0000 Message-ID: <20180523204619.GB4191@ACM> References: <20180522174054.GA4504@ACM> <877envijii.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1527108385 17578 195.159.176.226 (23 May 2018 20:46:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 23 May 2018 20:46:25 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Emacs developers , Tino Calancha To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 23 22:46:21 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fLaeL-0004Sh-FB for ged-emacs-devel@m.gmane.org; Wed, 23 May 2018 22:46:21 +0200 Original-Received: from localhost ([::1]:35359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLagS-0001H4-EL for ged-emacs-devel@m.gmane.org; Wed, 23 May 2018 16:48:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLagC-0001BI-NX for emacs-devel@gnu.org; Wed, 23 May 2018 16:48:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLag9-00059z-II for emacs-devel@gnu.org; Wed, 23 May 2018 16:48:16 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61023 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fLag9-00059N-6s for emacs-devel@gnu.org; Wed, 23 May 2018 16:48:13 -0400 Original-Received: (qmail 68739 invoked by uid 3782); 23 May 2018 20:48:10 -0000 Original-Received: from acm.muc.de (p5B1475BE.dip0.t-ipconnect.de [91.20.117.190]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 23 May 2018 22:48:09 +0200 Original-Received: (qmail 5125 invoked by uid 1000); 23 May 2018 20:46:19 -0000 Content-Disposition: inline In-Reply-To: <877envijii.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225633 Archived-At: Hello, Joćo. On Tue, May 22, 2018 at 20:21:25 +0100, Joćo Tįvora wrote: > Hi Alan, > Alan Mackenzie writes: > > electric-tests.el is anything but straightforward to read. > lol, sorry I couldn't quite make the 20000+LOC standards of cc-mode.el > :p. :-) > No really, kidding, , that file needs macros because it > defines almost 500 tests with very subtle variations between them. Yes, I understand this. > You tripped one of them, and I think we're both glad you did > (regardless of who is at fault: test or c++-mode) Well, I'm glad about it, so thanks for this test file!. The bug is most definitely in CC Mode - I'd neglected to handle properly an open string lacking an EOL to "terminate" it. This will be easy to fix. > > The test referred to above is generated by a nest of two or three > > macros, somehow, and it is not obvious what buffer operations were > > generated by these macros, and how they triggered a newly introduced bug > > in C++ Mode. The comments in the file are too sparse to help. > Here's how it works: There's only one macro for electric-pair tests, > aptly named define-electric-pair-test. > In that file, find the `define-electric-pair-test' that most closely > matches the test failure, in this case its: > (define-electric-pair-test autowrapping-5 > "foo" "\"" :expected-string "\"foo\"" :expected-point 2 > :fixture-fn #'(lambda () > (electric-pair-mode 1) > (mark-sexp 1))) > now go to the end of the expression and type M-x > pp-macroexpand-last-sexp. It should be easy to find your failing test, > defined in terms of `ert-deftest', in a list of 6 tests. Here it is: > (ert-deftest electric-pair-autowrapping-5-at-point-2-in-c++-mode-in-strings nil > "With |\"foo\"|, try input \" at point 2. Should become |\"\"foo\"\"| and point at 3" > (electric-pair-test-for "\"foo\"" 2 34 "\"\"foo\"\"" 3 'c++-mode nil > #'(lambda nil > (electric-pair-mode 1) > (mark-sexp 1)))) > Now M-x edebug-defun this form straight in the *Pp Macroexpand Output* > buffer, and M-x edebug-defun the `electric-pair-test-for' defun, > too. Now run the test: > M-x ert RET electric-pair-autowrapping-5-at-point-2-in-c++-mode-in-strings RET Thanks for this recipe. It wasn't self evident. > As you step through the code, you'll eventually land on that lambda > which calls mark-sexp and hints, along with the name, that this is a > region-autowrapping test. This is why it expects, for a single character > of input, that two quotes are inserted in the buffer instead of > one. The test passes in my 26.1 as you probably already knew. > Good luck hunting the bug and let me know if you have more problems. Thanks for the help. > Thanks, > Joćo > PS: you could also have used: > M-x ert-describe-test RET electric-pair-autowrapping-5-at-point-2-in-c++-mode-in-strings > Which would have rendered a nice docstring > electric-pair-autowrapping-5-at-point-2-in-c++-mode-in-strings is a > test defined in `electric-tests.elc'. > With |"foo"|, try input " at point 2. Should become |""foo""| and point at 3 > [back] > Though, admittedly, this is misleading for the "autowrapping" tests, > since it doesn't tell you about the "mark-sexp" region-making > command. Also not immediatly clear perhaps it that the | are buffer > boundaries. Just to be pedantic, it also doesn't say where " number 4 is inserted (whether at EOL, or before " number 2), but that can be resolved by the application of intelligence. :-) > Ideally, it should read read > With |"foo"|, at point 2, (mark-sexp 1) and try input ". > Should become |""foo""| and point at 3 > I will try to fix this in master. > Also M-x ert-find-test-other-window could have helped you, but it > doesn't (brings me to the beginning of the file, which isn't helpful). I > don't know why, does anyone? -- Alan Mackenzie (Nuremberg, Germany).