branch: elpa/logview
commit 93111330013bad83e2d108c422cd349f1caae466
Author: Paul Pogonyshev <pogonys...@gmail.com>
Commit: Paul Pogonyshev <pogonys...@gmail.com>
Update README section from commit c06cdb2 with the latest changes.
---
README.adoc | 45 +++++++++++++++++++++------------------------
logview.el | 1 -
2 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/README.adoc b/README.adoc
index e16e047c15..a9ef0c5e0c 100644
--- a/README.adoc
+++ b/README.adoc
@@ -522,29 +522,26 @@ changed in each individual buffer.
Emacs 29 (in development) has introduced locked narrowing as a way to
improve performance. At the same time, it broke compatibility by
making function `widen` not always do what packages would expect from
-it. This caused Logview, in particular, fail unpredictably, up to
-causing a full freeze in Emacs (where even `C-g` does nothing) from
-its fontification code.
-
-Locked narrowing restrictions currently cannot be lifted. It is
-extremely difficult to adapt Logview to `widen` not widening as it has
-always does. Therefore, Logview currently tries to _disable long-line
-optimizations in its buffers_. I don’t know if it will always succeed
-or not; if it does not, Logview will now fail hard before causing more
-problems.
-
-If you experience problems with Logview still not being able to
-disable long-line optimization and, therefore, not working at all, you
-can add the following to your Emacs initialization code:
-
- (setf long-line-threshold nil)
-
-Note that this will disable long-line optimization *everywhere*,
-though. It’s up to you to decide whether that is more important than
-having Logview or not; as said, this is an emergency setting only,
-_probably_ Logview should work regardless.
+it.
+
+It is extremely difficult to adapt Logview to `widen` not widening as
+it has always does. Or likely even impossible without completely
+redesigning the mode, sacrificing lazy filtering in the process.
+
+Locked narrowing restrictions can be lifted, but for this you need to
+know the “tag” used to install them. There is no way to find the tag
+(unless you have locked with it yourself and thus just know), but at
+least Emacs itself uses only a few hardcoded tags. Logview tries to
+unlock all of those. However, if restrictions are still locked after
+that, Logview will fail before causing more (and unpredictable)
+problems: e.g. previously it could even cause a full freeze in Emacs
+(where even `C-g` does nothing) from its fontification code.
+
+Normally, such errors should not happen now, but if they do then
+either Emacs invented yet another place where it has to
+[line-through]#break everything# lock restrictions, or this has made
+it into some minor mode you use (they made function `narrowing-lock`
+public for everyone to try and break other code).
I have tried arguing with Emacs developers about this, but that is
-pointless, as I have found on this and several other occasions. The
-only positive thing I got from it is that locked narrowing will become
-liftable in fontification code at least. Somewhen.
+pointless, as I have found on this and several other occasions.
diff --git a/logview.el b/logview.el
index e5f422db1a..feb09d40bc 100644
--- a/logview.el
+++ b/logview.el
@@ -907,7 +907,6 @@ macro `logview--std-temporarily-widening' instead."
;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57804. They care about
responsiveness
;; with long lines, but not here, right.
(unless (and (= (point-min) 1) (= (point-max) (1+ (buffer-size))))
- ;; DONOTRELEASE: Document changes.
(error "Logview is incompatible with locked narrowing; see
https://github.com/doublep/logview#locked-narrowing";)))
(defmacro logview--std-temporarily-widening (&rest body)
