Emacs24 unpredictable behaviour [Was: coding system problems]

[Uday Reddy]

Eli Zaretskii writes:

> If you do this on a collection of messages that don't have any
> non-ASCII characters, and now CR-LF style EOLs, does the problem
> happen then?  If it does, then decoding non-ASCII characters is not
> the root cause.

Messages are always made of ASCII characters.  So, that is not an issue.
The folder I am working with has Unix line endings.  The folder is loaded
into a unibyte buffer.  (VM always does that.)

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>]...])

Even more crazily, for another message, the first debug prints this:

Debugger entered: ((104925 104925 t))
  vm-test-retrieve([[#<marker at 98745 in test-imap> #<marker at 98778 in 
test-imap> nil #<marker at 104925 in test-imap> #<marker at 104925 in 
test-imap> #<marker at 104926 in test-imap>]...])

and the second debug prints this:

Debugger entered: (nil)
  vm-test-retrieve([[#<marker at 98745 in test-imap> #<marker at 98778 in 
test-imap> nil #<marker at 104925 in test-imap> #<marker at 104925 in 
test-imap> #<marker at 104926 in test-imap>]...])

How does the point change from one debug to the next?  I have no idea.

--------

The good news is that these problems may not have anything to do with the
buffer-file-type changes.  I see them as far as back as revision 107968. 


Cheers,
Uday