Re: yet more term.el fixes #2

[Dan Nicolaescu <dann@ics.uci.edu>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > (insert (string-as-unibyte (substring str i funny)))
  > 
  > I think string-as-unibyte is also an extremely poor choice here and will
  > likely lead to unexpected errors in some cases (it's a function that should
  > have big warning signs all around it, like string-as-multibyte).
  > 
  > Also calling set-buffer-multibyte is to be avoided if possible.
  > 
  > Can you try with
  > 
  >   (insert (decode-coding-string (substring str i funny) locale-coding-system))
  > Also based on your above code, it seems that `str' is a multibyte string,
  > which sounds wrong.  I think that the coding-system used for the process's
  > output should be `binary'.  Can you see what coding-system is used for
  > the process?

In term-exec-1:
 	(coding-system-for-read 'unknown-unix)

  > I suggest a patch like the one below,
[snip]

Did not work. 

It can be made work by binding: 

(default-enable-multibyte-characters t)

when creating the buffer in make-term  (so as to do what
set-buffer-multibyte used to do)

and binding 
(default-enable-multibyte-characters nil)
in term-exec-1. 

Now that this stuff work I found out that pasting non-ASCII text with
the mouse does not work. Pasting works by doing process-send-string
with the data from the kill ring. It seems that the string must be
encoded in some way. Any idea how to deal with that?