From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Tue, 12 May 2020 16:03:34 -0500 Message-ID: <875zd0hnmh.fsf@alphapapa.net> 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: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="87071"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 12 23:04:56 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 1jYc5A-000MWz-83 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 23:04:56 +0200 Original-Received: from localhost ([::1]:40278 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYc59-0007DL-97 for ged-emacs-devel@m.gmane-mx.org; Tue, 12 May 2020 17:04:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYc44-0005v1-Vf for emacs-devel@gnu.org; Tue, 12 May 2020 17:03:52 -0400 Original-Received: from ciao.gmane.io ([159.69.161.202]:37424) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYc43-00010k-U5 for emacs-devel@gnu.org; Tue, 12 May 2020 17:03:48 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jYc3z-000L5J-3L for emacs-devel@gnu.org; Tue, 12 May 2020 23:03:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=159.69.161.202; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/12 15:14:35 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-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:250045 Archived-At: João Távora writes: >> One minor drawback I see is that the symbol renaming is placed at the >> bottom of an Elisp file, while the loading of the library whose symbols >> are renamed is (usually) at the top of the file. >> >> Would a macro something like this be feasible, to (require ...) the >> library and specify the renamings together? >> >> (shorthand-require 'magnar-string :with "^s-" :as "magnar-string-") > > Yes, something like that is reasoanble. Or we can just have a table of > "notable renamings", and then the bare (require 'magnar-string) would > come with that. Or as Richard, suggested, the default renamings could > be given in the magnar-string.el file itself. They could be collected > within each byte-compile-file or load-file, then restored. I may be missing something, but it strikes me as almost duplicating the original problem, if libraries are allowed to define their own symbol abbreviations. IOW, it seems almost like solving the problem of libraries' "polluting" the global symbol namespace by allowing libraries to "pollute" the global symbol *abbreviation* namespace (in the sense that one would exist). Similarly to what you said, what if one user wants to write a package using magnar-string.el with the "^s-" abbreviation, but another user wants to write a package using a hypothetical super.el with the same abbreviation, and both magnar-string.el and super.el define a symbol `foo'? Or what if both magnar-string.el and super.el defined the same default abbreviation (since there is no enforcing body to prevent conflicts)? Shouldn't it be up to the "requiring" library to decide which shorthands it uses for libraries it requires? > 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). I suppose that would be ideal if it's possible. On the other hand, if a user wanted to write a package using s.el with a prefix like "^mstring-", and a hypothetical super.el with the "^s-" prefix, it would seem confusing for symbols like "s-foo" to not refer to those loaded by (require 's). The "don't do that if it hurts" axiom may apply, of course, but it would seem preferable to avoid such a situation. > Another thing that has to implemented is a special syntax to escape the > renamings (imagine that you want to use some legitimate "s-foo" function > that your renaming has shadowed) Would a table of buffer-local symbol aliases work? Maybe it could even work something like: (defalias-local :canonical 's-foo :local 'real-s-foo) Which would make the canonical s-foo accessible as real-s-foo in the local buffer's code. (The keyword arguments may be superfluous, but it may also help clarify that the s-foo referred to is the canonical one rather than a "shorthand"-abbreviated one.) If that were present in the file before the (shorthand-require ...), I suppose the "'s-foo" would not be intended to be read with the abbreviation. (Not commenting on the feasibility of the implementation, just musing on the user-facing API.)