bug#4047: marked as done (23.1.1: hexl-mode doesn't like UTF8 files with a byte-order mark)

[Emacs bug Tracking System]

Your message dated Sat, 22 Aug 2009 13:25:13 +0300
with message-id <83praof8mu.fsf@gnu.org>
and subject line Re: bug#4047: 23.1.1: hexl-mode doesn't like UTF8 files with a 
byte-order mark
has caused the Emacs bug report #4047,
regarding 23.1.1: hexl-mode doesn't like UTF8 files with a byte-order mark
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4047: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4047
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 23.1.1: hexl-mode doesn't like UTF8 files with a byte-order mark
>
>
>
>
> Date: 
>
> Wed, 5 Aug 2009 15:01:31 +0100
>
>
>
>
> Hi,
>
> I'm testing the windows version of the new emacs 23.1.1
>
> Here's what I noticed:
>
> If I open a UTF8 file with a byte-order mark, and if I
> try to enter hexl-mode, I get this error: "\357\273\277-hex: No such file or 
> directory".
>
> The presence of the BOM is important, I can enter hexl-mode
> with no problem if I remove the BOM from the file.
>
> I did the same test with emacs 22.3.1 and it worked fine, so
> this looks like a regression.
>
> Unfortunately I can't test a unix version at the moment.
>
> Regards,
>
> Pierre
>
> -- 
> Be Yourself @ mail.com!
> Choose From 200+ Email Addresses
> Get a Free Account at www.mail.com!
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#4047: 23.1.1: hexl-mode doesn't like UTF8 files with a byte-order mark
>
>
>
>
> Date: 
>
> Sat, 22 Aug 2009 13:25:13 +0300
>
>
>
>
> > From: Kenichi Handa <handa@m17n.org>
> > CC: 4047@emacsbugs.donarmstrong.com, monnier@iro.umontreal.ca,
> >         bogossian@mail.com, schwab@linux-m68k.org
> > Date: Fri, 21 Aug 2009 21:18:53 +0900
> > 
> > In article <83ljldh5pm.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > > > > Unless Handa objects, I'd recommend we change encode_coding_string to 
> > > > > > be
> > > > > > a nop on unibyte strings (tho, we may want to let it obey EOL
> > > > > > conversions).
> > > > > 
> > > > > I don't object to that change.
> > > > 
> > > > For strings only (i.e. in coding.h:encode_coding_string) or on the
> > > > more basic level, in coding.c:encode_coding_object?
> > 
> > > Ping!
> > 
> > At the moment, all I can say is that changing
> > coding.h:encode_coding_string is quite safe.  But,
> > encode_coding_object is used by Lisp functions
> > encode-coding-region and encode-coding-string, and thus the
> > change will break some packages that use them on unibyte
> > string/buffer.
>
> I fixed this in encode-coding-string.
>
> Thanks.
>
> --- End Message ---