From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Proposal: Forwards-Compatibility Library for Emacs Date: Tue, 21 Sep 2021 14:49:08 +0100 Message-ID: <87ilyuqbsb.fsf@gmail.com> References: <877dfavmzw.fsf@posteo.net> <83v92uxfto.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11194"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Philip K." , Eli Zaretskii , Stefan Monnier , Emacs developers To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 21 15:51:28 2021 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 1mSgB9-0002aW-SE for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 15:51:23 +0200 Original-Received: from localhost ([::1]:51074 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSgB8-00012W-EH for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Sep 2021 09:51:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSg8w-0007A4-On for emacs-devel@gnu.org; Tue, 21 Sep 2021 09:49:06 -0400 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:37439) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSg8v-00039G-1E; Tue, 21 Sep 2021 09:49:06 -0400 Original-Received: by mail-wr1-x42c.google.com with SMTP id t8so39405536wrq.4; Tue, 21 Sep 2021 06:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=/L0AjVeMojD5+e37U3sxDhZ1uGnzp/D5uFSDooylRXc=; b=erL1FxvtFtlolfSDe3R34THkOBDScQWMyWppS0UXB3iRdb7rln0ug2yrhiqK4FJRc3 zJbkW/PJDepvqLen070MA72kKqV1VcCOtUo6l2sKEHwUb4j9QkRcY5/xP2dJGGSzLmxW QEfRZUtp2SQDM+SIUo5uXVtV7dLWqR71eJbVSU287yB4vyBbI9bB4pMXXCssxu2p7pTh XCxag2q1pSg2Yv2/xeS7ZFfyiSMIqtWsv8V7j4AOO5IVSPbCSq7wZITe7Bnb93mFQ2RJ bvd6uNyjcUvOqb+VTDe/XD+qD4jBz6N5R/X445T2O2WsmjNn/2azlPpt8WYTlaLYFzx/ yi/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=/L0AjVeMojD5+e37U3sxDhZ1uGnzp/D5uFSDooylRXc=; b=d/cY116aPsZ2RPvoRPR89voxFztNNEwkAXGlIBnQcJWGlNe15oGchyujJBg7rvP5oZ 3uJW2OY5jRj0H2GegWfD39VnZDTJri64dG/mF6/gv16mM3VXVV4GqXFtE+h1NJ/ifGxA IZ/neR6HwEQlZ0MqIiVPb1DB8v7BPBbf/z/8TwS2ENMPJv0VtB3Cu3K0aLoRxhZzZpDF RvIwS/E4/hiwLdYcxcC5fa6ixHPh9qotplFFlaFQeNSSj+hOpR/hXd23xp3i8Z2RyzwT QIIsSJBfE1F1gw9STUR1NvsTXCNzKpuM7b0EUjxfvk1WXZIj7wEQ82wadmwWnzGDSDkF xHHA== X-Gm-Message-State: AOAM531CntB1n4MHG3oc2cKCnhAI+RyJ4ClriNxrWboH67KO13zA8hQ7 HQ2icaz0qznEyJDqFtxN5tTjBsWVkVs= X-Google-Smtp-Source: ABdhPJxYXlbip6gxto+Z9PZJPhRj62vAzlVqJ3rzQOcGCSUqG0QIsMfdiPnO/gM+OTBdZ+euUDkFnQ== X-Received: by 2002:a5d:6cb1:: with SMTP id a17mr35052287wra.72.1632232142839; Tue, 21 Sep 2021 06:49:02 -0700 (PDT) Original-Received: from nadja (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id q126sm2820999wma.10.2021.09.21.06.49.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 06:49:02 -0700 (PDT) In-Reply-To: (Stefan Kangas's message of "Tue, 21 Sep 2021 14:50:45 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:275236 Archived-At: Stefan Kangas writes: > Eli Zaretskii writes: > >> Can symbol-renaming help here, perhaps? I believe Jo=C3=A3o is trying to >> get it ready in time for Emacs 28. > > This sounds potentially exciting, especially with the two recent > posts, one from Richard and one from Eli, mentioning this work. The > last post on emacs-devel that I can find about "symbol renaming" > before that is from May 2020, and AFAICT it was buried in a > sub-thread. Yes, it was discussed in a subthread about namespacing. I think I outlined the main approach there, and pointed to some code once or twice. I had originally an Elisp-only version, but then crafted a C version. Symbol renaming, also known as "shorthands", is a namespacing system for Elisp. Like all namespacing systems, it's about referring to the same thing by different terms. Much like in this thread, if I write "Eli" it's obvious who I'm referring to: I don't have to write the full "Eli Zaretskii". But if I write "Stefan", there is ambiguity. Elisp shorthands were designed to disturb Elisp's existing practice of one global obarray as little as possible, and so their implementation is fairly short, and they work at the reader level. As always, only one obarray exists, and symbols are always "interned" there under their full names. However, the developer may setup certain shorthands so that she can write i.e. "s-concat" in her file, while still having the symbol interned as the proper, more hygienic, and much harder to type "the-magnificent-string-library-concat". This can be customized per-file using a file-local variable not unlike lexical-binding. There is no difference in what kind of Elisp entity (function, variable, plain symbol) the symbols refer to: Elisp shorthands are agnostic to that.=20=20 I'm currently working on the documentation, which I hope to be able to clear the most obvious/burning questions. I ask you to hold them off for some days to give me time to clear things up there (yes, xref-find-definitions and eldoc are working :-) ) > Perhaps this would be a good time for a new post that explains the > current status of this, with a quick re-cap and perhaps even some > code? (If there exists a branch, I can't find it.) If you're very curious, you can find some code (and tests) in the branch scratch/shorthand-namespacing, but that _isn't_ the latest version. (though it _should_ be working). Indeed I thought I had published the most recent version to our Git repo, but it seems I haven't (which means I must get back to my other machine as push it asap). Jo=C3=A3o