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:47 -0800 (PST) Message-ID: References: <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> <20161216192558.GA3858@acm.fritz.box> 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 1481930237 27233 195.159.176.226 (16 Dec 2016 23:17:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 23:17:17 +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:17:12 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 1cI1kS-0005o5-1P for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2016 00:17:08 +0100 Original-Received: from localhost ([::1]:34666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1kW-0005Lz-GG for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 18:17:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32999) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI1kG-00059v-9F for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cI1kD-0003Wi-1S for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:56 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:33118) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cI1kC-0003Tv-NQ for emacs-devel@gnu.org; Fri, 16 Dec 2016 18:16:52 -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 uBGNGo0T012148 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Dec 2016 23:16:51 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBGNGo3v016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 23:16:50 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uBGNGmmg014174; Fri, 16 Dec 2016 23:16:49 GMT In-Reply-To: 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:210554 Archived-At: > 1. Classical example of mixing narrowing for two different purposes, and > how that backfires: M-: (info "(elisp) Variables") > Select some region, and to focus on reading it better (or some other > reason you use narrowing interactively for), narrow to it: C-x n n. > Finish reading it, try to get back to the node with `C-x n w'. >=20 > Instead, you see the whole elisp.info. Not a problem for me. And doesn't have to be a problem for vanilla Emacs users either, if the proper commands are added. For me, narrowing (and widening) pushes the current buffer limits to a list. And it is trivial to return to any previous restriction (including fully wide). In my case: 1. `C-x n n' to "focus on reading" a paragraph in the node. 2. `C-x n x' to return to the full node (not all of Info). End of story. or: 1. `C-x n w' to see all of the Info file (for context or whatever). 2. `C-x n x' to return to seeing just the node. or: `C-x n n' here and `C-x n n' there, any number of times & places, followed by `C-x n x' with a prefix arg, to choose any of those restrictions again. Or just cycle among them by repeating `C-x n x'. Either within a buffer or across buffers. ---- zz-narrow-repeat is an interactive compiled Lisp function in `zones.el'. It is bound to C-x n x. (zz-narrow-repeat ARG) Cycle to the next buffer restriction (narrowing). This is a repeatable version of `zz-narrow'. Note that if the value of `zz-izones-var' is not buffer-local then you can use this command to cycle among regions in multiple buffers. ---- It's a repeatable version of `zz-narrow' (prefix arg acts the same): ---- zz-narrow is an interactive compiled Lisp function in `zones.el'. (zz-narrow ARG &optional MSGP) Widen to a previous buffer restriction (narrowing). The candidates are the zones in the current `zz-izones-var'. With no prefix arg, widen to the previous narrowing. With a plain prefix arg (`C-u'), widen completely. With a zero prefix arg (`C-0'), widen completely and reset (empty) the list of zones for this buffer. With a numeric prefix arg N, widen abs(N) times (to the abs(N)th previous narrowing). Positive and negative args work the same, except that a negative arg also pops entries off the ring: it removes the ring entries from the most recent back through the (-)Nth one. ---- `C-x n x' is simple, but it goes a long way. If better control of restrictions by users is what you're after, then the code in `zones.el' is a good start, IMO. > 2. Multi-mode usage where the framework delegates to each > subregion's major mode for fontification and indentation. I can't speak to that (too vague for me). But a wild guess might be that maybe "the framework" should _not_ blindly so delegate. IOW, if it hurts, don't do it. Maybe a better sauce is needed for the recipe. Or maybe the delegate itself needs to be improved, before it can be delegated this way. > I'm not going to recap it all again now, but, suffice to say, font-lock > rules, indentation functions and syntax-ppss ignoring the narrowing > imposed on them by the calling code is highly inconvenient. Then maybe that should be fixed. Or maybe the fix should be in the calling code. Seems like font-lock etc. code should be able to do whatever narrowing it needs to do (modulo, perhaps, communicating what it's done). If that is wrong for a potential caller then the caller might need to do something different. Anyway, font-lock, indentation, and syntax-ppss are hardly your average bits of code. Perhaps some communication is in order, between them and potential callers, so that they can be properly or more easily used in more contexts. That's a far cry from wanting to simply replace narrowing for users with some kind of invisible-text hack. > We don't want the JS indentation or highlighting rules to look at HTML > code, and vice versa. So create environments for them - quarantine them. Or fix them so whatever they do to wrt buffer restriction is benign outside them.