Re: utf-16le vs utf-16-le

[Juri Linkov <juri@jurta.org>]

>>> Emacs behaves correctly IMO, since its behavior is tuned for reading
>>> text, and BOM is not part of the text.  If you want to debug the
>>> programs that generated that text, you can always use no-conversion or
>>> find-file-literally.
>
>> But you don't know what you are debugging until Emacs (or something else)
>> points out the unexpected BOM.  Indicating the presence of a BOM isn't
>> really any different to indicating the encoding, though a better (more
>> noticeable) UI might be some indicator in the left fringe on the first line
>> of the file, rather than just a change to the character in the modeline.
>
> We could use an approach similar to non-breaking space, where the BOM is
> made visible just like any other char, with a special face.  Ideally it
> would also be somehow protected from accidental removal,

There is currently one way to display the BOM in Emacs: visiting
a file that contains the BOM with a BOM-less coding (e.g. visiting
a utf-16le-with-signature file forcing the utf-16le coding) displays
at the beginning of the buffer a big ugly character that looks like
some screen garbage.  There is some interesting information about it:

  name: ZERO WIDTH NO-BREAK SPACE
  old-name: BYTE ORDER MARK

This looks like it was once renamed, and a new name hints not to
display it due to its supposed zero width.

Maybe then a better indication would be in the modeline by displaying
the name of the coding with signature explicitly like "U(BOM)".

-- 
Juri Linkov
http://www.jurta.org/emacs/