Re: Dynamic loading progress

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 1- Emacs calls some module code via the new API.
>> 2- This code (which is Emacs-specific) will know about Fthrow.
> Even if it knows about non-local jumps, in many cases it can't do anything
> about them except wrapping them.

There's nothing else none can ever do about them other than
wrapping them.  So the fact that they can only wrap them is not
a downside of some alternative.

> For example, longjmp is illegal in most C++ programs (and probably in
> most other languages as well).

Most Emacs modules will be written in C, methinks.  For those written in
other languages, since the API is expressed in C, they'll have to
accommodate the interaction with this C API, yes.

If they want to add a whole layer that wraps every function call in an
internal_condition_case, that's fine by me.

> The issue only requires that the plugin contains some code that is not
> suited for longjmp; e.g., all C++ code, no matter whether written
> specifically for Emacs or not.

That's a problem for the C++ code, not for Emacs's C-level module API.

> Partially yes. internal_condition_case with a Qt handler can indeed catch
> all signals, but this invocation is only possible from Emacs C code (using
> internal_condition_case),

Clearly, we'll want to export it to the modules as well.


        Stefan