From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Wed, 23 Mar 2016 21:16:05 +0000 Message-ID: <20160323211605.GA5324@acm.fritz.box> References: <20160322022539.16038.77264@vcs.savannah.gnu.org> <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1458767614 30754 80.91.229.3 (23 Mar 2016 21:13:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 21:13:34 +0000 (UTC) Cc: Andreas =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org, Stefan Monnier , Dmitry Gutov , Eli Zaretskii , Drew Adams To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 23 22:13:26 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aiq5l-00025R-CI for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 22:13:25 +0100 Original-Received: from localhost ([::1]:46130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiq5k-0004YI-Np for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 17:13:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiq5g-0004Y8-HY for emacs-devel@gnu.org; Wed, 23 Mar 2016 17:13:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiq5d-0006bR-Az for emacs-devel@gnu.org; Wed, 23 Mar 2016 17:13:20 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:61989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiq5d-0006bF-1W for emacs-devel@gnu.org; Wed, 23 Mar 2016 17:13:17 -0400 Original-Received: (qmail 98363 invoked by uid 3782); 23 Mar 2016 21:13:15 -0000 Original-Received: from acm.muc.de (p579E97BE.dip0.t-ipconnect.de [87.158.151.190]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 23 Mar 2016 22:13:14 +0100 Original-Received: (qmail 6785 invoked by uid 1000); 23 Mar 2016 21:16:05 -0000 Content-Disposition: inline In-Reply-To: <877fgtpfrw.fsf@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202146 Archived-At: Hello, Vitalie. On Wed, Mar 23, 2016 at 12:58:27PM +0100, Vitalie Spinu wrote: > >> On Wed, Mar 23 2016 08:16, Andreas Röhler wrote: > > preventing unwanted widen instead seems the way to go. > That's precisely what extra limit do. Prevent unwanted widen. How do you propose > to implement that? > I see 4 ways to go about it: > 1) Add an extra prog-widen and teach all modes out there to use it in contexts > like syntax-parsing, indentation, font-lock and who know what else. A half > backed version of this in already part of emacs. > 2) Have low level restrictions directly in `widen` and a macro > `with-widen-limit` that multi-modes can use. This is the current patch. > 3) Have two types of narrowing (soft and hard). This is harder to implement > but has the benefit that it can be used in non-transient situations like > Info mode. > 4) Bring widen to elisp and allow minor modes (and Info mode) advice widen in > whatever way they see. > I think (1) is a bad idea. (4) is simplest and very general. (3) might be useful > but it's hard. (2) is implemented to get rid of (1). > I proposed (4) very early in the thread, but didn't hear much support for > it. There are only three trivial usages of Fwiden in C code. Bringing `narrow` > to elisp is equally easy. All these options strike me as artificial, ad hoc, and ugly. I would go for option number (5) - to transcend the "unwanted widen" problem - to enhance Emacs such that users and Lisp hackers can freely narrow and widen _without_ upsetting the @dfn{super mode} (the multiple mode handling mode). What is a major mode? It is a collection of local variable settings, a syntax table, an abbreviation table, a mode specific key map, font lock mode settings, an indentation engine, Imenu settings, and one or two other things. Let us then have all these things in our super mode, such that their current values are according to where point is - if we have an AWK script embedded in a shell script, when point is in the AWK bit, the mode line should say "AWK", the C-c C-? bindings from CC Mode should be in force, the font locking should be AWK's, etc. For this we will need a new type of local variable, an "island-local" or "span-local" variable, or whatever you want to call it. Values of these variables will vary according to where point is. To transcend the "unwanted widen" problem, there will be a very special variable `restrict-to-island' or `restrict-to-span', or ..... When bound to non-nil (by the super mode), this instructs certain primitives to confine their attention to the individual island/span (or possibly a chain of them). There will be no restrictions on `widen' or `parse-partial-sexp', because there won't need to be. `parse-partial-sexp' would simply skip over "foreign spans" looking for the delimiter marking the beginning of the interesting span. Regexp searching would likewise restrict its attentions, as would several other facilities. Although the above vision implies a lot of development work, there is nothing there which is beyond our abilities to implement readily. It would give us a true multi major mode capability, yet the impact on individual major modes would be minimal. > Vitalie -- Alan Mackenzie (Nuremberg, Germany).