From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Mon, 18 May 2020 23:31:32 +0100 Message-ID: <87mu6450zf.fsf@gmail.com> References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87mu6dctgg.fsf@gmail.com> <87a72dge3u.fsf@alphapapa.net> <87y2px9c43.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="58115"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux) Cc: adam@alphapapa.net, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 19 00:32:44 2020 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 1jaoJP-000F0c-Mf for ged-emacs-devel@m.gmane-mx.org; Tue, 19 May 2020 00:32:43 +0200 Original-Received: from localhost ([::1]:52748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaoJO-00083w-PY for ged-emacs-devel@m.gmane-mx.org; Mon, 18 May 2020 18:32:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaoIX-0007Zt-Um for emacs-devel@gnu.org; Mon, 18 May 2020 18:31:50 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:39938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaoIW-0005s1-Og; Mon, 18 May 2020 18:31:49 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id n18so1226447wmj.5; Mon, 18 May 2020 15:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Bg5GGyBRfp2A1SVagFW74/3A7x8ejo+f5RR2+W60RMI=; b=TaIdNNEPb9tG87XyRJchFHloyOFewN215bLq4y4udIkUUsZVBsqliy8XM0EjbtbuYW vJh1EjezoQqsPqmox+TA8Df78MX6yjubF+wBd65WIHPVNMAAlAoQ4DUbpQIKB7pdKM6X Qt0mh7gdD2/nJtVsC5Nyr+QRiyYBFPKSNqXuqHXr1KINJihtub6OeHbEoYllLqPpq4Yu M2Z9urd8C3L/ADYoiurIDuRVnoTTamBon2DfjFPGRSSsCAEblNoQZ7D8gPTn0IlE0fUt X3lOCKGqJKJMTDRUxiTjDEx44kZzxfmi3Lv4QAiIS6pIr65L315plFU0FgPmqplDRFiG 51BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Bg5GGyBRfp2A1SVagFW74/3A7x8ejo+f5RR2+W60RMI=; b=g+Vol7KXj6i+zftviGfN2jipE4JmMbCNC+nObH3LsEXZ4VX1v25VHCFNYDAtazIqBw h6WxMBVcquyhOKIDAxsbXfM30s//3APMthbjGb+i/pwvTb+9UaBrVA6enylisDwGu1LL VLOzT4Oh1ItnqvJSJ8WGhtqeBvuvXtPtwzB7uXRTmc+zqgn1IP1bZrzlKCEbhb3VS6rF do6q0/9rvf4X/D4WzpXvSDOxXtkLXuOwgsTOOp/I+WYxk4GSZla+IVC8WKmg2w/ftmO/ XZF7aXTCTJymU7fyq3QKvOZEUu0JR/ad0LW/fTcrASzX9n5BlR4LU+nI8cXEOi6bA+li MjFg== X-Gm-Message-State: AOAM533BNp1xXX3dF2e47OpWQCYo5QqYkLhOSvzdyDsnXlB+1Tj9kDwj COV/tuy0XwECywXOxeG3IdrXLg4qwVtdrQ== X-Google-Smtp-Source: ABdhPJzk1DVB2siabRT6BUczNZZMyHZO1/UR2CM5FzNxGEPbobvTMjQFdsB+aa17z+gCIphLc2S/Ng== X-Received: by 2002:a7b:c767:: with SMTP id x7mr1702925wmk.181.1589841105543; Mon, 18 May 2020 15:31:45 -0700 (PDT) Original-Received: from krug ([2001:818:d820:9500:824a:171:15a:2213]) by smtp.gmail.com with ESMTPSA id f128sm1464362wme.1.2020.05.18.15.31.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2020 15:31:41 -0700 (PDT) In-Reply-To: (Richard Stallman's message of "Wed, 13 May 2020 00:07:05 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x330.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:250837 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > One thing that I'd like to discuss is whether it's a good idea or not= to > > rename s.el to magnar-string.el. Maybe there's a way to keep calling= it > > s.el and let every client keep using (require 's). > > We could have a file s.el which is not an ordinary file of Lisp, > but rather a special stub for 'require' to access. As I told you off-list, this can certainly be done, if we really can't or don't change existing code that uses the present s.el library. The stub s.el technique is only, in my opinion, a "nice to have" requirement. I don't expect users of magnars.el to be very bothered to change one or two lines of each file that currently uses s.el. The hypothesis here is that these users _want_ to be in GNU ELPA, they have fulfilled all other requirements, but can't easily switch to our string manipulation techniques. So, presumably, they won't mind changing a bit of their code, especially if we show them that they can do it in a backward compatible way. > (require 's) would load magnars.el, then set up the renamings for the > rest of the containing file so that it can say s-foo and that will be > renamed to magnars-foo. Exactly. > The s.el file can include a precise list of the necessary renamings > for callers to use. This woud be updated by scanning magnars.el. I don't understand this particular bit , the "precise list of necessary renamings"). It simply isn't needed, from my understanding of how the system works. Here's an example: say a user.el file has this content today: ;; user.el -- a file which is a user of s.el =20=20=20=20=20 (require 's) =20=20=20=20=20 (defun user-thingy () (message "%s" (s-lines "hello\nworld"))) (provide 'user) ;; user.el ends here It can remain completely unaltered.=20=20 Thus, when compiling user.el, the byte-compiler will evaluate some forms, including top-level require forms. After it has evaluated the first line (require 's) It has loaded the file s.el[c]. That, in turn will have `require`d magnars.el and set up the `s-` -> `magnars-` translation for the current compilation session (probably in a buffer-local version of the shorthand-shorthands variable).=20=20 >From this point on, back in the user.el file, the reader knows to replace the 's-' prefix with 'magnars-'. This means that the .elc file produced that will eventually be loaded will have references to longname version of every symbol. Not only that but during the reading itself, the `s-lines` symbol was never interned in the global obarray. So this is really a shorthand system, very much the way shorthands work in real life: we write AFAIK and IMNSHO for brevity but we the long names of these things. Anyway, when loading files something similar happens. The only think I'm not sure how it should work is if the value of shorthand-shorthands setup by requiring s.el should then remain in the buffer for further byte-compilations of evaluations of specific functions. I think it should. Jo=C3=A3o