bug#3003: 23.0.92; Point trapped in overlay

bug#3003: 23.0.92; Point trapped in overlay

[Leo]

Hi Emacs Developers,

I thought this was an org bug but it turns out an Emacs one. See the
discussion thread in: http://thread.gmane.org/gmane.emacs.orgmode/12885.

Here is how to reproduce.

1. Make an overlay
   Org mode is used only to easily create such an overlay that could
   demonstrate the bug.

   -  In a new buffer in org mode, begin a line with a few spaces and
      then type in http://www.google.com

   -  Move the cursor to be within that url and type 'C-c C-l' and follow
      the minibufer prompt to change the 'description' to 'google'

2. Put the point to the left of the url overlay and try move the cursor
   into the overlay. You can see when it reaches the first character of
   the overlay, it appears stuck.

Daniel Clemente in http://article.gmane.org/gmane.emacs.orgmode/12887
analysed the cause.

Kind regards,
-- 
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.

bug#3003: marked as done (23.0.92; Point trapped in overlay)

[Emacs bug Tracking System]

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


Your message dated Thu, 16 Apr 2009 00:07:37 -0400
with message-id <877i1lnsvq.fsf@cyd.mit.edu>
and subject line Re: 23.0.92; Point trapped in overlay
has caused the Emacs bug report #3003,
regarding 23.0.92; Point trapped in overlay
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
3003: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3003
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3119 bytes --]

From: Leo <sdl.web@gmail.com>
To: emacs-pretest-bug@gnu.org
Cc: Carsten Dominik <dominik@uva.nl>
Subject: 23.0.92; Point trapped in overlay
Date: Wed, 15 Apr 2009 17:44:37 +0100
Message-ID: <m1zlehyih6.fsf@cam.ac.uk>

Hi Emacs Developers,

I thought this was an org bug but it turns out an Emacs one. See the
discussion thread in: http://thread.gmane.org/gmane.emacs.orgmode/12885.

Here is how to reproduce.

1. Make an overlay
   Org mode is used only to easily create such an overlay that could
   demonstrate the bug.

   -  In a new buffer in org mode, begin a line with a few spaces and
      then type in http://www.google.com

   -  Move the cursor to be within that url and type 'C-c C-l' and follow
      the minibufer prompt to change the 'description' to 'google'

2. Put the point to the left of the url overlay and try move the cursor
   into the overlay. You can see when it reaches the first character of
   the overlay, it appears stuck.

Daniel Clemente in http://article.gmane.org/gmane.emacs.orgmode/12887
analysed the cause.

Kind regards,
-- 
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.



[-- Attachment #3: Type: message/rfc822, Size: 2121 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Leo <sdl.web@gmail.com>, Carsten Dominik <dominik@uva.nl>, 3003-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.92; Point trapped in overlay
Date: Thu, 16 Apr 2009 00:07:37 -0400
Message-ID: <877i1lnsvq.fsf@cyd.mit.edu>

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Stefan, this is due to your change.  Here is an easier recipe to
>> reproduce the bug:
>
> Yes, I recognized it right away :-(
> I think we're just going to have to revert that change for now.

OK.  I've ifdef'ed it out, with a comment.

> Tho, I think that in reality the "right" fix is to only place the
> rear-nonsticky property on the last invisible char since inserting text
> in the middle of the invisible "http://www.google.com" shouldn't result
> in an invisible "http://www.go" followed by the visible inserted text
> and then an invisible "ogle.com".

Yes, that's true.  However, I don't know how commonly other packages use
runs of rear-nonsticky properties.

bug#3003: 23.0.92; Point trapped in overlay

[Chong Yidong]

Stefan, this is due to your change.  Here is an easier recipe to
reproduce the bug:

(defun foo-test ()
  (interactive)
  (switch-to-buffer "* TEST *")
  (erase-buffer)
  (insert "asdfgh")
  (put-text-property 3 5 'rear-nonsticky '(invisible))
  (put-text-property 3 5 'invisible t)
  (goto-char (point-min)))

Moving point forward now gets point temporarily stuck.  The crucial
factor is the rear-nonsticky property.

2009-02-12  Stefan Monnier  <monnier@iro.umontreal.ca>

  * keyboard.c (adjust_point_for_property): Allow stopping betwen two
  invisible areas.

Here is the relevant code:

   /* Find boundaries `beg' and `end' of the invisible area, if any.  */
   while (end < ZV
          /* Stop if we find a spot between two runs of
             `invisible' where inserted text would be visible.
             This is important when we have two invisible
             boundaries that enclose an area: if the area is
             empty, we need this test in order to make it
             possible to place point in the middle rather than
             skip both boundaries.
             Note that this will stop anywhere in a non-sticky
             text-property, but I don't think there's much we
             can do about that.  */
          && (val = get_pos_property (make_number (end),
                                      Qinvisible, Qnil),
              TEXT_PROP_MEANS_INVISIBLE (val))

Do we really need to do this test?  This corner case seems unimportant,
as opposed to being able to treat non-sticky properties correctly.

bug#3003: 23.0.92; Point trapped in overlay

[Stefan Monnier]

> Stefan, this is due to your change.  Here is an easier recipe to
> reproduce the bug:

Yes, I recognized it right away :-(
I think we're just going to have to revert that change for now.

Tho, I think that in reality the "right" fix is to only place the
rear-nonsticky property on the last invisible char since inserting text
in the middle of the invisible "http://www.google.com" shouldn't result
in an invisible "http://www.go" followed by the visible inserted text
and then an invisible "ogle.com".

Or maybe the invisible text should be marked `read-only' and then my
code could be changed to only kick in for writable text.  But this would
require more changes to the handling of read-only (currently read-only
text is usually unbearable because it can't be removed, whereas what is
usually intended is just "don't modify, tho feel free to remove it
altogether").


        Stefan