Should invisible imply intangible?

Should invisible imply intangible?

[Richard Stallman]

A few weeks ago I made some changes that result in sensible cursor
motion behavior for invisible, intangible text.  However, invisible
text which is not intangible tends to give strange behavior.
Meanwhile, the buffer-invisibility-spec feature makes it easy to
control invisibility of parts of the text, but not intangibility as
well.

What would people think of making invisible imply intangible?  Is
there any practical use for text which is invisible but not
intangible?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Should invisible imply intangible?

[Paul Michael Reilly]

Richard Stallman writes:
...
 > What would people think of making invisible imply intangible?  Is
 > there any practical use for text which is invisible but not
 > intangible?

Invisible but tangible appealed to me for handling Rmail ignorable
headers using inbox format.  On the one hand I wanted to make these
headers invisible to the User but on the other hand I want to
add/remove text behind the scenes, so to speak, to the headers to
handle attributes and labels.  I can imagine that cursor movement
might get kind of weird around invisible but tangible text.

There are three or four other ways to solve the problem, each with its
own set of tradeoffs.  Invisible implying intangible also makes for a
useful solution.

My gut feel is that having the three choices of invisible, intangible
and hidden (which is both invisible and intangible) is the best
solution.  I'd also want to have a variable for each case like
buffer-invisibility-spec, e.g. buffer-intangible-spec and
buffer-hidden-spec.

-pmr

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    Invisible but tangible appealed to me for handling Rmail ignorable
    headers using inbox format.

That seems like the wrong tool for the job.

      On the one hand I wanted to make these
    headers invisible to the User but on the other hand I want to
    add/remove text behind the scenes, so to speak, to the headers to
    handle attributes and labels.

You could bind inhibit-point-motion-hooks to non-nil in these
commands.  That is simple, and gives much better results than making
them tangible for the user.

    My gut feel is that having the three choices of invisible, intangible
    and hidden (which is both invisible and intangible) is the best
    solution.

My gut feeling is the opposite.  Do you have any specific situations
to show me that my gut feeling is wrong?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> A few weeks ago I made some changes that result in sensible cursor
> motion behavior for invisible, intangible text.  However, invisible
> text which is not intangible tends to give strange behavior.
> Meanwhile, the buffer-invisibility-spec feature makes it easy to
> control invisibility of parts of the text, but not intangibility as
> well.
> 
> What would people think of making invisible imply intangible?

Bad idea.

> Is there any practical use for text which is invisible but not
> intangible?

Yes.  Check out lisp/reveal.el (aka reveal-mode) which detects
(from post-command-hook) when point is inside an invisible area
and makes that area visible (temporarily).

It works particularly nicely with outline-minor-mode (which has special
support for it), but it also work with hideif.el, hs-minor-mode, ...


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    > Is there any practical use for text which is invisible but not
    > intangible?

    Yes.  Check out lisp/reveal.el (aka reveal-mode) 

Ok, I am convinced.  But what do you think of the view that invisible
should imply intangible unless something like reveal.el is used?
We could have a flag which says whether invisible implies intangible.
It could default to t, and reveal-mode could set it to nil.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     > Is there any practical use for text which is invisible but not
>     > intangible?
> 
>     Yes.  Check out lisp/reveal.el (aka reveal-mode) 
> 
> Ok, I am convinced.  But what do you think of the view that invisible
> should imply intangible unless something like reveal.el is used?
> We could have a flag which says whether invisible implies intangible.
> It could default to t, and reveal-mode could set it to nil.

But reveal.el does not apply to all invisible text in a buffer.
Only to the text that's made invisible by an overlay and only if
the invisibility spec says that it should be replaced by an ellipsis.

Also, as David Kastrup has mentioned repeatedly, intangible text tends
to break lots of things, so we probably want to use something else.
For example: automatically move point to a visible area after each command
(and after post-command-hook, of course) or during redisplay (I believe
there is already such a feature for text with a `display' property).

The current intangibility which moves point to a tangible area for
each and every point motion tends to be too intrusive.

I think that a "move to visible, after post-command-hook" or something
like that might be appropriate.  And it wouldn't conflict with reveal.el
(although it could still conflict if reveal.el was changed to use an idle
timer rather than post-command-hook).


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    Also, as David Kastrup has mentioned repeatedly, intangible text tends
    to break lots of things...

I don't think so.

    For example: automatically move point to a visible area after each command
    (and after post-command-hook, of course) or during redisplay (I believe
    there is already such a feature for text with a `display' property).

If we can find some better way to move point out of certain text than
what `intangible' does now, perhaps we should redefine the meaning of
`intangible'.  But I think it breaks only a few things, occasionally.
I think it is pretty good.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     Also, as David Kastrup has mentioned repeatedly, intangible text tends
>     to break lots of things...
> 
> I don't think so.

Please, Richard, try to remember the lengthy discussion we've had about that.
The problem is that the vast majority of elisp code does not expect to
bump into a piece of intangible text and misbehaves when it happens.
In practice, it's generally a non-issue because most uses of intangible
text are restricted to a particular context so that this intangible
text is only accessed by a small body of elisp code.

>     For example: automatically move point to a visible area after each command
>     (and after post-command-hook, of course) or during redisplay (I believe
>     there is already such a feature for text with a `display' property).
> 
> If we can find some better way to move point out of certain text than
> what `intangible' does now, perhaps we should redefine the meaning of
> `intangible'.  But I think it breaks only a few things, occasionally.
> I think it is pretty good.

I think the current semantics of `intangible' is not useless and
until we can come up with something clearly superior, we shouldn't
change it.

I.e. what I suggest is more like the patch below (100% untested),
which extends the treatment of the `composition' and `display' properties
to `invisible'.


	Stefan


Index: keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.659
diff -u -u -b -r1.659 keyboard.c
--- keyboard.c	23 Feb 2002 22:02:18 -0000	1.659
+++ keyboard.c	3 Mar 2002 17:08:25 -0000
@@ -1750,7 +1750,7 @@
 {
   int start, end;
   Lisp_Object val;
-  int check_composition = 1, check_display = 1;
+  int check_composition = 1, check_display = 1, check_invisible = 1;
 
   while (check_composition || check_display)
     {
@@ -1766,8 +1766,24 @@
 	  else
 	    SET_PT (end);
 	  check_display = 1;
+	  check_invisible = 1;
 	}
       check_composition = 0;
+      if (check_invisible
+	  && PT > BEGV && PT < ZV
+	  && get_property_and_range (PT, Qinvisible, &val, &start, &end, Qnil)
+	  && TEXT_PROP_MEANS_INVISIBLE (val)
+	  && start < PT && end > PT
+	  && (last_pt <= start || last_pt >= end))
+	{
+	  if (PT < last_pt)
+	    SET_PT (start);
+	  else
+	    SET_PT (end);
+	  check_composition = 1;
+	  check_display = 1;
+	}
+      check_invisible = 0;
       if (check_display
 	  && PT > BEGV && PT < ZV
 	  && get_property_and_range (PT, Qdisplay, &val, &start, &end, Qnil)
@@ -1780,6 +1796,7 @@
 	  else
 	    SET_PT (end);
 	  check_composition = 1;
+	  check_invisible = 1;
 	}
       check_display = 0;
     }


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    >     Also, as David Kastrup has mentioned repeatedly, intangible text tends
    >     to break lots of things...
    > 
    > I don't think so.

    Please, Richard, try to remember the lengthy discussion we've had about that.

You seem to agree with my conclusion:

    In practice, it's generally a non-issue because most uses of intangible
    text are restricted to a particular context so that this intangible
    text is only accessed by a small body of elisp code.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

The change in adjust_point_for_property seems ok, and it might solve
this problem.  You need to change the while condition, though.
It should check all three flags.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     >     Also, as David Kastrup has mentioned repeatedly, intangible text tends
>     >     to break lots of things...
>     > 
>     > I don't think so.
> 
>     Please, Richard, try to remember the lengthy discussion we've had about that.
> 
> You seem to agree with my conclusion:
> 
>     In practice, it's generally a non-issue because most uses of intangible
>     text are restricted to a particular context so that this intangible
>     text is only accessed by a small body of elisp code.

I indeed agree as long as intangible stays as a rarely used feature.
OTOH If you turn invisible text into intangible text as well, then the
problem changes since it is not true any more that "most uses of
intangible text are restricted to a particular context".


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     >     Also, as David Kastrup has mentioned repeatedly, intangible text tends
>     >     to break lots of things...
>     > 
>     > I don't think so.
> 
>     Please, Richard, try to remember the lengthy discussion we've had about that.
> 
> You seem to agree with my conclusion:
> 
>     In practice, it's generally a non-issue because most uses of intangible
>     text are restricted to a particular context so that this intangible
>     text is only accessed by a small body of elisp code.

As for the patch to adjust_point_for_property, it not only
suffers from the minor problem you mentioned but from the fact that
adjust_point_for_property currently does not take overlays into
account, which makes it useless for outline-style invisible text.

See the attached patch.  It's rather ugly and I'm not convinced it works
100%, although superficial tests show it does work at least in
simple cases (but with overlapping overlays and text properties,
it's less sure).
The code's logic is fairly intricate because it tries (just like
the original code) to avoid redundant work (such as checking the
`composition' property even tho we haven't moved since last time
we checked it).
Maybe I shouldn't be trying so hard ?


	Stefan


Index: keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.660
diff -u -u -b -r1.660 keyboard.c
*** keyboard.c	4 Mar 2002 23:40:59 -0000	1.660
--- keyboard.c	5 Mar 2002 01:36:36 -0000
***************
*** 1741,1748 ****
  
  /* Adjust point to a boundary of a region that has such a property
     that should be treated intangible.  For the moment, we check
!    `composition' and `display' property.  LAST_PT is the last position
!    of point.  */
  
  static void
  adjust_point_for_property (last_pt)
--- 1741,1817 ----
  
  /* Adjust point to a boundary of a region that has such a property
     that should be treated intangible.  For the moment, we check
!    `composition', `display' and `invisible' properties.
!    LAST_PT is the last position of point.  */
! 
! static int
! adjust_composition_valid_p (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return COMPOSITION_VALID_P (start, end, val);
! }
! 
! static int
! adjust_text_prop_means_invisible (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return TEXT_PROP_MEANS_INVISIBLE (val);
! }
! 
! static int
! adjust_display_prop_intangible_p (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return display_prop_intangible_p (val);
! }
! 
! static int
! get_property_overlay_and_range (posn, prop, val, start, end)
!      int posn;
!      Lisp_Object prop, *val;
!      int *start, *end;
! {
!   int noverlays;
!   Lisp_Object *overlay_vec, tem;
!   int next_overlay;
!   int len;
!   
! 				/* First try with room for 40 overlays.  */
!   len = 40;
!   overlay_vec = (Lisp_Object *) alloca (len * sizeof (Lisp_Object));
!   
!   noverlays = overlays_at (posn, 0, &overlay_vec, &len,
! 			   &next_overlay, NULL, 0);
! 
! 				/* If there are more than 40,
! 				   make enough space for all, and try again.  */
!   if (noverlays > len)
!     {
!       len = noverlays;
!       overlay_vec = (Lisp_Object *) alloca (len * sizeof (Lisp_Object));
!       noverlays = overlays_at (posn, 0, &overlay_vec, &len,
! 			       &next_overlay, NULL, 0);
!     }
!   noverlays = sort_overlays (overlay_vec, noverlays, NULL);
!   
! 				/* Now check the overlays in order of decreasing priority.  */
!   while (--noverlays >= 0)
!     {
!       tem = Foverlay_get (overlay_vec[noverlays], prop);
!       if (!NILP (tem))
! 	{
! 	  /* Return the overlay we got the property from.  */
! 	  *val = tem;
! 	  *start = XINT (Foverlay_start (overlay_vec[noverlays]));
! 	  *end = XINT (Foverlay_end (overlay_vec[noverlays]));
! 	  return 1;
! 	}
!     }
!   return 0;
! }
  
  static void
  adjust_point_for_property (last_pt)
***************
*** 1750,1788 ****
  {
    int start, end;
    Lisp_Object val;
!   int check_composition = 1, check_display = 1;
  
!   while (check_composition || check_display)
!     {
!       if (check_composition
! 	  && PT > BEGV && PT < ZV
! 	  && get_property_and_range (PT, Qcomposition, &val, &start, &end, Qnil)
! 	  && COMPOSITION_VALID_P (start, end, val)
! 	  && start < PT && end > PT
! 	  && (last_pt <= start || last_pt >= end))
  	{
! 	  if (PT < last_pt)
! 	    SET_PT (start);
! 	  else
! 	    SET_PT (end);
! 	  check_display = 1;
! 	}
!       check_composition = 0;
!       if (check_display
! 	  && PT > BEGV && PT < ZV
! 	  && get_property_and_range (PT, Qdisplay, &val, &start, &end, Qnil)
! 	  && display_prop_intangible_p (val)
  	  && start < PT && end > PT
  	  && (last_pt <= start || last_pt >= end))
  	{
! 	  if (PT < last_pt)
! 	    SET_PT (start);
! 	  else
! 	    SET_PT (end);
! 	  check_composition = 1;
  	}
-       check_display = 0;
      }
  }
  
  /* Subroutine for safe_run_hooks: run the hook HOOK.  */
--- 1819,1853 ----
  {
    int start, end;
    Lisp_Object val;
!   struct {
!     Lisp_Object prop; int (*pred) (int, int, Lisp_Object); int overlays;
!   } proptable[] =
!     { { Qcomposition, adjust_composition_valid_p, 0 },
!       { Qinvisible, adjust_text_prop_means_invisible, 1 },
!       { Qdisplay, adjust_display_prop_intangible_p, 1 } };
!   int i = 0, lastdone = 0;
  
!   do
  	{
!       int textprop = 1;
!       while (PT > BEGV && PT < ZV
! 	     && ((proptable[i].overlays
! 		  && get_property_overlay_and_range (PT, proptable[i].prop,
! 						    &val, &start, &end, Qnil)
! 		  && (textprop = 1))
! 		 || (textprop
! 		     && (textprop = 0,
! 			 get_property_and_range (PT, proptable[i].prop,
! 						 &val, &start, &end, Qnil))))
! 	     && proptable[i].pred (start, end, val)
  	  && start < PT && end > PT
  	  && (last_pt <= start || last_pt >= end))
  	{
! 	  SET_PT (PT < last_pt ? start : end);
! 	  lastdone = i;
  	}
      }
+   while (lastdone != (i = (i + 1) % 3));
  }
  
  /* Subroutine for safe_run_hooks: run the hook HOOK.  */


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

I wrote

    The change in adjust_point_for_property seems ok, and it might solve
    this problem.

However, subsequently I realized it should be somewhat different.  The
buffer position just after the invisible text should be treated as
part of the range where point cannot be.  (This is how invisible,
intangible text is handled now.)


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> I wrote
> 
>     The change in adjust_point_for_property seems ok, and it might solve
>     this problem.
> 
> However, subsequently I realized it should be somewhat different.  The
> buffer position just after the invisible text should be treated as
> part of the range where point cannot be.  (This is how invisible,
> intangible text is handled now.)

But that would make it very awkward for the user to insert text
immediately after the invisible area.

If we still want to provide the illusion that the text really isn't
there at all, then we should treat either the buffer position
immediately before or immediately after as part of the intangible text,
depending on the direction of the motion (so that both positions
can still be reached "easily").


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> > I wrote
> > 
> >     The change in adjust_point_for_property seems ok, and it might solve
> >     this problem.
> > 
> > However, subsequently I realized it should be somewhat different.  The
> > buffer position just after the invisible text should be treated as
> > part of the range where point cannot be.  (This is how invisible,
> > intangible text is handled now.)
> 
> But that would make it very awkward for the user to insert text
> immediately after the invisible area.
> 
> If we still want to provide the illusion that the text really isn't
> there at all, then we should treat either the buffer position
> immediately before or immediately after as part of the intangible text,
> depending on the direction of the motion (so that both positions
> can still be reached "easily").

And here is a patch that does just that.
Note that there are two (related) problems left:
- when the text is replaced by an ellipsis, the cursor is always drawn
  after the ellipsis even if point is immediately *before* the invisible text.
- I feel like this new "pretend the text isn't there at all" behavior
  works well for completely invisible text, but not for text with an
  elipsis where it makes sense for C-f or C-b to only skip over
  the hidden text rather than "the hidden text + 1".

Of course, the second point would be even more relevant if the first point
was addressed.


	Stefan


Index: keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.660
diff -u -u -b -r1.660 keyboard.c
*** keyboard.c	4 Mar 2002 23:40:59 -0000	1.660
--- keyboard.c	5 Mar 2002 23:28:44 -0000
***************
*** 1741,1788 ****
  
  /* Adjust point to a boundary of a region that has such a property
     that should be treated intangible.  For the moment, we check
!    `composition' and `display' property.  LAST_PT is the last position
!    of point.  */
  
  static void
  adjust_point_for_property (last_pt)
       int last_pt;
  {
    int start, end;
!   Lisp_Object val;
!   int check_composition = 1, check_display = 1;
  
!   while (check_composition || check_display)
      {
!       if (check_composition
! 	  && PT > BEGV && PT < ZV
! 	  && get_property_and_range (PT, Qcomposition, &val, &start, &end, Qnil)
! 	  && COMPOSITION_VALID_P (start, end, val)
! 	  && start < PT && end > PT
  	  && (last_pt <= start || last_pt >= end))
  	{
! 	  if (PT < last_pt)
! 	    SET_PT (start);
! 	  else
! 	    SET_PT (end);
! 	  check_display = 1;
  	}
-       check_composition = 0;
-       if (check_display
- 	  && PT > BEGV && PT < ZV
- 	  && get_property_and_range (PT, Qdisplay, &val, &start, &end, Qnil)
- 	  && display_prop_intangible_p (val)
- 	  && start < PT && end > PT
- 	  && (last_pt <= start || last_pt >= end))
- 	{
- 	  if (PT < last_pt)
- 	    SET_PT (start);
- 	  else
- 	    SET_PT (end);
- 	  check_composition = 1;
- 	}
-       check_display = 0;
      }
  }
  
  /* Subroutine for safe_run_hooks: run the hook HOOK.  */
--- 1741,1814 ----
  
  /* Adjust point to a boundary of a region that has such a property
     that should be treated intangible.  For the moment, we check
!    `composition', `display' and `invisible' properties.
!    LAST_PT is the last position of point.  */
! 
! static int
! adjust_composition_valid_p (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return COMPOSITION_VALID_P (start, end, val);
! }
! 
! static int
! adjust_text_prop_means_invisible (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return TEXT_PROP_MEANS_INVISIBLE (val);
! }
! 
! static int
! adjust_display_prop_intangible_p (start, end, val)
!      int start, end;
!      Lisp_Object val;
! {
!   return display_prop_intangible_p (val);
! }
  
  static void
  adjust_point_for_property (last_pt)
       int last_pt;
  {
    int start, end;
!   Lisp_Object val, overlay;
!   struct {
!     Lisp_Object prop; int (*pred) (int, int, Lisp_Object); int overlays;
!   } proptable[] =
!     { { Qcomposition, adjust_composition_valid_p, 0 },
!       { Qinvisible, adjust_text_prop_means_invisible, 1 },
!       { Qdisplay, adjust_display_prop_intangible_p, 1 } };
!   int i = 0, lastdone = 0;
  
!   do
      {
!       int textprop = 1;
!       while (PT > BEGV && PT < ZV
! 	     && ((proptable[i].overlays
! 		  && (val = get_char_property_and_overlay (make_number (PT),
! 							   proptable[i].prop,
! 							   Qnil, &overlay),
! 		      start = NILP (overlay)
! 		              ? 0 : XINT (Foverlay_start (overlay)),
! 		      end = NILP (overlay) ? 0 : XINT (Foverlay_end (overlay)),
! 		      !NILP (val) && !NILP (overlay))
! 		  && (textprop = 1))
! 		 || (textprop
! 		     && (textprop = 0,
! 			 get_property_and_range (PT, proptable[i].prop,
! 						 &val, &start, &end, Qnil))))
! 	     && proptable[i].pred (start, end, val)
! 	     && (PT < last_pt
! 		 ? (start <= PT && end > PT) : (start < PT && end >= PT))
  	  && (last_pt <= start || last_pt >= end))
  	{
! 	  SET_PT (PT < last_pt ? max (start - 1, BEGV) : min (end + 1, ZV));
! 	  lastdone = i;
  	}
      }
+   while (lastdone != (i = (i + 1) % 3));
  }
  
  /* Subroutine for safe_run_hooks: run the hook HOOK.  */


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    Maybe I shouldn't be trying so hard ?

Since this runs only once when the user types a character, it need not
be super efficient.

Instead of optimizing this function I suspect it will be a bigger
optimization not to call it at all after a self-insert.  It seems
clear to me that this adjustment is always a no-op after self-insert,
and most user input characters are self-inserting.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    > However, subsequently I realized it should be somewhat different.  The
    > buffer position just after the invisible text should be treated as
    > part of the range where point cannot be.  (This is how invisible,
    > intangible text is handled now.)

    But that would make it very awkward for the user to insert text
    immediately after the invisible area.

That is ok.  When text is invisible, it is very confusing
if point can be either before or after.  It is much better
if point can only be on one of those two places.

Please do it that way.

    If we still want to provide the illusion that the text really isn't
    there at all, then we should treat either the buffer position
    immediately before or immediately after as part of the intangible text,
    depending on the direction of the motion (so that both positions
    can still be reached "easily").

This behavior of this would be similar in most respects to what I ask
for, except less predictable.  So what I designed seems to be clearly
better.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     > However, subsequently I realized it should be somewhat different.  The
>     > buffer position just after the invisible text should be treated as
>     > part of the range where point cannot be.  (This is how invisible,
>     > intangible text is handled now.)
> 
>     But that would make it very awkward for the user to insert text
>     immediately after the invisible area.
> 
> That is ok.  When text is invisible, it is very confusing
> if point can be either before or after.  It is much better
> if point can only be on one of those two places.

I could agree to it but only in the case where the screen representation
is really empty, so that both cursor positions are displayed in the same way.
On the other hand, if the text is replaced by ellipsis or by an image,
it is very strange not to be able to position the cursor after the invisible
text.

> Please do it that way.

I think it'd be an error because it's only desirable in some rare cases,
and I suspect that those cases would be better served by explicitly
using the `intangible' text property.

>     If we still want to provide the illusion that the text really isn't
>     there at all, then we should treat either the buffer position
>     immediately before or immediately after as part of the intangible text,
>     depending on the direction of the motion (so that both positions
>     can still be reached "easily").
> 
> This behavior of this would be similar in most respects to what I ask
> for, except less predictable.  So what I designed seems to be clearly
> better.

It is just as predictable.  And it is clearly superior since it allows
to do things which your design does not.  I often edit text with
hidden subparts (using outline-minor-mode) and I often insert text either
right before or right after an invisible area.  Being unable to insert
text right after would be very annoying.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    I could agree to it but only in the case where the screen representation
    is really empty, so that both cursor positions are displayed in the same way.

That is the case we are talking about.

    On the other hand, if the text is replaced by ellipsis or by an image,
    it is very strange not to be able to position the cursor after the invisible
    text.

Images have nothing to do with this, because we're only talking about
the invisible property.  I agree that in the case of an ellipsis it is
right to allow point to be either before or after.  In that case, the
user can see the difference between the two positions, so it is not
confusing.

    I think it'd be an error because it's only desirable in some rare cases,
    and I suspect that those cases would be better served by explicitly
    using the `intangible' text property.

This discussion started by noting that buffer-invisible-spec cannot
control intangibility.  We need to get the same effect as intangible,
but controlled with buffer-invisible-spec or something like it.  I was
thinking of making invisible imply intangible, but you proposed to do
the job here instead.

Doing the job here is ok, but it has to work the right way, the same
way that invisible/intangible text works.

Would you please make this work?  I will do it myself if necessary,
but I really would rather be able to keep up with my other work.



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    >     I could agree to it but only in the case where the screen representation
    >     is really empty, so that both cursor positions are displayed in the same
    >     way.
    > 
    > That is the case we are talking about.

    I do not know how to detect that case robustly.

Whenever the text is invisible and does not display an ellipsis.
The value of TEXT_PROP_MEANS_INVISIBLE will tell you whether this
is the case.

    But some texts can have both an image and the invisible property.

Shouldn't that make the image invisible?  The image property should
have no effect when the text is invisible.  (It doesn't matter what
the text wou;d looks like, if you don't see it.)

Is that not what happens now?

      In my experience
    most cases where I encounter invisible text (and where point can easily
    end up inside the invisible text) is with things like outline-minor-mode
    and hs-minor-mode (i.e. text replaced by ellisps), so that's what I consider
    as the most important case to handle.

What you want is right for that case, the case where an ellipsis is
displayed.  I am talking about what to do in the other case, the case
where the text is not replaced by an ellipsis.

    It looks like you have another kind of scenario in mind, but I don't know
    what it looks like.

The scenario is one where message header lines are marked as invisible
using overlays, the goal being to hide them.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     >     I could agree to it but only in the case where the screen representation
>     >     is really empty, so that both cursor positions are displayed in the same
>     >     way.
>     > 
>     > That is the case we are talking about.
> 
>     I do not know how to detect that case robustly.
> 
> Whenever the text is invisible and does not display an ellipsis.
> The value of TEXT_PROP_MEANS_INVISIBLE will tell you whether this
> is the case.

That much I know, but the problem is when there's some other property
like a `display' property that ends up displaying something.

>     But some texts can have both an image and the invisible property.
> 
> Shouldn't that make the image invisible?  The image property should
> have no effect when the text is invisible.  (It doesn't matter what
> the text wou;d looks like, if you don't see it.)
> 
> Is that not what happens now?

It seems not since David uses display+invisible when replacing TeX source
code with an image of the output in his preview-latex package (the `invisible'
property seems useless at first, but he uses it so he can use the
isearch-open-invisible hook).

>       In my experience
>     most cases where I encounter invisible text (and where point can easily
>     end up inside the invisible text) is with things like outline-minor-mode
>     and hs-minor-mode (i.e. text replaced by ellisps), so that's what I consider
>     as the most important case to handle.
> 
> What you want is right for that case, the case where an ellipsis is
> displayed.  I am talking about what to do in the other case, the case
> where the text is not replaced by an ellipsis.
> 
>     It looks like you have another kind of scenario in mind, but I don't know
>     what it looks like.
> 
> The scenario is one where message header lines are marked as invisible
> using overlays, the goal being to hide them.

Any reason why those cannot explicitly use the `intangible' property ?


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    That much I know, but the problem is when there's some other property
    like a `display' property that ends up displaying something.

If the text is invisible, it should not display *anything* no matter
what other properties it has (including `display', `after-string' and
`before-string').  An invisible piece of text should not contribute to
the screen contents (except for the ellipsis, if any).

    It seems not since David uses display+invisible when replacing TeX source
    code with an image of the output in his preview-latex package (the `invisible'
    property seems useless at first, but he uses it so he can use the
    isearch-open-invisible hook).

Isn't it the case that specifying an image with a property on some text
replaces the text with the image?  I think so.

If that is so, I don't understand what purpose this invisible property
is supposed to serve.  Can you explain?  I cannot figure out, from the
mere reference to isearch-open-invisible, what he is trying to do.

Anyway, it is clearly a bug if invisible fails to completely suppress
the display of the text it covers.

    > The scenario is one where message header lines are marked as invisible
    > using overlays, the goal being to hide them.

    Any reason why those cannot explicitly use the `intangible' property ?

Because the invisibility of these lines is controlled
buffer-invisibility-spec, and that can't control the intangible
property.  This text is visible sometimes and invisible sometimes,
and we want to change that *without* changing the text properties
directly.

The text should be intangible when it is invisible, and not when it is
not.  And none of that should require changing actual text properties.




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     That much I know, but the problem is when there's some other property
>     like a `display' property that ends up displaying something.
> 
> If the text is invisible, it should not display *anything* no matter
> what other properties it has (including `display', `after-string' and
> `before-string').  An invisible piece of text should not contribute to
> the screen contents (except for the ellipsis, if any).

Actually, I am using overlays here.  The overlay I use has the
display property set (to an image), and it has the invisible property
set.  This makes the original text invisible (in my book), and
displays some graphic.  Since the display property is that of the
overlay and not of the text, I find this more or less acceptable.

>     It seems not since David uses display+invisible when replacing
>     TeX source code with an image of the output in his preview-latex
>     package (the `invisible' property seems useless at first, but he
>     uses it so he can use the isearch-open-invisible hook).
> 
> Isn't it the case that specifying an image with a property on some
> text replaces the text with the image?  I think so.

Yes.

> If that is so, I don't understand what purpose this invisible
> property is supposed to serve.  Can you explain?  I cannot figure
> out, from the mere reference to isearch-open-invisible, what he is
> trying to do.

When somebody uses isearch in order to look for strings in the buffer,
I want to have the original text displayed where appropriate.
isearch-open-invisible will call a user-supplied hook in order to make
invisible texts appear when searching.  Those images I use in my
buffer effectively make the original text invisible (for example, I
replace $\frac{\pi}{3}$ by an image for the formula), so I want
isearch to "open" them while going through the buffer.  isearch will,
however, only call isearch-open-invisible if the text/overlay is
marked as invisible, so that is what I do.

> Anyway, it is clearly a bug if invisible fails to completely
> suppress the display of the text it covers.

The text is not displayed.  I presume that if a display property was
present as a text property of the text, that the text would still be
invisible.  The display property of the *overlay*, however, is not
really connected with the text.  For example, you can have empty
overlays (not covering any text) with a display property.  Those
effectively are "visible markers": you cannot change or delete them,
but they move around like markers when inserting and deleting things.
Since the display property of an overlay is not a property of the
text, I find it quite acceptable that it gets not masked out by the
invisible property.  Things would be different if we were talking
about a display property placed on text marked as invisible.

> The text should be intangible when it is invisible, and not when it
> is not.  And none of that should require changing actual text
> properties.

Intangibility in its current implementation is *much* too
heavy-handed for getting automatically activated.  It has lots of bad
side-effects, like making count-lines act differently and stuff.

I _strongly_ suggest that you refrain from making invisible text
intangible automatically.  It is ok to have point-adjustment (namely,
use the cursor out of invisible areas after a user command
completes), but the semantics of "intangible" disturb all buffer
manipulations.  Lots of packages will break if you apply it
automatically.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     > The scenario is one where message header lines are marked as invisible
>     > using overlays, the goal being to hide them.
> 
>     Any reason why those cannot explicitly use the `intangible' property ?
> 
> Because the invisibility of these lines is controlled
> buffer-invisibility-spec, and that can't control the intangible
> property.  This text is visible sometimes and invisible sometimes,
> and we want to change that *without* changing the text properties
> directly.
> 
> The text should be intangible when it is invisible, and not when it is
> not.  And none of that should require changing actual text properties.

Now it all makes a lot more sense, thank you.
I guess that's the part of the beginning of the discussion that I missed.
I'll see what code I can come up with,


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> >     > The scenario is one where message header lines are marked as
> >     > invisible using overlays, the goal being to hide them.
> > 
> >     Any reason why those cannot explicitly use the `intangible'
> >     property ?
> > 
> > Because the invisibility of these lines is controlled
> > buffer-invisibility-spec, and that can't control the intangible
> > property.  This text is visible sometimes and invisible sometimes,
> > and we want to change that *without* changing the text properties
> > directly.
> > 
> > The text should be intangible when it is invisible, and not when
> > it is not.  And none of that should require changing actual text
> > properties.
> 
> Now it all makes a lot more sense, thank you.
> I guess that's the part of the beginning of the discussion that I missed.
> I'll see what code I can come up with,

I don't think it appropriate to hack intangibility into the invisible
property just because intangibility happens to be missing an API that
invisibility has.

It will do no harm if the user gets his cursor moved out of invisible
areas at command completion time (as is done with point adjustment),
but the semantics of the intangibility property are much more
severe.  It violates a lot of assumptions a programmer might make
about how text behaves and should not be applied lightly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> > > The text should be intangible when it is invisible, and not when
> > > it is not.  And none of that should require changing actual text
> > > properties.
> > 
> > Now it all makes a lot more sense, thank you.
> > I guess that's the part of the beginning of the discussion that I missed.
> > I'll see what code I can come up with,
> 
> I don't think it appropriate to hack intangibility into the invisible
> property just because intangibility happens to be missing an API that
> invisibility has.
> 
> It will do no harm if the user gets his cursor moved out of invisible
> areas at command completion time (as is done with point adjustment),
> but the semantics of the intangibility property are much more
> severe.  It violates a lot of assumptions a programmer might make
> about how text behaves and should not be applied lightly.

I understand that.  When I say "intangible" I just mean that the
cursor will be somehow moved outside of the area.  When I mean intangibility
as is implemented by the `intangible' property, I say it explicitly.

I intend to provide the "invisible is intangible" by extending
the point adjustment function, as in my previous patch.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    I don't think it appropriate to hack intangibility into the invisible
    property just because intangibility happens to be missing an API that
    invisibility has.

I have decided that something along these lines must be done.



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    isearch-open-invisible will call a user-supplied hook in order to make
    invisible texts appear when searching.  Those images I use in my
    buffer effectively make the original text invisible (for example, I
    replace $\frac{\pi}{3}$ by an image for the formula), so I want
    isearch to "open" them while going through the buffer.  isearch will,
    however, only call isearch-open-invisible if the text/overlay is
    marked as invisible, so that is what I do.

It would make more sense to modify isearch-open-invisible so it can
deal with these images in another way.  The invisible property should
override the display property and make the text it covers not appear,
not as itself, not modified by a display property.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     isearch-open-invisible will call a user-supplied hook in order to make
>     invisible texts appear when searching.  Those images I use in my
>     buffer effectively make the original text invisible (for example, I
>     replace $\frac{\pi}{3}$ by an image for the formula), so I want
>     isearch to "open" them while going through the buffer.  isearch will,
>     however, only call isearch-open-invisible if the text/overlay is
>     marked as invisible, so that is what I do.
> 
> It would make more sense to modify isearch-open-invisible so it can
> deal with these images in another way.  The invisible property should
> override the display property and make the text it covers not appear,
> not as itself, not modified by a display property.

Well, I already explained that in the case of an overlay, the display
property is not really connected with the text but with the buffer
locations.  An overlay can cover an empty range of text, and still
have a display, before-string and after-string appear in a buffer.
If you want to have the display, before-string, and after-string be
covered by an invisibility property, you should tack the invisibility
property on the respective strings you store in the overlay
properties instead, since the invisibility property of the overlay
itself is supposed to apply to the covered text, not to the overlay
itself.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

>     isearch-open-invisible will call a user-supplied hook in order to make
>     invisible texts appear when searching.  Those images I use in my
>     buffer effectively make the original text invisible (for example, I
>     replace $\frac{\pi}{3}$ by an image for the formula), so I want
>     isearch to "open" them while going through the buffer.  isearch will,
>     however, only call isearch-open-invisible if the text/overlay is
>     marked as invisible, so that is what I do.
> 
> It would make more sense to modify isearch-open-invisible so it can
> deal with these images in another way.  The invisible property should
> override the display property and make the text it covers not appear,
> not as itself, not modified by a display property.

I'm not completely sure about that.  After all, why would someone
put a `display' property on an `invisible' overlay if the `invisible'
property means that the `display' property will be ignored anyway ?

In the case of `display' properties, I agree that your point of view
might be acceptable, but in the case of `before-string' and `after-string'
it is clearly not so, because it is very common to use an overlay
with both the `before-string' and the `invisible' property in order
to replace a piece of text with another.  In such a case we again end
up with `invisible' text which does have a screen representation so that
having point before or after the invisible text is user-visible
(just as is the case with ellipsis), which implies that we again shouldn't
prevent the user from placing point immediately after the invisible text.

I hope you're beginning to see what I meant when I said that it's
not easy to determine when a piece of `invisible' text really has
no effect on screen.  Checking the invisibility-spec is not enough:
you also have to check the presence of a `before-string' or an
`after-string' or a `display' (although this last one might disappear
if you decide that its behavior should be changed) and maybe there
are other cases.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> I'm not completely sure about that.  After all, why would someone
> put a `display' property on an `invisible' overlay if the `invisible'
> property means that the `display' property will be ignored anyway ?

Perhaps the properties come from different sources (e.g., one form a
text property, one from an overlay)?

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> > I'm not completely sure about that.  After all, why would someone
> > put a `display' property on an `invisible' overlay if the `invisible'
> > property means that the `display' property will be ignored anyway ?
> 
> Perhaps the properties come from different sources (e.g., one form a
> text property, one from an overlay)?

I was specifically referring to the case where both properties come
from the same overlay.  I don't know what should (or does) happen
when the two properties come from different sources.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> >     isearch-open-invisible will call a user-supplied hook in order to make
> >     invisible texts appear when searching.  Those images I use in my
> >     buffer effectively make the original text invisible (for example, I
> >     replace $\frac{\pi}{3}$ by an image for the formula), so I want
> >     isearch to "open" them while going through the buffer.  isearch will,
> >     however, only call isearch-open-invisible if the text/overlay is
> >     marked as invisible, so that is what I do.
> > 
> > It would make more sense to modify isearch-open-invisible so it can
> > deal with these images in another way.  The invisible property should
> > override the display property and make the text it covers not appear,
> > not as itself, not modified by a display property.
> 
> I'm not completely sure about that.  After all, why would someone
> put a `display' property on an `invisible' overlay if the `invisible'
> property means that the `display' property will be ignored anyway ?
> 
> In the case of `display' properties, I agree that your point of view
> might be acceptable, but in the case of `before-string' and
> `after-string' it is clearly not so, because it is very common to
> use an overlay with both the `before-string' and the `invisible'
> property in order to replace a piece of text with another.

Ok, I'll try now to be as pedantic as possible with regard to this.
If we make a large text area invisible, and there are some images
contained entirely within it, we would usually want to have them
disappear together with the hidden text.  Now in the case of overlays,
those are not connected with single characters, but with buffer
positions.  What to do in case an overlay ends exactly on a boundary
between visible and invisible text?  If we are at a boundary where
invisibility starts, the before-string is to be displayed before the
overlay, before invisibility starts.  If we are at a boundary where
invisibility ends, the after-string is to be displayed after the
overlay, after invisibility ends.  Since the invisibility property of
the overlay is proposed by Richard to be equivalent to the covered
text bearing an invisibility property, it would be entirely
consistent to let the before-string and after-string show in the case
that invisibility starts at the start of the overlay, or ends at the
end, respectively.  If you want to have the invisibility extend to
the before-string and after-string also in case where they sit on a
border of invisibility, add the appropriate text properties to the
strings themselves.

Now the question remains what to do with the display property itself.
In case the overlay lies completely contained within an invisible area
(as determined by text properties or another overlay with invisible
property), it should not display.  That much is obvious.  But if start
and/or end lie on the edge, what should we do?  If we really are
pedantic, the behavior will depend on the stickiness of the
invisibility borders.  If a character inserted at the front of the
overlay will be visible (namely the overlay-start marker is of the
moving type and the text invisibility comes from the overlay), the
overlay can be visible.  If a character inserted at the end of the
overlay will be visible (the overlay-marker of the non-moving kind),
the overlay can be visible, too.  If one would want finer control,
one would put a string into the display property.  Unfortunately, a
display property on characters of this string gets ignored, so there
is no way to show an image via that path.  I would prefer it if
recursive display properties would be heeded (perhaps with a hard
limit on the recursiveness, but exceeding the single level allowed
currently).  The most desirable semantics are less than clear here.


> In such a case we again end up with `invisible' text which does have
> a screen representation so that having point before or after the
> invisible text is user-visible (just as is the case with ellipsis),
> which implies that we again shouldn't prevent the user from placing
> point immediately after the invisible text.

Actually, there is a fine distinction here.  The cursor can never be
immediately before a before-string.  It is either strictly before the
start of the overlay, in which case it is one character away from the
before-string, or it is on the first character of the overlay, in
which case it is _after_ the before-string.  It would make no sense
to let it jump before the before-string once the text gets made
invisible, so the cursor as an indication of point will never appear
immediately before a before-string image.  In a similar vein, it can
never appear to be on an after-string image, but either on a
character before it, or on one after it.  The cursor *can*, however
appear on an image displayed with the display property.

> I hope you're beginning to see what I meant when I said that it's
> not easy to determine when a piece of `invisible' text really has no
> effect on screen.  Checking the invisibility-spec is not enough: you
> also have to check the presence of a `before-string' or an
> `after-string' or a `display' (although this last one might
> disappear if you decide that its behavior should be changed) and
> maybe there are other cases.

'display can carry various items.  Some *modify* the text under
consideration (different faces, for example).  The modifications
should certainly be made invisible together with the text affected by
invisibility spec of the overlay itself.  But those display properties
that *replace* the text altogether, well... see the above.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> > "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> > > I'm not completely sure about that.  After all, why would someone
> > > put a `display' property on an `invisible' overlay if the `invisible'
> > > property means that the `display' property will be ignored anyway ?
> > 
> > Perhaps the properties come from different sources (e.g., one form a
> > text property, one from an overlay)?
> 
> I was specifically referring to the case where both properties come
> from the same overlay.  I don't know what should (or does) happen
> when the two properties come from different sources.

I think it is reasonable to say that the overlay should not display
in case the entire range it covers (where the borders are decided
upon with the help of stickiness) can be said to lie within a closed
interval of invisibility.  If insertion immediately after the overlay
will not cause an invisible character, I would display entities from
entirely within the display property and the after-string.  If
insertion immediately before the overlay will not cause an invisible
character, the same holds for display property and before-string.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Stefan Monnier]

> Actually, there is a fine distinction here.  The cursor can never be
> immediately before a before-string.  It is either strictly before the
> start of the overlay, in which case it is one character away from the
> before-string, or it is on the first character of the overlay, in
> which case it is _after_ the before-string.

I believe that the behavior should again depend on the insertion-type
of the overlay's boundary.  If point is just at the beginning of an
overlay with a before-string and inserting a char will move the
overlay's boundary, then the cursor should be displayed before
the before-string.
This was recently brought up when discussing code that adds a "¶" at
end of paragraphs (using a before-string property): the current code
always displays the cursor just after this string, which looks very odd
since typed text will be inserted before the string.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> I believe that the behavior should again depend on the insertion-type
> of the overlay's boundary.  If point is just at the beginning of an
> overlay with a before-string and inserting a char will move the
> overlay's boundary, then the cursor should be displayed before
> the before-string.
> This was recently brought up when discussing code that adds a "¶" at
> end of paragraphs (using a before-string property): the current code
> always displays the cursor just after this string, which looks very odd
> since typed text will be inserted before the string.

You are going to make one mess out of my preview-latex package.  One
problem with making this depend on the insertion properties of overlay
markers is that it is not possible to change them once the overlay is
created.

Take preview-latex (illustration at the screen shot in
<URL:http://preview-latex.sourceforge.net>): if an overlay is opened
and I place the cursor at its beginning, it is after the before-string
carrying the "head" icon.  Inserting text here naturally inserts into
the overlay.  If the overlay is closed, it is replaced by the typeset
rendition of the text inside (by virtue of the display property, not
the before-string).  Inserting text when the cursor is on the start of
the overlay naturally inserts before the overlay.

How do I cope?  I cannot change the insertion type of those markers,
and if I did, undo would probably stop working (unless undo events
were invented that could record the change of a marker type).  So I
cope by always using non-moving markers, and if someone inserts text
in front of my overlay, I catch this with the insert-in-front-hook of
the overlay and move the overlay start by hand.  Unless
undo-in-progress is set, because an insertion carried out due to an
undo will already cope with the marker.

Hm.  Actually, it seems like the proposed change making the side on
which the cursor gets displayed depend on the insertion type of the
marker would not change the behavior of my code.  I luck out.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> This was recently brought up when discussing code that adds a "¶" at
> end of paragraphs (using a before-string property): the current code
> always displays the cursor just after this string, which looks very odd
> since typed text will be inserted before the string.

I agree strongly, I absolutely hate the way it currently works -- it's
basically just _wrong_ for inserted text to appear somewhere far away
from the cursor like that.

I looked at fixit it a while ago (this issue comes periodically in
different contexts, which seems like a pretty good clue that it's really
a problem), and unfortunately, it didn't seem entirely trivial to
implement.  By the time the code decides where to place the cursor,
information about where everything came from is gone, so additional info
has to be propagated through parts of the redisplay mechanism.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> > This was recently brought up when discussing code that adds a "¶" at
> > end of paragraphs (using a before-string property): the current code
> > always displays the cursor just after this string, which looks very odd
> > since typed text will be inserted before the string.
> 
> I agree strongly, I absolutely hate the way it currently works -- it's
> basically just _wrong_ for inserted text to appear somewhere far away
> from the cursor like that.

In this particular case the problem could be avoided by setting the
display property of the newline in question to "¶\n" instead of
setting its before-string.  But I agree that the behavior seems weird.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    Well, I already explained that in the case of an overlay, the display
    property is not really connected with the text but with the buffer
    locations.

You've stated your views, but I don't agree.




_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Well, I already explained that in the case of an overlay, the display
>     property is not really connected with the text but with the buffer
>     locations.
> 
> You've stated your views, but I don't agree.

In the case you should put forward a proposal that matches your views
consistently.  In particular, how would your model treat an overlay
having a display property with an image in it, when the text up to and
including character 10 of the buffer was invisible (due to a text
property, for example), and both overlay-start and overlay-end are 11.
This is an empty overlay, not convering any character, and the
character left from it is invisible, the character right from it is
visible.  According to your opinion, the visibility of the overlay
should be connected with the text it covers, but it does not cover
any.

So how would you want to treat this case?  There is a price I will
have to pay for an implementation of your views: it will be rather
hard to come up with working code for the preview-latex package for
both Emacs-21.3 and Emacs-21.1, and people upgrading their Emacs while
keeping a now current version of preview-latex will have it break.  I
would be loath to pay this price for the mere replacement of one
inconsistent interface with another.

So please let us get a complete scheme worked out of how to deal with
all cases involved before implementing things, and save the actual
interface change for 21.3, letting 21.2 still work in the old way.

Thanks,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

    I was specifically referring to the case where both properties come
    from the same overlay.  I don't know what should (or does) happen
    when the two properties come from different sources.

The simplest and cleanest thing to do is make the definition
of each property independent of how it gets applied.
We have to be very hesitant about making the meaning of a property
different for overlays vs text properties.

      Now in the case of overlays,
    those are not connected with single characters, but with buffer
    positions.

They are connected with a range of buffer positions, which covers
a run of characters.

      If we are at a boundary where
    invisibility starts, the before-string is to be displayed before the
    overlay, before invisibility starts.

That rule could be coherent both for text properties and for overlays.
Another coherent alternative would be to say that when a character is
invisible its before-string and after-string do not appear.  I am not
sure which is better--perhaps whichever one is easier to implement.
But I think text properties and overlays should do the same thing.

    Now the question remains what to do with the display property itself.
    In case the overlay lies completely contained within an invisible area
    (as determined by text properties or another overlay with invisible
    property), it should not display.  That much is obvious.  But if start
    and/or end lie on the edge, what should we do?  If we really are
    pedantic, the behavior will depend on the stickiness of the
    invisibility borders.

The display property has nothing particularly to do with stickiness.
Whether it specifies an image or something else, in all cases it
modifies the appearance for of text.  Its definition should be fixed
and static, and not affected by stickiness.  If the text is invisible,
the display property should be ignored.



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Richard Stallman]

      In particular, how would your model treat an overlay
    having a display property with an image in it, when the text up to and
    including character 10 of the buffer was invisible (due to a text
    property, for example), and both overlay-start and overlay-end are 11.

Your previous statements did not say that you meant empty overlays
only.  I was thinking of nonempty overlays.  For empty overlays, the
treatment you proposed might be right.  At least it seems plausible
to try.

It would be useful to have functions to get the text properties (or
just one of them) that would be inherited by an insertion at a given
buffer position.  It looks like that would be useful as a subroutine
for many purposes.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       In particular, how would your model treat an overlay
>     having a display property with an image in it, when the text up to and
>     including character 10 of the buffer was invisible (due to a text
>     property, for example), and both overlay-start and overlay-end are 11.
> 
> Your previous statements did not say that you meant empty overlays
> only.

Nor did this statement.  The point I wanted to make but apparently
failed to get across is that any behavior for treating the
invisibility property should work consistently with the special case
of empty overlays.

> I was thinking of nonempty overlays.  For empty overlays, the
> treatment you proposed might be right.  At least it seems plausible
> to try.
> 
> It would be useful to have functions to get the text properties (or
> just one of them) that would be inherited by an insertion at a given
> buffer position.  It looks like that would be useful as a subroutine
> for many purposes.

Now this failure to get my meaning across certainly is my fault for
using the wrong words.  What I wanted to make the behavior depend on
was not the stickiness of properties, but actually the marker
insertion type of the overlay boundaries.  I apologize for the
confusion.  Probably with text properties indeed the stickiness might
be interesting, but here I am currently concerned with overlays.

Let's try to come up with the most consistent behavior for cursor
display and invisibility display.

As Stefan (or was it Miles?) has already remarked, the default
display of cursors should preferably be such that an insertion of new
characters will occur at the location where the cursor is visible.
Let's first talk this through without the further complication of
invisibility.

If point is on the first character of a text-range with a
before-string property (this property only works with overlays), this
means that the cursor should display on the first character of the
range if the insertion type of the overlays begin marker is
don't-move-on-insertion, but it should display on the before-string
itself if the insertion type is move-on-insertion.  Similar behavior
would apply if point is on the first character following an overlay.

Ok, now we have the case that the cursor is usually moved out of
invisible areas (point adjustment) and currently cannot be positioned
immediately behind an invisible area so that cursor movement does not
appear to hesitate.  If the cursor is kept out of invisible areas, it
makes sense to try to define the insertion such that wherever a legal
cursor position is, insertion characters will not insert into the
invisible area.

This cannot always be achieved: when the overlay-beginning marker is
of the stay-before-insertion variety, and the overlay-end marker is
of the move-after-insertion variety, there will be no cursor position
between the preceding visible and the following visible character
where inserted characters would not become invisible.

The other cases can be dealt with consistently: if both markers are
of the moving variety, we want to have the cursor position before
the overlay legal.  If both are of the staying variety, we want to
have the cursor position behind the overlay legal.  If the front
marker is of the moving and the end marker of the staying variety, I
would tend to make the position behind the invisible overlay legal (so
that the overlay does not move), and the pathological case where
inserted characters disappear should be treated the same so that
successively entered invisible characters will appear (after point
adjustment) in the right order at the end of the invisible area.  If
the position before the invisible area would be the legal one, then
one character would get inserted invisibly, but then the cursor would
move to after the character following the overlay -- unpretty.

Now to the visibility of before-string and after-string: as pointed
out already, it is a common idiom to set some text (often just an "x")
to invisible and place a before-string or after-string for an image
instead, so we would not want to have those disappear in the common
case.

Afraid I am too tired currently to work out this in detail, too.  If
anybody cares about these sort of ramblings, I can try to think about
it later.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[Eli Zaretskii]

On 19 Mar 2002, David Kastrup wrote:

> As Stefan (or was it Miles?) has already remarked, the default
> display of cursors should preferably be such that an insertion of new
> characters will occur at the location where the cursor is visible.

Mostly unrelated to the current discussion, but I thought I'd raise that 
anyway: the principle that insertion should happen at cursor location is 
not carved in stone.  It will possibly not hold with bidirectional 
editing: when typing bidirectional text, it sometimes makes sense to 
insert characters not at the cursor (some editors do that).

So I think the possibility that insertion happens not at cursor should 
not be discarded right away: perhaps it makes sense to users in some 
situations.  (I'm not saying that the situations you are discussing are 
such cases.)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 19 Mar 2002, David Kastrup wrote:
> 
> > As Stefan (or was it Miles?) has already remarked, the default
> > display of cursors should preferably be such that an insertion of new
> > characters will occur at the location where the cursor is visible.
> 
> Mostly unrelated to the current discussion, but I thought I'd raise
> that anyway: the principle that insertion should happen at cursor
> location is not carved in stone.  It will possibly not hold with
> bidirectional editing: when typing bidirectional text, it sometimes
> makes sense to insert characters not at the cursor (some editors do
> that).
> 
> So I think the possibility that insertion happens not at cursor
> should not be discarded right away: perhaps it makes sense to users
> in some situations.  (I'm not saying that the situations you are
> discussing are such cases.)

We have not discarded it right away, it currently is happening.  But
the usual semantics should be "least element of surprise".  In case
where a certain application would have different requirements, it
would be better to add appropriate hooks instead of relying on
undocumented artifacts that are surprising in their default
behaviour.  One could probably work with pre-command-hook and the
like if one wanted to achieve something like that.  That would seem
more appropriate than trying to fiddle around with the before-string
property of overlays.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Should invisible imply intangible?

[David Kastrup]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

> > Actually, there is a fine distinction here.  The cursor can never be
> > immediately before a before-string.  It is either strictly before the
> > start of the overlay, in which case it is one character away from the
> > before-string, or it is on the first character of the overlay, in
> > which case it is _after_ the before-string.
> 
> I believe that the behavior should again depend on the insertion-type
> of the overlay's boundary.  If point is just at the beginning of an
> overlay with a before-string and inserting a char will move the
> overlay's boundary, then the cursor should be displayed before
> the before-string.
> This was recently brought up when discussing code that adds a "¶" at
> end of paragraphs (using a before-string property): the current code
> always displays the cursor just after this string, which looks very odd
> since typed text will be inserted before the string.

I just wanted to call back in order to report that preview-latex is
out of the debate.  I don't use the invisible text property any more.
And I don't use the isearch-invisible hooks anymore.  And I don't
want to have isearch bother about opening my overlays anymore (even
though they use the display property.  isearch never cared for that
up to now, and it should not do so in future.  If it will, I want to
know as soon as possible in order to know how to keep it from
bothering).

All that I ask is that
a) isearch and its cousins keep setting disable-point-adjustment to t
   when they don't want the cursor to be moved from the point of
   replacement
b) post-command-hook gets run *before* Emacs tries to attempt any point
   adjustment itself.

If it does, I have the choice of either
a) doing point adjustment the way I feel right if
disable-point-adjustment and global-disable-point-adjustment are not
set
b) remove the display property of my overlay if they are, so that
Emacs' point-adjustment will not have to do anything.
c) set disable-point-adjustment in the post-command-hook in order to
signal Emacs it should not bother itself.

I would be quite happy if query-replace would also run
post-command-hook with disable-point-adjustment set for every
replacement, but that's a different story.  Perhaps I'll be able to
find a way to persuade it to do the equivalent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel