From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Tue, 5 May 2020 20:41:53 +0100 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b4c04c05a4ebd7ca" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="84206"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Emacs developers , =?UTF-8?B?7KGw7ISx67mI?= , Dmitry Gutov , Eli Zaretskii , Drew Adams To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 21:42:45 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 1jW3Sm-000Lpv-Kp for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 21:42:44 +0200 Original-Received: from localhost ([::1]:38328 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jW3Sl-0004Zq-Lm for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 15:42:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37668) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jW3SD-00042g-Tf for emacs-devel@gnu.org; Tue, 05 May 2020 15:42:09 -0400 Original-Received: from mail-il1-x144.google.com ([2607:f8b0:4864:20::144]:35499) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jW3SC-0002gM-SU; Tue, 05 May 2020 15:42:09 -0400 Original-Received: by mail-il1-x144.google.com with SMTP id b18so3468744ilf.2; Tue, 05 May 2020 12:42:07 -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=nm2zElBehs4o84bmw7Ukba6YaeFksvg1WlF/pQ/0NXU=; b=ZXXqyQuBBDzOTkRXY/f4TPikJ50fHPU3IWVJHtlx4Heh5g1fv7LPY9yfNFsBOKKWy1 uefG5bSDvMd0xSSkc9rzDEIroqZ1s0jvT9KkfvMzs/xjYdYjoWYJZPVxqQFy8uZ3sb1E H7v7llpPwAFNJgSE+mYpOgc+rawErqlae4wZShvGrtGSkQCAzi4cKhoOTmSTLFJzvJmr 6ArqT1KIA1ijdDoNNOYT9gyxF+e+EnYIqFsaQkNlgojDMMn312ksrNN+Z7WdBWCeo12Y Trd2KpBBflSisg3Mc/i2KsBL32hMNeobhi7Dz4PodpZJ5HakPrn7jd4mCopm9/W9ORqS SFNQ== 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=nm2zElBehs4o84bmw7Ukba6YaeFksvg1WlF/pQ/0NXU=; b=PxE5SYScvx0zLl6399u0dwFjgW8EdOSrQ+XWiBESYCDbRnqvV+To/3LxSdUhDt7sRv aWaMEQQp1pGRznkl6HMl12/z+AUF6SnmOz1a0Muld23IlV63YuSJlOtHc7keaMnN9USP N9MCRCGWZ4cJGTgCIfBeRwCYHYULMwNCvRiQWds34Bfle0oF2srlzhvsrEr0UBhftkaV fCwhpf19zlpgqLRsEjSfCYx3dlF1lq9auu7VdAfhgBPeNd0vlngPz6hz5r/EMiXBAgJG x5do8mkI6X32PuOTutx9KWq5xl+Rs25QnUMcrn0OpOLgRtho7m82i7oQJqFe9um0MxSH lISw== X-Gm-Message-State: AGi0PuY9wZ/nzmMRX+NR/HBvmTgbf46AcnbJo/UU41/ZDo2eCYL557Fy k9eQ1RUwka/MOrMyaRhQAyijSPqd+yKH0xHgGKU= X-Google-Smtp-Source: APiQypKRGXfEI9T03YpXZXyqYgply/0lMg/iun/NbQYXvQrvLCyhmjLXJnnmqdZyHo+ZYLtqQHvR3EAVaHSjH7vOGno= X-Received: by 2002:a92:7e86:: with SMTP id q6mr5543023ill.9.1588707726768; Tue, 05 May 2020 12:42:06 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::144; envelope-from=joaotavora@gmail.com; helo=mail-il1-x144.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:249027 Archived-At: --000000000000b4c04c05a4ebd7ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2020 at 8:29 PM Stefan Monnier wrote: > But it could be in a destructive rather than constructive way: having > a separate "ELISP" package would reduce the impetus to impose a good > naming structure within this package, which is what this thread is > all about. You can split it up, slowly. Or quickly if you pick a namespacing technique that is backward compatible with the current naming scheme. Tom Tromey's idea sounds nice, and it could be enhanced, IMO. Let's at least admit that if namespaces were here right now it would be No Bad Thing. The s.el request that started this whole thing would be trivially attended to, at least. > > Jo=C3=A3o "who instantly regrets mentioning the manual cause I just = say > > unibyte-string there, too" > > Yup: `multybyte-string-p` is not even mentioned in the manual. multybyte-string-p isn't :-) , but multibyte-string-p is: in (elisp) Text Representations -- Function: multibyte-string-p string Return =E2=80=98t=E2=80=99 if STRING is a multibyte string, =E2=80=98n= il=E2=80=99 otherwise. This function also returns =E2=80=98nil=E2=80=99 if STRING is some object o= ther than a string. But OK. I've already said this one wouldn't bother me. It's just I've seen big lists (10-20 long) of renames/aliases and those new names would burden my mental namespace -- and my completion-based discovery techniques (and Eli's C-h a techniques, to a lesser degree). --000000000000b4c04c05a4ebd7ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2020 at 8:29 PM Stefan Monnier <monnier@iro.umontreal.ca> w= rote:

> But it could be in a destructive rather= than constructive way: having
> a separate "ELISP" package= would reduce the impetus to impose a good
> naming structure within = this package, which is what this thread is
> all about.

=
You can split it up, slowly. Or quickly if yo= u pick a namespacing
techniq= ue that is backward compatible with the current naming
scheme. Tom Tromey's idea sounds nice, and i= t could be
enhanced, IMO.=C2= =A0 Let's at least admit that if namespaces were here
=
right now it would be No Bad Thing. The s.el = request that started
this whole t= hing would be trivially attended to, at least.

> > =C2=A0 =C2=A0Jo=C3=A3o "who i= nstantly regrets mentioning the manual cause I just say
> > unibyt= e-string there, too"
>
> Yup: `multybyte-string-p` is not = even mentioned in the manual.

multybyte-string-p isn't :-) = , but multibyte-string-p is:

in (elisp) Text Repre= sentations

=C2=A0-- Function: multibyte-string-p string=
=C2=A0 =C2=A0 =C2=A0Return =E2=80=98t=E2=80=99 if STRING is a multibyte= string, =E2=80=98nil=E2=80=99 otherwise.=C2=A0 This
=C2=A0 =C2=A0 =C2= =A0function also returns =E2=80=98nil=E2=80=99 if STRING is some object oth= er than a
=C2=A0 =C2=A0 =C2=A0string.

But = OK. I've already said this one wouldn't bother me. It's just I&= #39;ve
seen big lists (10-20 long) of renames/aliases and th= ose new names
would burden my mental namespace -- and my com= pletion-based
discovery techniques (and Eli's C-h a tech= niques, to a lesser degree).
--000000000000b4c04c05a4ebd7ca--