all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: michael_heerdegen@web.de, jonas@bernoul.li, 19200@debbugs.gnu.org
Subject: bug#19200: Point adjustemnt moves *into* invisible text
Date: Thu, 31 Mar 2016 20:17:53 +0300	[thread overview]
Message-ID: <837fgiva66.fsf@gnu.org> (raw)
In-Reply-To: <jwvoaa5b39c.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Wed, 23 Mar 2016 12:10:26 -0400)

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 19200@debbugs.gnu.org, michael_heerdegen@web.de, jonas@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.





  reply	other threads:[~2016-03-31 17:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26 22:22 bug#19200: Point adjustemnt moves *into* invisible text Stefan Monnier
2016-03-20 22:58 ` Michael Heerdegen
2016-03-21  1:21   ` Stefan Monnier
2016-03-21  2:15     ` Michael Heerdegen
2016-03-21  2:23       ` Michael Heerdegen
2016-03-21 18:30         ` Eli Zaretskii
2016-03-21 12:08       ` Stefan Monnier
2016-03-21 14:52         ` Michael Heerdegen
2016-03-21 15:36           ` Stefan Monnier
2016-03-21 15:54             ` Michael Heerdegen
2016-03-21 18:08               ` Stefan Monnier
2016-03-21 18:28             ` Eli Zaretskii
2016-03-21 19:24               ` Michael Heerdegen
2016-03-21 19:40                 ` Eli Zaretskii
2016-03-21 20:10                   ` Michael Heerdegen
2016-03-21 20:21                     ` Michael Heerdegen
2016-03-21 20:43               ` Stefan Monnier
2016-03-22 16:39                 ` Eli Zaretskii
2016-03-22 18:36                   ` Stefan Monnier
2016-03-22 18:52                     ` Eli Zaretskii
2016-03-23  2:13                       ` Stefan Monnier
2016-03-23 15:15                         ` Eli Zaretskii
2016-03-23 15:32                           ` Stefan Monnier
2016-03-23 15:42                             ` Eli Zaretskii
2016-03-23 16:10                               ` Stefan Monnier
2016-03-31 17:17                                 ` Eli Zaretskii [this message]
2016-03-31 18:04                                   ` Stefan Monnier
2016-03-31 23:32                                     ` Michael Heerdegen
2016-03-26 21:49                             ` bug#19200: Point adjustment " John Wiegley
2016-03-21 18:31       ` bug#19200: Point adjustemnt " Eli Zaretskii
2016-03-21 18:50         ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837fgiva66.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=19200@debbugs.gnu.org \
    --cc=jonas@bernoul.li \
    --cc=michael_heerdegen@web.de \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.