From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Tue, 06 Dec 2016 17:56:56 -0500 Message-ID: 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> <20161206195507.GA2996@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481065087 4799 195.159.176.226 (6 Dec 2016 22:58:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2016 22:58:07 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 23:58:04 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 1cEOgU-0000RG-QY for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 23:58:03 +0100 Original-Received: from localhost ([::1]:35396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEOgY-0001KN-VN for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2016 17:58:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cEOfc-0000cJ-EB for emacs-devel@gnu.org; Tue, 06 Dec 2016 17:57:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cEOfT-0007Gg-V0 for emacs-devel@gnu.org; Tue, 06 Dec 2016 17:57:03 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:30403) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cEOfT-0007Fu-ME for emacs-devel@gnu.org; Tue, 06 Dec 2016 17:56:59 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/KQAu3EVY/50WNJ1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZeglwQgzAEAgKCEUMRAQIBAQEBAQEBYiiEaQEEAVYjBQsLDiYSFBgNJIh6CK0Ui0QBAQEHAiWLGYopBY98hQCFapsahjqSDzUheBMOg1wcgXsgiS0BAQE X-IPAS-Result: A0A/KQAu3EVY/50WNJ1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZeglwQgzAEAgKCEUMRAQIBAQEBAQEBYiiEaQEEAVYjBQsLDiYSFBgNJIh6CK0Ui0QBAQEHAiWLGYopBY98hQCFapsahjqSDzUheBMOg1wcgXsgiS0BAQE X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="281754340" Original-Received: from 157-52-22-157.cpe.teksavvy.com (HELO pastel.home) ([157.52.22.157]) by smtp.teksavvy.com with ESMTP; 06 Dec 2016 17:56:57 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id DE9CE6553A; Tue, 6 Dec 2016 17:56:56 -0500 (EST) In-Reply-To: <20161206195507.GA2996@acm.fritz.box> (Alan Mackenzie's message of "Tue, 6 Dec 2016 19:55:08 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:210095 Archived-At: > 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). It's probably a strong argument against installing it willy nilly, yes. > What, exactly, is this patch intended to do? That's not obvious. It gets rid of some pathological cases where backward scanning currently may re-scan the whole buffer over and over again, each time from point-min, resulting in excruciatingly slow backward movement (these cases are fairly rare, luckily). > 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. I don't much care for such philosophy, because I consider syntax-ppss to be low-level Lisp code. > 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. As you know by now this is just one opinion, and other users of narrow-to-region beg to differ, and hence we will need to provide a way for users of narrow-to-region to communicate their intentions, since without that extra information, there can be no reliable caching of parsing. > 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. Fine by me. >> 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. We've happily crossed that bridge already (tho not by calling syntax-ppss but by calling syntax-propertize). > 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), The patch I showed only uses syntax-ppss when we would otherwise re-parse the whole buffer, so it shouldn't slow things down too much. BTW, when writing syntax-ppss I did not really intend to "speed things up", but to get rid of pathologically slow behavior. In many cases calling parse-partial-sexp from point-min will be faster than calling syntax-ppss (mostly because syntax-ppss is all written in Elisp, so just the time to consult its cache can be longer than the time to compute the answer from scratch), but its behavior should stay "good enough" in a longish buffers (where calling parse-partial-sexp from point-min becomes excessive). IOW, syntax-ppss will be slower than parse-partial-sexp when parse-partial-sexp is fast, but it will be faster when parse-partial-sexp is slow. > and there's no need for it, given the existence of the > comment-cache branch. This branch has fundamentally the same caching problems as syntax-ppss (i.e. in case of narrowing it may sometimes return what the user intended and sometimes not), unsurprisingly. And it also suffers from "Such calls are likely to transform side-effect free functions (such as forward-comment) into side-effect encumbered functions". And of course, it's a much larger change, with a redundant cache. So, from where I sit I'd put it the other way around: "there's no need for the comment-cache branch, given the existence of this syntax-ppss-based simple patch". Of course, you could argue that your patch works with cc-mode whereas mine might not. It's no surprise, since you actually changed cc-mode to accommodate your comment-cache, like you could do to accommodate this patch. Stefan