* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.