[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 <eliz@gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Tue, 17 Apr 2018 22:39:29 +0200
>> Cc: 30171@debbugs.gnu.org
>>
>> 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