Re: decode-coding-region and encode-coding-region
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> I think that if you somehow manage to create an extent that
> ends up with endpoints inside a *-coding-region, you've screwed
> up somehow anyway so an approximation should be fine.
Hrvoje> Maybe. Generally, I want to fix the case where Gnus
Hrvoje> properties get screwed merely because it encodes/decodes
Hrvoje> the region.
If an approximation is good enough, OK. You're likely to get
rounding problems and endpoint problems (eg, if Gnus isn't really,
really careful about how it handles ISO-2022 escape sequences); I
don't know if that matters. At least it shouldn't result in data
loss, and should get faces (eg) right most of the time.
Hrvoje> That's not my care, really. I merely make sure that the
Hrvoje> extents are preserved -- how the stuff stored in the
Hrvoje> extents will be handled is up to the redisplay code.
OK.
> It seems to me that you probably want to split such extents,
> preserve the meaning outside of the *-coding-region, and do
> something (probably at user option) inside the *-coding-region.
Hrvoje> I will definitely not code something like that.
I now see that you're absolutely right; redisplay or user code should
handle it. Probably the *-coding-region functions should invoke
cleanup hooks to automate user-level operations, but no more.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."