GNU bug report logs - #25626
25.1; doc of `bufferpos-to-filepos' for type `exact'

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25626 <at> debbugs.gnu.org
Subject: bug#25626: 25.1; doc of `bufferpos-to-filepos' for type `exact'
Date: Sun, 5 Feb 2017 10:58:24 -0800 (PST)

> >   ‘exact’, in which case we may end up re-(en/de)coding a large
> >     part of the file/buffer.
> >
> > And (elisp) `Text Representations' says this:
> >
> >   ‘exact’
> >     The result must be accurate.  The function may need to encode
> >     and decode a large part of the buffer.
> >
> > If I understand the code right, I think both of these are misleading.
> > They can give the impression that the text in the region can have its
> > encoding changed in its buffer.
> 
> I don't understand how you get that impression.  You do know that
> encoding text and then decoding it back produces the same text as was
> there originally, right?
> 
> This text simply says that this option might be computationally
> expensive.

If that's the intent then say that.  And I think it is the
intent, hence this bug: please just say that.

Saying "we may end up re-(en/de)coding" and "may need to
encode and decode" does _not_ specify that the text is encoded
_and then_ decoded back again, resulting in no change to the
buffer.  And the former means re-encode OR re-decode, not AND.)

And in fact, IIUC, the text is encoded to a separate buffer
(arg DESTINATION of `encode-coding-region'); it is not encoded
in the original buffer - the text in that buffer is unaffected,
and not because it is encoded and then decoded back.  But
perhaps I misunderstand this part.

[There are also typos in the doc string of `encode-coding-region':
"Optional 4th arguments" should be "Optional 4th argument" and
"is replace by" should be "is replaced by".]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.