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: some design notes Date: Sat, 23 Apr 2016 21:08:07 +0000 Message-ID: <20160423210807.GE4624@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1461445715 1561 80.91.229.3 (23 Apr 2016 21:08:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Apr 2016 21:08:35 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 23 23:08:29 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 1au4mx-0004z9-GL for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 23:08:27 +0200 Original-Received: from localhost ([::1]:53479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au4mw-0007Ri-KK for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 17:08:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au4mi-0007K5-LX for emacs-devel@gnu.org; Sat, 23 Apr 2016 17:08:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1au4mf-0003ol-Ox for emacs-devel@gnu.org; Sat, 23 Apr 2016 17:08:12 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:35807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au4mf-0003n2-GG for emacs-devel@gnu.org; Sat, 23 Apr 2016 17:08:09 -0400 Original-Received: (qmail 3514 invoked by uid 3782); 23 Apr 2016 21:08:07 -0000 Original-Received: from acm.muc.de (p579E8F13.dip0.t-ipconnect.de [87.158.143.19]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 23 Apr 2016 23:08:05 +0200 Original-Received: (qmail 6058 invoked by uid 1000); 23 Apr 2016 21:08:07 -0000 Content-Disposition: inline In-Reply-To: <83shyc42k6.fsf@gnu.org> 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.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:203228 Archived-At: Hello, Eli. On Sat, Apr 23, 2016 at 09:12:25PM +0300, Eli Zaretskii wrote: > > Date: Sat, 23 Apr 2016 17:02:08 +0000 > > Cc: emacs-devel@gnu.org, dgutov@yandex.ru > > From: Alan Mackenzie > > > More generally, I think we should first and foremost make our goal to > > > have a clean and reasonably simple design, and only care about the > > > amount of changes in major mode code as a secondary goal. Thinking > > > about the changes in major modes first could easily lead us astray. > > We must consider both these things together. A prime design goal is to > > allow an arbitrary major mode to be used by a super mode with the minimum > > of adaptation to the major mode, ideally none. > I think you make this goal the main one, and that is a mistake. The > changes that will be needed for supporting multiple modes in the same > buffer will be extensive, whether you want it or not, so trying too > hard to make it easier on modes to adapt will skew the design. Let me put things another way. Above all, I want this new facility to be based on clean abstractions. Such are generally easier to code, easier to understand, and easier to debug, should such be necessary. And I assure you that in my head, the abstractions, particularly that of islands, came before the design. 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? 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. [ .... ] -- Alan Mackenzie (Nuremberg, Germany).