[Top][All Lists]

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

RE: [ELPA] New package: transient

From: Drew Adams
Subject: RE: [ELPA] New package: transient
Date: Sun, 3 May 2020 17:41:27 -0700 (PDT)

> > That's the rub/misunderstanding, I think.  That
> > namespaces are used does not imply that naming
> > need be based on object type.
> The propositions here aren't to group based on *types*.
> Please stop those strawman arguments, again.

Please stop claiming that I'm making strawman
arguments.  That's certainly not my intention.

The idea that functions (many, some, whatever)
should be prefixed by the name of a particular
kind of thing - whether file-name, string, regexp,...
is what I'm talking about, and I've understood
that to be what at least some others have been
talking about (proposing).

That's different from the general idea of grouping.
And it's different from the general idea of using
a name prefix (of arbitrary nature: thing-kind or
not).  And it's different from the idea of using a
library prefix - which Emacs already has and uses.
(Existing library prefixes, especially 3rd-party,
can be all over the map, from an author's initials
to who-knows-what.)

Now you say that it's not about grouping and
prefixing functions that are related to the same
kind of thing.

OK.  In that case, yes, I've misunderstood.  Not a
straw man, but a wrong idea of what's been suggested.

> E.g. the `re-<foo>` renaming is not about any rind of "regular
> expression type".  They're based on the same notions of namespacing
> used in modules/packages/younameit, which is also the namespacing used in
> Elisp packages, as a matter of fact, so it's really not a concept
> foreign to Elisp.

If all you've meant is a library prefix then there's
nothing new.  Except perhaps if you intend to move
existing functions around and put all those you want
to change into libraries, renamed with prefixes.
I certainly didn't understand that as what was being

If that's what you meant then is it your intention
that each such library would group only functions
for a particular kind of thing?  E.g. buffer-related
functions with prefix `buffer-' or `buf-' (e.g.)
in their own library, and so on for other kinds of
thing?  Or does it really have nothing to do with
grouping by thing-kind (and prefixing accordingly)?

I haven't seen a clear proposal, so perhaps you'll
forgive me for trying to guess what you and others
have meant, and guessing wrong (misunderstanding).

I've been under the impression that there's been a
suggestion, by some at least, to use a thing name
as the prefix.

And that can entail, for example, moving it to the
front from the middle of an existing name - e.g.
rename `multibyte-string-p` to `string-multibyte-p`,
to put `string' (the thing tested) first.

And I thought two of the arguments for that were
(1) consistency and (2) aid with completion (e.g.
many of the regexp functions with prefix `re-',
many of the string-related functions with prefix
`string-') - the latter point being that it can
help you find and access the functions concerned
with a given type/kind of thing.

If it's about a library prefix, is your idea to
have a library for regexp stuff, a library for
string stuff, etc., each with such a library prefix?

Frankly, what's proposed seems to be getting less
clear.   But maybe that's just me having difficulty
following.  You've said, regarding the string case,
that it's not about prefixing "string-manipulation"
functions, but it's been said to be about prefixing 
"string-related APIs".  Similarly, for regexps, I

I think I've made _my_ arguments clearly enough, so
perhaps I can stop here.  If they don't conflict
with what you want to do, great.  If they do, that's
OK too.  At this point I don't really know what you
want.  I guess I was mistaken before, in thinking I

In any case, believe me that I'm not trying to
misrepresent whatever it is that you're proposing,
as some straw-man argument to attack.  I thought I
was addressing what was being proposed.

reply via email to

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