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: Sun, 12 Jun 2016 01:52:42 +0300 Message-ID: <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@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> 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 1465685583 7806 80.91.229.3 (11 Jun 2016 22:53:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2016 22:53:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 12 00:52:57 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 1bBrlw-00081x-Jk for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2016 00:52:56 +0200 Original-Received: from localhost ([::1]:48927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBrlv-0000zq-FJ for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 18:52:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBrlq-0000zi-Ah for emacs-devel@gnu.org; Sat, 11 Jun 2016 18:52:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBrlm-0005VF-5X for emacs-devel@gnu.org; Sat, 11 Jun 2016 18:52:49 -0400 Original-Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:36621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBrll-0005Uy-Qw for emacs-devel@gnu.org; Sat, 11 Jun 2016 18:52:46 -0400 Original-Received: by mail-wm0-x22f.google.com with SMTP id n184so33282521wmn.1 for ; Sat, 11 Jun 2016 15:52:45 -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=49F3qjM27nBXC6GCsKUGySNUrmvzUPUEzmhXJzKbMxY=; b=scOEbqxQ0p8XYm7eNR2ppUf6HpBO24rLv2MNS1nvc2mT9Wz/Id451vSyraDZkQ4JZ3 yLb6WYnttHbfJ24vEnDHW+RSUoOU3vG0eJl6fHsmtAL6SbfguJadk/NBuHsj5OLx1rXo zlBPt0mC2ncUwSIN+Gj1ZGxxx3meWiapDwYABzYmN62yzp8RsUe1Zq1FIFwSn99Iy1AG KtZ6z9IA6nR9s3CsND6IXtxxGjTXXjKG5n3YdBXmBtIcD5fHQECkSIGn0XQBInjpf+T8 j3YS8WldncW9+d5WNWLQaSb4oJdBBUMSJo+hhCexJY/0YB8nJgz953HlShfbf34cXr27 CKYw== 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=49F3qjM27nBXC6GCsKUGySNUrmvzUPUEzmhXJzKbMxY=; b=XiEvcqQ++JR00hMczR58vmZ7Rx9WQYODdOUfQEEM49s2rbfgfPWDrWccuKGoD+3wst 3aPdVRnABUro2TKn86501rbUXxRrXC7FtOUA2fOyojCWh5FjQiIOxIDbKd/pMlftdCEw jSo3jY1YKu5cYPJpxAV08fPCd2d6eY+zLvmCQkkkWWJlOQp4JM5vE9ykydJav3EZvbL+ pAmeAiCxju0QStUhQvAn57ZhcymwGnfoHxRu5YmRGhqfJrY3qOuX5BKlurLkZyUAqq9m CQyEzNNtNjuh257tMSe0496yWkXNFSpBsSsnFw7qQyZvv9wJo8Qy+Zwzh+Dd7jVTk715 GSSQ== X-Gm-Message-State: ALyK8tKtsqqQ7AEiTOGffPMbW35nOr3zJaHXlffuwMGc52mUHga2Jci0Gz2IDVbhVyHVWA== X-Received: by 10.194.103.4 with SMTP id fs4mr8693587wjb.10.1465685564894; Sat, 11 Jun 2016 15:52:44 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id m7sm6151068wma.10.2016.06.11.15.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2016 15:52:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160611195016.GE2776@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::22f 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:204300 Archived-At: On 06/11/2016 10:50 PM, Alan Mackenzie wrote: >> I'm still not even clear which branch 25.2 will come from, and that's an >> important concern. > > My guess is it'll will come from the master branch. Otherwise, there'll > be too much work in cherry picking commits back to the emacs-25 branch. > That's just a guess, though. That sounds like we shouldn't commmit any significant changes to master, doesn't it? >> Hadn't you yourself proposed a far more invasive solution, not too long >> ago? > > Intrusive it is, but an ugly hack it certainly isn't. It's aim is to > bring Emacs to the state it would have been in if it had been designed > for multiple major modes per buffer right from the start. As such it > will be free from ugly workarounds. An ugly workaround is in the eye of a beholder. And it also depends on the context. I believe hard-widen can be made to work well, and not too hard to reason about. Although only time could tell. > The main problem with it is the amount of work to implement it is huge. > So much so, that I might well never finish it myself. There was not a > great deal of enthusiasm expressed for it all these weeks ago, apart from > from Eli and yourself, and even then, Eli was unhappy about a fairly > important part of it. Yes, the idea was big/complex, and the design is unprecedented among text editors, AFAIK. These two characteristics, taken together, make it it very risky, at least. > hard-widen seems to destroy the simplicity evident in narrow-to-region > and widen. What simplicity? narrow-to-region seemingly can't decide whether it's a command for users to invoke, or it's something for Lisp code to use. We end up treating both cases the same, and that causes a lot of problems. hard-widen would differentiate those. > Why does (presumably) a super mode want to do anything with narrowing > anyway? How else would you apply each major mode's fontifications only within its subregions? See https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816 > Narrowing is needed by users and by major modes, and its use by > a super mode might well clash. super modes are currently implemented as minor modes. major modes shouldn't override the choices made by minor modes, if at all possible. > Is this hard-widen proposal at all > documented in any coherent fashion? These have been several discussions. > I'm not convinced. But then, I don't know how the proposal will work in > any great detail. I've linked to the patch and the previous discussion not too long ago. > That paragraph worries me greatly. OF COURSE CC Mode uses > narrow-to-region and widen freely, there being code which can scarcely > work without it. I and other major mode maintainers will expect to > continue to be able to do so. 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). There may be some alternative approaches to this, but a super mode has to be able to *somehow* limit CC Mode's activity if we want to be able to use it for syntax highlighting and indentation inside e.g. Noweb's code chunks.