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: CC Mode and electric-pair "problem". Date: Sun, 1 Jul 2018 18:18:32 +0000 Message-ID: <20180701181832.GD4697@ACM> References: <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; charset=us-ascii X-Trace: blaine.gmane.org 1530469590 26692 195.159.176.226 (1 Jul 2018 18:26:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 18:26:30 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 20:26:26 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 1fZh3H-0006o9-4G for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 20:26:23 +0200 Original-Received: from localhost ([::1]:55249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZh5O-0001on-Dr for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 14:28:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZh4l-0001Vf-86 for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:27:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZh4g-0003TV-8f for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:27:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:28487 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fZh4f-0003Qv-St for emacs-devel@gnu.org; Sun, 01 Jul 2018 14:27:50 -0400 Original-Received: (qmail 90979 invoked by uid 3782); 1 Jul 2018 18:27:47 -0000 Original-Received: from acm.muc.de (p5B147BF6.dip0.t-ipconnect.de [91.20.123.246]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 01 Jul 2018 20:27:46 +0200 Original-Received: (qmail 6962 invoked by uid 1000); 1 Jul 2018 18:18:32 -0000 Content-Disposition: inline In-Reply-To: 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:226880 Archived-At: Hello, Stefan. On Sun, Jul 01, 2018 at 12:13:32 -0400, Stefan Monnier wrote: > >> 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. As you know, I solved these anomalies some while ago with the comment-cache branch. > 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. > .... so in the above case it should treat the \n as closing the string > rather than closing the comment. I 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.) > > 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. Yes. > > 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?". Yes. String-fence interferes with syntactical stuff "inside" the invalid string, whereas the `s' flag won't. > > 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). 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. > > 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. There's no need to guess. back_maybe_comment is in the new scratch/fontify-open-string branch. It is NOT that complicated. > Stefan -- Alan Mackenzie (Nuremberg, Germany).