From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: forward-comment and syntax-ppss Date: Fri, 16 Dec 2016 08:22:45 -0800 (PST) Message-ID: <4ded3b07-18ab-4864-b72d-f217a86c123d@default> References: <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209190747.GC2203@acm.fritz.box> <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> <20161211101715.GA14084@acm.fritz.box> <51c0554f-40d0-37a5-b134-17058343aa3f@yandex.ru> <877a8d5a-ee08-29a1-8c7e-6cc8a82dfc83@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1481905432 13675 195.159.176.226 (16 Dec 2016 16:23:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 16:23:52 +0000 (UTC) To: =?utf-8?B?Q2zDqW1lbnQgUGl0LS1DbGF1ZGVs?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 17:23:46 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHvIO-0002Sj-T6 for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 17:23:44 +0100 Original-Received: from localhost ([::1]:33086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvIT-000766-AG for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 11:23:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvHc-00075x-Ne for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHvHW-0003yU-OR for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:56 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:30995) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cHvHW-0003wb-AY for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:50 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBGGMk7P018970 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Dec 2016 16:22:47 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBGGMkkp002443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Dec 2016 16:22:46 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBGGMkum026105; Fri, 16 Dec 2016 16:22:46 GMT In-Reply-To: <877a8d5a-ee08-29a1-8c7e-6cc8a82dfc83@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:210527 Archived-At: > >> Thus, without making things harder for many other facilities. > > No one has given an example of how narrowing makes things > > hard "for many other facilities" - or even for one facility. >=20 > I think I gave one example of how narrowing breaks proof-general; in fact= , I > explained I developed my own alternative to narrowing with overlays becau= se > other packages broke in the face of regular narrowing. "Narrowing breaks proof-general". Really? Narrowing did that? This is all I saw that you said about it: There are many such places; unfortunately, the use of (point-min) means that the overlays do not have the right starting point: they start from the beginning of the narrowed region. =20 It's hard to fix this issue, because uses of point-min don't carry sufficient semantic information: did the original author mean (point-min), or 1? There's no general way to tell but to read the surrounding code. IIUC, the problem is that p-g makes use of some code that uses `point-min', and p-g does not know whether that code intended for `point-min' to mean the start of a buffer restriction or position 1 of the buffer. My answer to that is that `point-min' ALWAYS means the start of the buffer restriction (narrowing), if it is restricted. If p-g cannot count on that then it cannot count on using code that doesn't understand that. It should know what code that it reuses does; if not, all bets are off. It sounds like it is not narrowing that broke p-g, but its use of some broken code that uses `point-min' without understanding that it refers to the beginning of a buffer restriction. Or perhaps p-g just does not know what the code it reuses does. For p-g to decide whether it should `widen', it should be enough for it to know whether _it_ wants to work with the full buffer. If it tries to reuse some other code that is flakey or unsure in that regard, then I'd say that p-g is breaking itself. Code that uses `point-min' should always expect that the buffer is (because it could be) narrowed. It should never assume that `point-min' is necessarily position 1. Am I missing something?