bug#46933: Possible bugs in filepos-to-bufferpos / bufferpos-to-filepos

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: handa@gnu.org,  gregory@heytings.org,  46933@debbugs.gnu.org
> Date: Wed, 22 Jun 2022 06:17:09 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But there's one new in-tree usage for this -- in
> >> hexl.el.  (In hexl-mode-exit and hexl-maybe-dehexlify-buffer.)  I don't
> >> know whether that has the problem described in this bug report, though
> >> (I'm not familiar with hexl.el at all).
> >
> > There's no reason why this won't be relevant to hexl: it is a
> > general-purpose hex editor, so editing a file encoded in one of those
> > problematic ISO-2022 encodings should bump into the same issues.
> 
> I meant more that I don't really know what it wants to achieve, or what
> kinds of files are typically used by hexl users.

Let me explain.  These functions are used in hexl for the case where
you have a file visited "normally" (which decodes it using some
coding-system, as Emacs normally would), then want to run hexl on it
for some reason, and later perhaps go back to editing it "normally".
In this case, hexl tries to keep the buffer position in the same place
across conversion to hexl and back, because that's what the user would
expect.  The coding-system used for that is the one Emacs used to
decode the file's contents when originally visiting the file
"normally".

> Do people use that on huge hex dumps or something else?

Hexl is also useful to look at the exact contents of a file that
displays strangely when visited normally, and that's when these
functions are useful.

Of course, accuracy is less important in this case than in the case of
multi-file Info, so maybe we don't care too much for the hexl case.