From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Fri, 9 Dec 2016 23:09:05 +0000 Message-ID: <20161209230905.GD2203@acm.fritz.box> References: <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209180059.GB2203@acm.fritz.box> <1cd4ee6e-5da1-450e-ed68-42910015eaed@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1481324982 25841 195.159.176.226 (9 Dec 2016 23:09:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 23:09:42 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Cl=E9ment?= Pit--Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 10 00:09:38 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 1cFUIL-0005tO-LG for ged-emacs-devel@m.gmane.org; Sat, 10 Dec 2016 00:09:37 +0100 Original-Received: from localhost ([::1]:49343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFUIP-00074I-Ec for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 18:09:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFUIF-000737-6e for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:09:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFUIA-0008Fd-QK for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:09:31 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:32204 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cFUIA-0008FJ-Kd for emacs-devel@gnu.org; Fri, 09 Dec 2016 18:09:26 -0500 Original-Received: (qmail 37720 invoked by uid 3782); 9 Dec 2016 23:09:25 -0000 Original-Received: from acm.muc.de (p548C753B.dip0.t-ipconnect.de [84.140.117.59]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Dec 2016 00:09:25 +0100 Original-Received: (qmail 4091 invoked by uid 1000); 9 Dec 2016 23:09:05 -0000 Content-Disposition: inline In-Reply-To: <1cd4ee6e-5da1-450e-ed68-42910015eaed@gmail.com> 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 [fuzzy] X-Received-From: 193.149.48.4 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:210211 Archived-At: Hello, Clément. On Fri, Dec 09, 2016 at 05:33:09PM -0500, Clément Pit--Claudel wrote: > On 2016-12-09 13:47, Stefan Monnier wrote: > >> There is nothing in the notion of narrowing which suggests that it > >> should change the syntactic context of any text - if a certain > >> buffer position is inside a string, it is inside the string; it > >> doesn't suddenly become outside the string by virtue of where the > >> buffer is narrowed. Were that not the case, the notion "inside a > >> string" would become meaningless. > > Let's take sm-c-mode as an example: it marks CPP preprocessor > > elements as being comments. Yet, it also wants to know if there are > > strings inside that "comment", so it narrows to the "comment" and > > then parses the result as a chunk of C code. > > Other examples come from the context of > > multiple-major-modes-in-a-buffer. > I'm not directly involved in this discussion, but thanks to both of you > for these explanations. I didn't clearly understand the distinction at > hand up to this point. > Alan, is it valid to say that you view narrowing as a convenient > editing feature that lets you restrict operations to a subsection of > the buffer? Something like a "window" over the buffer (or maybe > "stencil" would be a better term?), which doesn't change any of > semantic meaning, but just conveniently restricts motion? In that > sense, your vision of narrowing is similar to my applying two overlays > to make the beginning of the buffer invisible up to a point, and the > end of the buffer invisible starting from a point, right? Yes, I think that's a very good summary. > Stefan, am I correct in thinking that the narrowing that you mention > above is of a different nature, in the sense that if I narrow a buffer > to the range a…b it's just as if I had copied that portion of the > buffer to a totally separate, disconnected buffer (possibly running a > different mode), and the text would get copied back into the original > buffer when I widen? I'm not Stefan, but that's pretty much my understanding of his understanding. > Maybe the solution is to just give these two things a different name? > It seems that in the first case we're narrowing to a region without > forgetting about the context — let's call this "context-aware > narrowing", or "focusing". In the second case we're narrowing to a > region and forgetting about the context entirely — let's call this > "context-oblivious narrowing", or "sub-buffer editing". No, I don't think this is right. The narrowing itself is simply narrowing. It's what you do on the narrowed buffer that makes the difference. In @dfn{ACM-narrowed-processing), the parse state of a position would be determined by (parse-partial-sexp 1 POS). In @dfn{SM-narrowed-processing} it would be determined by (parse-partial-sexp (point-min) POS). I think the main conceptual mistake people are making at the moment is attributing to the act of narrowing, differences in attitude to the processing done on narrowed buffers. > Context-aware narrowing allows one to work on just one function easily; > Context-oblivious narrowing makes things like > http://demonastery.org/2013/04/emacs-narrow-to-region-indirect/ > possible. > Cheers, > Clément. -- Alan Mackenzie (Nuremberg, Germany).