From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Add autoload cookies in seq.el Date: Thu, 21 Jul 2016 17:33:48 +0300 Message-ID: <834m7jysab.fsf@gnu.org> References: <877fepcezr.fsf@petton.fr> <83k2ip83qx.fsf@gnu.org> <83y4737vmf.fsf@gnu.org> <83mvlcz6jr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469112558 1602 80.91.229.3 (21 Jul 2016 14:49:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jul 2016 14:49:18 +0000 (UTC) Cc: nicolas@petton.fr, emacs-devel@gnu.org, tino.calancha@gmail.com To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 21 16:49:13 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bQFHh-0003xE-PE for ged-emacs-devel@m.gmane.org; Thu, 21 Jul 2016 16:49:09 +0200 Original-Received: from localhost ([::1]:41274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQFHg-00080Y-Ud for ged-emacs-devel@m.gmane.org; Thu, 21 Jul 2016 10:49:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQF2q-00048k-Nn for emacs-devel@gnu.org; Thu, 21 Jul 2016 10:33:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQF2l-0004rt-Pn for emacs-devel@gnu.org; Thu, 21 Jul 2016 10:33:48 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQF2l-0004ri-M6; Thu, 21 Jul 2016 10:33:43 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4921 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bQF2j-0001Xs-6q; Thu, 21 Jul 2016 10:33:41 -0400 In-reply-to: (message from Lars Ingebrigtsen on Thu, 21 Jul 2016 12:51:21 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:205958 Archived-At: > From: Lars Ingebrigtsen > Cc: tino.calancha@gmail.com, nicolas@petton.fr, emacs-devel@gnu.org > Date: Thu, 21 Jul 2016 12:51:21 +0200 > > > Are we mis-communicating? If somefile.el needs a function that is in > > subr-x.el, all it has to do is (require subr-x). How's that a > > problem? > > We seem to be. That paragraph was about seq.el. Was it? Here's what I saw and responded to: > > Lars, why did you put read-multiple-choice in subr.el? Its only user > > currently is message.el, which is not preloaded, so I think preloading > > seq.el as result of this is not justified. > > Perhaps subr-x.el would be a better place for it... > > But I find it rather odd that we can't use the best and most modern > libraries in the most central parts of Emacs. That's kinda backwards. > The most central parts of Emacs gets the most obfuscated code? IOW, from my POV some code which was only used by message.el (which is not preloaded, and was never supposed to be) was added to subr.el, which then required to preload seq.el. How is that related to the following complaint of yours: > Every time somebody introduces seq-based code into the dumped files, > it's rewritten since we can't use seq, since it's not dumped. seq was > written as a library meant to regularise all the different inconsistent > libraries and functions we use for that stuff. Since message.el is not a preloaded file, you are free to use seq-based code in it, which will cause seq.el to be loaded when message.el is. What I'm objected to is to put the code which uses seq.el in a preloaded file, when its _only_ user is not preloaded. I think such a policy makes sense; don't you? > Until seq stops being persona non grata in the most important Emacs Lisp > files, it'll probably not see much uptake in the rest of Emacs, either. > Who wants to go around remembering two different interfaces for lists, > one that's OK in subr.el and one that's not? Maybe I'm misremembering, but I only saw discussions about preloading seq once or twice, including this discussion. So I'm not sure where does "persona non grata" thing come from. Can you point me to those incidents which led you to this conclusion?