bug#36573: 26.1; bufferpos-to-filepos assumes coding-system-eol-type gives integer

[Rupert Swarbrick <rswarbrick@gmail.com>]

Thank you for the reply. I've now found the "culprit" (bisecting 
my init.el starting with emacs -Q). The dubious setting was:

  '(file-coding-system-alist
     (quote
      (("\\.dz\\'" no-conversion . no-conversion)
       ("\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . 
       no-conversion)
       ("\\.tgz\\'" no-conversion . no-conversion)
       ("\\.tbz\\'" no-conversion . no-conversion)
       ("\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . 
       no-conversion)
       ("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'" no-conversion . 
       no-conversion)
       ("\\.elc\\'" emacs-mule . emacs-mule)
       ("\\.utf\\(-8\\)?\\'" . utf-8)
       ("\\(\\`\\|/\\)loaddefs.el\\'" raw-text . raw-text-unix)
       ("\\.tar\\'" no-conversion . no-conversion)
       ("\\.po[tx]?\\'\\|\\.po\\." . po-find-file-coding-system)
       ("\\.lisp\\'" . utf-8-unix))))

I can't remember why I had this setting, rather than the default 
value, but clearing it out means I can read the info manual again.

I think it probably still makes sense to add a note to the manual 
for bufferpos-to-filepos and filepos-to-bufferpos to point out 
that they don't work if the line ending convention is unknown.

For bonus points, maybe it makes sense to add something to fail 
earlier (and more understandably!) in the info reading code. I'm 
not sure exactly where that would be, though.


Rupert