all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* policy regarding DEFUNs in subr-x.el
@ 2020-03-22 15:46 Štěpán Němec
  2020-03-22 17:12 ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Štěpán Němec @ 2020-03-22 15:46 UTC (permalink / raw)
  To: emacs-devel

When fixing bug#39980 [1], it seemed best to me to move a string utility
function to subr-x. Given the file's commentary (notably "NB If you want
to use this library, it's almost always correct to use:
(eval-when-compile (require 'subr-x))") and the fact that with a single
outlier of `replace-region-contents', everything in that file is either
inline functions or macros, I turned the added function into defsubst,
which seems to have raised Lars's eyebrows, and Eli's, probably, too.

Now, it does seem sensible for the function to be a normal, not inline,
function, but what about the commentary and all the other defsubsts,
including the other string utilities?

If the no-defun policy should be changed, or if I was mistaken in
believing there was one to begin with, shouldn't the commentary
recommending compile-time usage be removed, and at least some of the
other defsubsts turned into defuns, too?

Any clarification would be much appreciated.

[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-03/msg00643.html

-- 
Štěpán



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-22 15:46 policy regarding DEFUNs in subr-x.el Štěpán Němec
@ 2020-03-22 17:12 ` Eli Zaretskii
  2020-03-22 20:38   ` Tassilo Horn
  2020-03-28 14:20   ` Štěpán Němec
  0 siblings, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-22 17:12 UTC (permalink / raw)
  To: Štěpán Němec; +Cc: emacs-devel

> From: Štěpán Němec <stepnem@gmail.com>
> Date: Sun, 22 Mar 2020 16:46:36 +0100
> 
> Now, it does seem sensible for the function to be a normal, not inline,
> function, but what about the commentary and all the other defsubsts,
> including the other string utilities?
> 
> If the no-defun policy should be changed, or if I was mistaken in
> believing there was one to begin with, shouldn't the commentary
> recommending compile-time usage be removed, and at least some of the
> other defsubsts turned into defuns, too?

I don't see that the commentary says the code in this file must be
inline.  If something in the wording implies that, let's change the
wording so that it doesn't.

From my POV, there's no reason to require that everything in that file
is inlined, and that single "outlier" is the evidence.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-22 17:12 ` Eli Zaretskii
@ 2020-03-22 20:38   ` Tassilo Horn
  2020-03-28 14:20   ` Štěpán Němec
  1 sibling, 0 replies; 10+ messages in thread
From: Tassilo Horn @ 2020-03-22 20:38 UTC (permalink / raw)
  To: emacs-devel

Didn't we decide that replace-region-contents is to be moved to replace.el? Sorry, I didn't follow that past discussion/patch closely but from my pov that would make sense, and given that this function is new in emacs 27, now is the best time doing so.

Bye,
Tassilo

Am So, 22. Mär 2020, um 18:12, schrieb Eli Zaretskii:
> > From: Štěpán Němec <stepnem@gmail.com>
> > Date: Sun, 22 Mar 2020 16:46:36 +0100
> > 
> > Now, it does seem sensible for the function to be a normal, not inline,
> > function, but what about the commentary and all the other defsubsts,
> > including the other string utilities?
> > 
> > If the no-defun policy should be changed, or if I was mistaken in
> > believing there was one to begin with, shouldn't the commentary
> > recommending compile-time usage be removed, and at least some of the
> > other defsubsts turned into defuns, too?
> 
> I don't see that the commentary says the code in this file must be
> inline.  If something in the wording implies that, let's change the
> wording so that it doesn't.
> 
> From my POV, there's no reason to require that everything in that file
> is inlined, and that single "outlier" is the evidence.
> 
> 
>



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-22 17:12 ` Eli Zaretskii
  2020-03-22 20:38   ` Tassilo Horn
@ 2020-03-28 14:20   ` Štěpán Němec
  2020-03-28 14:35     ` Eli Zaretskii
  1 sibling, 1 reply; 10+ messages in thread
From: Štěpán Němec @ 2020-03-28 14:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On Sun, 22 Mar 2020 19:12:43 +0200
Eli Zaretskii wrote:

>> If the no-defun policy should be changed, or if I was mistaken in
>> believing there was one to begin with, shouldn't the commentary
>> recommending compile-time usage be removed, and at least some of the
>> other defsubsts turned into defuns, too?
>
> I don't see that the commentary says the code in this file must be
> inline.  If something in the wording implies that, let's change the
> wording so that it doesn't.

Thank you. In that case I suggest we remove the NB sentence, as IMO it
adds more confusion than useful information.

-- 
Štěpán



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 14:20   ` Štěpán Němec
@ 2020-03-28 14:35     ` Eli Zaretskii
  2020-03-28 14:47       ` Štěpán Němec
  0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-28 14:35 UTC (permalink / raw)
  To: Štěpán Němec; +Cc: emacs-devel

> From: Štěpán Němec <stepnem@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 28 Mar 2020 15:20:52 +0100
> 
> > I don't see that the commentary says the code in this file must be
> > inline.  If something in the wording implies that, let's change the
> > wording so that it doesn't.
> 
> Thank you. In that case I suggest we remove the NB sentence, as IMO it
> adds more confusion than useful information.

How about if instead of removing, we reword it so that it only talks
about the macros in the file?



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 14:35     ` Eli Zaretskii
@ 2020-03-28 14:47       ` Štěpán Němec
  2020-03-28 14:50         ` Štěpán Němec
  2020-03-28 15:04         ` Eli Zaretskii
  0 siblings, 2 replies; 10+ messages in thread
From: Štěpán Němec @ 2020-03-28 14:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On Sat, 28 Mar 2020 17:35:39 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 28 Mar 2020 15:20:52 +0100
>> 
>> > I don't see that the commentary says the code in this file must be
>> > inline.  If something in the wording implies that, let's change the
>> > wording so that it doesn't.
>> 
>> Thank you. In that case I suggest we remove the NB sentence, as IMO it
>> adds more confusion than useful information.
>
> How about if instead of removing, we reword it so that it only talks
> about the macros in the file?

IMHO that would still beg the question "what's so special about this
library that they're talking about this?", thus if not confusion, at
least still a distraction. I don't think the fact that you can `require'
libraries at compile time only (i.e. wrapped in `eval-when-compile'), as
long as you only use macros or inline functions from those libraries,
needs special mention?

-- 
Štěpán



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 14:47       ` Štěpán Němec
@ 2020-03-28 14:50         ` Štěpán Němec
  2020-03-28 15:04         ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Štěpán Němec @ 2020-03-28 14:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On Sat, 28 Mar 2020 15:47:11 +0100
Štěpán Němec wrote:

>> How about if instead of removing, we reword it so that it only talks
>> about the macros in the file?
>
> IMHO that would still beg the question "what's so special about this
> library that they're talking about this?", thus if not confusion, at
> least still a distraction. I don't think the fact that you can `require'
> libraries at compile time only (i.e. wrapped in `eval-when-compile'), as
> long as you only use macros or inline functions from those libraries,
> needs special mention?
        ^^^^^^^^^^^^^^^

(Just to be completely clear: I meant special mention in every file
concerned. I believe it _is_ mentioned in the manuals.)

-- 
Štěpán



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 14:47       ` Štěpán Němec
  2020-03-28 14:50         ` Štěpán Němec
@ 2020-03-28 15:04         ` Eli Zaretskii
  2020-03-28 15:31           ` Štěpán Němec
  1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-28 15:04 UTC (permalink / raw)
  To: Štěpán Němec; +Cc: emacs-devel

> From: Štěpán Němec <stepnem@gmail.com>
> Date: Sat, 28 Mar 2020 15:47:11 +0100
> Cc: emacs-devel@gnu.org
> 
> > How about if instead of removing, we reword it so that it only talks
> > about the macros in the file?
> 
> IMHO that would still beg the question "what's so special about this
> library that they're talking about this?"

It's "special" of sorts, in that it's mostly macros.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 15:04         ` Eli Zaretskii
@ 2020-03-28 15:31           ` Štěpán Němec
  2020-03-28 15:45             ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Štěpán Němec @ 2020-03-28 15:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

On Sat, 28 Mar 2020 18:04:40 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@gmail.com>
>> Date: Sat, 28 Mar 2020 15:47:11 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> > How about if instead of removing, we reword it so that it only talks
>> > about the macros in the file?
>> 
>> IMHO that would still beg the question "what's so special about this
>> library that they're talking about this?"
>
> It's "special" of sorts, in that it's mostly macros.

:-D Yes, but not only macros, so you'd have to say something like "if
you only need macros (and inline functions) from this library (and
byte-compile your code), you can do (eval-when-compile ...)", which
could be said about a lot of other libraries as well.

But yes, it would at least be less confusing than the current wording,
so if you don't want to remove the note, it would be an improvement I
think.

-- 
Štěpán



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: policy regarding DEFUNs in subr-x.el
  2020-03-28 15:31           ` Štěpán Němec
@ 2020-03-28 15:45             ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-03-28 15:45 UTC (permalink / raw)
  To: Štěpán Němec; +Cc: emacs-devel

> From: Štěpán Němec <stepnem@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 28 Mar 2020 16:31:12 +0100
> 
> But yes, it would at least be less confusing than the current wording,
> so if you don't want to remove the note, it would be an improvement I
> think.

Thanks, let's see what others think about this.



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-03-28 15:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-22 15:46 policy regarding DEFUNs in subr-x.el Štěpán Němec
2020-03-22 17:12 ` Eli Zaretskii
2020-03-22 20:38   ` Tassilo Horn
2020-03-28 14:20   ` Štěpán Němec
2020-03-28 14:35     ` Eli Zaretskii
2020-03-28 14:47       ` Štěpán Němec
2020-03-28 14:50         ` Štěpán Němec
2020-03-28 15:04         ` Eli Zaretskii
2020-03-28 15:31           ` Štěpán Němec
2020-03-28 15:45             ` Eli Zaretskii

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.