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: Sun, 05 Feb 2017 21:08:15 -0500 Message-ID: References: <20170202202418.GA2505@acm> <9d0b3156-e8b2-c2d8-0d0c-a025861e5e0c@yandex.ru> <20170203164457.GB2250@acm> <20170204110259.GB2047@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486346927 8461 195.159.176.226 (6 Feb 2017 02:08:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 02:08:47 +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 06 03:08:39 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 1caYjO-0001r3-1l for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 03:08:38 +0100 Original-Received: from localhost ([::1]:45226 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caYjR-00068h-Gg for ged-emacs-devel@m.gmane.org; Sun, 05 Feb 2017 21:08:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caYjG-00068b-3c for emacs-devel@gnu.org; Sun, 05 Feb 2017 21:08:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caYjC-0007T9-SZ for emacs-devel@gnu.org; Sun, 05 Feb 2017 21:08:30 -0500 Original-Received: from [195.159.176.226] (port=58298 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1caYjC-0007Sd-Mj for emacs-devel@gnu.org; Sun, 05 Feb 2017 21:08:26 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1caYj3-00013V-8I for emacs-devel@gnu.org; Mon, 06 Feb 2017 03:08:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:lEGOWGo3N9f7W+sitNOgK7Y0ArA= 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:212012 Archived-At: >> > The "alternative patch" didn't scan comments correctly all the time >> > when I looked at it, just as the current back_comment doesn't. Of course, there's an alternative way to look at this reality: your comment-cache changes the behavior in some cases where the AP patch doesn't. You claim that the new behavior is "correct" and the other one "wrong", but AFAIK these are borderline cases where both interpretations can be correct or wrong depending on what narrowing was used for. So while I don't claim that comment cache's behavior is *wrong*, it might break existing code. > In the following test case (same as in my other post) the "alternative > patch" doesn't work. Narrow the buffer with point-min at the indicated > position. Put point at EOL. Try M-: (forward-comment -1). This fails. > char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /* */ /* '"'" */ > ^ For example here, your intention for narrowing is clear, but Emacs currently doesn't keep track of the fact that the user put this narrowing (rather than some code like mmm-mode), so while in this case your comment-cache is probably right, in other cases it might give the wrong answer. E.g. maybe in a case such as char foo[] = "for (x = 0; x < n; x++) /* Loop header */\n"; ^ ^ where the user narrows to the string, then goes to EOL and does M-: (forward-comment -1) Really your comment-cache (just like the existing code) currently can't do much better, because to do better we need to fix the narrowing problem. So really, the problem to be solved is the problem of narrowing. Once that one is solved, AP and comment-cache should both be able to behave correctly in both cases (in the case of AP, this will happen without any changes to AP itself, because the fix will be in syntax-ppss). Stefan