[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add some aliases for re-related functions

From: Alan Mackenzie
Subject: Re: Add some aliases for re-related functions
Date: Sat, 2 May 2020 21:09:12 +0000

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

> > 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]