Re: unencodable-char-position [Re: Several serious problems]

[Kenichi Handa]

In article <address@hidden>, Dave Love <address@hidden> writes:
>>  By the way, I've just noticed that Dave has already
>>  installed the function `unencodable-char-position' in
>>  mule-cmds.el and used it in select-safe-coding-system.
>>  
>>  That function resembles to check-coding-system-region on
>>  which we are currently discussing.

> I'm sorry if that was wrong.  I thought it was supposed to have been
> installed months ago, and I was trying to clear out the Mule changes
> I've had hanging around after rms was on about it.  I thought that was
> all stuff you approved of, or `obviously right'.

You don't have to be sorry.  Perhaps, I've overlooked that
part when you asked about various changes long ago.

>>  But, as the docstring says, it's slow.

> [It seemed fast enough for that use since it's only executed
> occasionally, when there's actually a problem.  It was probably
> developed on a P133.]

Ah, yes.  Currently, it is used only interactively, thus the
speed is not that problem.  But, I'm thinking about using
unencodable-char-position to check if default coding systems
can encode the region or not in select-safe-coding-system
(not yet done).  I think such a change makes
select-safe-coding-system runs much faster.

> By the way, aborting in select-safe-coding-system can have bad effects
> when you're using VC.  As far as I remember, it actually loses your
> edits in some circumstance.  I haven't had time to look at the
> problem.

I noticed that too.  But, I also don't have time to fix it
for the moment.  I've never read the code of vc.

---
Ken'ichi HANDA
address@hidden