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 22:59:51 +0300 Message-ID: <83a8ki4w20.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> <83oa8z4izd.fsf@gnu.org> <20160424165721.GC3517@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461528029 3241 80.91.229.3 (24 Apr 2016 20:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2016 20:00:29 +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 22:00:28 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 1auQCh-0006xq-FD for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2016 22:00:27 +0200 Original-Received: from localhost ([::1]:56449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auQCh-0000Kc-0u for ged-emacs-devel@m.gmane.org; Sun, 24 Apr 2016 16:00:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auQCc-0000HQ-M2 for emacs-devel@gnu.org; Sun, 24 Apr 2016 16:00:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auQCb-0003q7-Fi for emacs-devel@gnu.org; Sun, 24 Apr 2016 16:00:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auQCV-0003pH-FK; Sun, 24 Apr 2016 16:00:15 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4382 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1auQCU-00082g-1l; Sun, 24 Apr 2016 16:00:14 -0400 In-reply-to: <20160424165721.GC3517@acm.fritz.box> (message from Alan Mackenzie on Sun, 24 Apr 2016 16:57:21 +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:203277 Archived-At: > Date: Sun, 24 Apr 2016 16:57:21 +0000 > Cc: emacs-devel@gnu.org, dgutov@yandex.ru > From: Alan Mackenzie > > > 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. > > But you have undoubtedly suffered the frustration of bits of scripts, > possibly html files, and the like, not being properly fontified/indented > for lack of such multiple modes. No, not really. > You seem to be saying I should abandon "abstraction A" (that major modes > should remain unaware of islands) as a design principle. It's not an abstraction, it's a design goal. And yes, I think you need to forget about it for a while. > Without this principle, I'm not sure how much of my design notes > make any sense. I don't see how that invalidates your proposal. > I certainly have no idea of what to replace it by. I suggest replacing it with nothing. Minimizing changes in major modes (and elsewhere) is a simple economy principle; you don't need to worry about us forgetting it. > > 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. > > How do you know? What I foresee happening is a lot of island handling > code being duplicated many times over, over many major modes. I think > that is a big deal. If it is, we will cross that bridge when we get to it. > > 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. > > The very basic assumption that each buffer has exactly one major mode is > being superseded. That is bound to have repercussions on several other > assumptions which are dependent on it, including in the ones you > identify. Searching, syntax, redisply, etc., will all need to be adapted > because that basic assumption (one major mode) will no longer hold. The > challenge is to identify all the code that implicitly assumes that > assumption. There's exactly zero references to major mode in C sources. (There's a function to store the major mode in the corresponding slot of the buffer object, but I see no code looking that slot's value.) And for a good reason: the major mode is an entirely Lisp-land phenomenon, it does all of its work by setting local variables and hook functions. So I think your assumption that having more than one mode in a buffer is already a cataclysm is incorrect. > I think some of these other dependent assumptions will become ambiguous. > For example, at the moment BEG and Z point to the start and end of the > part of the buffer the current major mode administers (this being the > entire buffer). Nobody up till now has bothered to separate those two > meanings of BEG and Z. Such disambiguation will be necessary to support > multiple major modes. I've already proposed doing this by means of the > magic variable `in-islands'. Indeed, I'm much more worried by the effect of islands in BEGV and ZV than by the fact that there could be more than one major mode active. Unlike references to the major mode, the number of places that use BEGV and ZV is enormous, and the unwritten assumptions about them are abundant and well entrenched. > I have spent quite some time studying data.c, syntax.c, xdisp.c, > buffer.[ch], lots of font locking code, and likely quite a few other > relevant files. I haven't come across anything that would be difficult > to adapt for the island mechanism - just there's a lot to adapt. We should try to minimize that impact as much as we can. > I tend to approach it from the other direction: is that handling of an > island as whitespace a satisfactory abstraction or not? It's not an abstraction at all. It's a trick, a device to make adaptation to the island-world easier. That text between two islands of the same chain should be invisible for the mode that's active in the chain -- that is an abstraction. But no one says that text must be treated as whitespace -- this is simply a convenient means to reach your ends. However, other means towards the same end might be available, onces that don't overload [:space:] with an entirely alien meaning. > > Did you consider how [bidi.c search] will work when islands are in the way? > > Yes. The bulk of the adaptation to bidi.c will be the generic changes in > search.c, etc., so that the bidi.c regexps will continue to work despite > the text it's matching over being two islands with a gap in the middle. Doesn't that contradict your design to limit point-min and point-max, since redisplay must be island-aware? > I know little about bidi, but there might have to be design decisions > made about how it should behave when the text it's dealing with isn't > contiguous in the whole buffer. These design decisions should predate the island-as-whitespace discussion, IMNSHO. And if you are sure this feature cannot happen without affecting bidi.c and search.c, then yes, you should study those and understand what they do and how. > No, I hadn't looked at find_newline. But it will need looking at > regardless of whether a space in a regexp matches an island. At the very > least, it will have to behave differently for finding newlines in an > island chain rather than finding them in the whole buffer. See, the ripples are starting already. That is why I say we should try to find a design that doesn't require rethinking, redesigning, and rewriting every single piece of our infrastructure. If we don't, we are making the implementation and testing of this feature a much more complex and hard job than it must be.