From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Wed, 13 May 2020 00:05:42 -0400 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87mu6dctgg.fsf@gmail.com> <87a72dge3u.fsf@alphapapa.net> <87y2px9c43.fsf@gmail.com> <875zd0hnmh.fsf@alphapapa.net> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="119447"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Adam Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 06:06:35 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 1jYifB-000Uxz-Hh for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 06:06:33 +0200 Original-Received: from localhost ([::1]:38696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYifA-0000ts-JO for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 00:06:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYieS-0007lh-S9 for emacs-devel@gnu.org; Wed, 13 May 2020 00:05:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57305) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYieS-0000pH-Cb; Wed, 13 May 2020 00:05:48 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYieM-0005tM-CL; Wed, 13 May 2020 00:05:42 -0400 In-Reply-To: <875zd0hnmh.fsf@alphapapa.net> (message from Adam Porter on Tue, 12 May 2020 16:03:34 -0500) 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:250088 Archived-At: [[[ 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. ]]] > 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. That depends on how a library would specify them. If it could be arbitrary string substitutions, it might have this consequence. Joao and I are talking about how to make it more controllable. > 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'? There is no conflict. In the first package, s-foo expands into magnars-foo. In the second package, s-foo expands into super-foo. Neither one actually uses the symbol s-foo. For that reason, we must not try to specify what the "canonical meaning" of s-foo is. It can have multiple ones. If you wanted to use both magnars.el and super.el in one program, you'd have to turn off the renamings for one or bot of those two. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)