[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yet more term.el fixes #2

From: Dan Nicolaescu
Subject: Re: yet more term.el fixes #2
Date: Wed, 22 Sep 2004 19:14:02 -0700

Stefan Monnier <address@hidden> 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) 
  > 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,

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? 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]