From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Thu, 24 Mar 2016 00:34:58 +0200 Message-ID: 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> <20160323211605.GA5324@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1458772528 9876 80.91.229.3 (23 Mar 2016 22:35:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 22:35:28 +0000 (UTC) Cc: Eli Zaretskii , =?UTF-8?Q?Andreas_R=c3=b6hler?= , Stefan Monnier , Drew Adams , emacs-devel@gnu.org To: Alan Mackenzie , Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 23 23:35:22 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 1airN2-0007N9-Mm for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 23:35:20 +0100 Original-Received: from localhost ([::1]:46442 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1airN2-0001CQ-0i for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 18:35:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1airMo-0001AL-3t for emacs-devel@gnu.org; Wed, 23 Mar 2016 18:35:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1airMk-0001wz-Ok for emacs-devel@gnu.org; Wed, 23 Mar 2016 18:35:06 -0400 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:34735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1airMk-0001vu-9E; Wed, 23 Mar 2016 18:35:02 -0400 Original-Received: by mail-wm0-x229.google.com with SMTP id p65so251790298wmp.1; Wed, 23 Mar 2016 15:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wtuyXm9acK6kgDFYZWFCvNxRpvzgI2Nq+AIsT9vM3zM=; b=FghbQjAkIv0kiTi5vtyWumNFhXznbiqCgeqFca+V7O6VJ/4T3paCOsoRSI77h6OuRn YJBJj1mM9qRk5CdsAT2c3dzVNY+bvP3SSAoX48GrMbostGDb31c6DyeWqg0+4JNIeqjt VXXfB4cQxz6jrP9nEZnYekVDrJt1SGq8i0UOqVHnJ2MTU23uJ3qLoe6FYgMDPL8djXq8 x6X1BYBdHPlx3Kb58nCSk6bN0b/qWuJHlZbfTS8nIpUYrVBgS6WP5RCJrjOjmOP8gK57 LqePl/AC5TNQV+9JpCkVNv969ahd7FVeyz4QmnJ4PE7GuoGmUTrN4eF7pa+APH782gur EN6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wtuyXm9acK6kgDFYZWFCvNxRpvzgI2Nq+AIsT9vM3zM=; b=aIhokXikJ9MLNDjrWQw4pKFBaKaU8kMOVyA57HmL7eKbuhYcT3n1TrgECRXYj2EPDA tiKZ+NLrbfXm3KTCLDIajbqKwX4EROCl+28FPgKMi7PXxtMnEIeKsnsMFSiNHqO0gz01 sqLq/u5I/L/+oqfAto2fpckJvggx5VexCjAvhERz8UDTodjkOdBCTQB+xNAXEj5+hhh2 KQsFmXBdZAHB3ilGYlb2JtBAJevZ70Q+Weln6ZoGz1j/NByxiYNrBXAguOhsGGAI/+ID yKpATGw2gVaoMFHduP0vpQVM87HBd2XbVCG6dSbaGf3WP8rzVPTBkuRFkul3Ujh6t+kW yIrQ== X-Gm-Message-State: AD7BkJK9OgdgSkZ0/0+gOaVRwhV0IhNo4D2fdJ1RKWOhvsmTchp3X3Q4cx2/58ZF7wnP+g== X-Received: by 10.28.146.209 with SMTP id u200mr6137267wmd.59.1458772501302; Wed, 23 Mar 2016 15:35:01 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id h7sm24168851wmf.9.2016.03.23.15.34.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 15:35:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160323211605.GA5324@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::229 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:202153 Archived-At: Hi Alan, On 03/23/2016 11:16 PM, Alan Mackenzie wrote: > 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). I disagree about ugly. Co-opting narrowing to do something useful for once is a pretty neat, and minimal, approach. > 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. > 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. > 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. For instance, you said that there could be island-local variables. Can I put some cache into one? 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)? 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? 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. > 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 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. 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. 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). 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. But the end benefits might not be high enough to justify the necessary work and the increase in complexity in internals.