diff options
| author | Michael Albinus <michael.albinus@gmx.de> | 2023-02-13 16:44:57 +0100 |
|---|---|---|
| committer | Michael Albinus <michael.albinus@gmx.de> | 2023-02-13 16:44:57 +0100 |
| commit | dd8b720ee74e72359eb174aa5a27ab1770a349bd (patch) | |
| tree | 7bdcd8132fa9e383b35d3cffaaa475d5f5004041 | |
| parent | 909bd04cf5fd42744ca5f1f34cb42b48b363ee62 (diff) | |
| download | emacs-dd8b720ee74e72359eb174aa5a27ab1770a349bd.tar.gz emacs-dd8b720ee74e72359eb174aa5a27ab1770a349bd.tar.bz2 emacs-dd8b720ee74e72359eb174aa5a27ab1770a349bd.zip | |
; * etc/NEWS: Fix typos.
| -rw-r--r-- | etc/NEWS | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -570,7 +570,7 @@ documented from day one; it just didn't behave according to documentation. It turns out some Lisp programs were using this coding-system on the wrong assumption that the "auto" part means some automagic handling of the end-of-line (EOL) format conversion; those -program will now start to fail, because BOM signature in UTF-8 encoded +programs will now start to fail, because BOM signature in UTF-8 encoded text is rarely expected. That is the reason we mention this bugfix here. @@ -618,7 +618,7 @@ and the major mode with 'M-x so-long-mode', or visit the file with In buffers in which these display optimizations are in effect, the 'fontification-functions', 'pre-command-hook' and 'post-command-hook' hooks are executed on a narrowed portion of the buffer, whose size is -controlled by the options 'long-line-optimizations-region-size' and +controlled by the variables 'long-line-optimizations-region-size' and 'long-line-optimizations-bol-search-limit', as if they were in a 'with-narrowing' form. This may, in particular, cause occasional mis-fontifications in these buffers. |