From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie 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 09:34:25 +0000 Message-ID: <20160612093425.GA3178@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1465724110 19576 80.91.229.3 (12 Jun 2016 09:35:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2016 09:35:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 12 11:34:58 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 1bC1nG-0001fd-5a for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2016 11:34:58 +0200 Original-Received: from localhost ([::1]:50360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC1nF-0006Vw-6c for ged-emacs-devel@m.gmane.org; Sun, 12 Jun 2016 05:34:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC1mf-0006Ve-9o for emacs-devel@gnu.org; Sun, 12 Jun 2016 05:34:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bC1mb-0003Qn-Se for emacs-devel@gnu.org; Sun, 12 Jun 2016 05:34:21 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:59278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC1mb-0003Qe-J2 for emacs-devel@gnu.org; Sun, 12 Jun 2016 05:34:17 -0400 Original-Received: (qmail 61433 invoked by uid 3782); 12 Jun 2016 09:34:15 -0000 Original-Received: from acm.muc.de (p4FC46287.dip0.t-ipconnect.de [79.196.98.135]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Jun 2016 11:34:13 +0200 Original-Received: (qmail 3311 invoked by uid 1000); 12 Jun 2016 09:34:25 -0000 Content-Disposition: inline In-Reply-To: <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@yandex.ru> User-Agent: Mutt/1.5.24 (2015-08-30) 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 X-Received-From: 193.149.48.3 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:204310 Archived-At: Hello, Dmitry. On Sun, Jun 12, 2016 at 01:52:42AM +0300, Dmitry Gutov wrote: > On 06/11/2016 10:50 PM, Alan Mackenzie wrote: [ .... ] > I believe hard-widen can be made to work well, and not too hard to > reason about. I can't reason about hard-widen very much, because I haven't read its specification. > Although only time could tell. 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. [ .... ] > > hard-widen seems to destroy the simplicity evident in narrow-to-region > > and widen. > What simplicity? `widen' makes the entire buffer accessible. `narrow-to-region' makes the specified region the accessible portion. And that's it! What could be simpler? That simplicity is a masterstroke in the early design of Emacs. > 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. That's the use case, not narrow-to-region itself. It's actually both a user command and a Lisp function, deliberately so, masterfully so. > We end up treating both cases the same, and that causes a lot of > problems. 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. > hard-widen would differentiate those. And that would cause great problems. It would likely make narrow-to-region/widen a pain to work with. > > 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? 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. > See > https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816 That's rather a lot to take in before breakfast! > > 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. What???? What major modes shouldn't override is user settings, or possibly minor mode settings. 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. > > Is this hard-widen proposal at all > > documented in any coherent fashion? > There have been several discussions. They're not coherent, and they're not very useful. 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. This is, after all, what I did for the "islands" concept a couple of months ago. Your document need only be 50 - 100 lines long at the most. Writing such doc would certainly help you clear things up for yourself, too. > > 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. They are not useful for this purpose. > > 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). That sounds like something worthwhile sorting out in advance. > 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. -- Alan Mackenzie (Nuremberg, Germany).