bug#81445: 30.2; Crash with Nonspacing Mark

>> - Why test NILP (Vcoding_system_for_read)?
> Because if the caller (or user) has already bound
> `coding-system-for-read`, that binding may not be overridden.  This is
> the usual protocol of using these variables, since they are global.

That seems wrong in the present case: the external binding was clearly
not intended to apply to this `load` and we know for certain what coding
system we should use for this specific spot.

IOW if this call happens to take place within a piece of code that
happens to let-bind `coding-system-for-read` to `windows-1252` we're
back to the same bug.

>> So maybe a better option is to specbind
>> `Vload_source_file_function` to nil so we'd also avoid the overhead
>> of going through `load-with-code-conversion` for those files, where's
>> it's just a waste, AFAICT, and has a non-negligible performance impact.
>>
>> [ I'm also favorable to removing the `no-byte-compile:t` from those
>>   files unless the corresponding `.elc` is really worse.  ]
>
> I feel that the change I suggest above is more conservative and local,
> thus safer.

Your call, especially for `emacs-31`.  But for `master` I think we may
want to consider what is "best".  BTW, another take on it is that those
files should have extension `.elc`: it would solve this bug and would
also save us from needing the `no-byte-compile:t`.  They're (currently)
not generated by `bytecomp.el` but they are basically pre-compiled
(which is why we mark them as `no-byte-compile:t`).

> After all, this code has been working for us since at least Emacs 25,
> with no problems, until this semi-crazy use case came along.

"No problems" beside needlessly paying for the
`load-with-code-conversion` tax, of course.  🙂


=== Stefan


PS: I've had `Vload_source_file_function` set to nil for many years, but
had to give up on that optimization because of `read-symbol-shorthands`.