From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Thu, 24 Mar 2016 21:22:28 +0100 Message-ID: <87shzffwxn.fsf@gmail.com> 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> <20160324183835.GB2721@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458850989 23434 80.91.229.3 (24 Mar 2016 20:23:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 20:23:09 +0000 (UTC) Cc: Andreas =?utf-8?Q?R=C3=B6hler?= , emacs-devel@gnu.org, Stefan Monnier , Dmitry Gutov , Eli Zaretskii , Drew Adams To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 21:22:57 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 1ajBmQ-0004hg-O5 for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 21:22:54 +0100 Original-Received: from localhost ([::1]:52602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajBmQ-0004Cv-0j for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 16:22:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajBm8-0003t2-00 for emacs-devel@gnu.org; Thu, 24 Mar 2016 16:22:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajBm4-0003CQ-Qm for emacs-devel@gnu.org; Thu, 24 Mar 2016 16:22:35 -0400 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:35110) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajBm4-0003C9-Gm; Thu, 24 Mar 2016 16:22:32 -0400 Original-Received: by mail-wm0-x229.google.com with SMTP id l68so819314wml.0; Thu, 24 Mar 2016 13:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=E5NgHI7TjmaV9j/oCnyauBtUKmuCwMIcydCLWb11sMY=; b=ETXnCtjHw0S8oz8QiAtPKpcJdrqsUQORiLQQvr+ln1BfoPJxnifnNKliccsfCm4brJ hIrvBFFck904Me0G6DheIbXN0JtxT8hbIC6iEcnP1JZehAEBCOZa/CzRRIH0ndEWLsbz ZFr6hLNmCMV4rB8N1outV7ReQnSrTldxuSUGpz+sFpS91DE8osVKJQnyq25z+UeZw7rW z1jAjBLRIf3O2kD5NffxMoHmy0KmAjze/zAX70GMBp160mzjBVY6LxVZtHhBfx4D2O/q dJhvAhKvCuEbuknUKgbfVnFG9QjiaxoOj/trdvfqiS1nFD1TFZ5IVuht0OBGXeVghlzR rINg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=E5NgHI7TjmaV9j/oCnyauBtUKmuCwMIcydCLWb11sMY=; b=KOUuKJM1QDsAlIVrpcvq5f+Q02iV7zrPhxYAadtFNwkqqGwjEh26PXMQz/QAI1VxCe Idj5zNEtdUdoJ6KZT54WJnSUNqAVN84/rX6MUN0grf14OXIsWx373eRGr+ID55flZvRX OwXEVfChL6CiP7dmhA2mhZ81lwguAzEk5ILGDoUUwW1za7dmuzLseL0zcvpQpWrauZ0M 2gX/7HdhwuVZ/zBTldWj7t/Q8PPuBKymiaqtFTRuJ5lLkNjdlBrngEJsSWpHPkZMhxPw Ck37LTMBD1GDh+pvxOBblL8wCctTo5l+OlEKU5gWX0VFaTSTdfhiVGRB77lQe4iksEeO UwEQ== X-Gm-Message-State: AD7BkJKm8p0HUXYBL8gJlnfjl9yKdg7ARZrCRhwdDm1qe/7iMsVJYs/BnFLpio1LHx4pxQ== X-Received: by 10.194.85.161 with SMTP id i1mr12768727wjz.95.1458850951528; Thu, 24 Mar 2016 13:22:31 -0700 (PDT) Original-Received: from localhost (ma-130-115-183-228.mobile-devices.eur.nl. [130.115.183.228]) by smtp.gmail.com with ESMTPSA id a16sm108068wmi.0.2016.03.24.13.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Mar 2016 13:22:30 -0700 (PDT) In-Reply-To: <20160324183835.GB2721@acm.fritz.box> (Alan Mackenzie's message of "Thu, 24 Mar 2016 18:38:35 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) 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:202194 Archived-At: >> On Thu, Mar 24 2016 18:38, Alan Mackenzie wrote: >> For instance, you said that there could be island-local variables. Can I >> put some cache into one? > I can't see why not. Not sure why would you need island local variables but sub-mode local variables are very meaningful. For instance, polymode gives each submode its own indirect buffer. So all those critical variables that you mentioned are already sub-mode local and independent between sub-modes. Polymode never bothers with thing like syntax-tables, font-lock keywords and most of other buffer local vars. > 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). Are islands of same mode connected in any way? If you delete one char of a chunk head, the island disappears. You type it back and the islands re-appears. Is this a new island? Or is it the same old one? Are local variables from old island preserved or not? This stuff is stuffy. If you are so excited about your general proposal, then why not give it a try and implement a proof of concept - a new multi-mode engine? > What is "(narrow-to-region 1 (point-max))" going to become? Out-of-range error. Unless a mode is already smart enough to use (point-min) it will have to learn that the hard way. > I'm worried that the multi-mode projects will suborn these > text properties, making them unavailable for major modes to use. Not if there will be special "whitespace-begin/end" syntax class designed for multitudes only. But that work won't be complete without tackling regexp search. Your idea of "whitespacing" the regexp search might be handy but it's probably a lot of complex work with long list of problems which no-one has ever seen before. For instance a lot of searches are user level and must be on the whole buffer. So you will need to differentiate between sub-mode search/replace and user search/replace. Then you need to define the semantics of matching or replacing on the boundaries. What if a mode wants to replace a regexp that starts in one chunk and ends in another? More generally, you will need to decide if the mode is allowed to manipulate regions that start in one of its chunks and end in another of its chunks. And if so with what semantics. Etc. etc. Restricting a sub-mode to it's own bubble within a single span is a much simpler implementation and is quite well understood by now. In so many years no-one came across with a better idea than widen/narrow. AFAIK this situation is unlikely to change in the foreseeable future. Vitalie