From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Preloading seq.el Date: Thu, 29 Aug 2019 14:21:00 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="53397"; mail-complaints-to="usenet@blaine.gmane.org" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 29 14:22:15 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i3JRO-000Der-3Y for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 14:22:14 +0200 Original-Received: from localhost ([::1]:49314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3JRM-0004kF-TY for ged-emacs-devel@m.gmane.org; Thu, 29 Aug 2019 08:22:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39721) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i3JQU-0004j4-P1 for emacs-devel@gnu.org; Thu, 29 Aug 2019 08:21:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i3JQS-0007VN-Ok for emacs-devel@gnu.org; Thu, 29 Aug 2019 08:21:18 -0400 Original-Received: from mail-pg1-f171.google.com ([209.85.215.171]:36938) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i3JQQ-0007O9-Rd for emacs-devel@gnu.org; Thu, 29 Aug 2019 08:21:16 -0400 Original-Received: by mail-pg1-f171.google.com with SMTP id d1so1512456pgp.4 for ; Thu, 29 Aug 2019 05:21:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CET6xQYs6ULBpfWqRg++HlNfz72+8tzfHuaC0AagRHQ=; b=PBRf0s0kTo0P64M31psKBD8jHFFJXi+OaNnupzPbkEh59AOUAtUUIf4vDw28j+FYh6 z4fYmaMN7vpfSkgKUNCf1F9yzrO3UXlIGYhp8ziVcPwdcGatoc83WKiOrhF8cemFDtY/ 0pM+JelvEwpJTLKeaMx6qWN7nf70RxSkp5OCd7S/+RT/3nHIrG5Jzq1KRrXIBf44w5cj nE05W+Ie+NLtl0i9Uo0JUgTsyNg3BPqurUhhuwf82UZI6Hy/a6Jwua6REnrzgSZC0p4T s2Q0L8gQ+H6ExUpY1WHPbpXBanjCs+8xDtLsvJddIRy9D0e2wlx/ul6IHsjHtN+eITgA u3UA== X-Gm-Message-State: APjAAAVaO3batChi8mf0Lts0OX7G1gTdrwCtGBrC7mwECmqYIcPkbITK 1JqhI9r58MVLdnulGisKqmVWqILxeHkutENA+NHMPw== X-Google-Smtp-Source: APXvYqzSMZmvE54T+U2B77ilroal3VrPGLFXED4VIIk0P9oFWwHFho2TNpiTWaQge+Z7Eg2WIQX9US9k4ftvrm2Bo4w= X-Received: by 2002:a62:7789:: with SMTP id s131mr11026643pfc.50.1567081272224; Thu, 29 Aug 2019 05:21:12 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.215.171 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239672 Archived-At: Hi, I'm working on some things in help.el, and it would be very nice to be able to use a function in seq.el to simplify my code. Alas, seq.el is not preloaded. Could we preload seq.el? Previous discussion here: https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00852.html In the previous discussion someone said that we would be punishing users that do not use it if we preloaded it. It's not clear to me how this would punish users. On the contrary, if it was preloaded, more powerful abstractions would make it easier to maintain Emacs and free time for developers by not forcing us to reinvent wheels. This would improve Emacs and help all users. Another argument was that seq.el is not used that much. This is not surprising, since it's not preloaded. It's therefore hard to use in some places of Emacs. If it was preloaded, it would presumably see more use. Stefan Monnier also pointed out that seq.el depends on cl-lib, and that to preload seq, we would need to preload cl-lib. This seems to be due to a single use of the cl-subseq function in cl-extra.el. If this is a show stopper, perhaps we could see if we can get rid of that single use. Best regards, Stefan Kangas