Re: master baf331e 3/3: Rename replace-in-string to string-replace

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Sat, 26 Sep 2020 18:25:02 -0400 (EDT), larsi@gnus.org (Lars Ingebrigtsen) said:

    Lars> branch: master
    Lars> commit baf331e40c08155082e255372d7cc3c9d63aa3c8
    Lars> Author: Lars Ingebrigtsen <larsi@gnus.org>
    Lars> Commit: Lars Ingebrigtsen <larsi@gnus.org>

    Lars>     Rename replace-in-string to string-replace
    
    Lars>     * doc/lispref/searching.texi (Search and Replace): Update.
    Lars>     * lisp/bindings.el (mode-line-position): Update callers.
    
    Lars>     * lisp/subr.el (string-replace): Rename from replace-in-string
    Lars>     since that clashes with XEmacs' replace-in-string which is
    Lars>     equivalent to the Emacs replace-regexp-in-string (bug#43598).

Do we need a (defalias 'string-replace-regexp
'replace-regexp-in-string)?

Robert

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Do we need a (defalias 'string-replace-regexp
> 'replace-regexp-in-string)?

I'm not very enthusiastic about adding noun-verb aliases for the
verb-noun functions we already have.  It makes reading code more
confusing when we have several names for the same thing.

Discoverability is an issue, though, and I'm working on that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Mon, 28 Sep 2020 13:14:49 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Do we need a (defalias 'string-replace-regexp
    >> 'replace-regexp-in-string)?

    Lars> I'm not very enthusiastic about adding noun-verb aliases for the
    Lars> verb-noun functions we already have.  It makes reading code more
    Lars> confusing when we have several names for the same thing.

I agree, but in this case anyone who finds 'string-replace' is going
to have a harder time finding 'replace-regexp-in-string'. The two
functions are twins, they should be easy to find from one another.

    Lars> Discoverability is an issue, though, and I'm working on that.

We can always stick cross-references in the respective docstring, but
people are still going to wonder about the irregular naming.

Robert
-- 

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

>  >> Do we need a (defalias 'string-replace-regexp
>  >> 'replace-regexp-in-string)?
> 
>  Lars> I'm not very enthusiastic about adding noun-verb aliases for the
>  Lars> verb-noun functions we already have.  It makes reading code more
>  Lars> confusing when we have several names for the same thing.
> 
> I agree, but in this case anyone who finds 'string-replace' is going
> to have a harder time finding 'replace-regexp-in-string'. The two
> functions are twins, they should be easy to find from one another.
> 
>  Lars> Discoverability is an issue, though, and I'm working on that.
> 
> We can always stick cross-references in the respective docstring, but
> people are still going to wonder about the irregular naming.


FWIW - two things to say here, one about the name
`string-replace' and one, more general, about naming.


1. `replace-in-string' is pretty self-explanatory,
certainly more so than `string-replace'.  The latter
makes you think that you're replacing one string with
another (which you are) - but where?  In a buffer? file?
the region?

`string-replace' suggests the same that `replace-string'
suggests.  And we already have `replace-string':
"Replace occurrences of FROM-STRING with TO-STRING."
Now we'll have `replace-string' and `string-replace'?
Is that progress?

IIUC, `replace-in-string' was rejected because of some
incompatibility with XEmacs (name clash?).  If so,
that's too bad, as replacing something within a string
is pretty clear from that name.  And as the something
isn't part in the name, it's pretty straightforward to
guess that it's a substring that's being replaced.

Both `replace-in-string' and `replace-regexp-in-string'
are pretty clear.  `string-replace' and
`string-replace-regexp' not so much.

Just sayin'.  I don't really have a great alternative
here.  (`replace-substring'? `replace-within-string'?
`replace-some-of-string'? `replace-string-substring'?)
If `replace-in-string' is off limits for some reason
then so be it - but too bad.


2. Discoverability is important, yes - very important.
But it's a mistake, IMO, to sacrifice more easily
understood names in favor of less easily understood
names, only because of easier discoverability by
_prefix completion_.  (Again, general argument here -
not about `string-replace'.)

Better to improve completion (use substring or regexp
or fuzzy or ... completion) so that the better names
are more easily discovered using completion.

_Apropos_ should be our guide for discoverability, not
prefix completion.  Our UI (especially completion)
should make it easy to discover a name by its
"components", in whatever order they might appear.

[I have a lot of experience with "apropos" completion,
including ways to match name components/substrings in
arbitrary order.  That's lacking in vanilla Emacs.]

We should not name things with discovery by prefix
completion foremost in mind.  That's a step backward.
If all other things are equal (rare), prefix-oriented
discovery can be nice to have - nothing more.

This point (#2) is not about _what can make_ a name
more understandable.  (There are lots of things to
consider for that.) 

And this point isn't an argument favoring noun-verb
or verb-noun.  This is only to favor understandable
names (however that's judged), and to deal with
discoverability separately, rather than elevating
prefix-completion discoverability as an important
criterion for naming.

And this point says nothing about the value of
naming _consistency_.  That's a different, but
related, topic.

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Mon, 28 Sep 2020 08:21:03 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:


    Drew> FWIW - two things to say here, one about the name
    Drew> `string-replace' and one, more general, about naming.


    Drew> 1. `replace-in-string' is pretty self-explanatory,
    Drew> certainly more so than `string-replace'.  The latter
    Drew> makes you think that you're replacing one string with
    Drew> another (which you are) - but where?  In a buffer? file?
    Drew> the region?

    Drew> `string-replace' suggests the same that `replace-string'
    Drew> suggests.  And we already have `replace-string':
    Drew> "Replace occurrences of FROM-STRING with TO-STRING."
    Drew> Now we'll have `replace-string' and `string-replace'?
    Drew> Is that progress?

    Drew> IIUC, `replace-in-string' was rejected because of some
    Drew> incompatibility with XEmacs (name clash?).  If so,
    Drew> that's too bad, as replacing something within a string
    Drew> is pretty clear from that name.  And as the something
    Drew> isn't part in the name, it's pretty straightforward to
    Drew> guess that it's a substring that's being replaced.

Yes, itʼs an unfortunate clash. Then again, how much XEmacs code still
exists that depends on it?

    Drew> Both `replace-in-string' and `replace-regexp-in-string'
    Drew> are pretty clear.  `string-replace' and
    Drew> `string-replace-regexp' not so much.

I agree with this. However it seems some people are used to
<datatype>-<operation> type naming, hence the long discussion about
prefixing functions. (I use helm, which doesnʼt care what order the
subwords are in, presumably ivy/company etc donʼt either).

    Drew> Just sayin'.  I don't really have a great alternative
    Drew> here.  (`replace-substring'? `replace-within-string'?
    Drew> `replace-some-of-string'? `replace-string-substring'?)
    Drew> If `replace-in-string' is off limits for some reason
    Drew> then so be it - but too bad.

I can offer: 'replace-string-in-string', which has the advantage of
being very regular with regard to 'replace-regexp-in-string' (and with
completion should not be very difficult to type).

Robert
-- 

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Mattias Engdegård]

28 sep. 2020 kl. 17.42 skrev Robert Pluim <rpluim@gmail.com>:

> Yes, itʼs an unfortunate clash. Then again, how much XEmacs code still
> exists that depends on it?

In the Emacs tree, prolog-mode used replace-in-string for regexp-matching replacement. This was taken as an indication that repurposing that name would have been risky.

The change of names may have been wise or unnecessarily prudent; I haven't found any other use of replace-in-string in the wild that isn't explicitly guarded by a test for XEmacs. Nevertheless, 'string-replace' isn't a bad name.

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[tomas]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Mon, Sep 28, 2020 at 05:42:38PM +0200, Robert Pluim wrote:

[...]

> I agree with this. However it seems some people are used to
> <datatype>-<operation> type naming [...]

Those have been brainwashed by single-dispatch OOPs and miss the
Delights of CLOS ;-P

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Stefan Monnier]

> Now we'll have `replace-string' and `string-replace'?

I don't care much which name we use, but I mist admit that I'm always
annoyed by `string-match` vs `match-string` so I'd be happy if we
avoided this snag for `replace-string' vs `string-replace'?


        Stefan

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

> > Now we'll have `replace-string' and `string-replace'?
> 
> I don't care much which name we use, but I mist admit that I'm always
> annoyed by `string-match` vs `match-string` so I'd be happy if we
> avoided this snag for `replace-string' vs `string-replace'?

+1.

There's a lot of name legacy in Emacs.  There's
certainly room for some crusader to go hog-wild
renaming things.  And then for another to come
along later and re-rename in some other direction.

As usual, we're better off considering any possible
renamings one case at a time.

Following any "Consistency Now!" pied-piping is
likely to lead to some buyer's remorse at some
point.  Not to mention a lot of time spent,
including by users trying to deal with such name
changes.

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Now we'll have `replace-string' and `string-replace'?
>
> I don't care much which name we use, but I mist admit that I'm always
> annoyed by `string-match` vs `match-string` so I'd be happy if we
> avoided this snag for `replace-string' vs `string-replace'?

That's true -- I often get string-match and match-string mixed up, so
perhaps we should have a different name for string-replace.

On the other hand, the reason string-match and match-string get mixed up
is that they are used in the same context.  replace-string and
string-replace are not.  So I'm not sure that pair is as bad as the
former pair.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Stefan Monnier]

> I'm not very enthusiastic about adding noun-verb aliases for the
> verb-noun functions we already have.  It makes reading code more
> confusing when we have several names for the same thing.
> Discoverability is an issue, though, and I'm working on that.

See the `prefixed-core` GNU ELPA package.


        Stefan

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm not very enthusiastic about adding noun-verb aliases for the
>> verb-noun functions we already have.  It makes reading code more
>> confusing when we have several names for the same thing.
>> Discoverability is an issue, though, and I'm working on that.
>
> See the `prefixed-core` GNU ELPA package.

That's what I was nonenthusiastically referring to.  I'm so sneaky.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Stefan Kangas]

Robert Pluim <rpluim@gmail.com> writes:

> Do we need a (defalias 'string-replace-regexp
> 'replace-regexp-in-string)?

Or (define-obsolete-function-alias 'replace-regexp-in-string
#'string-replace-regexp "28.1")

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Mon, 28 Sep 2020 16:56:28 +0200, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Robert Pluim <rpluim@gmail.com> writes:
    >> Do we need a (defalias 'string-replace-regexp
    >> 'replace-regexp-in-string)?

    Stefan> Or (define-obsolete-function-alias 'replace-regexp-in-string
    Stefan> #'string-replace-regexp "28.1")

Obsoleting such a commonly used function just because we have an
additional name for it would cause lots of needless warnings in
perfectly fine elisp. e.g., just because we have 'first' is not a
reason to declare 'car' obsolete.

Robert
-- 

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

> Stefan> Or (define-obsolete-function-alias 'replace-regexp-in-string
> Stefan> #'string-replace-regexp "28.1")
> 
> Obsoleting such a commonly used function just because we have an
> additional name for it would cause lots of needless warnings in
> perfectly fine elisp. e.g., just because we have 'first' is not a
> reason to declare 'car' obsolete.

Where's your modernism spirit, Robert?

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Mon, 28 Sep 2020 08:41:02 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:

    Stefan> Or (define-obsolete-function-alias 'replace-regexp-in-string
    Stefan> #'string-replace-regexp "28.1")
    >> 
    >> Obsoleting such a commonly used function just because we have an
    >> additional name for it would cause lots of needless warnings in
    >> perfectly fine elisp. e.g., just because we have 'first' is not a
    >> reason to declare 'car' obsolete.

    Drew> Where's your modernism spirit, Robert?

People who wish to have modernism in Emacs are welcome to add it, even
by default, as long as there's an 'enable cantankerous oldtimer mode'
variable.

Robert
-- 

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

> People who wish to have modernism in Emacs are welcome to add it, even
> by default, as long as there's an 'enable cantankerous oldtimer mode'
> variable.

Are we assuming an empty intersection of cantankerous
oldtimer and modernist? ;-)

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

> > Do we need a (defalias 'string-replace-regexp
> > 'replace-regexp-in-string)?
> 
> Or (define-obsolete-function-alias 'replace-regexp-in-string
> #'string-replace-regexp "28.1")

(define-obsolete-function-alias 'cons
#'conscell-construct "30.1")

(define-obsolete-function-alias 'append
#'string-vector-or-list-append-as-list "30.1")

(define-obsolete-function-alias 'setq
#'symbol-variable-value-set "30.1")

...


Bye-bye Lisp / bye-bye happiness / hello loneliness /
I think I'm gonna cry-y.

Bye-bye Lisp / bye-bye sweet caress / hello emptiness /
I feel like I could die-ie.

(Do I need a smily? ;-))

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Robert Pluim]

>>>>> On Mon, 28 Sep 2020 08:38:29 -0700 (PDT), Drew Adams <drew.adams@oracle.com> said:

    Drew> (define-obsolete-function-alias 'setq
    Drew> #'symbol-variable-value-set "30.1")

This is clearly unacceptable: youʼre denying the plurality of 'setq',
that should be

#'symbol-variable{s}-value{s}-set

Robert
-- 

RE: master baf331e 3/3: Rename replace-in-string to string-replace

[Drew Adams]

>     Drew> (define-obsolete-function-alias 'setq
>     Drew> #'symbol-variable-value-set "30.1")
> 
> This is clearly unacceptable: youʼre denying the plurality of 'setq',
> that should be
> 
> #'symbol-variable{s}-value{s}-set

Touché !

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Do we need a (defalias 'string-replace-regexp
>> 'replace-regexp-in-string)?
>
> Or (define-obsolete-function-alias 'replace-regexp-in-string
> #'string-replace-regexp "28.1")

I sympathise with the impulse, because `replace-regexp-in-string' is
probably the most awkward of the commonly used function names, in my
extremely, super-duper, incredibly humble opinion (nobody has humbler
opinions than I do, everybody knows that).

But I don't think the churn would be worth it.  (And shouldn't it be
`re-replace'?  `regexp-replace-string'?  Let the bikeshedding commence!)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master baf331e 3/3: Rename replace-in-string to string-replace

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > Or (define-obsolete-function-alias 'replace-regexp-in-string
> > #'string-replace-regexp "28.1")
>
> I sympathise with the impulse, because `replace-regexp-in-string' is
> probably the most awkward of the commonly used function names, in my
> extremely, super-duper, incredibly humble opinion (nobody has humbler
> opinions than I do, everybody knows that).
>
> But I don't think the churn would be worth it.

Yeah, that's true.  The suggestion is probably a bit too enthusiastic.