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: Mon, 13 Jun 2016 01:58:02 +0300 Message-ID: References: <20160607220928.GA5155@acm.fritz.box> <7eeaa57a-698d-bde0-d740-efa8968c7583@yandex.ru> <20160607224829.GC5155@acm.fritz.box> <20160611100750.GB2776@acm.fritz.box> <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> <20160611195016.GE2776@acm.fritz.box> <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@yandex.ru> <20160612093425.GA3178@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 1465772313 19563 80.91.229.3 (12 Jun 2016 22:58:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2016 22:58:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 13 00:58:25 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 1bCEKl-0006O4-T1 for ged-emacs-devel@m.gmane.org; Mon, 13 Jun 2016 00:58:24 +0200 Original-Received: from localhost ([::1]:52993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCEKh-0001C5-H2 for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2016 18:58:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCEKY-0001Bo-P9 for emacs-devel@gnu.org; Sun, 12 Jun 2016 18:58:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCEKU-00014K-Ki for emacs-devel@gnu.org; Sun, 12 Jun 2016 18:58:09 -0400 Original-Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:38269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCEKU-00012p-9K for emacs-devel@gnu.org; Sun, 12 Jun 2016 18:58:06 -0400 Original-Received: by mail-wm0-x231.google.com with SMTP id m124so56921550wme.1 for ; Sun, 12 Jun 2016 15:58:05 -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=fDOL81j/1/z9ns2i6n6yAE+703iOi7kLqdW+0P0xCq4=; b=FHtGivt5sFWyl6wwQLX0Oht3zu2Cer50XNXjEzpGt12kFz5ZCLB1Z2jRJYi7UhuObW JJ6EIUck7I6QFTtaEbV+mBAn3A1QNyK3tyXUgGCgN61qcF7x4PLIQDt+PZqQaDUvvjWc SSzmyjMWVc+ZijX99UPxRsLY2lpdH9cZu/02PCg1ibJ2W4ldVpwbZua5+KBT7VkocWlN G/kisDQ8ucSmSqNWB2FiW3Oe01B4UUpqXbxJTEwWZBDbx6vJRnknJx9HQMfBH3uo+Ras PejHjHkjz3Oya7qUMakqFTWXmCtcXOwNX+Hc6nrNBFDcZSMcoWuc7ToSQwxAtgggZVLH Kx0w== 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=fDOL81j/1/z9ns2i6n6yAE+703iOi7kLqdW+0P0xCq4=; b=AOAvvR7BWWq6k2FfuHgjV1vuG2vo4hesFqW28k3CM3dfjK7dWlVS9ILGLtgG4KqeZM bQQ4AKbi7AR8kUGwW/EITfg29NWIfbqlL6zFqvu8Id3sjTkjzGqGJs4jRKXhe/1p9UoJ RD1tbzh0bLC4DsAaRsQM7gTF9GBzotywao9nS/tZMWW4W4axW/paIn4/lAJMJu4EvN5v d8QfURobCsbu0stw6X8+wCaLLVjMyLllS/SSOlqvUY8/b2inIegfEvypwGBeuMZOG8GU hnQxpl2LzecRICIqIO45lSgDJO6FJtPB32P9dSaGQ76wJz+YE5BPq9j+i2sSgd1rHW+q zcrw== X-Gm-Message-State: ALyK8tJ7sLydqhDI8ZJ2V9bpztHD5+plS+5WBm5wL//89E3aYbKudj0mBX32FKyUuu6olA== X-Received: by 10.194.41.170 with SMTP id g10mr6206106wjl.176.1465772284920; Sun, 12 Jun 2016 15:58:04 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id u70sm11168386wmd.4.2016.06.12.15.58.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jun 2016 15:58:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160612093425.GA3178@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::231 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:204323 Archived-At: On 06/12/2016 12:34 PM, Alan Mackenzie wrote: > I can't reason about hard-widen very much, because I haven't read its > specification. The change to the narrow-to-region's docstring in the patch contains the specification. Here's a better link to the message: http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html > No. A careful consideration of its proposed working before > implementation (let's call it a design ;-) can reveal a lot about how > well it could work. ...and time, if we're being realistic. > `widen' makes the entire buffer accessible. `narrow-to-region' makes > the specified region the accessible portion. And that's it! What could > be simpler? If you take a shovel and remove its blade, the result will look very simple. That doesn't mean it's appropriate for any interesting task. Nowhere does narrow-to-region's documentation say it should only be used in major modes. > I have encountered no such problems in over 15 years of hacking Emacs. > I think you're seeing problems somewhere and blaming > narrow-to-region/widen, when the real problem is somewhere else. It's been a known problem for a while, and it has come up in multiple discussions over the last years. The "real problem" is a matter of perspective. Some might argue that trying to use narrowing at all, for any purpose, is a bad idea, and then, of course, the right choice would be to use something else. >> How else would you apply each major mode's fontifications only within >> its subregions? > > By adding the appropriate structures as buffer local variables (or > perhaps as text properties) which would delimit the subregions, then > enhance Font Lock to respect those boundaries. Please go ahead and write up this proposal in detail. It doesn't seem as simple as you make it sound. And I wonder if it ends up to be different from the "islands" proposal. Further, font-lock is not the only facility we want here. Making syntax-ppss obey region boundaries is another. There's also indentation code, which is more difficult to handle, but limiting visibility there somehow also seems essential. The super mode can also adapt different simpler facilities, like Imenu, using the same approach (go over the chunks, narrow to each, scan using the language-appropriate tools, and concatenate the results). >> See >> https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816 > > That's rather a lot to take in before breakfast! Did you have the breakfast yet? It's just 30 lines. >> super modes are currently implemented as minor modes. major modes >> shouldn't override the choices made by minor modes, if at all possible. > > What???? What I said. To the extent the facilities allow, of course. > The use/non-use of narrowing is NOT a > setting, any more than the use/non-use of cdr is. They're just general > purpose tools. Turns out, they are not general purpose enough. That's the problem. >> There have been several discussions. > > They're not coherent, and they're not very useful. If there's anything in them that makes you confused, I've yet to hear about it. As far as I can see, you're not interested in making even that effort in learning the subject. > Could you please write this document. Given the massive change you want > to make in a fundamental Emacs tool, this is not unreasonable to ask. I don't enjoy rehashing others' arguments when the original messages are readable enough. It's a small change, by itself. Please read the discussion, starting with http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01129.html And http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01182.html in particular. After that, please let me know if you have any specific questions. > This is, after all, what I did for the "islands" concept a couple of > months ago. And I have spent considerable time contributing to that discussion as well. >> The main thing CC Mode would have to worry about from then on, is that >> it won't always be able to goto-char to positions beyond the hard >> narrowing, even if they exist in the buffer (and are pointed to by some >> buffer-local data structure maintained by CC Mode's parser). > > That sounds like something worthwhile sorting out in advance. Sure. Please go ahead and present your thoughts on the subject. I realize it might be rather complicated, actually, to use the narrowing approach with CC Mode as submode. But I don't see any alternative solutions that we're likely to implement. So it may be that some modes will still refuse to work in multi-mode context.