From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please. Date: Sat, 11 Jun 2016 19:10:03 +0300 Message-ID: <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> References: <20160607220928.GA5155@acm.fritz.box> <7eeaa57a-698d-bde0-d740-efa8968c7583@yandex.ru> <20160607224829.GC5155@acm.fritz.box> <20160611100750.GB2776@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465661438 28955 80.91.229.3 (11 Jun 2016 16:10:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2016 16:10:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 11 18:10:24 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBlUN-00050o-Hm for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 18:10:23 +0200 Original-Received: from localhost ([::1]:47705 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBlUJ-0008NV-PK for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 12:10:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBlUD-0008N9-KP for emacs-devel@gnu.org; Sat, 11 Jun 2016 12:10:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBlU7-0000YQ-HO for emacs-devel@gnu.org; Sat, 11 Jun 2016 12:10:12 -0400 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:37869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBlU7-0000XP-AL for emacs-devel@gnu.org; Sat, 11 Jun 2016 12:10:07 -0400 Original-Received: by mail-wm0-x22e.google.com with SMTP id k204so27298920wmk.0 for ; Sat, 11 Jun 2016 09:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fFrD0ZjdHjCYPHd1uBr4c00yK7u5Zf9KAuDuCt/b9c8=; b=cPpC43CdzIaFB/URZRfz/tOuFwlvqWqm7ywgfA2hW2dH8PZT5VHGfnIqRmHByMwCfy K03tZZzrPDqmpv/tEwlvJsmMMyOvHxvTW3MLrQZGcJCqdEoqoN3vydqCC9Okbi+G/ZRV gtPxKwgxrPDMW7+anb5UubYbekBlP7vzZlTAfn7anc21KhVujWQii/tLXRL+JPnzyrCk XfAA0iSpQwitrIUyvL/3TL9BRzE6yfR1QtXzaLWIi17/pFWjxiiLrI05l3VNH4hH0jZN Tzx8zR7srdZuk7j2DZJrehSKXFj3PHJ1Hfik7opl4HLGMOf77de7jh26gNFE+jz64gYq mwtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fFrD0ZjdHjCYPHd1uBr4c00yK7u5Zf9KAuDuCt/b9c8=; b=X5i2knuM+5ymfZrfVGYB9Z92YVu0pkMifwyu+TQlsrhDzYycL8EMYBwhBuHhQDqb76 eQl+kI1C7I9S9sMZTq0nUyhhAXa5S4K5qmiGHE3PP8TF9TiAONInkntOCoe/a0Bm+/yz 7v0H7Yxx3F2iDTUz4KBQuIjzWE2Jmmt9pN4t8fNLTyeotO4Qe2ioVR4+wbro6s7qgiUZ /KiQspen1KeIFJ9zC4iFy6uwi6fFMP4T6iHB/zOyqfJtI+x4ytTcu5blV0iVIx/TMuAB gf3RFD6nWptkbhkz9PJnraEV+fqEbc0l+QNVx8NxZhUUPq+A0/xOFYDu8Do2aJ7E1O47 PdHg== X-Gm-Message-State: ALyK8tKgL30Fmq1iSEu+dl83C5uA9M5Whnluos/qIaC3bZT1Heqf5Ft2dcxFLGJRZ59/Kg== X-Received: by 10.194.81.8 with SMTP id v8mr7005785wjx.155.1465661406438; Sat, 11 Jun 2016 09:10:06 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id y3sm17981884wji.40.2016.06.11.09.10.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2016 09:10:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160611100750.GB2776@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22e 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:204285 Archived-At: On 06/11/2016 01:07 PM, Alan Mackenzie wrote: >> Why before the release in particular? > > Haven't I just said? :-) If not before the release, then when? Right after? Slightly after that? Whenever. "Before the release" doesn't look like a meaningful constraint, considering the commit will go on master. I'm still not even clear which branch 25.2 will come from, and that's an important concern. > Is Vitalie still working on ... anything else to do with > Emacs)? Yes: https://github.com/emacs-ess/ESS/commits/master https://github.com/vspinu/polymode/commits/master Adding hard-widen, however, is a low-level endeavor, and it seems nobody sufficiently proficient there is in any hurry to help. > I can't say I feel enthusiastic about "hard-widen". I haven't looked > into it that thoroughly, but it feels a bit like an ugly hack whose > ramifications might percolate all the way through Emacs, and that might > make us regret it fairly heavily in the not too distant future. Hadn't you yourself proposed a far more invasive solution, not too long ago? I think hard-widen strikes a certain balance, in that is will require a moderate amount of changes in Emacs, and little to no changes in the user code, considering we've always (or at least for a long time) had to write it with consideration for the current narrowing. If there's anything to complain about it, it's that it doesn't bring new niceties. So: modest gains, and little amount of pain. Seems conservative enough for the Emacs community. >>> Yes, I think having the binary toggle `syntax-ppss-dont-widen' purely to >>> direct the innards of the function is poor programming (since it >>> explicitly toggles a toggle inside a supposedly abstract function). > >> Abstract? > > Yes, abstract. `syntax-ppss' has an specification and interface on the > one side, and an implementation on the other. Just like any other function? >>> I think an improvement would be to dispense with that toggle, and >>> have two distinct functions, one in place of >>> `syntax-ppss-dont-widen' being nil, and the other in place of >>> `s-p-d-w' being non-nil. The latter function might usefully have an >>> extra parameter specifying the base point that parse-partial-sexp >>> should be calculated from. That would leave quite a few options >>> open for the internal logic of the function. > >> That wouldn't help in the multi-mode case, which is the primary use I >> have in mind for syntax-ppss-dont-widen. > > Why would it not help? Because you (in CC Mode) will choose the more straightforward version that does widen. And I, in mmm-mode, will thus have no ability to modify what your code is doing by narrowing, and will send you dark thoughts instead. What's the purpose of the other function? Who's going to use it?