Richard Zidlicky writes:
> is this expected behaviour? Tested with 21.5.28 and 21.5.29
> rm -f xx.txt; gnuclient xx.txt # -> coding system UTF8
> rm -f xx.txt; touch xx.txt ;gnuclient xx.txt # -> coding system Auto/undecided
This is not expected. It's not hard to imagine the code the leads to
this result, but it's incorrect; we'll fix it. (I don't see a hurry,
it may take some time. Patches welcome!) The undecided coding system
is a sentinel, and should always be changed as the end result of
autodetection, presumably to default-buffer-file-coding-system in the
case
> Worse yet, upon saving no sensible coding is selected --
This is a different bug (a user could set buffer-file-coding-system).
In the case of buffer-file-coding-system(-for-write) being 'undecided
or similar, the writer function (output might not be to a file) should
error.
> Worse yet, upon saving no sensible coding is selected - texts with
> accents or foreign chars get munged.
And this is a third bug. I thought Aidan had fixed this, but I guess
it's only for his new unibyte coding systems.
> In my (very) old .xemacs/init.el I also had an additional
> (set-default-coding-systems 'utf-8)
>
> which does no longer exist but apparently cured the problem. Afaicr 0-sized
> files caused me some coding system related trouble even in 21.4.8 which was
> fixed with the above setting.
If you don't mind explaining, how are you in this situation frequently
enough to figure out what happened, let alone care? I don't think
I've ever edited an existing file with zero-size. If there's a common
workflow that leads to this, maybe there's more hurry than I thought.
|