From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Thu, 30 Apr 2020 21:34:17 +0200 Message-ID: References: <87368npxw4.fsf@bernoul.li> <87v9ljo5d0.fsf@bernoul.li> <87ftcnxu5m.fsf@bernoul.li> <83y2qezlpd.fsf@gnu.org> <83tv12zjx1.fsf@gnu.org> <837dxyz83p.fsf@gnu.org> <978f970b-b5c2-bd83-39da-f632d069d7d5@yandex.ru> <98ab19cf-680b-9cd2-7c42-89dd0b2f470a@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000194af305a487285d" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="9625"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jonas Bernoulli , Emacs developers , Stefan Monnier , Adam Porter , Eli Zaretskii , Kyle Meyer To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 21:40:09 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 1jUF2W-0002Mt-NS for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 21:40:08 +0200 Original-Received: from localhost ([::1]:56958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUF2V-0003nV-Mk for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 15:40:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48114) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUEzw-0001nX-Jg for emacs-devel@gnu.org; Thu, 30 Apr 2020 15:38:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUEz8-0004Bz-4P for emacs-devel@gnu.org; Thu, 30 Apr 2020 15:37:28 -0400 Original-Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]:35456) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUExJ-0008QM-Tv; Thu, 30 Apr 2020 15:34:45 -0400 Original-Received: by mail-lj1-x22d.google.com with SMTP id g4so614373ljl.2; Thu, 30 Apr 2020 12:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AL2LLgXsrVJ/xDT7geMwqQaj9R0ICgZQFlPzmMSzElk=; b=cnFM9VDbaPPuZ/QbHOzrKdck34/ML33nd6qKX9NdEJ86ZXtWMJEexbxwcrX5HWA4kA liSu58lAJEvTTInUeNwkoeC/9WYsC5KrRJqihht94ZMXHao/m0yC2LCapkkaZ2auzXpJ uyHUZv8RRjr+OuU0NV78ev3FowmZgkF/8pKQpv4Jk6roa8Pl7Mp0jXXeUVADhMp1eWSB A/cvRO6CWpeHtOYyiQNbcog0jCkhU6Zr0TYmi9sz1VJ1ovErTrFndyVqtp5E1H0aslov clkYGHYprNu1G219sT2VNnptvw0Ael++6OHeirCpM6yXMd/pIysxCrBIZ3wbEJGJCddF ULDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AL2LLgXsrVJ/xDT7geMwqQaj9R0ICgZQFlPzmMSzElk=; b=ej/WWj7VNceC4K4yaHAy1K5Zt96U+KT3E5pwSalSDhKMzPT5A0VxSnbOLQa/MA+jz4 7mWwVlJGwGkB+nK+GqGjm4ev1f9nLQFVBjQTDvWWOUKAmjMauNGkBxUy+oUIB5ew2VTP /f+7Xqj1Axydk+AotFGcxo54t2WjM+asXH0ZrCvQQIHAuBj6o2Mo1aZvAJA8H70Y/CzD qk9MCBgo1MGW3sC6LIjstxvsECn42kSoILfSlYq0XNP/+TO2CpBoAxWOd4PAShaij0ak oW6V509CKajjbYuYxawesWE29zscs7ckHC+tXfRDzZ1z2vdJelJobDM+7bD2ndD1uNIO iWpA== X-Gm-Message-State: AGi0PuaKCMgzABxS5ap548IbWcw8HAsLf7OTGDAfGlyVj3QBcB7JlGjD qDuqNbx05e6B2sQw0CqBqR88o6POAzuSRHQQgUo= X-Google-Smtp-Source: APiQypKs61nqOV5HFO2ZeJkxYrgVIGYdvZKB4S7/Kji4sMxUwiX3pVhJgfUqXnvbmtFVT27CjjcUqJvT4OprxcHho7g= X-Received: by 2002:a05:651c:2011:: with SMTP id s17mr262820ljo.242.1588275283837; Thu, 30 Apr 2020 12:34:43 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::22d; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x22d.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::22d 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:248273 Archived-At: --000000000000194af305a487285d Content-Type: text/plain; charset="UTF-8" > > I haven't used dash/s/f much, but from what I see they do try to bring a >> more "flat" style of APIs, following the style of Clojure. There are a >> lot of utility functions in there too (like extra abstractions on top of >> the basics that the authors found to be useful). So when you ask the >> core library to be more like f.el, you'll have to specify what exactly >> you'd like to see changed: rename existing functions dealing with files >> to start with file-* or to add new ones. Then we can work out some sort >> of policy to adopt (or not) such changes. >> > > I think the crux of the issue regarding existing Emacs lisp would be > "should all file related apis start with file- ?" > > If we decide the answer is yes (as advised by the coding conventions) we > could start by simply aliasing the existing API that does not follow this > convention. That'd mean `copy-alist` would be aliased as `alist-copy`, do > you think people would be strongly against this? > I think I was not clear enough: - I propose to alias (not rename) existing functions dealing with files to start with file- - I propose to extend this to most emacs topics (except maybe the "touchy" ones) - I propose to extend some of these topics with functions that looks like good additions For example s.el contains a lot of IMHO obvious functions that emacs could include easily under a proper namespace that would probably not offend anyone. Philippe > --000000000000194af305a487285d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I haven't used dash/s/f much, but= from what I see they do try to bring a
more "flat" style of APIs, following the style of Clojure. There = are a
lot of utility functions in there too (like extra abstractions on top of the basics that the authors found to be useful). So when you ask the
core library to be more like f.el, you'll have to specify what exactly =
you'd like to see changed: rename existing functions dealing with files=
to start with file-* or to add new ones. Then we can work out some sort of policy to adopt (or not) such changes.

I think the crux of the issue regarding=C2=A0existing Emacs lisp would b= e "should all file related apis start with file- ?"
If we decide the answer is yes (as advised by the coding conven= tions) we could start by simply aliasing the existing API that does not fol= low this convention. That'd mean `copy-alist` would be aliased as `alis= t-copy`, do you think people would be strongly against this?

I think I was not clear enough:

- I propose to alias (not rename) existing functions deal= ing with files to start with file-
- I propose to extend this to = most emacs topics (except maybe the "touchy" ones)
- I = propose to extend some of these topics with functions that looks like good = additions

For example s.el contains a lot of IMHO = obvious functions that emacs could include easily under a proper namespace = that would probably not offend anyone.

Philippe
--000000000000194af305a487285d--