From: Alan Mackenzie <acm@muc.de>
To: Philippe Vaucher <philippe.vaucher@gmail.com>
Cc: Yuan Fu <casouri@gmail.com>, Emacs developers <emacs-devel@gnu.org>
Subject: Re: Add some aliases for re-related functions
Date: Sat, 2 May 2020 21:09:12 +0000 [thread overview]
Message-ID: <20200502210912.GE6832@ACM> (raw)
In-Reply-To: <CAGK7Mr4W-mJUegaj5+UDzV1gHYQ19kUOFCWxjB=V1VvWWdtuYA@mail.gmail.com>
Hello, Philippe.
On Sat, May 02, 2020 at 22:10:29 +0200, Philippe Vaucher wrote:
> > On Sat, May 02, 2020 at 14:28:08 -0400, Yuan Fu wrote:
> > > While debating whether it’s effective to add prefixes to increase
> > > 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.
I don't think it does.
> 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.
In the current Emacs you can type in C-h f *posix<TAB> and one of the
alternatives (there are five) is posix-search-forward.
But just how important are such search facilities, really?
> 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.
See above. If anything, the number of different ways to search for
function names might be considered confusing, but that's a separate
matter.
> > 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 spend a fair amount of time debugging, other people's code as well as
my own. If these long aliases get mechanically swapped in (as I presume
is the intention), as well as having to decypher the new names, there
will be more occasions when a line of code no longer fits within my 78
character wide follow-mode screen. Hassle.
Debugging, which is already difficult enough, will get more difficult.
> I mean you agree they won't take away your ability to use the old names?
This old one! I disagree with you entirely, here. I debug other
people's code as well as my own. I'd have to put up with
"re-match-after-point" and friends, thus losing the ability to "use" the
current names.
And there's a good chance some "helpful" person will decide it's time to
purge the traditional names from all code, including my code.
Anyhow, why not look at existing examples from history?
On 1991-07-25, Jim Blandy introduced the alias `search-forward-regexp'
for `re-search-forward'. Why? Lost in the mists of time. Possibly for
the same reasons people are advancing now - make all the search functions
begin with "search-" for supposed easier searching (of their names). In
master we currently have 3534 occurences of re-search-forward and 134 of
search-forward-regexp. Would anybody here argue that Emacs is the better
for these 134 alternatively named function calls? I'd say it was a
mistake, and there is nothing positive to offset the confusion.
Or `delete-backward-char' and its alias `backward-delete-char'. We have,
respectively, 5 and 36 uses. To me, this is just confusion, whatever the
original reason was for these aliases.
I say we shouldn't add to such confusion.
> Philippe
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2020-05-02 21:09 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 18:28 Add some aliases for re-related functions Yuan Fu
2020-05-02 18:39 ` Eli Zaretskii
2020-05-02 18:43 ` Yuan Fu
2020-05-02 21:21 ` Stefan Monnier
2020-05-02 22:27 ` Drew Adams
2020-05-03 8:33 ` Michael Albinus
2020-05-03 19:07 ` Drew Adams
2020-05-02 19:29 ` Alan Mackenzie
2020-05-02 19:48 ` Yuan Fu
2020-05-02 20:10 ` Philippe Vaucher
2020-05-02 20:13 ` Philippe Vaucher
2020-05-03 14:16 ` Eli Zaretskii
2020-05-04 3:09 ` Richard Stallman
2020-05-04 14:28 ` Eli Zaretskii
2020-05-04 17:12 ` Dmitry Gutov
2020-05-04 17:35 ` Eli Zaretskii
2020-05-04 17:42 ` Dmitry Gutov
2020-05-04 17:46 ` Eli Zaretskii
2020-05-04 17:53 ` Dmitry Gutov
2020-05-02 21:09 ` Alan Mackenzie [this message]
2020-05-02 21:51 ` Philippe Vaucher
2020-05-03 9:43 ` Alan Mackenzie
2020-05-03 15:00 ` 조성빈
2020-05-02 22:41 ` Stefan Monnier
2020-05-03 17:14 ` Alan Mackenzie
2020-05-04 10:07 ` João Távora
2020-05-03 14:16 ` Eli Zaretskii
2020-05-03 16:20 ` Yuri Khan
2020-05-03 16:42 ` Eli Zaretskii
2020-05-03 16:50 ` Dmitry Gutov
2020-05-02 21:33 ` Stefan Monnier
2020-05-02 22:10 ` Dmitry Gutov
2020-05-02 22:18 ` Eric Abrahamsen
2020-05-02 22:49 ` Stefan Monnier
2020-05-02 23:13 ` Dmitry Gutov
2020-05-03 3:55 ` Stefan Monnier
2020-05-04 0:29 ` Dmitry Gutov
2020-05-04 3:11 ` Stefan Monnier
2020-05-02 22:44 ` Drew Adams
2020-05-03 3:26 ` Stefan Monnier
2020-05-03 4:37 ` Drew Adams
2020-05-03 8:05 ` Philippe Vaucher
2020-05-03 9:55 ` Alan Mackenzie
2020-05-03 10:26 ` tomas
2020-05-03 15:15 ` Eli Zaretskii
2020-05-03 19:47 ` Drew Adams
2020-05-04 7:32 ` Philippe Vaucher
2020-05-04 8:20 ` Sending plaintext with Gmail (was: Add some aliases for re-related functions) Kévin Le Gouguec
2020-05-04 8:45 ` Philippe Vaucher
2020-05-04 15:09 ` Sending plaintext with Gmail Stefan Monnier
2020-05-04 15:25 ` Kévin Le Gouguec
2020-05-04 15:29 ` Lars Ingebrigtsen
2020-05-05 8:13 ` HTML display in Gnus (was: Sending plaintext with Gmail) Kévin Le Gouguec
2020-05-05 8:24 ` HTML display in Gnus Lars Ingebrigtsen
2020-05-05 9:26 ` Kévin Le Gouguec
2020-07-17 17:14 ` Kévin Le Gouguec
2020-05-04 15:39 ` Sending plaintext with Gmail Andreas Schwab
2020-05-04 16:51 ` Add some aliases for re-related functions Drew Adams
2020-05-04 17:10 ` Drew Adams
2020-05-04 18:17 ` Philippe Vaucher
2020-05-04 18:33 ` Drew Adams
2020-05-05 2:48 ` Richard Stallman
2020-05-04 3:08 ` Richard Stallman
2020-05-04 10:16 ` João Távora
2020-05-04 3:04 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200502210912.GE6832@ACM \
--to=acm@muc.de \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=philippe.vaucher@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).