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: Add some aliases for re-related functions Date: Sat, 2 May 2020 22:10:29 +0200 Message-ID: References: <7976B8C1-AFC7-4662-B750-6492EB70C0D5@gmail.com> <20200502192908.GD6832@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000037229905a4afe5e9" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="21604"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 22:11:29 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 1jUyTx-0005YV-0n for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 22:11:29 +0200 Original-Received: from localhost ([::1]:42544 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUyTw-0002gU-3A for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 16:11:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUyTS-00027x-8Y for emacs-devel@gnu.org; Sat, 02 May 2020 16:10:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUyTR-0002ib-L6 for emacs-devel@gnu.org; Sat, 02 May 2020 16:10:57 -0400 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:40408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUyTR-0002i9-7K for emacs-devel@gnu.org; Sat, 02 May 2020 16:10:57 -0400 Original-Received: by mail-lj1-x232.google.com with SMTP id y4so5775201ljn.7 for ; Sat, 02 May 2020 13:10:56 -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=w/Ls4YceXBWVYSxx+GrHsu5Q70PtEl+rKCu6fW0DMbg=; b=EY2kTQH8pSLu/LB23apNotyh0yzWwd6L+DM2HwvK00Z1e67Ht/WS8+ice4WWKqHgNI H7K+Qzrs8useDnNbu0EsMEvv8njcOTC4QSupad4YujE13BF/LlZvXrTOyHAuNrVZ/bQ8 9g7ysNJbhE1JGb39LCCsiENihfKDuxbUrJGpPoC1Ze9eB4OgB1w7dptBf1ujEfgODhAI LkvjDMaL5eN5kmhwEmPFE4nRxFuXQdFusSr8U0BLU13e40rK45oQz8L8jhJdK8UMVbpV u/yc/JI48zSdi8nxiz3vHuCk+Nd4yTe0uROubMFuPD0fHyreIy6oJTLsrHc7zffh59bS jS7Q== 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=w/Ls4YceXBWVYSxx+GrHsu5Q70PtEl+rKCu6fW0DMbg=; b=ELo4Fph7hy4daNmB1dsp9K5KW58Mzz2oEUKnR3+iF+YQUskPqig0oauurjNDNzrfqG HUdDng3oBBxj8cr+lRvGiYtmMKsyynhFNPrlcP1H6/pMWtg7WOIqXlvN8ZAM+9dg6ZI6 AQRb87oIkzuFiQMqwrS6Fwz0s5UdXEVnehIKxJlzCB/sR7exo4d799I8zBjouABf2TU3 DEreRmotw3U8O35QZXIkO+EkKyjiqFUZjK/L7MCxyqI4ZytnoqJ7OJUpOt2NVrRLMkMH n1eG38TCpFAlbhBe2Wt6ITVOZEPDiLUuIiAB96iv7/HlSTha8zbaigb/9NUkbIxXdIr/ xFeQ== X-Gm-Message-State: AGi0PuYGTV54BdPqJe4CvhH59+zQPQx92sk2/JatrgwMQ7zf7OiSGWLl Z4x/LiMWnguzdLUAYae4XX9nz7ilZbj7THWQyT0= X-Google-Smtp-Source: APiQypID6Jy0ZeiBp4lus4yD1EqxsH+a0PQ4gryc4iHl8HvAzZ3vgVv6l6tQfNhTRM+2J0T8huhLI6pA7Guj0ddjGFE= X-Received: by 2002:a2e:8999:: with SMTP id c25mr6030873lji.73.1588450255379; Sat, 02 May 2020 13:10:55 -0700 (PDT) In-Reply-To: <20200502192908.GD6832@ACM> Received-SPF: pass client-ip=2a00:1450:4864:20::232; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x232.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::232 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:248560 Archived-At: --00000000000037229905a4afe5e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote: > > While debating whether it=E2=80=99s effective to add prefixes to increa= se > > discoverability, lets start with incremental and uncontroversial > > changes. > > Ha! No chance! ;-( > > I don't believe these proposed changes will increase discoverability to > any important extent. More importantly, they will decrease the > usability of these functions, as they will be more of a hassle to type > in and (more importantly) make the functions they are in more difficult > to read. > Just wanted to explicit that this assume we know both function already. If I don't know `posix-search-forward` but know one exists, but cannot remember if it's regexp-search-posix-forward or posix-regexp-forward or forward-search-posix, in Yuan's proposal I could "C-h f re- TAB posix TAB and select "re-posix-search-forward" quickly. Without that I have to C-h d "regexp posix" and curse because it returns no result (Eli <--- please fix this), then search for C-h d posix and only then find it. > I strongly object to those aliases which make the function name longer. > I particularly object to `re-match-after-point' for `looking-at'. Not > only is it much longer, it lacks the instant readibility of looking-at, > and the slightly humorous notion of "looking", as though with ones eyes. > I particularly object to `re-matched-string', which has double the > number of syllables in it as the original. > Just to be clear, you don't like aliases because if they were to be used you'd hate reading code using them, correct? I mean you agree they won't take away your ability to use the old names? Philippe --00000000000037229905a4afe5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote: > While debating whether it=E2=80=99s effective to add prefixes to incre= ase
> discoverability, lets start with incremental and uncontroversial
> changes.

Ha!=C2=A0 No chance!=C2=A0 ;-(

I don't believe these proposed changes will increase discoverability to=
any important extent.=C2=A0 More importantly, they will decrease the
usability of these functions, as they will be more of a hassle to type
in and (more importantly) make the functions they are in more difficult
to read.

Just wanted to explicit that t= his assume we know both function already. If I don't know `posix-search= -forward` but know one exists, but cannot remember if it's regexp-searc= h-posix-forward=C2=A0or posix-regexp-forward or forward-search-posix, in Yu= an's proposal I could "C-h f re- TAB posix TAB and select "re= -posix-search-forward" quickly.

Without that = I have to C-h d "regexp posix" and curse because it returns no re= sult (Eli <--- please fix this), then search for C-h d posix and only th= en find it.

=C2=A0
I strongly object to those aliases which make the f= unction name longer.
I particularly object to `re-match-after-point' for `looking-at'.= =C2=A0 Not
only is it much longer, it lacks the instant readibility of looking-at,
and the slightly humorous notion of "looking", as though with one= s eyes.
I particularly object to `re-matched-string', which has double the
number of syllables in it as the original.

<= div>Just to be clear, you don't like aliases because if they were to be= used you'd hate reading code using them, correct?
I mean you= agree they won't take away your ability to use the old names?

Philippe
--00000000000037229905a4afe5e9--