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: Sat, 23 Apr 2016 21:12:25 +0300 Message-ID: <83shyc42k6.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461435192 15399 80.91.229.3 (23 Apr 2016 18:13:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Apr 2016 18:13:12 +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 Sat Apr 23 20:13:11 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 1au23F-0002Aj-P6 for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 20:13:05 +0200 Original-Received: from localhost ([::1]:53181 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au23F-0002bC-2n for ged-emacs-devel@m.gmane.org; Sat, 23 Apr 2016 14:13:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49766) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au239-0002VP-7g for emacs-devel@gnu.org; Sat, 23 Apr 2016 14:13:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1au238-0000lA-7Z for emacs-devel@gnu.org; Sat, 23 Apr 2016 14:12:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1au231-0000kV-0b; Sat, 23 Apr 2016 14:12:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1au230-0007yq-6t; Sat, 23 Apr 2016 14:12:50 -0400 In-reply-to: <20160423170207.GB4624@acm.fritz.box> (message from Alan Mackenzie on Sat, 23 Apr 2016 17:02:08 +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:203225 Archived-At: > 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. > > By hard-wiring this special meaning of [:space:] into your design, you > > are limiting future (and possibly some rare extant) major modes. > > I don't think it's all that special. It's natural. IME, authors who write Emacs features are known to not limit themselves to only those things that the infrastructure designers deem "natural". > > Are you sure that none of the background processing will ever need to > > treat islands as such? I'm talking about stuff like timers, process > > filters and sentinels, hook functions run by redisplay and the command > > loop, etc. > > All these subsystems will need to be aware of whether they are dealing > with the buffer as a whole, or merely with an island chain. They will > need to bind `in-islands' appropriately, frequently using the value that > was current when they were invoked. Which means that code that was never aware of any "current mode" will need to adapt. For example, BEGV and ZV (a.k.a pointy-min and point-max) will be suddenly limited to an island while such code runs. That's a major issue, IMO, something that will need changes in many places. > > > > If it is stored in the text property, then you will have to decide > > > > what happens when text is copied and yanked elsewhere. > > > > It would be the job of the `island-after-change-function' to strip the > > > unwanted text properties (both the `island' and `syntax-table' ones) and > > > to apply any needed new ones to the yanked region. > > > The problem is the decision whether they are unwanted or not. It's > > usually not simple to make that decision for text properties that > > change the way text is displayed, when surrounding text also affects > > that. > > But that decision has to made somewhere, somehow, by the super mode, > regardless of how multiple major modes are implemented. If the implementation is not based on text properties, then it doesn't have to. > One detail struck me immediately on seeing the code in > set_buffer_internal_1. The code has to cdr its way down the entire > list of variables in local_var_alist_, despite the fact that only a > few of them point to C variables. Maybe it would make sense to > extract this smaller list into a separate chain. You can't: redisplay allows Lisp evaluation in some places (like the mode line), and any Lisp run there will expect to find buffer-local bindings of all the variables.