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 19:16:06 -0400 Message-ID: References: <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> <20180701105820.GB4697@ACM> <20180701181832.GD4697@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530486859 9993 195.159.176.226 (1 Jul 2018 23:14:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 23:14:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 02 01:14:15 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 1fZlXo-0002SZ-2b for ged-emacs-devel@m.gmane.org; Mon, 02 Jul 2018 01:14:12 +0200 Original-Received: from localhost ([::1]:55944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZlZv-00044b-0K for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 19:16:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZlZl-00043a-Rh for emacs-devel@gnu.org; Sun, 01 Jul 2018 19:16:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZlZi-0002o4-AG for emacs-devel@gnu.org; Sun, 01 Jul 2018 19:16:13 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:34575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZlZi-0002lK-3R for emacs-devel@gnu.org; Sun, 01 Jul 2018 19:16:10 -0400 Original-Received: from milanesa.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w61NGgJJ017182; Sun, 1 Jul 2018 19:16:43 -0400 Original-Received: by milanesa.home (Postfix, from userid 20848) id 9040D66100; Sun, 1 Jul 2018 19:16:06 -0400 (EDT) In-Reply-To: <20180701181832.GD4697@ACM> (Alan Mackenzie's message of "Sun, 1 Jul 2018 18:18:32 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered TRK_NCM1=0.1, EDT_SA_DN_PASS=0, RV6319=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6319> : inlines <6730> : streams <1791322> : uri <2667137> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:226881 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. > There is no comment there, but scan-sexps skips to it nevertheless. The starting point is within the string (not according to the C language rules, of course, but according to the syntax-tables settings), and operations like scan-sexps are documented to work under the assumption that the starting point is outside of strings/comments, so it is very much correct for it to consider this "// string\n" to be a comment. I agree that it would be OK for scan-sexps in this case to consider that \n terminates the string rather than the comment, tho. >> When you change the syntax property of ?\n to be "> s", it changes the >> behavior expected based on the documentation, .... > Er, documentation? This new flag isn't documented yet, or at least not > in any permanent fashion. Well, I was talking hypothetically under the assumption that "s" is documented to mean something like "closes a string if there's one to close". >> .... so in the above case it should treat the \n as closing the string >> rather than closing the comment. > I agree. OK, sorry 'bout the above, then, I see we agree. >> It needs to work reliably for those languages where strings >> are indeed terminated by newline (e.g. jgraph-mode in GNU ELPA). > You mean, jgraph-mode is another use-case for `s'? (I'm not familiar > with it.) I looked for existing use-cases and I indeed found one. It's very much not high-profile, tho. Also this use-case is slightly different in that the \n is really the normal/only way to terminate the string in jgraph. In case you're interested: http://web.eecs.utk.edu/~plank/plank/jgraph/jgraph.html >> But that brings us back to "why not use string-fence?". > Yes. String-fence interferes with syntactical stuff "inside" the > invalid string, whereas the `s' flag won't. Not sure how serious this "interferes with syntactical stuff" is in practice. >> 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). > There's no need to guess. The compiler defines the state, namely that > the (invalid) string ends at the EOL, and what follows is non-string. The compiler just makes an arbitrary choice, just like we do and that has no bearing on what the intended valid state is (which is not something the compiler can discover either: it's only available in the head of the coder). > There's no need to guess. back_maybe_comment is in the new > scratch/fontify-open-string branch. It is NOT that complicated. Unsurprisingly it introduces a complexity which I find unjustified by the presented benefits. But it now occurs to me that maybe we can do better: have you tried to merge back_maybe_comment into back_comment? After all, back_comment already pays attention to strings (in order to try and correctly handle comment openers appearing within strings), so there's a possibility that back_comment might be able to handle your use case with much fewer changes (and in that case, the performance cost would be pretty close to 0, I think). Stefan