Problems with non-UTF8 files

[chrneumann]

While editing some files that have faulty coding (non-UTF8, file-coding not correctly set), after every file change there is a prompt to select a coding system with the error message:

These default coding systems were tried to encode text
in the buffer ‘ *temp file*-855866’:
  (utf-8 (127 . 4194294) (221 . 4194300) (287 . 4194294) (372 . 4194276) (482 .
  4194300) (604 . 4194271) (706 . 4194300) (1493 . 4194276) (1547 . 4194276)
  (2118 . 4194276) (2168 . 4194276))
However, each of them encountered characters it couldn’t encode:
  utf-8 cannot encode these:           ...

Click on a character (or switch to this window by ‘SPC w w’
and select the characters by RET) to jump to the place it appears,
where ‘SPC u C-x =’ will give information about it.

Select one of the safe coding systems listed below,
or cancel the writing with SPC w p p and edit the buffer
   to remove or modify the problematic characters,
or specify any other coding system (and risk losing
   the problematic characters).

  raw-text no-conversion

A backtrace of the write-region call (issued by git-gutter) gives:

* write-region(nil nil "/tmp/git-gutter-origsznO2j" nil 0)
  git-gutter:write-original-content("/tmp/git-gutter-origsznO2j" "the_filename")
  git-gutter:live-update()
  apply(git-gutter:live-update nil)
  timer-event-handler([t 0 2 0 t git-gutter:live-update nil idle 0])

Maybe git-gutter does not respect the newly selected / changed coding? I could not resolve the issue. Setting a different coding does not work.

[chrneumann]

Ah, there seems to be a PR that addresses this? #210

[sleetdrop]

Have the same problem, wish this issue could be fixed.

[richcarl]

Same here

These default coding systems were tried to safely encode the following
problematic characters in the buffer ‘ *temp file*’:
  Coding System           Pos  Codepoint  Char
  iso-latin-1-unix      14163  #x3FFFC0   \300
                        14172  #x3FFFDE   \336
                        14181  #x3FFFD7   \327

However, each of them encountered characters it couldn’t encode safely:
  iso-latin-1-unix cannot safely encode these: \300 \336 \327

Not sure if it's part of the actual problem, but for some reason it looks like the Latin-1 bytes (C0, DE, D7) have been mapped to within the 3FFFxx range.