bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Philipp Stephani]

C-x b *foo* RET
M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo" 'invisible 'foo)))

Now "foo" is visible, as it should be.

M-x fundamental-mode => "foo" becomes invisible, because
`kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
This can be confusing for modes that use conditional invisibility
properties such as markdown-mode.
Probably `kill-all-local-variables' shouldn't blindly reset
`buffer-invisibility-spec', or maybe it should remove conditional
invisibility properties.


In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2018-01-22 built on localhost
Repository revision: d0fd9809d7574c67a181225fcc1c59afdbb1295c
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 95246 8855)
 (symbols 48 20322 1)
 (miscs 40 41 121)
 (strings 32 28332 1986)
 (string-bytes 1 756483)
 (vectors 16 14131)
 (vector-slots 8 499256 13014)
 (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.

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 22 Jan 2018 10:51:32 +0100
> 
> C-x b *foo* RET
> M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo" 'invisible 'foo)))
> 
> Now "foo" is visible, as it should be.
> 
> M-x fundamental-mode => "foo" becomes invisible, because
> `kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
> This can be confusing for modes that use conditional invisibility
> properties such as markdown-mode.
> Probably `kill-all-local-variables' shouldn't blindly reset
> `buffer-invisibility-spec', or maybe it should remove conditional
> invisibility properties.

Why can't you make buffer-invisibility-spec be a permanent-local
variable in the cases where that is TRT?

(In general, clearing buffer-invisibility-spec on major mode change
sounds appropriate to me.)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 22. Jan. 2018 um 16:57 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Mon, 22 Jan 2018 10:51:32 +0100
> >
> > C-x b *foo* RET
> > M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo"
> 'invisible 'foo)))
> >
> > Now "foo" is visible, as it should be.
> >
> > M-x fundamental-mode => "foo" becomes invisible, because
> > `kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
> > This can be confusing for modes that use conditional invisibility
> > properties such as markdown-mode.
> > Probably `kill-all-local-variables' shouldn't blindly reset
> > `buffer-invisibility-spec', or maybe it should remove conditional
> > invisibility properties.
>
> Why can't you make buffer-invisibility-spec be a permanent-local
> variable in the cases where that is TRT?
>
>
Hmm, yes, that sounds like a good idea. Let me try that.

[-- Attachment #2: Type: text/html, Size: 1415 bytes --]

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Philipp Stephani <p.stephani2@gmail.com> schrieb am Mo., 22. Jan. 2018 um
21:42 Uhr:

> Eli Zaretskii <eliz@gnu.org> schrieb am Mo., 22. Jan. 2018 um 16:57 Uhr:
>
>> > From: Philipp Stephani <p.stephani2@gmail.com>
>> > Date: Mon, 22 Jan 2018 10:51:32 +0100
>> >
>> > C-x b *foo* RET
>> > M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo"
>> 'invisible 'foo)))
>> >
>> > Now "foo" is visible, as it should be.
>> >
>> > M-x fundamental-mode => "foo" becomes invisible, because
>> > `kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
>> > This can be confusing for modes that use conditional invisibility
>> > properties such as markdown-mode.
>> > Probably `kill-all-local-variables' shouldn't blindly reset
>> > `buffer-invisibility-spec', or maybe it should remove conditional
>> > invisibility properties.
>>
>> Why can't you make buffer-invisibility-spec be a permanent-local
>> variable in the cases where that is TRT?
>>
>>
> Hmm, yes, that sounds like a good idea. Let me try that.
>

I don't think this works: The permanent-local property is a global symbol
property, but I'd need it to be per-buffer.

[-- Attachment #2: Type: text/html, Size: 1962 bytes --]

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

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

> C-x b *foo* RET
> M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo" 'invisible 'foo)))
>
> Now "foo" is visible, as it should be.
>
> M-x fundamental-mode => "foo" becomes invisible, because
> `kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
> This can be confusing for modes that use conditional invisibility
> properties such as markdown-mode.

I'm not quite sure I understand the problem here -- if you have a buffer
in markdown-mode (that's set these properties), why would you change to
fundamental-mode?

And I think this is correct behaviour -- if you've switched to
fundamental-mode, then you don't want these remnants from markdown-mode
to survive, I think?

>  Why can't you make buffer-invisibility-spec be a permanent-local
>  variable in the cases where that is TRT?
> 
>  Hmm, yes, that sounds like a good idea. Let me try that. 
> 
> I don't think this works: The permanent-local property is a global symbol
> property, but I'd need it to be per-buffer. 

Yes, I don't think we have any mechanism that says "this buffer-local
value should survive if you change major mode, but only this one".  And
I think that's probably a good idea, because it sounds like a confusing
interface.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Philipp]

> Am 13.08.2021 um 14:50 schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> 
> Philipp Stephani <p.stephani2@gmail.com> writes:
> 
>> C-x b *foo* RET
>> M-: (progn (add-to-invisibility-spec 'bar) (insert (propertize "foo" 'invisible 'foo)))
>> 
>> Now "foo" is visible, as it should be.
>> 
>> M-x fundamental-mode => "foo" becomes invisible, because
>> `kill-all-local-variables' has reset `buffer-invisibility-spec' to t.
>> This can be confusing for modes that use conditional invisibility
>> properties such as markdown-mode.
> 
> I'm not quite sure I understand the problem here -- if you have a buffer
> in markdown-mode (that's set these properties), why would you change to
> fundamental-mode?

Why not?  Changing the major mode of a buffer is a supported operation.  For example, maybe I decide mid-way while writing a Markdown document that I'd rather want a plain text file without special syntax.

> 
> And I think this is correct behaviour -- if you've switched to
> fundamental-mode, then you don't want these remnants from markdown-mode
> to survive, I think?

Yes, but they do survive, i.e. once markdown-mode has made some text conditionally-visible (which it does for URLs etc.), I'd expect it to become unconditionally-visible instead of unconditionally-invisible when changing the major mode.

> 
>> Why can't you make buffer-invisibility-spec be a permanent-local
>> variable in the cases where that is TRT?
>> 
>> Hmm, yes, that sounds like a good idea. Let me try that. 
>> 
>> I don't think this works: The permanent-local property is a global symbol
>> property, but I'd need it to be per-buffer. 
> 
> Yes, I don't think we have any mechanism that says "this buffer-local
> value should survive if you change major mode, but only this one".  And
> I think that's probably a good idea, because it sounds like a confusing
> interface.
> 
> 

Yes, and probably it's difficult to define a reasonably generic API for this.
Maybe we should aim for a more specific solution: For example, Emacs could make all conditionally-visible text unconditionally-visible when changing major modes?  Or have a way for major modes to declare which invisibility specifiers are mode-specific and should be undone when leaving the mode?

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

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

>> And I think this is correct behaviour -- if you've switched to
>> fundamental-mode, then you don't want these remnants from markdown-mode
>> to survive, I think?
>
> Yes, but they do survive, i.e. once markdown-mode has made some text
> conditionally-visible (which it does for URLs etc.), I'd expect it to
> become unconditionally-visible instead of unconditionally-invisible
> when changing the major mode.

That's true.  Hm...  Should major modes remove `invisible' text
properties (where the value isn't t)?  No, that wouldn't be right,
either.

Uhm.  OK, if `buffer-invisibility-spec' isn't t,
`kill-all-local-variables' could remove the `invisible' text property
from all text that has a non-t value?

That sounds like it would potentially be expensive, but a non-nil
invisibility spec is quite unusual (and switching major modes, in
general, is unusual (well, switching from anything but fundamental-mode
is unusual)).

I dunno.  Anybody have an opinion here?

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 05 Sep 2021 10:53:05 +0200
> Cc: 30204@debbugs.gnu.org
> 
> > Yes, but they do survive, i.e. once markdown-mode has made some text
> > conditionally-visible (which it does for URLs etc.), I'd expect it to
> > become unconditionally-visible instead of unconditionally-invisible
> > when changing the major mode.
> 
> That's true.  Hm...  Should major modes remove `invisible' text
> properties (where the value isn't t)?  No, that wouldn't be right,
> either.
> 
> Uhm.  OK, if `buffer-invisibility-spec' isn't t,
> `kill-all-local-variables' could remove the `invisible' text property
> from all text that has a non-t value?
> 
> That sounds like it would potentially be expensive, but a non-nil
> invisibility spec is quite unusual (and switching major modes, in
> general, is unusual (well, switching from anything but fundamental-mode
> is unusual)).
> 
> I dunno.  Anybody have an opinion here?

I think this is a corner use case, and if there's no easy way of doing
something better with it, we shouldn't do anything.

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I think this is a corner use case, and if there's no easy way of doing
> something better with it, we shouldn't do anything.

Perhaps we should have a mode that even more fundamental than
fundamental-mode, that does a real cleanup of the buffer (removes all
text properties, overlays, etc), and just document that there are some
artefacts that may remain otherwise when changing modes?

We could call it...  fundamentalist-mode.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: p.stephani2@gmail.com,  30204@debbugs.gnu.org
> Date: Sun, 05 Sep 2021 11:43:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think this is a corner use case, and if there's no easy way of doing
> > something better with it, we shouldn't do anything.
> 
> Perhaps we should have a mode that even more fundamental than
> fundamental-mode, that does a real cleanup of the buffer (removes all
> text properties, overlays, etc), and just document that there are some
> artefacts that may remain otherwise when changing modes?
> 
> We could call it...  fundamentalist-mode.

We could.  But my understanding of the original report is that it
isn't limited to Fundamental mode, it expects a switch to _any_ mode
to do the same.

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> We could.  But my understanding of the original report is that it
> isn't limited to Fundamental mode, it expects a switch to _any_ mode
> to do the same.

Yes, so this wouldn't fix this, per se.  We'd just document that
changing modes doesn't clear everything out (in some obscure corner
cases), and then provide this new mode for those corner cases.

Actually, that's a function that's I've wanted before -- I sometimes
find myself in a buffer with lots of...  stuff, and then resorting to
saving, killing the buffer and then loading the contents to be sure that
I'm rid of all local variables/overlays/text properties/etc.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: p.stephani2@gmail.com,  30204@debbugs.gnu.org
> Date: Sun, 05 Sep 2021 12:12:18 +0200
> 
> Actually, that's a function that's I've wanted before -- I sometimes
> find myself in a buffer with lots of...  stuff, and then resorting to
> saving, killing the buffer and then loading the contents to be sure that
> I'm rid of all local variables/overlays/text properties/etc.

Doesn't font-lock-fontify-block (which used to be "M-o M-o") do what
you want?

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Doesn't font-lock-fontify-block (which used to be "M-o M-o") do what
> you want?

Nope -- that doesn't get rid of all the shenanigans that may be going on
in the buffer (display properties, overlays, etc).

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps we should have a mode that even more fundamental than
> fundamental-mode, that does a real cleanup of the buffer (removes all
> text properties, overlays, etc), and just document that there are some
> artefacts that may remain otherwise when changing modes?
>
> We could call it...  fundamentalist-mode.

I've now added this to Emacs 29 under the name `clean-mode'.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Perhaps we should have a mode that even more fundamental than
  > > fundamental-mode, that does a real cleanup of the buffer (removes all
  > > text properties, overlays, etc), and just document that there are some
  > > artefacts that may remain otherwise when changing modes?
  > >
  > > We could call it...  fundamentalist-mode.

  > I've now added this to Emacs 29 under the name `clean-mode'.

I see the usefulness of a command to remove such things from the
buffer, but I don't think it fits the Emacs concept of "mode".  It
changes the contents of the buffer.

I suggest renaming it to something like `clean-buffer'.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I see the usefulness of a command to remove such things from the
> buffer, but I don't think it fits the Emacs concept of "mode".  It
> changes the contents of the buffer.
>
> I suggest renaming it to something like `clean-buffer'.

It's a mode -- it continues to remove text properties from text you yank
into it.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I suggest renaming it to something like `clean-buffer'.

  > It's a mode -- it continues to remove text properties from text you yank
  > into it.

Thanks for explaining.

"Clean" is not a very clear name for this, because the idea that
having no text properties is "cleaner" is a matter of taste.  Some
might not make the connection between the word "cleam" and what this
does.  Thus, people will have more difficulty remembering the name
from the meaning and vice versa.

I suggest renaming it to "no-properties-mode".

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> "Clean" is not a very clear name for this, because the idea that
> having no text properties is "cleaner" is a matter of taste.  Some
> might not make the connection between the word "cleam" and what this
> does.  Thus, people will have more difficulty remembering the name
> from the meaning and vice versa.
>
> I suggest renaming it to "no-properties-mode".

I think `no-properties-mode' sounds pretty awkward, but I don't really
have much of an opinion here, one way or the other.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Juri Linkov]

>> "Clean" is not a very clear name for this, because the idea that
>> having no text properties is "cleaner" is a matter of taste.  Some
>> might not make the connection between the word "cleam" and what this
>> does.  Thus, people will have more difficulty remembering the name
>> from the meaning and vice versa.
>>
>> I suggest renaming it to "no-properties-mode".
>
> I think `no-properties-mode' sounds pretty awkward, but I don't really
> have much of an opinion here, one way or the other.

Since it strips all text properties, then maybe 'stripped-mode'.

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 10 Oct 2021 19:50:22 +0300
> Cc: 30204@debbugs.gnu.org, p.stephani2@gmail.com,
>  Richard Stallman <rms@gnu.org>
> 
> >> "Clean" is not a very clear name for this, because the idea that
> >> having no text properties is "cleaner" is a matter of taste.  Some
> >> might not make the connection between the word "cleam" and what this
> >> does.  Thus, people will have more difficulty remembering the name
> >> from the meaning and vice versa.
> >>
> >> I suggest renaming it to "no-properties-mode".
> >
> > I think `no-properties-mode' sounds pretty awkward, but I don't really
> > have much of an opinion here, one way or the other.
> 
> Since it strips all text properties, then maybe 'stripped-mode'.

I suggest stripped-naked-mode.

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Since it strips all text properties, then maybe 'stripped-mode'.

  > I suggest stripped-naked-mode.

I think that `stripped-mode' might be a good name.  But since it is not
about nudity, adding he word "naked" would only cause confusion.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think `no-properties-mode' sounds pretty awkward, but I don't really
  > have much of an opinion here, one way or the other.

How about Vow of Poverty mode or just Poverty mode?
(Poverty is having no properties.)

M-x poverty-mode and M-x vow-of-poverty-mode
can complete from only 2 or 3 characters.
Likewise M-x no-properties-mode.

M-x clean-mode requires 7 characters for completion.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Phil Sainty]

On 2021-10-11 12:26, Richard Stallman wrote:
> How about Vow of Poverty mode or just Poverty mode?
> (Poverty is having no properties.)

Neat, albeit unlikely to help anyone to find it.  I suspect it might
be considered to be in poor taste though (it needn't be interpreted as
such, but I think it has potential to be).

I agree that "clean" has no particular association with a lack of text
properties, and I think Juri's suggestion:

> Since it strips all text properties, then maybe 'stripped-mode'.

is little different to "clean" -- anything can be stripped of anything,
so there's no obvious reason why "text properties" should come to mind.


> can complete from only 2 or 3 characters.

Is it very important to optimise for this, in this particular case?


I think that "no-properties" is sufficiently well-established
terminology that incorporating that into the mode name would at least
make it very easy to discover.


Index entries that match ‘no-properties’:

* buffer-substring-no-properties [Index]: Buffer Contents. (line 38)
* field-string-no-properties [Index]:    Fields. (line 61)
* insert-buffer-substring-no-properties [Index]: Insertion. (line 94)
* match-string-no-properties [Index]:    Simple Match Data. (line 53)
* minibuffer-contents-no-properties [Index]: Minibuffer Contents. (line 
27)
* substring-no-properties [Index]:       Creating Strings. (line 101)

(thing-at-point THING &optional NO-PROPERTIES)
(buffer-substring-with-bidi-context START END &optional NO-PROPERTIES)
(line-substring-with-bidi-context START END &optional NO-PROPERTIES)


If someone is looking for related concepts, it's likely where they
would start.

A bit awkward/boring maybe, but probably still a good option.


-Phil

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> M-x poverty-mode and M-x vow-of-poverty-mode
> can complete from only 2 or 3 characters.
> Likewise M-x no-properties-mode.

It also removed overlays and local variables, so it's not all about text
properties...

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> M-x poverty-mode and M-x vow-of-poverty-mode
>> can complete from only 2 or 3 characters.
>> Likewise M-x no-properties-mode.
>
> It also removed overlays and local variables, so it's not all about text
> properties...

Maybe the name should emphasize the _lack_ of any features whatsoever,
rather than the _removal_ of features?  E.g. void-mode, null-mode,
nil-mode, empty-mode, bare-mode, plain-mode?

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Robert Pluim]

>>>>> On Mon, 11 Oct 2021 11:14:07 +0200, Kévin Le Gouguec <kevin.legouguec@gmail.com> said:

    Kévin> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> Richard Stallman <rms@gnu.org> writes:
    >> 
    >>> M-x poverty-mode and M-x vow-of-poverty-mode
    >>> can complete from only 2 or 3 characters.
    >>> Likewise M-x no-properties-mode.
    >> 
    >> It also removed overlays and local variables, so it's not all about text
    >> properties...

    Kévin> Maybe the name should emphasize the _lack_ of any features whatsoever,
    Kévin> rather than the _removal_ of features?  E.g. void-mode, null-mode,
    Kévin> nil-mode, empty-mode, bare-mode, plain-mode?

ascetic-mode, austere-mode, thomas-à-becket-mode?

Robert
-- 

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ascetic-mode, austere-mode, thomas-à-becket-mode?

Of those, I think "austere" mode is more correct -- but still, not
immediately clear like no-properties-mode.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Phil Sainty]

On 2021-10-11 22:14, Kévin Le Gouguec wrote:
> Maybe the name should emphasize the _lack_ of any features whatsoever,
> rather than the _removal_ of features?  E.g. void-mode, null-mode,
> nil-mode, empty-mode, bare-mode, plain-mode?

foundation-mode?

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Tomas Nordin]

"Kévin Le Gouguec" <kevin.legouguec@gmail.com> skrev: (11 oktober 2021 11:14:07 CEST)
>Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> M-x poverty-mode and M-x vow-of-poverty-mode
>>> can complete from only 2 or 3 characters.
>>> Likewise M-x no-properties-mode.
>>
>> It also removed overlays and local variables, so it's not all about text
>> properties...
>
>Maybe the name should emphasize the _lack_ of any features whatsoever,
>rather than the _removal_ of features?  E.g. void-mode, null-mode,
>nil-mode, empty-mode, bare-mode, plain-mode?
>
>

minimalistic-mode

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It also removed overlays and local variables, so it's not all about text
  > properties...

Changing major mode always eliminates local variables, so there is no need
to regard that as a feature of this particular mode.

Also, normally overlays are created by modes, so removing them may also be
due to changing the mode, not a feature of this particular mode.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Changing major mode always eliminates local variables, so there is no need
> to regard that as a feature of this particular mode.

It also blanks out the permanent local variables, so it's unusual that way.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It also blanks out the permanent local variables, so it's unusual that way.

That is indeed pretty strong medicine.

Perhaps vanilla-mode ?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Robert Pluim]

>>>>> On Fri, 08 Oct 2021 00:25:57 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Richard Stallman <rms@gnu.org> writes:
    >> I see the usefulness of a command to remove such things from the
    >> buffer, but I don't think it fits the Emacs concept of "mode".  It
    >> changes the contents of the buffer.
    >> 
    >> I suggest renaming it to something like `clean-buffer'.

    Lars> It's a mode -- it continues to remove text properties from text you yank
    Lars> into it.

I see you did that with 'after-change-functions'. Would a
'pre-yank-hook' be a useful addition to Emacs? I often yank output
from badly behaved programs, and having a buffer-local hook to replace
non-breaking-spaces and the like before insertion would be useful.

Robert
-- 

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I see you did that with 'after-change-functions'. Would a
> 'pre-yank-hook' be a useful addition to Emacs? I often yank output
> from badly behaved programs, and having a buffer-local hook to replace
> non-breaking-spaces and the like before insertion would be useful.

There's `filter-buffer-substring' to do it from the other side...  But I
see now that I could just have set `yank-excluded-properties' to t in
this mode to get the same effect as the `after-change-functions'.  I'll
adjust.

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Robert Pluim]

>>>>> On Sat, 09 Oct 2021 13:10:57 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> I see you did that with 'after-change-functions'. Would a
    >> 'pre-yank-hook' be a useful addition to Emacs? I often yank output
    >> from badly behaved programs, and having a buffer-local hook to replace
    >> non-breaking-spaces and the like before insertion would be useful.

    Lars> There's `filter-buffer-substring' to do it from the other side...  But I
    Lars> see now that I could just have set `yank-excluded-properties' to t in
    Lars> this mode to get the same effect as the `after-change-functions'.  I'll
    Lars> adjust.

Doesnʼt `filter-buffer-substring' only work if Iʼm yanking from one
buffer to another? What if Iʼm yanking the X selection?

Robert
-- 

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Doesnʼt `filter-buffer-substring' only work if Iʼm yanking from one
> buffer to another? What if Iʼm yanking the X selection?

Then you have...  er...  interprogram-paste-function and friends.  :-/

Hm...  perhaps there is no transform function that handles all yanks?  I
thought I remembered that we'd added that, but apparently not...

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

bug#30204: 27.0.50; Changing major mode resets non-default invisibility spec

[jakanakaevangeli]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philipp <p.stephani2@gmail.com> writes:
>
>>> And I think this is correct behaviour -- if you've switched to
>>> fundamental-mode, then you don't want these remnants from markdown-mode
>>> to survive, I think?
>>
>> Yes, but they do survive, i.e. once markdown-mode has made some text
>> conditionally-visible (which it does for URLs etc.), I'd expect it to
>> become unconditionally-visible instead of unconditionally-invisible
>> when changing the major mode.
>
> That's true.  Hm...  Should major modes remove `invisible' text
> properties (where the value isn't t)?  No, that wouldn't be right,
> either.
>
> Uhm.  OK, if `buffer-invisibility-spec' isn't t,
> `kill-all-local-variables' could remove the `invisible' text property
> from all text that has a non-t value?
>
> That sounds like it would potentially be expensive, but a non-nil
> invisibility spec is quite unusual (and switching major modes, in
> general, is unusual (well, switching from anything but fundamental-mode
> is unusual)).
>
> I dunno.  Anybody have an opinion here?

markdown-mode should simply add `invisible' to
font-lock-extra-managed-props. Font-lock will then automatically remove
this property as well from the buffer in change-major-mode-hook.

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