bug#20704: info.el bug fix; Interprets Info format wrongly

[Eli Zaretskii <eliz@gnu.org>]

> From: Teddy Hogeborn <teddy@recompile.se>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  20704@debbugs.gnu.org
> Date: Tue, 09 Jun 2015 13:09:08 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > > +	      (+ (point-min) (byte-to-position
> > > > +                              (read (current-buffer))))
> > > 
> > > Hmm... this only works if the Info file is encoded in UTF-8.  I
> > > guess in the case of Info, 99% of the files are just ASCII and
> > > there's a chance that the vast majority of the rest is (or will be)
> > > UTF-8, so maybe this hack works well in practice.
> >
> > Using byte-to-position would make things worse for Latin-1 and the
> > likes.
> 
> No, byte-to-position already checks for that:
> 
> ---- src/marker.c, line 302
>   /* If this buffer has as many characters as bytes,
>      each character must be one byte.
>      This takes care of the case where enable-multibyte-characters is nil.  */
>   if (best_above == best_above_byte)
>     return bytepos;
> ----

I think you are misreading the code: the above snippet is for unibyte
buffers, whereas a Latin-1 encoded Info file will be read into a
multibyte buffer (and decoded into the internal Emacs representation
of characters during the read).  So this optimization is not going to
work in that case.

IOW, what matters for byte-to-position is the encoding used in
representing characters in Emacs buffers, not the one used externally
by the Info file on disk.

> Therefore, an Info file in Latin-1 should work just fine.
> 
> > But it shouldn't be hard to add a simple test of
> > buffer-file-coding-system: if it states fixed-size encoding, like any
> > of the 8-bit encodings, or UTF-16,
> > the conversion to character position is trivial.
> 
> I think you mean UTF-32 instead of UTF-16, since UTF-16 is variable-
> length.

UTF-16 is fixed length for characters in the BMP.