RE: Imports / inclusion of s.el into Emacs

[Drew Adams]

>> It can make [more] sense to adopt a prefix convention
>> for functions that define a type of thing (e.g. buffer,
>> window, vector, string) than it does to impose it
>> willy-nilly way on functions that might just return
>> such a thing or accept it as one of their args.
>
> Just to be clear, "type-grouping" you more or less see
> the point but "topic-grouping" (e.g regexp, string)
> not so much?

No.  I was distinguishing the definition of an
abstract data type, and the function definitions
needed for that, as a more focused kind of grouping
from grouping functions just by the type of an
argument or the return value.

In OOP, a function that merely uses an object in
a given class is often required to itself be a
method of that class.  That's not so for other
kinds of programming, and it's not so, in general,
for formal definition of ADTs.

>> Most functions do not fit that bill of defining a
>> thing type.  And many (most?) do not fit the bill
>> of acting only/mainly on one particular type of
>> thing or having as their main purpose to return
>> such a thing.
>>
>> That was really the point.  Perhaps there are some
>> cases in Elisp where it would make sense to prefix
>> more functions that involve a particular kind of
>> thing.  I've acknowledged that.  And others have
>> said the same thing, citing strings as a type that
>> might be looked at more in this regard.
>
> Okay, but I think we already agree on this?

Not so sure.  If so, good.

> I propose to alias/rename functions where it's
> "obvious", but as we saw that what is obvious for
> me is not obvious for everyone, so that's
> complicated.

Yes.  And I'm guessing that the more you think
about it, the more you might find that some of
what you thought was obvious is not quite so
straightforward.  Just a thought.

In some of what you wrote, you seemed to think
that your background of having worked with many
languages etc. made things obvious to you, and
that others might not have such a rich background
and so they don't see easily the light.

You might be surprised that some here also have
long and rich backgrounds with many languages.
That they might not agree with you - might not
see what you see as "obvious" - might not mean
what you think.

> I think we reached a point where everything
> proposed was rejected so this is a dead end.

I haven't seen a clear proposal.  And I don't
know that anything has been rejected.  The
discussion has been rather mixed and somewhat
unclear, IMO.

I don't think anyone has rejected the idea of
renaming some functions or aliases them to new
names.  The devil is in the details.

I suggested that any proposed name changes
(including aliases) be submitted (and tracked)
as bug/enhancement requests.

> > The corner cases for me are the relatively few
> > functions whose names cry out for labeling as
> > specific to some type, and I'd propose fixing
> > their names, case by case.
>
> The ones I proposed were all rejected :-/ Do you
> have one in mind?

No, not at the moment.

And I'm not aware that anything has been rejected.
If you submit them as a bug report (or bug reports,
if they're not very related) then it will be clear
if the bug gets fixed, stalls, or is closed as
won't fix.