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: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Thu, 24 Mar 2016 18:38:35 +0000 Message-ID: <20160324183835.GB2721@acm.fritz.box> References: <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> <20160323211605.GA5324@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1458844577 17239 80.91.229.3 (24 Mar 2016 18:36:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 18:36:17 +0000 (UTC) Cc: Vitalie Spinu , Andreas =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org, Stefan Monnier , Eli Zaretskii , Drew Adams To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 19:36:11 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 1ajA75-0000XT-9z for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 19:36:07 +0100 Original-Received: from localhost ([::1]:52264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajA74-00077t-7H for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 14:36:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajA6p-00077m-HV for emacs-devel@gnu.org; Thu, 24 Mar 2016 14:35:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajA6m-0005I6-7Y for emacs-devel@gnu.org; Thu, 24 Mar 2016 14:35:51 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:24019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajA6l-0005Hm-UF for emacs-devel@gnu.org; Thu, 24 Mar 2016 14:35:48 -0400 Original-Received: (qmail 98866 invoked by uid 3782); 24 Mar 2016 18:35:46 -0000 Original-Received: from acm.muc.de (p579E9D87.dip0.t-ipconnect.de [87.158.157.135]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 24 Mar 2016 19:35:45 +0100 Original-Received: (qmail 4973 invoked by uid 1000); 24 Mar 2016 18:38:35 -0000 Content-Disposition: inline In-Reply-To: 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:202190 Archived-At: Hello, Dmitry. On Thu, Mar 24, 2016 at 12:34:58AM +0200, Dmitry Gutov wrote: > On 03/23/2016 11:16 PM, Alan Mackenzie wrote: > > 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. > Each multi-mode package implements something like this already. It > doesn't work well e.g. because font-lock rules of each particular > language, indentation code, etc, are free to widen. With islands it should work well, regardless of whether any major mode widens or narrows. That's because primitives (such as regexp search) would constrain themselves to the island. > > 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. > That part is already doable (and done), for most practical purposes. Except you said above that it doesn't work very well. > > 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. > You'll have to present the total list of facilities, decide how the > islands would be applied, and other issues will likely come up from > unexpected places. That will require more investigation. But syntax based searching and regexp based searching will certainly be amongst them. > For instance, you said that there could be island-local variables. Can I > put some cache into one? I can't see why not. > Earlier, you suggested that the islands would be applied via text > properties. What happens to all island-local variables when someone, > somewhere, changes an island's boundary (maybe adds, maybe removes, > maybe moves it)? The island-local variables would stay with the island, so that when somebody inserts or removes text the right thing would be done. If somebody deletes the island, those variables would disappear (just as buffer local ones do when a buffer is deleted). > On the one hand, we'd probably want to retain some variables, in order > not to rerun the major mode functions over and over again. On the > other hand, if we were to put e.g. syntax-ppss-last into an > island-local variable (and it's a logical continuation of this idea), > after island boundaries change it should what... become unbound? Nil? That's for the application to decide. The island local binding would countinue to exist for as long as the island exists, and the application would be free to use it. > Or carefully managed by the mult-mode package, which happens already. > Next, at which points exactly would Emacs look at the island boundaries > and change the island-local variables to the values set in the current > island? Probably not after each point movement. In post-command-hook? > That's also already done. It wouldn't use any high level facility like post-command-hook. The mechanism would be more like a buffer local variable, entirely handled by the C level, so that such a binding would simply exist. > > 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. I'm worried by this. Already narrowing/widening which is currently simple, straightforward, and rigorously defined, is looking like becoming complicated. Major modes are going to be constrained in what they can do. I get the impression that major modes are going to be restricted in how they can use parse-partial-sexp. These are serious matters, but I haven't seen any widespread debate on emacs-devel about them. > I'm sure this is eventually doable. But this proposal looks rather > similar to what Lennart Borgman has been asking, in multi-mode related > discussions, on several occasions separated by years. Also in broad > strokes (probably a bit broader that these). Nobody has been both > capable and invested enough into the issue of multi-mode buffers to even > start working on it, AFAIK. > On the other hand, using narrowing for multi-mode purpose is a familiar > ground already, and the changes in Emacs core required to do so are > minimal. And most of the code written for Emacs has been taught to > respect narrowing bounds (even if only by the virtue of always using > (point-min) instead of 1), so we can utilize that. What is "(narrow-to-region 1 (point-max))" going to become? It seems there will be a need for "the bounds of the island", which will impose complexities in major mode code. > Another (probably minor, it's hard to tell now) disadvantage, is if the > multi-mode package sets narrowing bounds itself, it will decide which > islands are visible from the current island, dynamically, so to speak. How will this be done when narrowing is the tool used? It you narrow to an island, none of the other islands in a chain are visible. If you narrow to the smallest region which spans those islands, you leave a lot of stuff visible which shouldn't be. > Maybe just the current one. Or it can copy just a couple of islands from > the same mode to a temp buffer, call the indentation function there, and > use the result. Doing that using an islands framework limits it to a > predefined set of semantics (e.g. all Ruby islands see all other Ruby > islands). I don't see why. There's no reason why islands couldn't be linked to and unlinked from eachother freely at runtime. > That's not to say that being able to make parse-partial-sexp to skip > over certain intervals wouldn't be valuable. But you can do that, sort > of, already, by applying existing text properties to those intervals > (like beginning-of-comment/end-of-comment, or just "whitespace" over the > whole of it), and then removing them at the end of an operation. Not really. If you "whitespace" a region out, you've got to remember the text properties that were there originally, and restore them afterwards. There's no easy way to do that. The comment-fence text properties won't work either, because, in the general case, there will already be comment-fence properties in your region which will foul things up. I'm worried that the multi-mode projects will suborn these text properties, making them unavailable for major modes to use. > But the end benefits might not be high enough to justify the necessary > work and the increase in complexity in internals. They might not. They might. Basically, nobody else really seams interested in my idea, so it doesn't look like it will happen. -- Alan Mackenzie (Nuremberg, Germany).