decode-coding-region and encode-coding-region
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
We should ask Ken'ichi what he thinks the correct behavior of
`decode-coding-region' should be; I don't think it should move
point, myself, but I don't know what the "correct" behavior should
be if point starts strictly between START and END.
This may not be related to your problem, but I'll chime in anyway.
decode-coding-region is broken in both FSFmacs and XEmacs, primarily
because it destroys all metainformation on buffer regions (markers and
extents/text-props). If you look at the implementation of
encode/decode-coding-region, you'll easily guess why that is so.
I tried to fix these two functions, but couldn't think of a way to fix
do so within the current stream-based framework. IMHO the trick is
for decoding streams to (optionally) maintain some kind of information
about old and new byte-positions, so that markers and extents can be
saved internally and re-attached after the streams do their work.
Currently the only way to do it is to break the streams abstraction,
and there must be a better way. I think I'll pester Ben about it when
I see him.