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: Bug #25608 and the comment-cache branch Date: Mon, 13 Feb 2017 16:21:25 -0500 Message-ID: References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170205220045.GB2294@acm> <83d1es61li.fsf@gnu.org> <20170211232511.GA13712@acm> <20170212120553.GB3087@acm> <20170213180919.GA2377@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487020948 1321 195.159.176.226 (13 Feb 2017 21:22:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Feb 2017 21:22:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 13 22:22:24 2017 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 1cdO4j-0008KB-BZ for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2017 22:22:21 +0100 Original-Received: from localhost ([::1]:59577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdO4o-0002sY-SN for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2017 16:22:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdO4D-0002k6-BG for emacs-devel@gnu.org; Mon, 13 Feb 2017 16:21:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdO4A-0005sA-6G for emacs-devel@gnu.org; Mon, 13 Feb 2017 16:21:49 -0500 Original-Received: from [195.159.176.226] (port=59714 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdO49-0005pm-Qd for emacs-devel@gnu.org; Mon, 13 Feb 2017 16:21:46 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cdO3v-0005Z7-Lm for emacs-devel@gnu.org; Mon, 13 Feb 2017 22:21:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 136 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:OzIsHvLizPg96/+9WtdrVHGnCeA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:212353 Archived-At: > comment-cache is a gross simplification of syntax.c, scanning comments > only in the forward direction and totally eliminating > open-paren-in-column-0-is-defun-start from syntax.c. BTW, let me help you: eliminating open-paren-in-column-0-is-defun-start is not terribly important and doesn't justify all those changes (my syntax-ppss-based patch does that in a much simpler way). The real upside to your code is the elimination of back_comment. If I were you, that's how I'd try to sell it. > To achieve this simplification took a lot of work. I don't doubt it. syntax-ppss OTOH didn't take much work at all. >> - add a font-lock rule which highlights open-paren-in-column-0 inside >> comments in bright red. > Totally irrelevant to what's required. Very relevant to: demoralizing work debugging bugs caused by open parens in column zero in comments. since even if that highlighting is something personal in your ~/.emacs that should make such debugging trivial, since you can easily arrange to burp very loudly as soon as such an open paren occurs, so when you get a bug report about it, as soon as you try to reproduce the problem with the OP's file your hack will scream bloody murder and your debugging will be immediately done for you. > By the way, did you ever get around to looking at that bug which noted > that mechanism no longer working? No, I became more interested in using that syntax-ppss-based patch to get rid of open-paren-in-column-0-is-defun-start in syntax.c ;-) >> - use my syntax-ppss-based patch. > Doesn't work all the time, in particular in narrowed buffers. Works just fine in narrowed buffers for me, and I can't remember any bug report about it other than yours so the problem doesn't seem nearly as serious as you make it out to be. BTW, your code also breaks down miserably in some narrowed buffers (i.e. in those narrowed buffers where the narrowing semantics expected is not the one you decided is The Only Choice). > Of all the words in English which mean "imperfection", that's one of the > milder ones. Would you prefer I used "defect" or "fault" or something > else? How 'bout "bug"? > If that word would provoke you into actually fixing #22983, after all > this time, I would use it again for that purpose. As you know, fixing this depends on figuring out how to solve the narrowing-semantics issue. Once a solution is chosen, fixing the bug will be very easy. > syntax-ppss is a cache of the syntax-table text property. > Not invalidating the cache when a syntax-table text property is changed is > an imperfection. Will it be fixed? Patch welcome. The lack of bug-reports about it makes it a rather low-priority issue. >> >> BTW, your comment-cache doesn't fix that "flaw" and hence won't help any >> >> of those users of syntax-ppss which can't be changed to use your >> >> comment-cache. >> > That's incoherent. comment-cache was never intended to help those other >> > uses, though it appears it could do so for most of them. >> It's only incoherent if you refuse to see the larger picture. > The larger picture is that comment-cache can work alongside syntax-ppss > pefectly happily without any contention. Looks like you still haven't seen the larger picture. >> > Can't be done, as I keep telling you. comment-cache is solely for >> > handling literals. >> Then it's useless, AFAIC: >> - we need syntax-ppss's data for lots of things. >> - your code can't replace all those uses. >> - so we're stuck with syntax-ppss, no matter how much you think it sucks. >> - then we might as well use it in back_comment instead of your code, >> since it's there and is cheap. > But it doesn't work properly. comment-cache is also cheap, having > already been written and debugged. Which part of "comment-cache is solely for handling literals" don't you understand? >> For that we need to provide something equivalent to >> >> (save-restriction >> (narrow-to-region BEG END) >> ...) >> >> but where syntax-ppss and friends will know that we shouldn't widen past >> BEG/END .... > I thorougly dislike the conceptualization of handling syntax as > "widening". Yes, sorry. Rather than "widen" above, you should read "look". > Introducing the new syntactic symbols "island start/end" would cater for > with-region-as-subbuffer admirably, without having to resort to > confusing narrowing. What about those cases where the "subbuffer region" on which the code wants to operate shouldn't have any special syntax-table properties in general (the code just wants to temporarily operate on it in a particular way). E.g. some minor-mode may want to treat some C strings as "sub-buffer written in some other programming language" for some specific commands, while still keeping them as "plain old strings" in general. If I understand correctly your suggestion of islands markers, the minor mode would have to add those markers temporarily, then operate on the sub-buffer and then remove them. And along the way this causes the whole comment-cache/syntax-ppss/font-lock state to be flushed because of the temporary change. In contrast, currently that minor mode could do (save-restriction (narrow-to-region BEG END) (with-syntax-table other-mode-syntax-table) ...) which doesn't need to modify the buffer at all, and hence doesn't invalidate any cache. Stefan