From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Fri, 9 Dec 2016 17:33:09 -0500 Message-ID: <1cd4ee6e-5da1-450e-ed68-42910015eaed@gmail.com> References: <20161206195507.GA2996@acm.fritz.box> <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209180059.GB2203@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T15lMAe2J7cqpNaJA693rg0liJLAV1IVv" X-Trace: blaine.gmane.org 1481322834 26803 195.159.176.226 (9 Dec 2016 22:33:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Dec 2016 22:33:54 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 09 23:33:48 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 1cFTjf-00061u-RN for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 23:33:48 +0100 Original-Received: from localhost ([::1]:49253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFTjj-0005c1-Rk for ged-emacs-devel@m.gmane.org; Fri, 09 Dec 2016 17:33:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFTjb-0005V7-9r for emacs-devel@gnu.org; Fri, 09 Dec 2016 17:33:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFTjY-0004fK-53 for emacs-devel@gnu.org; Fri, 09 Dec 2016 17:33:43 -0500 Original-Received: from mout.kundenserver.de ([212.227.126.133]:53397) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cFTjX-0004VF-R2 for emacs-devel@gnu.org; Fri, 09 Dec 2016 17:33:40 -0500 Original-Received: from [18.26.2.123] ([18.26.2.123]) by mrelayeu.kundenserver.de (mreue001 [212.227.15.168]) with ESMTPSA (Nemesis) id 0LjR72-1cmcgW1t2u-00bYY4 for ; Fri, 09 Dec 2016 23:33:16 +0100 In-Reply-To: X-Provags-ID: V03:K0:i1100R7YD5QIiWml+sEITjjNVlbuHLGp2gM3lPAYa9MS0PFMIHE 5DoYPYeVV/rtyDmJli3YiygB9mzSCNogbDJJqtVCoVPWrB4dd6A4xjeUjn7lHXkiNNXJv01 eNNyOIVndWiu+4YknsLsvMWzVR3vw/RNCB7b80O9MUzmMaS87IQk+89aZ7y7IqbqkZsxwNR HZfAgunPfMkmigvuB1i5A== X-UI-Out-Filterresults: notjunk:1;V01:K0:WFbeO6VfxZI=:ChO/2ejGa4xdWiNChdrbPz 5cl98NUEaGZTB2O25o6Fdjb6A/A4zETNwNIlv7j01AhMRi/Ngin+gfabyaHl9fIuaXjrIbwKj 8HlUhjMB+NVLB9C5Iz+drE7eXECC/Mzjrxt4Xe/jII2lR5KORtndD6dweeq+sugDY4AkWx+Gg YgwQyn03qEpYNe09c8C19GmIrK6ixD8RP76O3adV4IMUTaq6GEjN5JCujGuRKAUYg2we57oYS xTUxaEfZYzsddOAxrfs50EZ/3/YNPU6m2OY1cP9XC+2l3rdqCZI2Rb82NwVJNV9kTvGA7YvX0 pGrFf1yR8XTBrQKtVfDmIcTiq6l4STgjkrRtrxJrGDn7+dZWLHDcyx4NBE9cnW/88dd7sqV3i I5OgCuTKWGmjy0f8r1fard5nZIuI1klndeLt5nKU5N1Nu9V0sOs2x+jWktb369MiLyas2wKKR brfgXjQb9hknTmqM28KeItaDLQmziPKsw+5lKlm7pLl54PQw0TNXqOuKfr+RpvpTcATnMqwrP c/n5rVweza8fulJ7VgouCWfTH1qJb2ObTeTcnOf4+Xr7rtnRDpg47iRbXJIhovPDCIJcjIcZP 2Z8bVZ/cld8W9FEQLfC4sbSTbw5jrG0AucJ5Km8Yhz4zgjpawaN7LCx2U+eLXwP3dRoqEdRKD lBDmVHE+HHUdR5f1WNuF0OsWzSRGZLGXRIVmBSPgOtlX2adoDmmnRmYxEzo0IrcR4MCo= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.126.133 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:210206 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T15lMAe2J7cqpNaJA693rg0liJLAV1IVv Content-Type: multipart/mixed; boundary="wSmoRtu2PW7xinrn6upGEqt4Ej2OV6rhx"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: emacs-devel@gnu.org Message-ID: <1cd4ee6e-5da1-450e-ed68-42910015eaed@gmail.com> Subject: Re: forward-comment and syntax-ppss References: <20161206195507.GA2996@acm.fritz.box> <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209180059.GB2203@acm.fritz.box> In-Reply-To: --wSmoRtu2PW7xinrn6upGEqt4Ej2OV6rhx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. >=20 > Other examples come from the context of multiple-major-modes-in-a-buffe= r. I'm not directly involved in this discussion, but thanks to both of you f= or these explanations. I didn't clearly understand the distinction at ha= nd 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 co= nveniently restricts motion? In that sense, your vision of narrowing is similar to my applying two ove= rlays to make the beginning of the buffer invisible up to a point, and th= e end of the buffer invisible starting from a point, right? Stefan, am I correct in thinking that the narrowing that you mention abov= e is of a different nature, in the sense that if I narrow a buffer to the= range a=85b 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 wid= en? 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 forgetti= ng about the context =97 let's call this "context-aware narrowing", or "f= ocusing". In the second case we're narrowing to a region and forgetting = about the context entirely =97 let's call this "context-oblivious narrowi= ng", or "sub-buffer editing". Context-aware narrowing allows one to work on just one function easily; C= ontext-oblivious narrowing makes things like http://demonastery.org/2013/= 04/emacs-narrow-to-region-indirect/ possible. Cheers, Cl=E9ment. --wSmoRtu2PW7xinrn6upGEqt4Ej2OV6rhx-- --T15lMAe2J7cqpNaJA693rg0liJLAV1IVv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYSzEqAAoJEPqg+cTm90wjvwUP/0EPbIXFX+Z472VO1WMbkJsm Di0/H+p64caZwt/b3lZYWd0cOXFrhSIkdXI9+TN8KTbdrGTgd1fnEl29S0VUW+XX 8XFlnIW+zdL0VTH0aE9NBSJh/UJTYrK7FQ0AFBNeCBEylqWk0gkJPkyfx7b9VALh Ybp0rCX+W74nVfkAEIhAhyu2IAOrkhp4Qka1vgCxbyrwhvxuuQ3iSfej0aLMzLBw oPZzB4K85TRuz0XZDin/8QpSXXCnvjPPKZehtmfqOEnf+pK5ahCfBcNg8NdTdMCU ExINdHryx6KrOpXx0xxSG7Edfy8PWjKp6sbwK/tnnpwNet5KHkbrzwBTk62LVxIp guXwoUBxlQaVCAl4OZoa1aNNWtpU36h3IC7OevM46IucDiJaV1F+tXuHM16aYOmc A394cUFR2BdkZLyqdDO/IlcQ1MGxhKiBhlXVZoAdqw9MGJRH4N7UCAT2b2zYAqa6 KfG5HH38YNpXVJ+Jh8ykMiSJHE8YECh9JYQkltHE28v+Bzv90C3J6DBQUlvAwbiT u+0eeIgizYP9gVjUUXCyUM7iksGpW2l36Ian17CdHOy+h/lpe4ofqFaExnD8kQGZ HYx3XLf2pqZQVR9w28q9wzisE4DIPWvhl/0a6vUHlyCMNFHemH1qwJvBIAU0Rfp/ QuKyQ2h3XiVS4jq8UU7k =qBvi -----END PGP SIGNATURE----- --T15lMAe2J7cqpNaJA693rg0liJLAV1IVv--