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 18:36:56 +0300 Message-ID: <57d7a64b-81af-73d3-31c2-727eb5e43049@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> <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> <20160611195016.GE2776@acm.fritz.box> <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@yandex.ru> <20160612093425.GA3178@acm.fritz.box> <20160613122803.GA3084@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 1465832249 9928 80.91.229.3 (13 Jun 2016 15:37:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2016 15:37:29 +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 17:37:22 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 1bCTvU-0003ex-Qq for ged-emacs-devel@m.gmane.org; Mon, 13 Jun 2016 17:37:21 +0200 Original-Received: from localhost ([::1]:57274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCTvU-0006JT-0p for ged-emacs-devel@m.gmane.org; Mon, 13 Jun 2016 11:37:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCTvG-0006EQ-68 for emacs-devel@gnu.org; Mon, 13 Jun 2016 11:37:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCTvB-0005Mj-3X for emacs-devel@gnu.org; Mon, 13 Jun 2016 11:37:05 -0400 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:36402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCTvA-0005MZ-4g for emacs-devel@gnu.org; Mon, 13 Jun 2016 11:37:01 -0400 Original-Received: by mail-wm0-x235.google.com with SMTP id n184so84159740wmn.1 for ; Mon, 13 Jun 2016 08:37:00 -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=74+1OOcYMWbdXs9V1GYdnou0v7c9JQK68GnE2/Rec8M=; b=Jmxhs5qyxlYcKl86xMsuQV/9J+QOE5wMU1oVvvQ4Df1hwnvd6gR+GutdFsVDoCzfGk PK3HuP1xaK0eQ0mk+d+djy9FgwdcXm8nc0XAUXVRAiEOEfFplKa0k/Y2KHrewso44VTv kqKGaCVm3WHF2WjfI7pJwq+dR7nopkadwYJPPkwfdqB/PLP6r6Bz+AVu+kr4RQZysmZC 8Qz6wqGKH1CVEILfbnC74teXwbOtnQly0eUUpZDqvK7hFzl6lPY2y1wZmXiAGzUwo7mq dKNvDaFizZvuCSkKmf6PTRBVqqO6moVamlta/RvIASMAZGXtFnBy+UskaWHmIeTE6MGB 6khQ== 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=74+1OOcYMWbdXs9V1GYdnou0v7c9JQK68GnE2/Rec8M=; b=fe1tmlvLBqMyk123qfviC3Q06Vcc2fY8rcbJrUL/TbYZuXangpVYof6LCuxXCM0SK4 tRaYxdQnCbiHhQbJvdzXmEPIVePr2jnRV1hGFcYWhzCHaWWDJRwlw+w1xslXmCC82kLi Pa1HKJ1XpYNTv0z3aaXNjljSh/vqP6T9E7IGhawJttprnpAGBBIc2GspRVH1rIZKCnwt tCXfKpc9qYHjCV1W+VsaPS+AXe9v3E19y6XnfUKCYbYn8zr1eQQB5YvBByUgDiFBEZeZ xSPZvvGKO88qGAiV0IPm6UhI6VlRc0DGeT8ehwQBSf7+uFk53RTpDnmC0+3NZ4XrXd5k N1Lg== X-Gm-Message-State: ALyK8tKMtFdZWST1KkSzVTZqE93RGqD0brOyj/V7H5305YtUSwheAMngXSt+tqKMoOhUtg== X-Received: by 10.28.5.147 with SMTP id 141mr240939wmf.48.1465832219144; Mon, 13 Jun 2016 08:36:59 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id w76sm13139384wmd.11.2016.06.13.08.36.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2016 08:36:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160613122803.GA3084@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::235 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:204340 Archived-At: On 06/13/2016 03:28 PM, Alan Mackenzie wrote: > It does not. It contains a few relatively vague aspects, undefined > terms, and "for full details, search!". I'm not trying to slag off > Vitalie here, because clearly he was in the middle of trying to figure > things out, and was unclear about things. There's no word "search" in the patch. >> Here's a better link to the message: > >> http://lists.gnu.org/archive/html/emacs-devel/2016-03/msg01576.html > > I've glanced through that, and I found the doc string you've referred > to. It's some help. Also see the new widen's docstring. It's the whole proposal. >> 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. > > So, you consider widen and narrow-to-region in their current form as > being as useless as a detached shovel blade? Maybe a dinner utensil with fork on one side and spoon on the other (thus lacking a handle) would be a better illustration. >> Nowhere does narrow-to-region's documentation say it should only be used >> in major modes. > > Of course not. As I've said, it's a general purpose tool used > univerally in Emacs. I would like to keep it that way. It wouldn't go anywhere. Its usages, however, would better convey the intended use. >> It's been a known problem for a while, and it has come up in multiple >> discussions over the last years. > > "It's been known"? To whom? The only discussion I have seen on the > topic has been between Stefan, yourself, and Vitalie. Apologies if I've > missed anything. See this discussion, for example: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg01104.html This subject has come up in virtually every discussion related to mixed modes. > The right choice for multiple major modes might well be to use something > other than narrowing. As you know, I proposed something else a few > weeks ago. Something we're unlikely to ever get? That's not a good alternative. >> Please go ahead and write up this proposal in detail. > > No, I was simply answering your question, giving you ideas for further > ideas. I've been thinking about it for years now, on and off, and changing narrowing looks like the best realistic idea so far. > Nothing we do here is going to be simple, admittedly. There might well > be a way of doing things which is a bit like the "islands" proposal but > without its main disadvantage (the huge effort to implement it), and > also a bit like the complexification of narrowing, but without its > disadvantages. You are welcome to think about and present such a design. > Ah, I see! It wasn't clear to me that you were talking just about a > single defun in that file. I'm not accustomed to reading and > interpreting long URLs. That was a function which fontifies a number of > regions. I've forgotton why I should be interested in it. ;-( Is it too hard for you to go back a couple of emails are re-read what you wrote yourself? Do you need a recommendation for a better email client? >>> 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. > > That's an interpretation of the problem. Your solution appears to be to > make narrowing LESS general, specific to a single problem. No, it would still serve the existing use cases, just better. > There's nothing in particular that "leaves me confused". It's that > there no coherent description. To try and pick everything up from a few > discussions on emacs-devel going arbitrarily far back would take me > several days, and even then I couldn't be sure I'd not missed anything. There are about 10-15 short messages in there. That's maybe 20 minutes of reading. Certainly less than we've spent on this thread by now. > The original messages aren't readable enough for this purpose; some > things are said many times - other things are left out altogether. The > whole discussion is an incoherent jumble. It doesn't look that way to me. And if it does to you, it's quite likely that a summary I would present would look just the same. > Why do you think I put so much effort into getting > the "islands" proposal coherent - everything said once, and as far as > the flow of the ideas would allow, only once? Because you wanted to make your own thoughts clear? > What I'm not asking you to rehash is other people's arguments - only the > salient technical points, "one per line". So that you comment on them, ignoring the previous discussions, and we rehash the points that have already been made, yet again? Let me make one thing clear: it's not my design, and I'm not working on that patch. Maybe Vitalie would like to describe the current state of the proposal, you should ask him. > One of these has a patch, which looks fairly simple. One thing which > isn't simple is replacing > > (widen) > > with > > (let (hard-widen-limits) > (widen)) > > in all the places needed. (I've counted ~705 uses of `widen' in our C > and Lisp sources.) None of those places need to be updated. CC Mode worries about visual narrowings, right? It should keep hard-widen-limits in place. > And maybe, just maybe, we might somehow get back to discussing the > actual topic of this thread which is a bug concerning syntax-ppss. Not if you keep forgetting why the discussion went the way it went.