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: forward-comment and syntax-ppss Date: Sun, 11 Dec 2016 10:17:15 +0000 Message-ID: <20161211101715.GA14084@acm.fritz.box> References: <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209190747.GC2203@acm.fritz.box> <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1481451475 12038 195.159.176.226 (11 Dec 2016 10:17:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 10:17:55 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 11 11:17:51 2016 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 1cG1CX-0001vK-SH for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 11:17:50 +0100 Original-Received: from localhost ([::1]:55061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG1Ca-000431-JF for ged-emacs-devel@m.gmane.org; Sun, 11 Dec 2016 05:17:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cG1CT-00042f-Ju for emacs-devel@gnu.org; Sun, 11 Dec 2016 05:17:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cG1CQ-0005Cf-GB for emacs-devel@gnu.org; Sun, 11 Dec 2016 05:17:45 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:14705 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cG1CQ-0005C9-5N for emacs-devel@gnu.org; Sun, 11 Dec 2016 05:17:42 -0500 Original-Received: (qmail 30841 invoked by uid 3782); 11 Dec 2016 10:17:39 -0000 Original-Received: from acm.muc.de (p4FC46F9E.dip0.t-ipconnect.de [79.196.111.158]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 11 Dec 2016 11:17:38 +0100 Original-Received: (qmail 14194 invoked by uid 1000); 11 Dec 2016 10:17:15 -0000 Content-Disposition: inline In-Reply-To: <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> 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.4 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:210263 Archived-At: Hello, Dmitry. On Sat, Dec 10, 2016 at 01:30:24AM +0200, Dmitry Gutov wrote: > On 09.12.2016 21:07, Alan Mackenzie wrote: > > That could be. But a variable called syntax-ppss-dont-widen has the > > caller explicitly messing around with the flowchart of syntax-ppss, > > which is not a good thing. I think my proposed new local variable is > > better for this reason. > It's better in one sense and worse in another. Since parse-partial-sexp > can't parse backwards, you're leaving a whole range of values of POS on > which syntax-ppss will have to just raise an error. I don't think this is an issue. (syntax-ppss-1 POS), when new-local-variable is non-nil simulates (parse-partial-sexp new-local-variable POS), and the latter would throw an error for precisely the same values of POS as the former. > > Narrowing doesn't change the buffer state either, beyond what it > > explicitly says it does. > It changes state and, as such, behavior of a huge number of functions > (both core and third-party ones). Maybe, but these changes are the direct desired effect of narrowing. They're not nasty unforeseen side effects. > > In particular, it doesn't change things like > > whether a particular buffer position is inside a string. > Not every buffer position is unequivocally "inside a strong" or not. > Take this example. > // Here's a string: "abc". > Is abc inside a string? That depends on what exactly we mean by that, > for a given use case. That may be the case, but that has nothing to do with what I said ("In particular, it doesn't change ...."). Whether abc is inside a string or not doesn't vary by the narrowing. It's determined by other factors. > > It tends to be trivial to add stuff on. Much easier than getting rid of > > stuff. And that extra stuff might well be fat rather than muscle. > That's just rhetoric. I don't think so. In particular, I was thinking of what I think is called "hard widening". I think it would be a mistake to add this feature. At the moment, narrowing is a strong, direct, simple facility - it does what it says it does and no more. Were "hard widening" to be introduced, we could easily end up with a confused mess of `widen' and `hard-widen' through the code, with nobody being quite sure which one to use and why. There might be lots of depressing errors where the wrong one is used. > >> You keep repeating that word (replace), as though that solves anything. > > It would solve bug #22983. > No, it won't. For instance, because the bug is complaining about the > behavior of syntax-ppss (see, I can play these word games too). Oh dear, Dmitry! ;-) > More importantly, any change you would make to the "new" function you > could make to syntax-ppss instead. The new function would be a different function, i.e. it would have a different definition. Just for clarity, it would not be written from scratch, it would be based on the current syntax-ppss. > >> and that function doesn't have an "escape hatch", the multi-mode > >> packages will be hung out to dry. > > I wouldn't want that to happen. Does the suggested new buffer local > > variable (to specify the lower bound in the notional partial-parse-sexp) > > not provide this escape hatch? > It would (if we're talking about changing syntax-ppss, and not anything > else). It does come with its own weird semantics, however, mentioned at > the top of this message. > Further, the good part of this proposal is more or less equivalent to > "indexing syntax-ppss cache by point-min" as proposed by Stefan. I think I agree here. But "good part" implies the existence of a "less good part". What, in your view, constitues this "less good part"? -- Alan Mackenzie (Nuremberg, Germany).