From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes: some design notes Date: Sun, 24 Apr 2016 09:29:58 +0300 Message-ID: <83oa8z4izd.fsf@gnu.org> References: <20160420194450.GA3457@acm.fritz.box> <8360vb6o7u.fsf@gnu.org> <20160421221943.GE1775@acm.fritz.box> <83a8km58qz.fsf@gnu.org> <20160422223507.GD1873@acm.fritz.box> <83d1pg6aes.fsf@gnu.org> <20160423170207.GB4624@acm.fritz.box> <83shyc42k6.fsf@gnu.org> <20160423210807.GE4624@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461479457 22540 80.91.229.3 (24 Apr 2016 06:30:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2016 06:30:57 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 24 08:30:52 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 1auDZD-0002nr-SS for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2016 08:30:52 +0200 Original-Received: from localhost ([::1]:54315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auDZC-00066z-H5 for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2016 02:30:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auDYv-00063j-72 for emacs-devel@gnu.org; Sun, 24 Apr 2016 02:30:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auDYt-0002xw-Rp for emacs-devel@gnu.org; Sun, 24 Apr 2016 02:30:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auDYn-0002xQ-0R; Sun, 24 Apr 2016 02:30:25 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3742 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1auDYk-0004cl-3B; Sun, 24 Apr 2016 02:30:22 -0400 In-reply-to: <20160423210807.GE4624@acm.fritz.box> (message from Alan Mackenzie on Sat, 23 Apr 2016 21:08:07 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:203237 Archived-At: > Date: Sat, 23 Apr 2016 21:08:07 +0000 > Cc: emacs-devel@gnu.org, dgutov@yandex.ru > From: Alan Mackenzie > > I see three layers of software, here: Major modes, super modes, and > subsystems. What is the relationship of each of them to islands? > > Super modes essentially deal with islands - that is what their main > purpose is. They create islands, they destroy them, possibly they > coalesce them, they coordinate the rare interactions between islands > (yanking for example), they coordinate change hooks as they affect > islands. Most of the changes I have proposed is in features directly to > support super modes' handling of islands. > > Subsystems code, like redisplay, font locking, timers, ...., is going to > have to deal with islands incidentally - that is not its main purpose, > but there is no getting away from it. A redisplay action might act on > several islands, so might a font locking action. And so on. > > But major modes? The abstraction I propose is that major modes see their > own parts of the buffer as the entire buffer, and know nothing of > islands or gaps between them. This is a clean abstraction and will lead > to all the advantages enumerated a few paragraphs back. > > Eli, you seem to disagree with the above analysis. Would you like to > outline your scheme of abstractions on this topic? Most of my comments were not about the abstractions. I don't have any alternative scheme to offer, because I have no experience in using, let alone writing, multiple modes in the same buffer. > You say that extensive changes will be needed to support multiple modes > in a buffer, and this is clearly true. Where we seem to differ is where > these changes should be made. I want the vast bulk of these changes to > be in super mode support and subsystems. You seem additionally to want > to make subtantial changes in the major mode "layer". I cannot see this > as a good thing at the moment. I'm saying that worrying about the amount of changes in major modes at this stage is premature optimization. If major modes will have to adapt themselves in non-trivial ways, e.g. by changing their regexps or font-lock settings, it's not a big deal. It is much more important to make sure the design doesn't contradict more basic assumptions and design principles of Emacs, including the low-level code which implements searching, syntax, redisplay, etc., because if the contradiction does happen, you will at best have a bunch of hairy problems to solve, and at worst will simply fail to produce a workable solution. IOW, I suggest to forget for a while about the amount of changes major modes will need, and leave that for later. At this stage, you should be worried much more about how core design features of Emacs will work with islands, and make sure you have all that figured out, before you decide that the island design is valid. In practice, this means that, for example, I would expect you to study all the uses of search in the low-level code, before you decide that making [:space:] match an island edge is sound. E.g., did you know that even bidi.c, which is about as low-level as you can get, uses regexp search to look for a certain combination of whitespace characters? Did you consider how this will work when islands are in the way? What about basic features like find_newline -- did you look into that? You see, if any of these break due to islands, you have some major rewrites on your hands, and the ripples will probably be very far-reaching. The need to change major modes pales by comparison.