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 09:59:02 -0700 (PDT) Message-ID: <791d74d1-2b1d-4304-8e7e-d6c31af7aa41@default> 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>> 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 1461257969 11930 80.91.229.3 (21 Apr 2016 16:59:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2016 16:59:29 +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 18:59:17 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 1atHwg-0000ld-7w for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 18:59:14 +0200 Original-Received: from localhost ([::1]:44547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atHwf-00054h-QW for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 12:59:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atHwb-00050u-SB for emacs-devel@gnu.org; Thu, 21 Apr 2016 12:59:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atHwb-00060v-0l for emacs-devel@gnu.org; Thu, 21 Apr 2016 12:59:09 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:39526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atHwX-00060a-3m; Thu, 21 Apr 2016 12:59:05 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3LGx3pZ011171 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 16:59:04 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3LGx3Wl018834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 16:59:03 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 u3LGx2K2001117; Thu, 21 Apr 2016 16:59:03 GMT In-Reply-To: <<83oa926i0e.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: userv0021.oracle.com [156.151.31.71] 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:203151 Archived-At: > > I have no problem with stuff being in C for performance reasons. > > When that is not critical, keeping stuff in Lisp is good. > > > > Especially for a new and very general feature: let folks play > > with it and experiment with new possibilities. We can later > > optimize any parts we like. >=20 > The parts that affect redisplay must at least partially be in C, > because there's no existing infrastructure that I'm aware of that > can be piggy-backed to do this kind of stuff. Anything that must be in C must be in C, of course. ;-) 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. If we mean also some parts that would just be faster if done in C then maybe, or maybe not. 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. No, I don't claim to understand this. I'll stick with agreeing that if there is an effect from this feature on redisplay, or if redisplay affects this feature somehow, and if that means that some bits of the feature must be implemented in C, that's fine. I would just prefer that we not go overboard wrt a C implementation, just because we can or because something might be faster in C. I'd just as soon have a general, open, and easy-to-modify-&-extend feature at the outset, and worry later about optimizing bits of it that are important to optimize. From my point of view, a feature such as this opens new possibilities that are ripe for exploration. And that shouts, "Lisp, please!". Anyway, not knowing anything about this part of things, I'll shut up about C vs Lisp, at least for now.