* Re: [Emacs-diffs] trunk r115287: * lisp/emacs-lisp/helpers.el (string-empty-p): New function.
[not found] <E1VmRIu-00084e-Mh@vcs.savannah.gnu.org>
@ 2013-11-29 18:23 ` Stefan Monnier
2013-11-29 21:29 ` Bozhidar Batsov
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2013-11-29 18:23 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: emacs-devel
> + (string= string ""))
I think `equal' is preferable since it avoids signaling an error if
STRING is not a string.
> +(defsubst string-blank-p (string)
> + "Check whether STRING is either empty or only whitespace."
> + (string-empty-p (string-trim string)))
Better use (string-match-p "\\`...\\'" string) to avoid allocating a new
string.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Emacs-diffs] trunk r115287: * lisp/emacs-lisp/helpers.el (string-empty-p): New function.
2013-11-29 18:23 ` [Emacs-diffs] trunk r115287: * lisp/emacs-lisp/helpers.el (string-empty-p): New function Stefan Monnier
@ 2013-11-29 21:29 ` Bozhidar Batsov
2013-11-29 23:50 ` helpers.el [was: ... lisp/emacs-lisp/helpers.el...] Drew Adams
0 siblings, 1 reply; 6+ messages in thread
From: Bozhidar Batsov @ 2013-11-29 21:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On 29 November 2013 20:23, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > + (string= string ""))
>
> I think `equal' is preferable since it avoids signaling an error if
> STRING is not a string.
>
Not sure about that. After all, this function is meant to be used with a
STRING argument. On the other hand using `equal' will make it play better
with nil.
>
> > +(defsubst string-blank-p (string)
> > + "Check whether STRING is either empty or only whitespace."
> > + (string-empty-p (string-trim string)))
>
> Better use (string-match-p "\\`...\\'" string) to avoid allocating a new
> string.
>
You're right. I'll change this.
>
>
> Stefan
>
[-- Attachment #2: Type: text/html, Size: 1435 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* helpers.el [was: ... lisp/emacs-lisp/helpers.el...]
2013-11-29 21:29 ` Bozhidar Batsov
@ 2013-11-29 23:50 ` Drew Adams
2013-11-30 7:41 ` Bozhidar Batsov
2013-11-30 8:07 ` Jambunathan K
0 siblings, 2 replies; 6+ messages in thread
From: Drew Adams @ 2013-11-29 23:50 UTC (permalink / raw)
To: Bozhidar Batsov, Stefan Monnier; +Cc: emacs-devel
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.)
Please consider coming up with something better than "helpers".
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?
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.
Where to put such things, if not in a dedicated trifles bag?
Put similar things together (and not just similar by being tiny).
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...]
2013-11-29 23:50 ` helpers.el [was: ... lisp/emacs-lisp/helpers.el...] Drew Adams
@ 2013-11-30 7:41 ` Bozhidar Batsov
2013-11-30 8:07 ` Jambunathan K
1 sibling, 0 replies; 6+ messages in thread
From: Bozhidar Batsov @ 2013-11-30 7:41 UTC (permalink / raw)
To: Drew Adams; +Cc: Stefan Monnier, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
On 30 November 2013 01:50, Drew Adams <drew.adams@oracle.com> 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.
[-- Attachment #2: Type: text/html, Size: 3774 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...]
2013-11-29 23:50 ` helpers.el [was: ... lisp/emacs-lisp/helpers.el...] Drew Adams
2013-11-30 7:41 ` Bozhidar Batsov
@ 2013-11-30 8:07 ` Jambunathan K
2013-12-04 15:55 ` Ted Zlatanov
1 sibling, 1 reply; 6+ messages in thread
From: Jambunathan K @ 2013-11-30 8:07 UTC (permalink / raw)
To: Drew Adams; +Cc: Stefan Monnier, Bozhidar Batsov, emacs-devel
Drew Adams <drew.adams@oracle.com> writes:
> `helpers.el' is an *un*helpful file name.
I thought of GNU ELPA (also as) a waiting-room or a staging area.
----------------------------------------------------------------
Folks,
What we need is a meaning-less name - in corporate-speak a code-name, a
release name. We shouldn't allow questions like "What goes here and
what doesn't go here?" to arise.
Get creative.
Dig in to mythology, folklore, sci-fi or resort to just plain absuridty.
Call it
- absurd
- bazaar (flea market)
- confused
- hairball
- hammock
- inbox
- memo
- mystic
- noodle
- pandora
- piggy (bank)
- rug
- sack
- sandbox
- spaghetti
- just base64 encode your favorite star's name
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...]
2013-11-30 8:07 ` Jambunathan K
@ 2013-12-04 15:55 ` Ted Zlatanov
0 siblings, 0 replies; 6+ messages in thread
From: Ted Zlatanov @ 2013-12-04 15:55 UTC (permalink / raw)
To: emacs-devel
On Sat, 30 Nov 2013 13:37:02 +0530 Jambunathan K <kjambunathan@gmail.com> wrote:
JK> Folks,
JK> What we need is a meaning-less name - in corporate-speak a code-name, a
JK> release name. We shouldn't allow questions like "What goes here and
JK> what doesn't go here?" to arise.
JK> Get creative.
JK> Dig in to mythology, folklore, sci-fi or resort to just plain absuridty.
JK> Call it
JK> - absurd
JK> - bazaar (flea market)
JK> - confused
JK> - hairball
JK> - hammock
JK> - inbox
JK> - memo
JK> - mystic
JK> - noodle
JK> - pandora
JK> - piggy (bank)
JK> - rug
JK> - sack
JK> - sandbox
JK> - spaghetti
JK> - just base64 encode your favorite star's name
Thank you for the suggestion. Unfortunately it is terrible.
Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-04 15:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1VmRIu-00084e-Mh@vcs.savannah.gnu.org>
2013-11-29 18:23 ` [Emacs-diffs] trunk r115287: * lisp/emacs-lisp/helpers.el (string-empty-p): New function Stefan Monnier
2013-11-29 21:29 ` Bozhidar Batsov
2013-11-29 23:50 ` helpers.el [was: ... lisp/emacs-lisp/helpers.el...] Drew Adams
2013-11-30 7:41 ` Bozhidar Batsov
2013-11-30 8:07 ` Jambunathan K
2013-12-04 15:55 ` Ted Zlatanov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).