Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...]

[Bozhidar Batsov]

On 30 November 2013 01:50, Drew Adams <address@hidden> wrote:

FWIW -

`helpers.el' is an *un*helpful file name.

It is bad enough that we already have a file `helper.el' in
the same directory.  Even for that file the name is not so
useful, but at least that is about providing "help in electric
modes".  (Something like `elec-help.el' would have been better.)

Yeah, ele-help would have been a better name.

 

Please consider coming up with something better than "helpers".

We were a bit short on ideas - the alternative were "one-liners", "misc-helpers", "misc-utils", etc. 

Suggestions for a better name are welcome.

 

Especially since `helpers.el' is purportedly "Some non-essential
library extensions."  Library extensions?  What library is
extended?  If not a library, what is extended by this code?

Assuming we can say we have a "string" library and a "hash" library, I'd say currently "helpers" have extensions for them.

 

Non-essential is right, however.  This file has 7 one-liner
defsubsts in it - nothing more.  Now maybe big things are
expected for this little file in the future, but even then I'd
suggest that, at least for now, these functions be put
somewhere else.

Stefan mentioned that we wants to move many *defsubst*s to a common library at some point. 

As far as I'm concerned I would have preferred to have the currently present functions in a place like `subr.el`, since I'm pretty sure of the usefulness

of those "non-essential" functions. 

 

Where to put such things, if not in a dedicated trifles bag?
Put similar things together (and not just similar by being tiny).

I guess we can have separate helper libs - something like *string-ext*, *hash-ext*, etc. 

This is fine by me.

 

And if the intention is to progressively pick up other such
functions from other files and toss them in `helpers.el', so
that it becomes a growing catch-all, then I'd recommend to
think twice about that project.

But if you really cannot do any better than create a grab bag,
then please at least give it a name that reflects that failure
and does not lead to more confusion.

I'd argue that several existing libraries exhibit the same problem (most notably - subr.el). Maybe we should try

harder to arrange related code together in the future.