From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Wed, 01 Jan 2020 18:42:02 +0000 Message-ID: References: <83tv5mp48l.fsf@gnu.org> <83sgl0lchm.fsf@gnu.org> <83imlwl9vm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="176821"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 01 19:42:14 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1imiwg-000jrw-4b for ged-emacs-devel@m.gmane.org; Wed, 01 Jan 2020 19:42:14 +0100 Original-Received: from localhost ([::1]:60804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imiwe-00089B-9g for ged-emacs-devel@m.gmane.org; Wed, 01 Jan 2020 13:42:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36715) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imiwY-000895-69 for emacs-devel@gnu.org; Wed, 01 Jan 2020 13:42:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imiwX-0006ep-3V for emacs-devel@gnu.org; Wed, 01 Jan 2020 13:42:06 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:54122) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1imiwW-0006eF-Re; Wed, 01 Jan 2020 13:42:05 -0500 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 001Ig4vO011378 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Wed, 1 Jan 2020 18:42:04 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 001Ig346006849; Wed, 1 Jan 2020 18:42:03 GMT In-Reply-To: (Stefan Monnier's message of "Wed, 01 Jan 2020 10:14:30 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:243848 Archived-At: Stefan Monnier writes: > I think the focus should be on: > - making it work everywhere > - making it easy/convenient to use (e.g. even if you share your $HOME between > different architectures or even different OSes as well as different > versions of Emacs) I think the natural action would be to move the eln in the build directory (as these are in fact compiled). Unfortunately this would not work with the elpa packages... The other option would be to add a suffix to the the eln file but is not nice at all. Any idea? Consider that now the situation is pretty bad because eln are likely not to be compatible even from different builds on the same codebase with different configure parameters. > As far as I'm concerned, support for a nil value of lexical-binding is > a non-goal (it should still work, of course, e.g. by using the > bytecode): the dynbind version of Elisp is a legacy language and it's > better to update the code to lexbind than to try and make that legacy > code run faster. Good I agree, and even if not that hard would be something more to care about. -- akrl@sdf.org