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.