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 (was: Preview: portable dumper) Date: Tue, 6 Dec 2016 19:55:08 +0000 Message-ID: <20161206195507.GA2996@acm.fritz.box> References: <83zikdl7oo.fsf@gnu.org> <83y3zxkwms.fsf@gnu.org> <20161203143603.GA6921@acm.fritz.box> <43e8a279-3278-817b-7cd4-b669c5ae320b@yandex.ru> <20161204123434.GB2791@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 1481054187 13101 195.159.176.226 (6 Dec 2016 19:56:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2016 19:56:27 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 20:56:22 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 1cELqe-0002DH-T1 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 20:56:21 +0100 Original-Received: from localhost ([::1]:34397 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cELqi-000418-Lm for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 14:56:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cELpu-0003zq-2o for emacs-devel@gnu.org; Tue, 06 Dec 2016 14:55:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cELpr-0002V6-AG for emacs-devel@gnu.org; Tue, 06 Dec 2016 14:55:34 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:31676 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cELpr-0002Ug-12 for emacs-devel@gnu.org; Tue, 06 Dec 2016 14:55:31 -0500 Original-Received: (qmail 10880 invoked by uid 3782); 6 Dec 2016 19:55:28 -0000 Original-Received: from acm.muc.de (p548C7114.dip0.t-ipconnect.de [84.140.113.20]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 06 Dec 2016 20:55:27 +0100 Original-Received: (qmail 3111 invoked by uid 1000); 6 Dec 2016 19:55:08 -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:210091 Archived-At: Hello, Stefan. On Sun, Dec 04, 2016 at 05:24:45PM -0500, Stefan Monnier wrote: > >> Your patch was indeed simpler. Indeed, it was so simple as actually not > >> to work in general, as well as being ~2 orders of magnitude slower than > >> the current (forward-comment -1). > > You make it sound like it barely ever works and it's always 100 > > times slower. I think this qualifies as "gross misrepresentation". > As a counter-point, I've been using the patch below since this > discussion, without noticing any adverse effects. I don't doubt that it > will occasionally mis-behave in cc-mode buffers, but I'm not sure it's > an argument against this patch. I'm not quite sure what you're saying here. Normally, a piece of software not working properly is an extremely strong argument against it (though it's an equally strong argument for fixing it). > After all, there are mostly 3 entities at play here: > - this patch (i.e. the linkage between forward-commment and syntax-ppss). > - syntax-ppss itself. > - cc-mode. > I think most of the problems that will show up with this patch .... What, exactly, is this patch intended to do? That's not obvious. > .... can be attributed to the current syntax-ppss implementation (e.g. > its inability to deal reliably with narrowing or with changes of the > syntax-table). Maybe those problems will best be solved not just by > changing syntax-ppss but by providing more info to syntax-ppss (e.g. > requiring major modes who narrow the buffer or change the syntax-table > to indicate to syntax-ppss how to handle it (since there are various > possible choices and syntax-ppss usually can't know which is best or > even which is right)). I think this would be a last resort, when nothing else can work. The syntactic primitives should not have high level lisp code poking about in their innards. When it comes to narrowing a buffer, I think that the syntactic context of a buffer position should not depend on whether the buffer has been narrowed. If there are use cases this inconveniences, I think that those use cases' use of narrowing is mistaken, and some other tool should be used in its place. > So I see this patch as an opportunity to improve syntax-ppss. I don't think anybody will object to improving syntax-ppss. But, at the same time, calling syntax-ppss from the C syntax routines should be avoided, as far as possible. Such calls are likely to transform side-effect free functions (such as forward-comment) into side-effect encumbered functions, which is likely to make them less useful, and to make Emacs more buggy, less flexible and more difficult to use. And, just to emphasise, I think it's clear that syntax-ppss has no business in forward-comment. syntax-ppss is slow (compared to the current implementation of forward-comment), and there's no need for it, given the existence of the comment-cache branch. > Stefan -- Alan Mackenzie (Nuremberg, Germany).