From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Consideration for Rust contributions in Emacs Date: Mon, 23 Jan 2023 21:04:47 +0200 Message-ID: <837cxdhy28.fsf@gnu.org> References: <878rhuc79x.fsf@gmail.com> <66c86c61-93ac-4723-81a4-ced034f61550@Spark> <87zga9tln8.fsf@web.de> <83cz75i3iu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38000"; mail-complaints-to="usenet@ciao.gmane.io" Cc: arne_bab@web.de, comms@dabrev.com, allred.sean@gmail.com, emacs-devel@gnu.org To: John Yates Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 23 20:05:25 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pK28D-0009d2-2f for ged-emacs-devel@m.gmane-mx.org; Mon, 23 Jan 2023 20:05:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pK27U-0007Gh-Dg; Mon, 23 Jan 2023 14:04:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pK27T-0007GV-AF for emacs-devel@gnu.org; Mon, 23 Jan 2023 14:04:39 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pK27S-0004qO-J6; Mon, 23 Jan 2023 14:04:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hHh8GMzIVocALdepFE0/v4jrPNsWUtuMFTp32qqSFZ8=; b=I5K5bMqr0+tN N+O3V0P1lAfdF/BL8wRvxrpublR2z2+XMGFHFuNRaGPnyDKBmGt+6UsLRHv4erPmcp2Cgpjc4lMCj SbDBA0X1tjgx/D1euBHqs5Pl5FLbhPSdJL53rDME2f18FUq4tifiZhOI9G/8vcK8BSm1inTlTF4fZ fnZydVW/zc0qaDeuqtOXm+259ncyZrslR41F9y6nsFbqSbxMBJzFiLStLU+mxZNiaUvgyhvw/cZTT wwyHe98EzwkQ4vDX1qfitcPuE2FFrl+n3YcxH0hDRT9gXh8AwE9bv8oiHbx2WxBRxuTmD+5QiEyBl 4hOw1poZqIHOdv/RKV2+TA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pK27R-0002f1-SB; Mon, 23 Jan 2023 14:04:38 -0500 In-Reply-To: (message from John Yates on Mon, 23 Jan 2023 13:22:44 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302620 Archived-At: > From: John Yates > Date: Mon, 23 Jan 2023 13:22:44 -0500 > Cc: arne_bab@web.de, comms@dabrev.com, allred.sean@gmail.com, > emacs-devel@gnu.org > > On Mon, Jan 23, 2023 at 12:06 PM Eli Zaretskii wrote: > > > > Quite a few new features are still being implemented in C. Consider > > just the recent innovations: native-compilation, tree-sitter, support > > for XInput2 and touch devices, to name just a few. > > Of these four, only tree-sitter seems to be implemented in C solely > for performance reasons. IIANM, there is nothing fundamental about > what tree-sitter is doing that *could not* be done in lisp. The > only issue is performance. > > By contrast, the three other features that you list (native- > compilation, XInput2 and touch screen support) need to interact > with the host environment. From what I have observed, developers > typically partition such features into a C component and a lisp > component. The impetus seems to be to find a natural partition: > to do in C what must (which may still include some performance > considerations) and then to expose a nice, clean interface to lisp. Right. Which is exactly my point: some parts of Emacs are implemented in C for reasons that have nothing (or almost nothing) to do with performance. E.g., even in the first example, you cannot access buffer text directly except on the C level. > > Moreover, familiarity with the internals implemented in C is IME quite > > necessary even for Emacs developers who almost never touch that layer. > > For some definition of Emacs developer, I do agree. I think for any serious Emacs developer. Limiting the familiarity to the Lisp level will leave many important aspects look like black magic, because what we expose to Lisp is higher-level abstractions that sometimes create a completely inaccurate mental picture of what really happens. A good example is the machinery that triggers redisplay and how it integrates into the Emacs "main loop".