bug#3003: 23.0.92; Point trapped in overlay

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

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 :.