From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Fri, 16 Dec 2016 21:14:41 +0200 Message-ID: <3102f0a0-88de-b1e6-9966-c4ece13a61af@yandex.ru> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1481917073 787 195.159.176.226 (16 Dec 2016 19:37:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 19:37:53 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 Cc: Stefan Monnier , emacs-devel@gnu.org To: Drew Adams , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 20:37:49 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 1cHyKD-0007ul-EE for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 20:37:49 +0100 Original-Received: from localhost ([::1]:33956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHyKH-0006Dj-LH for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 14:37:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHxxw-0003rm-P4 for emacs-devel@gnu.org; Fri, 16 Dec 2016 14:14:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHxxt-0000sf-Hn for emacs-devel@gnu.org; Fri, 16 Dec 2016 14:14:48 -0500 Original-Received: from mail-wm0-x242.google.com ([2a00:1450:400c:c09::242]:35909) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHxxt-0000rN-Bg for emacs-devel@gnu.org; Fri, 16 Dec 2016 14:14:45 -0500 Original-Received: by mail-wm0-x242.google.com with SMTP id m203so7195381wma.3 for ; Fri, 16 Dec 2016 11:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=g9D4LFoIx2FzNRApXg+A73piXVFQBAMyiwDHZEXHQuU=; b=i0dniM0wxxRWSTxbaXoW3NUOKXhhzLALyrRuAOMZuD38lh4ZK4NkFJHwiL2aC0M32J sl8z4StlPuSKAadoggz0JQutOPd14Bxv9f2Tek1ikZG3HFsM5nfvl83ziMvUqyLhYTBs Hd01nnP8ShHGap745ZtAc0znSvAIxE70KNCj9NRrpUf3nyWpyMCE/wgAVurukbjj2EoH MgzYg2+vTvGjWc4msHmdMhx4/kS+nW8r6AxEXsFQUtjc/AbbxkjkXxrZMpzCNFd6JbbK sMauONhrUquJeJvO8Q4SpW0/S8x3aYNojuLyeFZqxlKQmN+QEIjUv+d/XlGAmImEB4IQ gz1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g9D4LFoIx2FzNRApXg+A73piXVFQBAMyiwDHZEXHQuU=; b=BgFL2U3j4G+qnDaQOtdgwAqea32Y4evIQlMkg5d/DcFA/zzA7pjLT84WnUk/hSBijN Iu/nCY05vkcw+cgzQUEKQAXXI6p94GSymSg34bbbwz3VAmBLhMFdquMTyoSNnLzTTUAa qFdbLqQB38mmv3+S/xterYg4V8Fb6MZeB7Re4akKV5Y0rDIAdM06ZGstG1I8BFkEXt7n pz4y/cphFQM6P8jgEmDdxsgbA/hF6sWgYeuBaPO5zWvFVxBAXeHPk2JD1fsV51Yb/rGy /nkGTsi+eWq3SIwlsCL3JibOh73RxUraAKQF4PE4n0gEt5tSIKlQUI9/MaHcYWHzweSO XVUA== X-Gm-Message-State: AIkVDXJFQW+7yvzom8x+PMcjdOGYMUUrkXEJtbDEIW8FQzDf96lJef94zFI2kUdR7aglGA== X-Received: by 10.28.92.21 with SMTP id q21mr4233576wmb.71.1481915684315; Fri, 16 Dec 2016 11:14:44 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id c202sm5662403wme.1.2016.12.16.11.14.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Dec 2016 11:14:43 -0800 (PST) In-Reply-To: <9c16a23c-252a-40a7-bdcc-479b1113e4cb@default> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::242 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:210535 Archived-At: On 16.12.2016 18:22, Drew Adams wrote: > I said "certain...operations". You said "some facilities". > I did not say that _every_ operation/facility needs or > takes advantage of such text inaccessibility. Those that > instead want to ignore narrowing do so. No problem. The facilities do not "want", they can't make these choices for us. The difficulty is in deciding which Lisp code should ignore narrowing, and which shouldn't. And also, for each arbitrary piece of code, for the programmer to remember to make that choice. > That narrowing restricts the buffer limits is its effect. > Code can use that effect to any purpose it wants. Except if the other code, which the current code wants to call inside a narrowing (and respect that narrowing!), always widens. > That's a question of designing the two bits of code. Because that's never difficult. And if only all code was written by one person. > The > latter bit is working with what the former bit dishes out. > It has choices for how to deal with it, one of which is to > `save-restriction', then `widen' and do its > ignore-the-restriction thing. That only helps to retain the narrowing bounds for the caller code. > See my reply to Clément for the case of reusing code that > is broken because it does not expect `point-min' to refer > to a buffer-restriction limit. 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. >> You haven't been paying attention. > > Prove it. See above. I don't see a problem with > narrowing. We've had numerous discussions on this subject already. If you still don't see any problem, good luck with that. > 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). Neither of that helps in the actual problem cases.