[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t

From: Lars Ingebrigtsen
Subject: bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
Date: Wed, 18 Apr 2018 13:34:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Lars Ingebrigtsen <address@hidden>
>> Date: Tue, 17 Apr 2018 22:39:29 +0200
>> Cc: address@hidden
>> In any case, perhaps calling `remove-from-invisibility-spec' that's not
>> in the spec anyway shouldn't alter it?  It's certainly surprising.
> If the only problem is the surprising behavior, I'd prefer to document
> it rather than potentially open a can of worms.

The change below is the cause of this odd feature set, and I wonder
whether Stefan (who made the change) meant for it to do what it does.
The relevant bit commit message seems to be "Handle the t case".

Stefan, the issue is that t and `(t)' mean wildly differing things: `t'
means "hide everything that has an invisibility spec" and `(t)' means
"hide the things that has an invisibility spec `eq' to `t'."

So if the spec was t, and you remove `foo', you end up with `(t)', which
means that if you had invisible text that was `eq' to `bar', that
suddenly becomes visible.

If you understand what I mean.  :-)

diff --git a/lisp/subr.el b/lisp/subr.el
index 5d40aaae41..535fa2d3d0 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4066,9 +4066,10 @@ add-to-invisibility-spec
 (defun remove-from-invisibility-spec (element)
   "Remove ELEMENT from `buffer-invisibility-spec'."
-  (if (consp buffer-invisibility-spec)
-      (setq buffer-invisibility-spec
-           (delete element buffer-invisibility-spec))))
+  (setq buffer-invisibility-spec
+        (if (consp buffer-invisibility-spec)
+           (delete element buffer-invisibility-spec)
+          (list t))))

(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

reply via email to

[Prev in Thread] Current Thread [Next in Thread]