From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: ELPA: new package nano-agenda Date: Mon, 18 Oct 2021 17:50:32 -0500 Message-ID: References: <87tuhmgiew.fsf@posteo.net> <87pmsaghed.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19070"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Nicolas P. Rougier \(inria\)" , emacs-devel To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 19 00:51:42 2021 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 1mcbTo-0004lB-PA for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Oct 2021 00:51:40 +0200 Original-Received: from localhost ([::1]:53884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcbTm-0003vv-BZ for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Oct 2021 18:51:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34058) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcbSz-0003Fl-EI for emacs-devel@gnu.org; Mon, 18 Oct 2021 18:50:49 -0400 Original-Received: from mail-lj1-f169.google.com ([209.85.208.169]:38650) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcbSw-0000Zs-EJ for emacs-devel@gnu.org; Mon, 18 Oct 2021 18:50:48 -0400 Original-Received: by mail-lj1-f169.google.com with SMTP id n7so2498658ljp.5 for ; Mon, 18 Oct 2021 15:50:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QkYHa9v6JhFddidYjrKItHDOmf0KNpfr9pMF5SZNCWM=; b=i+xUn9PSfhZok3ERdkkseGASJYBJIdlCpUWsJNedbyEBDdUINxRhYcr/0F3p1qmBLV jOURsXZS4MnPubebap5DoFLKRiW93Qu3dr+qspznVGI/bCAScf0kWQkri32DRXKGGgCc f5nJJsRXG6UXPG9mR3k3cPDSkQFDjV72XgKIngNKhoIxiUfuBU21spS1EMgXT4zeoS9T AtZ9WStP9xfg3cLxCVKvi7tpT3/PQY/5CIrIA4PMdC2LXi8vFM17X+nZqXcbZZ5toFWL jZUYkqu3XiPEVOVwbLX6sPobK5+K6CETziX8d1lXtvFBW/lH0rym49X9KdTIF/FZxtPR VFcw== X-Gm-Message-State: AOAM530MGnUNG/4eQwsmkq7bDwvRcqhlnlj2xOv6VX5VTyzXxHSKWH0+ 0Lufktha5eWuxOG4ypysRzr+a8SzvFYGpRhAnGc= X-Google-Smtp-Source: ABdhPJx07T26r+a3trSu/GfkzLt/SGLbrSGiq/quar8nLqqUOYNXgfCk2b0X3mhjZNmKkEWXveyBcf3xtYVQjZ01tX0= X-Received: by 2002:a2e:a7d3:: with SMTP id x19mr2685433ljp.506.1634597443880; Mon, 18 Oct 2021 15:50:43 -0700 (PDT) In-Reply-To: <87pmsaghed.fsf@posteo.net> Received-SPF: pass client-ip=209.85.208.169; envelope-from=alphadeltapapa@gmail.com; helo=mail-lj1-f169.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no 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:277329 Archived-At: Hi Philip, Nicolas, et al, On Tue, Oct 12, 2021 at 2:41 PM Philip Kaludercic wrot= e: > > "Nicolas P. Rougier (inria)" writes: > > > Philip Kaludercic writes: > > > >> It seems you are using ts.el, which isn't on ELPA, and additionally > >> depends > >> on s.el that also (famously) isn't on ELPA. > >> > >> That being said, ts seems to only have a weak dependency on s (two > >> usages of s-join), so maybe ts could be added to ELPA -- in one form > >> or > >> another -- as it seems to have a few useful improvements over the > >> default time and duration functions. > > > > Thanks for the review, I didn't pay attention to this point > > actually. I confirm than ts would be a very nice addition to ELPA > > since it really simplifies time management for user and comes with a > > very clean API. I guess only Adam Porter can answer if he want to add > > it to ELPA or not. > > As he is the only major contributor, this might be worth considering. > I've Cc'ed Adam to see what he thinks. Yes, I'd be glad to have ts.el in GNU ELPA. And I'd be glad to remove the dependency on s.el to facilitate that. The only potential issue that I can see is that it currently emits extra warnings at load time (or is it compile time? I forget...) on Emacs 28 due to more strict checking in the byte compiler. The warnings are harmless, and everything works correctly in spite of them. The last time I tried to find the cause of them, I wasn't successful despite some effort. I don't know if that would or should keep it out of GNU ELPA; I would guess that it wouldn't, and that the warnings can always be fixed or worked around later. > What might be an issue is if the "ts-" namespace is considered to be > "too valuable", as was the issue with "s-" and "f-". The maintainers > would have to decide on that, I can only speculate. I hope that wouldn't be the case. In fact, I've already "defended" the "ts-" prefix against other packages. (That sounds aggressive or confrontational, which I don't intend, but I'm not sure how else to put it. Actually, the maintainer of the elisp-tree-sitter repo, Tu=E1=BA=A5n-Anh Nguy=E1=BB=85n (@ubolonton), was very kind to rename his p= ackage's prefix to `tsc-` to avoid conflicts when I asked him last year. See https://github.com/emacs-tree-sitter/elisp-tree-sitter/issues/35 ) And it's already used as a dependency in several other Elisp packages. --=20 Thanks, Adam