unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
@ 2018-01-19 13:34 Philipp Stephani
  2018-04-17 20:39 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Philipp Stephani @ 2018-01-19 13:34 UTC (permalink / raw)
  To: 30171


(with-temp-buffer
  (insert (propertize " " 'invisible 'foo))
  (remove-from-invisibility-spec 'what)
  (invisible-p 1))

is nil.  Commenting out the `remove-from-invisibility-spec' form causes
it to return t.  I'd expect t with `remove-from-invisibility-spec', but
that function and `add-to-invisibility-spec' always convert a
buffer-invisibility-spec of t to (t), which is not the same.


In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2018-01-19 built on localhost
Repository revision: ffeb1164d43c351786bc1e93e441fcbc29f5207b
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description: Debian GNU/Linux

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --without-threads --enable-gcc-warnings=warn-only
 --enable-gtk-deprecation-warnings --without-pop --with-mailutils
 --enable-checking --enable-check-lisp-object-type --with-modules
 'CFLAGS=-O0 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS FREETYPE XFT
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES JSON

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95220 8811)
 (symbols 48 20320 1)
 (miscs 40 41 121)
 (strings 32 28334 1953)
 (string-bytes 1 756739)
 (vectors 16 14131)
 (vector-slots 8 499016 12234)
 (floats 8 49 68)
 (intervals 56 225 0)
 (buffers 992 12))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

If you received this communication by mistake, please don’t forward it to
anyone else (it may contain confidential or privileged information), please
erase all copies of it, including all attachments, and please let the sender
know it went to the wrong person.  Thanks.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-01-19 13:34 bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially Philipp Stephani
@ 2018-04-17 20:39 ` Lars Ingebrigtsen
  2018-04-18  6:13   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-17 20:39 UTC (permalink / raw)
  To: Philipp Stephani; +Cc: 30171

Philipp Stephani <p.stephani2@gmail.com> writes:

> (with-temp-buffer
>   (insert (propertize " " 'invisible 'foo))
>   (remove-from-invisibility-spec 'what)
>   (invisible-p 1))
>
> is nil.  Commenting out the `remove-from-invisibility-spec' form causes
> it to return t.  I'd expect t with `remove-from-invisibility-spec', but
> that function and `add-to-invisibility-spec' always convert a
> buffer-invisibility-spec of t to (t), which is not the same.

Yes, that's extremely confusing, but poking around, it seems like the
idea is that if you've altered the `buffer-invisibility-spec' in any
way (i.e., made it into a list), then only the properties that are in
the list are the ones that are supposed to be invisible.

In that light, the behaviour here makes sense.

But I'm not sure that's really what's intended here.  Perhaps somebody
who was involved with implementing this could shed some light?

In any case, perhaps calling `remove-from-invisibility-spec' that's not
in the spec anyway shouldn't alter it?  It's certainly surprising.

This definition seems odd to me:

(defun remove-from-invisibility-spec (element)
  "Remove ELEMENT from `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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-04-17 20:39 ` Lars Ingebrigtsen
@ 2018-04-18  6:13   ` Eli Zaretskii
  2018-04-18 11:34     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2018-04-18  6:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: p.stephani2, 30171

> 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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-04-18  6:13   ` Eli Zaretskii
@ 2018-04-18 11:34     ` Lars Ingebrigtsen
  2018-04-18 12:35       ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-18 11:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: p.stephani2, 30171, Stefan Monnier

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





^ permalink raw reply related	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-04-18 11:34     ` Lars Ingebrigtsen
@ 2018-04-18 12:35       ` Stefan Monnier
  2018-04-18 12:40         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2018-04-18 12:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: p.stephani2, 30171

> 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 commit message refers to bug#20468 where the discussion indicates
that it seems to be on purpose.

One way to look at it is that the patch made

    (remove-from-invisibility-spec FOO)

give the same result as

    (add-to-invisibility-spec FOO)
    (remove-from-invisibility-spec FOO)

I guess the fundamental problem here is that the special behavior for
the value `t` of buffer-invisibility-spec is just not reflected in
(add-to|remove-from)-invisibility-spec.

So if you rely on the current value being `t` and someone comes along
and just does (add-to-invisibility-spec (make-symbol "unused")),
suddenly your invisible stuff becomes visible.

IOW you just can't rely on the special `t` behavior: if you want your
thing to be invisible, you need to either use the special `t` value of
the `invisible` property (which is invisible regardless of
buffer-invisibility-spec), or you need to add your value via
add-to-invisibility-spec.


        Stefan





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-04-18 12:35       ` Stefan Monnier
@ 2018-04-18 12:40         ` Lars Ingebrigtsen
  2018-04-24 15:20           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-18 12:40 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: p.stephani2, 30171

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> IOW you just can't rely on the special `t` behavior: if you want your
> thing to be invisible, you need to either use the special `t` value of
> the `invisible` property (which is invisible regardless of
> buffer-invisibility-spec), or you need to add your value via
> add-to-invisibility-spec.

I see.  Makes sense.  I'll clarify this in the doc strings of those
functions, then.

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially
  2018-04-18 12:40         ` Lars Ingebrigtsen
@ 2018-04-24 15:20           ` Lars Ingebrigtsen
  0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-24 15:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: p.stephani2, 30171

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> IOW you just can't rely on the special `t` behavior: if you want your
>> thing to be invisible, you need to either use the special `t` value of
>> the `invisible` property (which is invisible regardless of
>> buffer-invisibility-spec), or you need to add your value via
>> add-to-invisibility-spec.
>
> I see.  Makes sense.  I'll clarify this in the doc strings of those
> functions, then.

I've now done so and am closing this bug report.

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-04-24 15:20 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-19 13:34 bug#30171: 27.0.50; {add-to,remove-from}-invisibility-spec don't treat t specially Philipp Stephani
2018-04-17 20:39 ` Lars Ingebrigtsen
2018-04-18  6:13   ` Eli Zaretskii
2018-04-18 11:34     ` Lars Ingebrigtsen
2018-04-18 12:35       ` Stefan Monnier
2018-04-18 12:40         ` Lars Ingebrigtsen
2018-04-24 15:20           ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).