Strange font-lock/invisible/intangible bug

Strange font-lock/invisible/intangible bug

[Damien Elmes]

Hello,

I've been trying to debug some weird behavior with emacs-wiki.el on
the nearly-latest CVS (as of about a week ago). emacs-wiki.el uses font-lock
mode to convert a string of the form "*foo*" to bold, in the process
propertizing the "*"s as invisible and intangible.

Now, there is a difficult to reproduce bug in the latest CVS which wasn't
around in previous emacs releases. Sometimes (maybe 1 in 20 times?), when
typing "*foo* ", point is suddenly moved to the line below. Infact, not just
space, but any command - Even C-x =, which you'd expect to show no character
(as I'm at the end of the buffer), instead says "C-j" in the minibuffer and
point is suddenly moved to the start of the next line. Repeating C-x = now
indicates that there's no character on point.

The other strange thing is that pressing backspace a few times and repeating
the same key combination results in it working. But if you undo the previous
line instead, and type it again, the strange behavior results.

Does anyone have a 'hunch' on where this bug might be, or any tips on how I
might debug where this is going on? My C knowledge is somewhat rusty.

Regards,
-- 
Damien Elmes

Re: Strange font-lock/invisible/intangible bug

[Stefan Monnier]

> I've been trying to debug some weird behavior with emacs-wiki.el on
> the nearly-latest CVS (as of about a week ago). emacs-wiki.el uses font-lock
> mode to convert a string of the form "*foo*" to bold, in the process
> propertizing the "*"s as invisible and intangible.
> 
> Now, there is a difficult to reproduce bug in the latest CVS which wasn't
> around in previous emacs releases. Sometimes (maybe 1 in 20 times?), when
> typing "*foo* ", point is suddenly moved to the line below. Infact, not just
> space, but any command - Even C-x =, which you'd expect to show no character
> (as I'm at the end of the buffer), instead says "C-j" in the minibuffer and
> point is suddenly moved to the start of the next line. Repeating C-x = now
> indicates that there's no character on point.
> 
> The other strange thing is that pressing backspace a few times and repeating
> the same key combination results in it working. But if you undo the previous
> line instead, and type it again, the strange behavior results.
> 
> Does anyone have a 'hunch' on where this bug might be, or any tips on how I
> might debug where this is going on? My C knowledge is somewhat rusty.

It's in adjust_point_for_properties.  Same problem as reported
earlier for some wnn input method system.

Since both cases show up in conjunction with `intangible' (which
is made unnecessary by the new problematic code), maybe we can simply
disable that code in case there is an `intangible' property around.

I don't have time to try it out right now, but I'll look at it later.


	Stefan

Re: Strange font-lock/invisible/intangible bug

[Richard Stallman]

Can you send us a precise self-contained test case?  We can't debug it
without that.

Re: Strange font-lock/invisible/intangible bug

[Damien Elmes]

Kenichi Handa <handa@m17n.org> writes:

> The similar bug can be reproduced without intangible
> property.  Intangible property just moves the point more.
>
> And, I found that the attached patch (the same one as what I
> sent to Richard and Stefan previously) at least fixes the
> case of the input method.  It's not a complete fix but I
> think it's worth as a workaround.
>
> Could you also try it?

Unfortunately that behavior is still happening with this patch applied.

Cheers,
-- 
Damien Elmes

Re: Strange font-lock/invisible/intangible bug

[Stefan Monnier]

> > I've been trying to debug some weird behavior with emacs-wiki.el on
> > the nearly-latest CVS (as of about a week ago). emacs-wiki.el uses font-lock
> > mode to convert a string of the form "*foo*" to bold, in the process
> > propertizing the "*"s as invisible and intangible.
> > 
> > Now, there is a difficult to reproduce bug in the latest CVS which wasn't
> > around in previous emacs releases. Sometimes (maybe 1 in 20 times?), when

Actually, now that I think about it, it might also be due to
interaction with something else.  Which "previous Emacs releases"
worked correctly ?

Could you send us a self-contained test case ?


	Stefan