Proposed new minor mode

Proposed new minor mode

[Luc Teirlinck]

I propose to add the following new minor mode to Emacs.  Direct
motivation is Info, where I propose to bind it to `i', but it could be
used elsewhere.

It makes all invisible text visible, after saving the old value of
buffer-invisibility-spec.  Disabling the minor mode restores the old
value.  Switching major modes automatically disables, because the new
major mode might want to set its own value of
buffer-invisibility-spec.

The main motivation is that killing and yanking, saving to file,
copying parts of the buffer to file, mailing, printing, make all
invisible text visible.  It is good to let the user see which text he
really is going to yank, save or copy to file, mail, print and so on.
Also, to allow him to figure why various commands like M-x man, C-h f
and the like might be behaving strangely.  Also to allow him to edit
in a way that he really knows what he is editing.  

This is not meant as a substitute for similar commands in specialized
modes, say outline mode, which should have commands to make only the
text they made invisible back visible.

A good place to try it out would be the dir file in info.  Doing so
will also show that there are still some problems with Stefan's new
node hiding implementation.  I believe these problems can be fixed.  I
will go into that separately.

I would not know in which file exactly the stuff would need to go.
Info is the main motivation, but it is much more general.


===File ~/vis-mode.el=======================================
(make-variable-buffer-local 'saved-buffer-invisibility-spec)

(defvar saved-buffer-invisibility-spec nil
  "Saved value of buffer-invisibility-spec when `vis-mode' is on.")

;; The next function is needed for use in change-major-mode-hook.
(defun vis-mode-disable ()
  "Disable vis-mode."
  (vis-mode 0))

(define-minor-mode vis-mode
  "Toggle vis-mode.
With argument ARG turn vis-mode on iff ARG is positive..

Enabling vis-mode sets `buffer-invisibility-spec' to nil, after
saving the old value in the variable
`saved-buffer-invisibility-spec', making all invisible text in
the buffer visible.

Disabling vis-mode restores the saved value of
`buffer-invisibility-spec'.

Cannging the major mode always disables vis-mode"
  :lighter " Vis"
  (if vis-mode
      (progn
	(setq saved-buffer-invisibility-spec buffer-invisibility-spec
	      buffer-invisibility-spec nil)
	(add-hook 'change-major-mode-hook 'vis-mode-disable nil t))
    (setq buffer-invisibility-spec saved-buffer-invisibility-spec
	  saved-buffer-invisibility-spec nil)))

  
============================================================

Re: Proposed new minor mode

[Luc Teirlinck]

>From my previous message:

   Cannging the major mode always disables vis-mode"

should of course be:

Changing the major mode always disables vis-mode."

Ispell claimed that "cannging" was correct.  I do not know what it
means however.

Sincerely,

Luc.

Re: Proposed new minor mode

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I propose to add the following new minor mode to Emacs.  Direct
> motivation is Info, where I propose to bind it to `i', but it could
> be used elsewhere.

The mode is so unimportant that I would not give it a keybinding of
its own: it would be only interesting, at best, for debugging
purposes of some manner.  If buffers make text invisible, they have a
reason for it and should provide sane semantics in connection.

I don't see the necessity in the context of info files: there I would
just delete the text in question from the buffer instead of making it
visible (we had this already).  Most certainly the `i' binding in
info is much too important to give it up for toggling a minor mode
most people will never in their life need to use.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Proposed new minor mode

[Eli Zaretskii]

> From: David.Kastrup@t-online.de (David Kastrup)
> Date: 07 Jun 2003 08:55:53 +0200
> 
> The mode is so unimportant that I would not give it a keybinding of
> its own

Full agreement.

Let the users who need this type "M-x vis-mode-disable RET" or some
such.

Re: Proposed new minor mode

[Luc Teirlinck]

Eli Zaretskii wrote:

   Let the users who need this type "M-x vis-mode-disable RET" or some
   such.

Whether we need a binding for this or not is a different matter.  But
it would seem (given the current implementation) that every user,
even, or I would say especially, a novice user, would need to use the
command at least once (actually twice, because it needs to be disabled
again), because otherwise the confusion when killing and yanking,
printing part of the buffer, using commands like M-x man and the
like, is going to be too big.  The user needs to be aware the text is
there, because sooner or later he is going to be confronted with it.
If the text were erased, instead of being made invisible, that would
be a different matter, but that is not how it is currently
implemented.   I do not know of any plans to implement it that way.

Killing and yanking are not just commands for advanced users and there
are plenty of reasons to kill and yank text from info buffers.

Sincerely,

Luc.

Re: Proposed new minor mode

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Eli Zaretskii wrote:
> 
>    Let the users who need this type "M-x vis-mode-disable RET" or
>    some such.
> 
> Whether we need a binding for this or not is a different matter.
> But it would seem (given the current implementation) that every
> user, even, or I would say especially, a novice user, would need to
> use the command at least once (actually twice, because it needs to
> be disabled again), because otherwise the confusion when killing and
> yanking, printing part of the buffer, using commands like M-x man
> and the like, is going to be too big.

The surprise is not ameliorated by the availability of a command
toggling some visibility.  The novice user caught by surprise will not
think "Oh, I should have called vis-mode-disable in order not get
this".

> The user needs to be aware the text is there, because sooner or
> later he is going to be confronted with it.

And then he will get aware of it.

> If the text were erased, instead of being made invisible, that would
> be a different matter, but that is not how it is currently
> implemented.  I do not know of any plans to implement it that way.

Strange.  I think I read the contention several times that it would
be a good idea to edit the buffer, making the text better match the
appearance.

> Killing and yanking are not just commands for advanced users and
> there are plenty of reasons to kill and yank text from info buffers.

Sure, but if we have an inconsistency there, the solution is to fix it
instead of providing a command nobody would ever think of using,
because it only uglifies the current buffer and does not cause
anything different to be yanked to the destination buffer.

It won't do a harm to have such a mode for debugging info files and
their display, and other invisibility matters, but it would be an
illusion to think that it would be of major interest to novices, or
help them much.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Proposed new minor mode

[Luc Teirlinck]

David Kastrup wrote:

   Strange.  I think I read the contention several times that it would
   be a good idea to edit the buffer, making the text better match the
   appearance.

A contention is not a decision.  I was told that the only decision
remaining to be made on info was whether or not we would pursue Kim's
current attempts at refilling, with which there seem at present still
to be some problems.  (I do not know whether or not they are fixed or
about to be fixed by now.)  If I misunderstood this, then we could
reopen the discussion on this.

   The surprise is not ameliorated by the availability of a command
   toggling some visibility.  The novice user caught by surprise will not
   think "Oh, I should have called vis-mode-disable in order not get
   this".

Users who do not read manuals will get surprises.  Users who do read
manuals or tutorials deserve not to.  I plan to rewrite a part of the
tutorial.  Given the current implementation, I believe that I have to
make the user aware that the text described for the standalone version
is really there in the Emacs version too, just hidden, and that one
can get confronted with it.  (I do not intend to spend paragraphs on
this, but I believe it needs to be mentioned.)  It also has the
advantage that the Emacs user learning this would have encountered the
notion of a node name at this stage, just like the user using the
standalone version.  That notion is referred to later.  If we
implement buffer editing, I would tell the Emacs user about node names
in some other way.

On a separate matter, if you want to use this minor mode, you have to
call vis-mode.  vis-mode-disable is a technical internal function,
needed because functions in normal hooks can not accept arguments.

    > The user needs to be aware the text is there, because sooner or
    > later he is going to be confronted with it.

    And then he will get aware of it.

But clueless.

Sincerely,

Luc.

Re: { SPAM 2 }::Re: Proposed new minor mode

[Luc Teirlinck]

David Kastrup wrote:

   Sure, but if we have an inconsistency there, the solution is to fix it
   instead of providing a command nobody would ever think of using,
   because it only uglifies the current buffer and does not cause
   anything different to be yanked to the destination buffer.

I actually agree with this.

However, people have argued that the hidden information is so
important that it should _never_ be hidden.  Other people, including
you, have argued that it is so unimportant it should be erased.  Not
erasing it, but making it invisible is a compromise solution.  But
that compromise makes no sense if you do not support it.  The `v'
command I propose would allow an extremely easy hiding and reappearing
of that information.  To me, it seems to work instantaneously, it is
not slow stuff like an inflatable airbag.  Saying that nobody would
ever use the mode in info for anything else than debugging purposes
(although I actually do find it very useful while debugging
invisibility related stuff in all kinds of situations) is more or less
arguing that the information in question is of no interest to anybody.
(In which case it should be erased, not hidden).  But, some people
find it interesting enough to set Info-hide-note-references to nil.
This command would seem to me to provide some kind of "best of both
worlds".

    because it only uglifies the current buffer

The fact that it uglifies the buffer to the extent it does is due to
imperfections in Stefan's implementation.  I believe these could be
fixed.  (But that would make no sense if we would decide to go for
deletion.)  The "only" means that you consider the hidden text
useless.  Not everybody agrees with that.  I personally have no strong
opinions on the subject.

    and does not cause anything different to be yanked to the
    destination buffer.

But hiding that text instead of deleting it means that you _want_ the
text to be yanked, you _want_ the text to be copied to files, you
_want_ the text to be printed out to hardcopy.  Fine.  But then the
user has to know it is there and needs convenient access to it.

    Sure, but if we have an inconsistency there, the solution is to
    fix it

Of course, the only question is in which direction.  I know and
respect your opinion on the matter.  Other people have other
opinions.  I actually can live with all of them, all the way from
Robert's to yours, let us just be consistent.

If we go for hiding, rather than outright deletion or outright visible
inclusion, I believe that consistency means easy toggling.

Sincerely,

Luc.

Re: { SPAM 2 }::Re: Proposed new minor mode

[Luc Teirlinck]

David Kastrup wrote:

   I don't see the necessity in the context of info files: there I would
   just delete the text in question from the buffer instead of making it
   visible (we had this already).

When?

   Most certainly the `i' binding in
   info is much too important to give it up for toggling a minor mode
   most people will never in their life need to use.

As I already said in my reply to Eli, I just miswrote.  I meant `v'
(for visible).  I never meant to rebind `i' (even though I
absent-mindedly wrote so).

Sincerely,

Luc.

Re: Proposed new minor mode

[Miles Bader]

On Sat, Jun 07, 2003 at 08:55:53AM +0200, David Kastrup wrote:
> The mode is so unimportant that I would not give it a keybinding of
> its own: it would be only interesting, at best, for debugging
> purposes of some manner.

Agree completely.  It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Proposed new minor mode

[Eli Zaretskii]

> Date: Fri, 6 Jun 2003 20:51:10 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> I propose to add the following new minor mode to Emacs.  Direct
> motivation is Info, where I propose to bind it to `i', but it could be
> used elsewhere.

The command currently bound to `i' in Info is so important that I'm
sure we don't want to give it up.  If nothing else, it will introduce
yet another incompatibility between the stand-alone Info reader and
Emacs.

Re: Proposed new minor mode

[Luc Teirlinck]

Eli Zaretskii wrote:

   The command currently bound to `i' in Info is so important that I'm
   sure we don't want to give it up.  If nothing else, it will introduce
   yet another incompatibility between the stand-alone Info reader and
   Emacs.

Sorry, I was just terribly absent-minded, I meant `v' not `i'.

Sincerely,

Luc.

Re: Proposed new minor mode

[Richard Stallman]

I think the mode is a good idea.  However, instead of using
vis-mode-disable, just make all the variables buffer-local and not
permanent.  Then it will automatically go away when you change major
modes.

I also agree with Kastrup that it doesn't deserve a key binding like
`i'.  Or even `v'.  I think of this as a general feature, so the
command we teach people for invoking it should be one that works
any time.