bug#81445: 30.2; Crash with Nonspacing Mark

Eli Zaretskii <[email protected]> Sat, 01 Aug 2026 12:41:26 +0300
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
> From: Stefan Monnier <[email protected]>
> Cc: [email protected],  [email protected]
> Date: Mon, 27 Jul 2026 09:41:00 -0400
> 
> >> - 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.

Fair enough, so I removed the condition.

> >> 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.  🙂

Thanks, so now installed on the master branch, and closing the bug.