GNU bug report logs - #60750
29.0.60; encode-coding-char fails for utf-8-auto coding system

Previous Next

Full log

Message #17 received at 60750 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60750 <at> debbugs.gnu.org
Subject: Re: bug#60750: 29.0.60; encode-coding-char fails for utf-8-auto
 coding system
Date: Thu, 12 Jan 2023 15:28:49 +0100

>>>>> On Thu, 12 Jan 2023 16:04:07 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: 60750 <at> debbugs.gnu.org
    >> Date: Thu, 12 Jan 2023 14:44:29 +0100
    >> 
    >> One minor nit, the description for ':endian' says:
    >> 
    >> `:endian'
    >> 
    >> VALUE must be `big' or `little' specifying big-endian and
    >> little-endian respectively.  The default value is `big'.
    >> 
    >> This attribute is meaningful only when `:coding-type' is `utf-16'.
    >> 
    >> That last sentence seems untrue, as ':endian' is meaningful for
    >> 'utf-8-auto'

    Eli> That depends on what you mean by "meaningful".  What it wants to say
    Eli> is that it's meaningless to change the value of this property for any
    Eli> coding-system other than UTF-16.

OK

    Eli> Who does set utf-8-auto? where did you originally bump into this?
    Eli> This is an obscure coding-system, and the fix to make it work as
    Eli> documented will produce an incompatible change in behavior.  So before
    Eli> I decide whether to make the change and on what branch, I'd like to
    Eli> know how in the world did you encounter this.
    >> 
    >> Itʼs entirely my own fault:
    >> 
    >> The file where I noticed this is shared between a GNU/Linux and a
    >> macOS machine, which means I foolishly added the following a year ago,
    >> even though itʼs unnecessary (perhaps I was thinking I was going to be
    >> sharing it with a Windows machine?):
    >> 
    >> ;; -*- lexical-binding: t; coding: utf-8-auto; -*-

    Eli> So you thought the "-auto" part was about the EOL format?

yes. Iʼm having a reading incomprehension day, obviously (just like a
year ago when I made the change originally).

    >> I think that means we can leave the code as it is.

    Eli> ??? "As it is" means this coding-system behaves contrary to
    Eli> documentation: it should produce BOM on encoding.  Leaving it as is
    Eli> doesn't sound TRT, so I'd like to have this fixed.  From your
    Eli> description, it sounds like you bumped into this by mistake, and I see
    Eli> only one other use of it -- in the test suite.  So I'm inclined to
    Eli> installing this on the emacs-29 release branch.

Oh, I thought you were proposing *not* to fix it at all, since itʼs
such an obscure coding system. I have no opinion on where a fix should
go: Iʼm not going to be using that coding system again.

Robert
-- 

Previous Next

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