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: some design notes Date: Fri, 22 Apr 2016 17:33:48 +0300 Message-ID: <1b6cb9af-0b30-401b-bf4c-f86c5e62fd04@yandex.ru> References: <20160420194450.GA3457@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 1461335650 32313 80.91.229.3 (22 Apr 2016 14:34:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2016 14:34:10 +0000 (UTC) To: Alan Mackenzie , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 16:34:06 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 1atc9l-0008EY-Ko for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 16:34:05 +0200 Original-Received: from localhost ([::1]:34176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atc9h-0002yS-Rf for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 10:34:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atc9d-0002sw-C5 for emacs-devel@gnu.org; Fri, 22 Apr 2016 10:33:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atc9Y-0007vY-C5 for emacs-devel@gnu.org; Fri, 22 Apr 2016 10:33:57 -0400 Original-Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:36011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atc9Y-0007vU-1M for emacs-devel@gnu.org; Fri, 22 Apr 2016 10:33:52 -0400 Original-Received: by mail-wm0-x241.google.com with SMTP id w143so3743034wmw.3 for ; Fri, 22 Apr 2016 07:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dcXlOmUPIDPH5d3Pu5cDZ9rYTs5irF1TQrPVg+Wt2Hw=; b=EYYwk4K49nTdOBS/9vjyt5Ix+zyzB+OhynJNzZGq+6jzeGcSxoibBCoblrUl4AbzSu iTDytvDztoXlWSxArZihj4laaB+RBKV4n5SZ+iD31J365+hDTbEMpj2gLKTfZJR0ZRu7 LINHhtE7FluZcIRbnxlVNwLxdCoWCt1YKm6EUKXVuzWoOT6L8IAoZiCJ6wYuIDn0BEfY aiqW3foo0DWiLDL3XOH2tfGjB/XMTYAqXugrNk4gapvIu5e2At37S3g6FWMtbV1Rr/yy IOwoM22JW/iky1VVL/1C5ITg2lfpr4Sb2+XYgbUY8wFw+LHYMVKt0JQwAvxy18QwmWLj 6Faw== 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:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dcXlOmUPIDPH5d3Pu5cDZ9rYTs5irF1TQrPVg+Wt2Hw=; b=flQFMA78ePnSQfP9GWIFKVWFctjIJi0PFKjqG1eE8Xk/dl9Wq9rXTVUzgBlht8yfe1 wKk02AXcRML8DXsjhiHy2vqp4+9Kzf29KXCoc+DUhpQwJr8yWejTokhXqUx9Um0ksQCA 20B9AXwTRmlVOFUmibO2VwPe5ldF5Yp7wAxtA9Qs2CUUXDq61DBOcgteVlYF+zuQCgE4 qqS1kwZfB/zGpCo/0446hgpk6g9Rc2JsRk04fodfesuqBUg4rlXITfTDzwnJmABOl/q1 1xy2Zj+hdkgniTGxOgrk5UZH6JOLQ6IMYRchaoBX352+vfspa5cwndRhHIfPlxEi0Nwj 806g== X-Gm-Message-State: AOPr4FXwBn2nX8NywcJPLcrT8njQawTRy6ALBxF+Q6Ae32QRiO6sS2L8nJydfmu6MytZdQ== X-Received: by 10.195.12.162 with SMTP id er2mr20570847wjd.39.1461335630984; Fri, 22 Apr 2016 07:33:50 -0700 (PDT) Original-Received: from [192.168.0.185] ([212.50.99.193]) by smtp.googlemail.com with ESMTPSA id wr2sm8384142wjc.49.2016.04.22.07.33.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 07:33:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160420194450.GA3457@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::241 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:203176 Archived-At: Hello Alan, Thank you for writing this expansive summary. I'll comment on a couple of the items below, but overall, if you're asking my personal opinion, we should put a pin in this for now, and first see where the hard-widen feature gets us. After that, we could see whether it wouldn't be easier to extract certain individual pieces of this proposal in an independent fashion. The main two I see are: - A way to assign buffer boundaries that make certain core primitives treat some buffer regions as whitespace, maybe with support for nesting. I don't know if that should be via text properties. As long as this feature is only used dynamically, it could be a list structure stored in a dynamic variable. That way the `in-islands' variable would become redundant. - A way to quickly store and switch between sets of buffer-local variables. If you go ahead with this proposal, though, I think it should be implemented in close collaboration with an author of a related package. Vitalie Spinu and Christoph Wedler (polymode and andlr-mode maintainers) would be good candidates, and neither has shown up at this discussion yet. Unfortunately, I don't have a lot of time to dedicate to mmm-mode lately (and it probably has the highest backward compatibility expectations out of the three anyway). The main drawbacks of this, IMHO, are that it's big (like you mentioned yourself), and that it's fairly opinionated. Hence the two-item list above. On 04/20/2016 10:44 PM, Alan Mackenzie wrote: > * - The coordination of these bindings will be carried out by the > mechanisms described below, without explicit coding in the super mode. This seems a little too optimistic. For instance: > o - To the user, the current major mode will be that of the island where > point is. All familiar commands will work without restriction. Imenu, as one example, will require coordination from the super mode, or from the multi-mode framework. The user will normally want to see all of entries in the current buffer in the index, so something would have to merge them. > o - To the writer of major modes, a minimal set of restrictions will apply: > * - For some major mode commands, the mode will have to bind the variable > `in-islands' (see below) to non-nil. Ideally, the writers of the "island" major modes wouldn't do anything special to support multi-mode usage. It would be better if the "superior" major modes would have to do all the "special" things. I.e., it's fine to have to introduce a new major mode for a templating language if it can easily use existing major modes for the code regions inside. Here's a related question: would `indent-for-tab-command' bind `in-islands' to t, or not? > (iv) Islands. > o - An island will be delimited in two complementary ways: > * - It will be enclosed syntactically by characters with "open island" and > "close island" syntax (see section (v)). Both of these syntactic > markers will include a flag "chain" indicating whether there is a > previous/next island in the chain. The cdr of the syntax value will be > the island chain to which the island belongs. > * - It will be covered by the text property `island', whose value will be > the pertinent island or island chain (see section (ii)) (not yet > decided). Note that if islands are enclosed inside other islands, the > value is the innermost island. There is the possibility of using an > interval tree independent of the one for text properties to increase > performance. Going by the current implementation in mmm-mode, it would be handy if the islands could be distinguished using one text property only. Then we simply set it on all overlays that cover mmm-mode's subregions. But if all three elements are required, so be it.