Re: Dynamic modules: emacs-module.c and signaling errors

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 26 Nov 2015 20:21:26 -0500
> 
> >> >> Because this loses the connection between the signal and its origin.
> >> > Not really, it doesn't.  You get the same Lisp error you'd get in
> >> > Emacs proper.
> >> That's only the signal, not its origin.  Its origin is lost.
> > Not sure what you mean by that.  The origin is clearly stated in the
> > error message.
> 
> You mean debug-on-error will properly show me the right stack state and
> let me look up and change the corresponding variables?

Up to the C level, yes.  You cannot do that once you get to the C
level, not with the Lisp debugger we have.

> Hmm... didn't think so.

Can you show some example of where some data is lost?  Because I think
we may be miscommunicating: I don't see that significant lost of data
that causes such strenuous objections.  Maybe you can explain that to
me.  Maybe something is indeed missing.

> >> >> Because it imposes a cost which we may not want to pay.
> >> > What cost is that?
> >> Catch and then rethrow.  Which is pure cost with no benefit, if you ask me.
> > A cost very close to zero.
> 
> Who cares.  Still pure cost with no benefit.

It's not without benefits.

> The core provides naturally a plain raw non-catching funcall, but with
> the current design a module author who wants this behavior can't have it

Why would a module author want a non-catching funcall?  Are the
reasons for having that strong enough to override the dangers?
Because there are other things a module author currently cannot do, as
the API offers only limited ways into Emacs.  Why would having a
non-catching funcall be so much more important than, say, being able
to add watchers to the Emacs event queue?

> This is completely dumb.

I'd appreciate if you refrained from name-calling.  It doesn't help
keep the discussion technical and constructive.

> > No one needs to do anything, the code is already written, and module
> > authors don't even need to know it exists, or what exactly does it do.
> 
> The criteria to accept bad design shouldn't be "does the code
> already exist?".

And whether it works, yes.  This is Free Software: whoever does the
job gets to choose the tools and the methods.  You know that.

> > It's not obvious to me, sorry.  The costs of the current code are
> > minimal, and the advantages to have the "raw" functionality in
> > addition to what we have aren't clear-cut.
> 
> As I said, we have plenty of experience in Emacs's own source code:
> look in Emacs's source code and compare the number of uses of
> "safe_call" and friends to the number of uses of "callN" and friends.
> The catching version is useful at times, but it's the exception rather
> than the rule.  XEmacs's experience is the same, apparently.

Modules aren't core Emacs, and weren't supposed to be it.  Not
everything that's possible in core _must_ be available to modules.
Modules aren't a way to extend Emacs in unlimited ways.  So just
saying this is possible in core is not a useful argument in this
discussion.  The important question here is: why is it important that
modules have this functionality at their disposal.