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: Bug #25608 and the comment-cache branch Date: Mon, 6 Feb 2017 20:01:16 +0000 Message-ID: <20170206200116.GD3568@acm> 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; charset=us-ascii X-Trace: blaine.gmane.org 1486411322 6790 195.159.176.226 (6 Feb 2017 20:02:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 20:02:02 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 21:01:57 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 1capU0-0001LC-5z for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 21:01:52 +0100 Original-Received: from localhost ([::1]:50510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1capU5-0007m7-Uc for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 15:01:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1capTp-0007ec-Jy for emacs-devel@gnu.org; Mon, 06 Feb 2017 15:01:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1capTm-0000mq-9u for emacs-devel@gnu.org; Mon, 06 Feb 2017 15:01:41 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:56710 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1capTm-0000mM-4G for emacs-devel@gnu.org; Mon, 06 Feb 2017 15:01:38 -0500 Original-Received: (qmail 10591 invoked by uid 3782); 6 Feb 2017 20:01:36 -0000 Original-Received: from acm.muc.de (p548C7532.dip0.t-ipconnect.de [84.140.117.50]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Feb 2017 21:01:35 +0100 Original-Received: (qmail 4574 invoked by uid 1000); 6 Feb 2017 20:01:16 -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:212061 Archived-At: Hello, Stefan. On Sun, Feb 05, 2017 at 21:08:15 -0500, Stefan Monnier wrote: > >> > 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. I think that is a fundamental mistake in thinking. The syntactic significance of a buffer position is not changed by any narrowing in force, no matter what the narrowing is "used for". Any other interpretation leads to the inconsistencies you've identified. That one or more multiple-mode attempts attempt to use narrowing that way is a fundamental problem in those modes which we should solve by providing a better method. (I suggested one such method last spring.) > 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, .... There's no "intention" involved here. There's just narrowing. > .... 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) Even if the user narrows to the string, it's still a string. It's not a comment, and can't be one. Even if, traditionally, Emacs has treated this string portion as a comment, that was merely for simplicity of implementation. This is not an important point, however, because moving back over comments is not a user command, and major modes will have checked for a "safe place" before attempting (forward-comment -1) or a backwards scan-lists. > 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. I don't think there is such a 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). As I pointed out to Dmitry, AP fails to clear the syntax-ppss cache when syntax-table properties in a buffer are changed (which is _always_ done with the change hooks disabled) or the current syntax table is changed, or a different syntax table is made current. comment-cache clears its cache correctly in these scenarios. > Stefan -- Alan Mackenzie (Nuremberg, Germany).