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 15:16:20 -0800 (PST) Message-ID: 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> <54c62db5-08e9-38bd-e6f7-c571039d376a@yandex.ru> <9c16a23c-252a-40a7-bdcc-479b1113e4cb@default> <3102f0a0-88de-b1e6-9966-c4ece13a61af@yandex.ru> 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 1481930206 8929 195.159.176.226 (16 Dec 2016 23:16:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 23:16:46 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 17 00:16:39 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 1cI1jz-00013Q-CX for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2016 00:16:39 +0100 Original-Received: from localhost ([::1]:34661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1k3-0004IN-Ng for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 18:16:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1jr-0004Au-Qm for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cI1jo-0002y8-JN for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:31 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28857) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cI1jo-0002xX-9l for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:28 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBGNGPC1007417 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 23:16:26 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBGNGOv2020421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 23:16:24 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 uBGNGLMb002079; Fri, 16 Dec 2016 23:16:21 GMT In-Reply-To: <3102f0a0-88de-b1e6-9966-c4ece13a61af@yandex.ru> 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: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 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:210553 Archived-At: > > That narrowing restricts the buffer limits is its effect. > > Code can use that effect to any purpose it wants. >=20 > Except if the other code, which the current code wants to call inside a > narrowing (and respect that narrowing!), always widens. Therein lies your mistake - mistaken assumption, perhaps. Why should "the current code" call other code that widens, and yet expect that it will _not_ widen? The fault here is not from the "other code" narrowing or widening. It is from the "current code" calling such "other code". Code needs to choose wisely any "other code" that it tries to use. IOW, this sounds a lot like a case where the doctor should tell you, "If it hurts, stop doing that." But if the called code is indeed defective - if it should in fact restore the initial buffer restriction after it widens or narrows to do its work, then that should be fixed. That's no reason to say that it should never widen or narrow. > > That's a question of designing the two bits of code. >=20 > Because that's never difficult. > And if only all code was written by one person. Why? If you call a function in your code, regardless of who wrote that function, you need to know what it does, no? And in particular, you need to know how it handles a buffer restriction - at least if you are _counting on_ some particular behavior wrt that. You need to know whether you need to wrap its call (or some other bits of your code) in `save-restriction', for example. Or to otherwise set and save some restriction limits, and then restore them at the proper time. Restriction limits are just buffer positions. Setting and saving them is not rocket science. This is similar to knowing whether called code moves point or changes which buffer is current or which window is selected or... It sounds like you are complaining that when you use function `abcde' it doesn't behave as you would like. Maybe consider not trying to expect it to do something that it does not do? Or (again) if the code being called is defective, and it should really restore the initial restriction, then fix that. > > See my reply to Cl=C3=A9ment for the case of reusing code that > > is broken because it does not expect `point-min' to refer > > to a buffer-restriction limit. >=20 > It's not enough to know what the code you're reusing does, > if there's no way to make that code respect your narrowing. What do you mean by "respect your narrowing"? If you mean that there is no way to prevent called code from applying a different buffer restriction (including widening completely), then, well, duh! Just as there is no way to prevent it from assigning a different value to a variable that is visible to it. Or to prevent it from changing the current buffer (and even leaving it changed), or the selected window. Or any number of other things. If code that you're thinking about calling from your code does something you do not want, then, well, don't call it. Call some other code - maybe write your own, possibly enhance the code you were thinking about calling unwisely,... > >> You haven't been paying attention. > > > > Prove it. See above. I don't see a problem with > > narrowing. >=20 > We've had numerous discussions on this subject already. > If you still don't see any problem, good luck with that. That's one way to evacuate the discussion... How about: If you still see a problem, and you cannot articulate it, good luck with that. If you think it is important enough, perhaps speak concretely, in terms of particular code. Show a case where something really needs to be changed in Emacs, because there is an inherent problem. > > Maybe we need to beef up the doc of `point-min', to > > emphasize that it is the lower _buffer-restriction_ > > limit. And maybe some users need to better document > > their functions, to make it clear when they respect a > > narrowed buffer (as the Isearch doc makes clear, for > > instance). >=20 > Neither of that helps in the actual problem cases. What "actual problem cases"?