From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: A vision for multiple major modes: some design notes Date: Thu, 21 Apr 2016 13:26:53 -0700 (PDT) Message-ID: References: <<<20160420194450.GA3457@acm.fritz.box> <05d5bd7e-1cea-4336-a37c-fe6bd6752558@default> <20160421124325.GC1775@acm.fritz.box>>> <<<64f1d39a-dfd0-44ca-86c1-b4d6104b5702@default>>> <<<83oa926i0e.fsf@gnu.org>>> <<791d74d1-2b1d-4304-8e7e-d6c31af7aa41@default>> <<83eg9y68jy.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1461270454 19664 80.91.229.3 (21 Apr 2016 20:27:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2016 20:27:34 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 21 22:27:21 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 1atLC2-0001e1-GQ for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 22:27:18 +0200 Original-Received: from localhost ([::1]:47558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atLC1-0000R1-Fc for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 16:27:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atLBm-00006g-Ig for emacs-devel@gnu.org; Thu, 21 Apr 2016 16:27:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atLBl-0007y0-Co for emacs-devel@gnu.org; Thu, 21 Apr 2016 16:27:02 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:19632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atLBh-0007xe-E6; Thu, 21 Apr 2016 16:26:57 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3LKQthx012238 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 20:26:56 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3LKQs4V014365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 20:26:55 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3LKQsw1012230; Thu, 21 Apr 2016 20:26:54 GMT In-Reply-To: <<83eg9y68jy.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:203155 Archived-At: > > But just what does "the parts that affect redisplay" mean? > > If we mean parts that need to do something particular wrt > > redisplay, then yes, that makes sense. >=20 > I mean the part that is needed for redisplay to behave in each island > according to user expectations. For example, imagine that a mode that > is relevant to a certain island chain sets up face-remapping-alist in > some particular way -- when redisplay does its job, it repeatedly > consults this variable when it needs to compute faces. I'm saying > that the part of the changes for this feature that affects redisplay > will have to arrange for recalculation of the value of > face-remapping-alist when the display engine gets to examining the > portion of buffer text that belongs to this island chain. Since the > position where the display engine processes is not visible to Lisp, > this arrangement will have to be in C. And similarly with any other > variable whose value the display engine accesses from its C code, like > standard-display-table, for example. Thanks for the example. That's the kind of thing I thought you had in mind. > > You mentioned earlier that redisplay needs to access > > buffer-local variables as it moves through the buffer. > > And you said that redisplay needs to get the right values > > of such variables. > > > > But for some island-chain operations, e.g. some that I'm > > thinking of that do not care about the mode of a chain > > or whether it even has a mode, I don't see why redisplay > > would need to do anything special. >=20 > This could be so in some particular use cases, but it's not > so in general. Depends on what one means by "in general". ;-) To me, having a different mode associated with a chain is a special case of either having such a mode or not having one. Likewise, for having chain-local variables or not. Both having and not having are special cases of "in general". > Modes do affect the way text is displayed. Yes. But if a chain does not use a mode that is different from the buffer's mode, then there should be no special mode-specific handling needed for it. > Besides, Alan says that "most" buffer-local variables will > become island-chain local. If we believe him, then your > use cases you mention above are lucky exceptions rather > than the rule. I don't see them as either lucky exceptions or the rule. I imagine that there are lots of possible uses of a chain of islands of text, some of which involve a different mode or in some other way involve different display possibilities, and some of which do not. >From the point of view of C code (e.g. redisplay) modification, the latter use cases would I guess be lucky (little or nothing new to do). That doesn't mean they would be exceptional (rare) in terms of user use cases. (Dunno know whether they would be.)