Re: Emacs24 unpredictable behaviour [Was: coding system problems]

[Uday Reddy]

Uday Reddy writes:

> Here is a sample piece of code that I inserted into the middle of VM, to
> figure out how Emacs24 is behaving:
> 
> (defun vm-test-retrieve (mm)
>   (save-current-buffer
>     (set-buffer (vm-buffer-of mm))
>     (goto-char (vm-text-of mm))
>     (debug nil (list (point)
>                    (marker-position (vm-text-of mm))
>                    (= (point) (marker-position (vm-text-of mm)))
>                    ))
>     (debug nil (= (point) (marker-position (vm-text-of mm))))
>     ))
> 
> Since goto-char is going to (vm-text-of mm), the first debug should
> print two identical numbers and `t' for the comparison.  However, here is an
> instance where it doesn't:
> 
> Debugger entered: ((99947 98744 nil))
>   vm-test-retrieve([[#<marker at 93074 in test-imap> #<marker at 93107 in 
> test-imap> nil #<marker at 98744 in test-imap> #<marker at 98744 in 
> test-imap> #<marker at 98745 in test-imap>]...])

Following Andreas Schwab's prompt, I have changed the "debug" calls to
"message".  And, the misbehaviour of goto-char is still found:

(102332 98744 nil)
nil
98744 98744 t

The third line is printed by the regular VM code, which is right after this
call to `vm-test-retrieve'.  Surprisingly, in that instance, goto-char
works.  From this point on, VM appears to work normally.

The problem that causes buffer corruption happens earlier, which produced a
trace like this:

(104925 104925 t)
t
104925 104925 t
just before fetch 104925
just before insert 98778

The problem here is that between the "just before fetch" line and the 
"just before insert" line, the point changes.  The message body gets
inserted in the wrong place as a result.

I have narrowed down this point change to a call to
`auth-source-user-or-password' because, if I set `auth-sources' to nil, this
point change is avoided.  However, `auth-source-user-or-password' couldn't
have guessed the position 98778 where another marker is pointing.  So, the
problem must be some marker code of Emacs.

I suspect that if we can figure out why the `goto-char' above doesn't work,
we might be closer to identifying the problem.

Cheers,
Uday