GNU bug report logs - #19200
Point adjustment moves *into* invisible text

Previous Next

Full log

Message #89 received at 19200 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: michael_heerdegen <at> web.de, jonas <at> bernoul.li, 19200 <at> debbugs.gnu.org
Subject: Re: bug#19200: Point adjustemnt moves *into* invisible text
Date: Thu, 31 Mar 2016 20:17:53 +0300

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: 19200 <at> debbugs.gnu.org, michael_heerdegen <at> web.de, jonas <at> bernoul.li
> Date: Wed, 23 Mar 2016 12:10:26 -0400
> 
> So someone needs to step through the code and figure out why this
> doesn't happen.

I guess you expected me to be that Someone...

> E.g. maybe it doesn't happen because adjust_point_for_property is
> not called at all.

It _is_ called.

> >> The issue of the main bug is not so much that we don't know how to fix
> >> it, but that noone has bothered to investigate it to try and figure out
> >> what is actually happening.
> > Didn't I do that?  Doesn't the fact that the relevant code calls
> > get-char-property-and-overlay explain what happens?
> 
> No: the get-char-property-and-overlay calls will only determine the
> boundaries of the invisible text (i.e. they should find that the
> invisible chunk goes between 3 and 5).

The function is entered with point at 5, so 'beg' and 'end' start with
that value.

Then get_char_property_and_overlay in the "while (end < ZV" loop
returns nil for position 5, so that loop is exited immediately.

Then a similar call in the "while (beg > BEGV" loop returns t for
position 5 - 1 = 4.  Then previous-single-char-property-change returns
3, so 'beg' becomes 3.  Then another call to
get_char_property_and_overlay returns nil for position 3 - 1 = 2, and
the while loop is exited with beg = 3 and end = 5.  Since point is 5,
we land here:

	  /* Pretend the area doesn't exist if the buffer is not
	     modified.  */
	  if (!modified && !ellipsis && beg < end)
	    {
	      if (last_pt == beg && PT == end && end < ZV)
		(check_composition = check_display = true, SET_PT (end + 1));
	      else if (last_pt == end && PT == beg && beg > BEGV)
		(check_composition = check_display = true, SET_PT (beg - 1));
	      else if (PT == ((PT < last_pt) ? beg : end))
		/* We've already moved as far as we can.  Trying to go
		   to the other end would mean moving backwards and thus
		   could lead to an infinite loop.  */
		;
	      else if (val = Fget_pos_property (make_number (PT),
						Qinvisible, Qnil),
		       TEXT_PROP_MEANS_INVISIBLE (val)
		       && (val = (Fget_pos_property
				  (make_number (PT == beg ? end : beg),
				   Qinvisible, Qnil)),
			   !TEXT_PROP_MEANS_INVISIBLE (val)))
		(check_composition = check_display = true,
		 SET_PT (PT == beg ? end : beg));
	    }

last_pt is 1, so we wind up in this branch:

	      else if (PT == ((PT < last_pt) ? beg : end))
		/* We've already moved as far as we can.  Trying to go
		   to the other end would mean moving backwards and thus
		   could lead to an infinite loop.  */
		;

which does nothing.  So point never moves and stays at 5.

> After that, adjust_point_for_property should start by moving point to
> position 3 (because last_pt should be < 3).

It doesn't.

> And after that it should use Fget_pos_property to decide whether to stay
> at position 3 or to move to position 5, and in this case it should
> choose to stay at position 3.

It doesn't get there.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.