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: Fri, 9 Dec 2016 19:07:47 +0000 Message-ID: <20161209190747.GC2203@acm.fritz.box> References: <20161206195507.GA2996@acm.fritz.box> <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1481310530 15842 195.159.176.226 (9 Dec 2016 19:08:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 19:08:50 +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 Fri Dec 09 20:08:46 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 1cFQXF-0003DD-7j for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 20:08:45 +0100 Original-Received: from localhost ([::1]:48320 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFQXJ-0000BQ-8e for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 14:08:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFQWk-0008W3-7J for emacs-devel@gnu.org; Fri, 09 Dec 2016 14:08:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFQWh-0000F8-0E for emacs-devel@gnu.org; Fri, 09 Dec 2016 14:08:14 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:12866 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cFQWg-0000Ei-MA for emacs-devel@gnu.org; Fri, 09 Dec 2016 14:08:10 -0500 Original-Received: (qmail 86224 invoked by uid 3782); 9 Dec 2016 19:08:08 -0000 Original-Received: from acm.muc.de (p548C753B.dip0.t-ipconnect.de [84.140.117.59]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 09 Dec 2016 20:08:07 +0100 Original-Received: (qmail 2925 invoked by uid 1000); 9 Dec 2016 19:07:47 -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.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:210200 Archived-At: Hello, Dmitry. On Thu, Dec 08, 2016 at 11:24:12PM +0200, Dmitry Gutov wrote: > On 08.12.2016 22:15, Alan Mackenzie wrote: > > I propose, additionally, a new buffer local variable which, if > > non-nil, will contain a buffer position to use in place of the "1". > That's functionally equivalent to my proposed patch with > syntax-ppss-dont-widen, except for the case where that buffer local > value turns out to be higher than POS. 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. > Can parse-partial-sexp parse backwards? No, not at all, and it's unlikely ever to be able to do so. > > Our primitives `car', `cdr', `list', etc. also don't say > > what the intention behind them is; they just work. Narrowing is what it > > is. Simple and austere. > All the primitives you've enumerated above work on simple values and > don't change the buffer state. Narrowing doesn't change the buffer state either, beyond what it explicitly says it does. In particular, it doesn't change things like whether a particular buffer position is inside a string. > Narrowing is anything but austere. I disagree. I think there are attempts afoot to make it non-austere, and that these attempts are mistaken in principle. > > Complexifying narrowing by introducing a notion of "intention" would > > surely make it more difficult to use and possibly foul things up > > massively. > The reasons for it have been described plenty of times. And no, it will > be pretty trivial conceptually. 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. > > As I said above, I think syntax-ppss should be retired and replaced by a > > function which does parse-partial-sexp starting at 1 rather than > > (point-min). > You keep repeating that word (replace), as though that solves anything. It would solve bug #22983. > If we introduce the new function and all of Emacs core switches to it, > 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? -- Alan Mackenzie (Nuremberg, Germany).