bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> >> To force the .elc to be loaded one has to bind `load-no-native' to
>> >> non-nil.
>> >
>> > I think if load-file is invoked interactively, and the user actually
>> > types "foo.elc", we need to bind load-no-native non-nil
>> > automatically.  Otherwise users would be surprised, as it goes against
>> > the logic of what we do when the user types "foo.el".
>> 
>> We certanly can do this if this is what we want.  This breaks a little
>> the idea to have the system as much transparent as possible, I went this
>> way cause this was my understanding of what we wanted but I've no strong
>> feeling with that.
>
> I don't think this will break the transparent operation, because
> loading a package non-interactively (as in when the corresponding
> feature is 'require'd by some code) will still load the .eln file.
> Only the following 2 use cases will be affected:
>
>   M-x load-file RET /path/to/FOO.elc RET
>   M-x load-library RET FOO.elc RET
>
> IOW, when the user loads the file/library interactively, and
> explicitly uses the .elc extension, we load the file the user
> specified, not the corresponding .eln file.

Hi Eli,

I've a patch that works modifying `load' to prevent native code being
loaded when a file with .elc suffix is explicitly presented as argument.

I was going to post it but re-reading your message I now wanted to ask:
do we want to act at `load' level or at `load-file' + `load-library'
level?

TIA

  Andrea