From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Sat, 10 Dec 2016 01:30:24 +0200 Message-ID: <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> References: <20161206195507.GA2996@acm.fritz.box> <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209190747.GC2203@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1481326372 7441 195.159.176.226 (9 Dec 2016 23:32:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 23:32:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 Cc: Stefan Monnier , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 10 00:32:48 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 1cFUek-00016L-T7 for ged-emacs-devel@m.gmane.org; Sat, 10 Dec 2016 00:32:47 +0100 Original-Received: from localhost ([::1]:49404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFUeo-0000xS-PV for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 18:32:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFUdt-0000sE-Ka for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:31:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFUdo-0006lQ-No for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:31:53 -0500 Original-Received: from mail-wm0-f51.google.com ([74.125.82.51]:38628) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cFUdo-0006R5-IC for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:31:48 -0500 Original-Received: by mail-wm0-f51.google.com with SMTP id f82so870055wmf.1 for ; Fri, 09 Dec 2016 15:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=57fFD1sCSPS3IiGA66sjcJzmQbtpoNVAcP4X0BEmEnU=; b=wTR+IcEtah3aY0m+PX1Qjbwz/D53jFv/jj4utqrPOQFkE8K4K/kuFPfaEFG5x15FY/ BdvHR5Y9thfNFEUtTwco1uaH6dfXWkgYU1Y4NwiTTfO8CUXZgJCUyt5/pzfr2wq/QJYd U9awMryQwCw2cWcWxGxLgxM3M17afNpoFK9WcWil3sGb03/8IEatXR/i1ArhlhBunBtv T7hsQJE+Qk2+e1zSzsfZfVs5rgQXqfhK32D3a27yaPjnt1DHhlgojavpdLAJaMuoUiER HvxvJIPThdN7DWhjkgiSz+cpeyX43sB0q+GSs9HQ41nyX614udTTtk61Izjm9qj7Pm9f 1wtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=57fFD1sCSPS3IiGA66sjcJzmQbtpoNVAcP4X0BEmEnU=; b=WcZVGhwJAEBC0XW7k3N/AD7DlX80cZ1NtmHbqBo6dnLmijNdSmn1KFBNb2le2EWW/P zmLx5VjaGR6LzmTnZpitP4y7EAKNEAs/P+KTfrReWKXgpcNIweCZM2O5jzENcmu5l4CW rRQDWz21C1HCYP6ePHhrs/vDmEzcju+P/UpyS7/DgOyyHECzCjL862StoYx8xSMdEjJV 3fuxutuDOKZqor4raQKJdxCK+EGgzfqzYnbtn/uoaLpXk+OAkywPz9lz4w/9oFiQGs6z w0qKF7Q6VpB1PcneXKiCRc+onArkXRvpcmb1RDkfXwbL2XDGNNpgPD+9BwLESPfedcXI mKqA== X-Gm-Message-State: AKaTC02qz7Vevgyr2WE83fl6UCq3i9zh8+9MNbtcBv1b5FsLrnsyEB9hMaf7Ue7UaCXJeQ== X-Received: by 10.28.150.75 with SMTP id y72mr508575wmd.47.1481326226328; Fri, 09 Dec 2016 15:30:26 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id c202sm825232wme.1.2016.12.09.15.30.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Dec 2016 15:30:25 -0800 (PST) In-Reply-To: <20161209190747.GC2203@acm.fritz.box> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.51 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:210213 Archived-At: On 09.12.2016 21:07, Alan Mackenzie wrote: > That could be. But a variable called wyntax-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. > 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). > 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. > 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. >> 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). More importantly, any change you would make to the "new" function you could make to syntax-ppss instead. >> 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.