C-x RET f

[B. T. Raven]

After setting all kindred variables that I could find to utf-8, I still
see ...default, nil... when I issue the C-x RET f command. It also
changes the u in the status line to a dash or something.
Describe coding systems returns:

quote

Coding system for saving this buffer:
  u -- utf-8 (alias of mule-utf-8)
Default coding system (for new files):
  u -- mule-utf-8 (alias: utf-8)
Coding system for keyboard input:
  u -- utf-8 (alias of mule-utf-8)
Coding system for terminal output:
  u -- utf-8 (alias of mule-utf-8)
Defaults for subprocess I/O:
  decoding: u -- mule-utf-8 (alias: utf-8)
  encoding: u -- mule-utf-8 (alias: utf-8)

Priority order for recognizing coding systems when reading files:
  1. mule-utf-8 (alias: utf-8)
  2. iso-latin-1 (alias: iso-8859-1 latin-1)
  3. iso-2022-jp (alias: junet)
  4. iso-2022-7bit
  5. iso-2022-7bit-lock (alias: iso-2022-int-1)
  6. iso-2022-8bit-ss2
  7. emacs-mule
  8. raw-text
  9. japanese-shift-jis (alias: shift_jis sjis)
  10. chinese-big5 (alias: big5 cn-big5)
  11. no-conversion (alias: binary)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The followings are decoded correctly but recognized as
iso-2022-7bit-lock:
    iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext
iso-2022-jp-2 iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION TARGET PATTERN  CODING SYSTEM(s)
  --------- --------------  ----------------
  File I/O      "\\.elc\\'"             (emacs-mule . emacs-mule)
                "\\(\\`\\|/\\)loaddefs.el\\'"
                                        (raw-text . raw-text-unix)
                "\\.tar\\'"             (no-conversion . no-conversion)
                ""
find-buffer-file-type-coding-system
  Process I/O   "[cC][mM][dD][pP][rR][oO][xX][yY]"
                                        (utf-8-dos . utf-8-dos)
  Network I/O nothing specified

unquote

Is that ... default, nil ... in this case a bug?

Thanks,

Ed