From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: CC Mode and electric-pair "problem". Date: Sun, 01 Jul 2018 12:13:32 -0400 Message-ID: References: <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <20180701105820.GB4697@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530461540 830 195.159.176.226 (1 Jul 2018 16:12:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 16:12:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 18:12:16 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 1fZexU-00007l-84 for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 18:12:16 +0200 Original-Received: from localhost ([::1]:54927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZezb-0007Xl-8J for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 12:14:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZeyx-0007XV-LC for emacs-devel@gnu.org; Sun, 01 Jul 2018 12:13:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZeyu-0001oM-G5 for emacs-devel@gnu.org; Sun, 01 Jul 2018 12:13:47 -0400 Original-Received: from [195.159.176.226] (port=35963 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fZeyu-0001nH-8e for emacs-devel@gnu.org; Sun, 01 Jul 2018 12:13:44 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fZewj-0007hg-6Y for emacs-devel@gnu.org; Sun, 01 Jul 2018 18:11:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:9Sy7ITkYK8+tftOv9QiVFbj5xzc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:226875 Archived-At: >> Why? How 'bout: >> char foo[] = "some unterminated // string > Bug compatibility with the current scan-sexps. I don't see why: currently, scan-sexps skips over the comment, but that's not a bug: it's exactly what it is documented to do. When you change the syntax property of ?\n to be "> s", it changes the behavior expected based on the documentation, so in the above case it should treat the \n as closing the string rather than closing the comment. It needs to work reliably for those languages where strings are indeed terminated by newline (e.g. jgraph-mode in GNU ELPA). > Hmmm. Yes, this could increase the backward scanning time quite > substantially, but we already do this for back_comment, though. I expect the impact will be less than that of back_comment, but I think we'd want actual measurements anyway. > A possibility would be to apply the `s' flag only in a syntax-table text > property applied to the newlines of unterminated strings. But that brings us back to "why not use string-fence?". > I disagree. Whilst editing code, it is in an invalid state nearly all > the time. But we usually don't make any effort to guess what the intended closest valid state might be, except where the user is actively editing the text (e.g. by proposing completion candidates for identifiers). >> I can't imagine how seeing the code could change my opinion on whether >> it's worth it. > I would hope you would weigh up the small additional complexity against > the new features it brings, and reach a balanced judgment, rather than > dismissing the new idea without consideration. I did consider it. I just know syntax.c well enough that I'd be very surprised if the actual patch (as opposed to by guess at the what the patch would look like) makes me change my mind. Stefan