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 10:58:20 +0000 Message-ID: <20180701105820.GB4697@ACM> References: <20180618103654.GA9771@ACM> <20180618154227.GB3973@ACM> <20180619050244.GA3946@ACM> <20180627182717.GA4625@ACM> <20180630190327.GC6816@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530443178 26808 195.159.176.226 (1 Jul 2018 11:06:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Jul 2018 11:06:18 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Stephen Leake , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 01 13:06:13 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 1fZaBJ-0006rq-8C for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 13:06:13 +0200 Original-Received: from localhost ([::1]:54023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZaDO-0003Mj-ML for ged-emacs-devel@m.gmane.org; Sun, 01 Jul 2018 07:08:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fZaCh-0003Mc-V0 for emacs-devel@gnu.org; Sun, 01 Jul 2018 07:07:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fZaCe-0005VP-Qe for emacs-devel@gnu.org; Sun, 01 Jul 2018 07:07:39 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52065 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fZaCe-0005Ut-If for emacs-devel@gnu.org; Sun, 01 Jul 2018 07:07:36 -0400 Original-Received: (qmail 4374 invoked by uid 3782); 1 Jul 2018 11:07:35 -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 13:07:34 +0200 Original-Received: (qmail 4733 invoked by uid 1000); 1 Jul 2018 10:58:20 -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:226866 Archived-At: Hello, Stefan. On Sun, Jul 01, 2018 at 00:02:56 -0400, Stefan Monnier wrote: > >> So let's look at the technical issues: > >> You suggest introducing a new syntax-table thingy similar to > but for > >> strings. Let's call it ] > > As I noted above, I have implemented it as another flag, `s'. > Better, yes. > > This is simple with the flag `s'. NL would thus have end-comment syntax > > _and_ the `s' flag. In scan_lists, back_comment will be tried before > > what I'm calling `back_maybe_string', since being a comment ender must have > > precedence over being a string terminator. > Why? How 'bout: > char foo[] = "some unterminated // string Bug compatibility with the current scan-sexps. > > String-fence stopped the 'chomp facility of electric-pair-mode > > working properly (for the currently accepted value of "properly"). > I suspect that it'll be easier to fix electric-pair-mode. This would be my preferred option too, but it's not easy. > But the downside is that every time we scan backwards over a newline > we'll have to pay the extra cost of checking whether it's maybe > closing an unterminated string. Hmmm. Yes, this could increase the backward scanning time quite substantially, but we already do this for back_comment, though. It might be unacceptable. A possibility would be to apply the `s' flag only in a syntax-table text property applied to the newlines of unterminated strings. > I think such a "string terminator" thingy would be valuable if it were > used/needed for *valid* code. But introducing such complexity just to > tweak the handling of invalid code doesn't seem like a good tradeoff > at all. I disagree. Whilst editing code, it is in an invalid state nearly all the time. It is our job to present the user with the best possible display for this dominant state. > > That's what I'm doing with `s'. The extra complexity in syntax.c > > doesn't seem all that bad at the moment. back_maybe_string is currently > > 137 lines long (including a macro analogous to INC_FROM, and a lossage: > > clause modelled on the one in back_comment)), compared with > > back_comment's 289 lines. I'm planning on committing this new code to a > > branch in the next few days, then you can judge better whether the new > > facility is worth it. > 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. > > "S-T-NG" may be fine for Emacs 28 or 29, but the syntax table is what we > > have, and what we must work with in the short term. > We'll never get to "S-T-NG" if we keep it for the future. You see the need for it, and have at least some vague notion of what it should look like. I don't. Get hacking! > Stefan -- Alan Mackenzie (Nuremberg, Germany).