Re: w3m - ASCII 160

[Katsumi Yamaoka <yamaoka@xxxxxxx>]

I could reproduce the problem using XEmacs 21.4.20 without Mule.

>>>>> In [Wanderlust English : No.01998] Ron Isaacson wrote:

> I also tried 21.4.17, but it has the same problem. I recently tried
> upgrading to 21.5, but couldn't get Wanderlust working there at all.
> That's another issue though. :-)

I have no problem in running Wanderlust on XEmacs 21.5-b27 with
Mule.  It may possibly be solved if you rebuild Wanderlust (and
possibly APEL, FLIM and SEMI beforehand) using XEmacs 21.5.

> When I used w3m 0.3.1, I didn't have this problem at all; w3m passed
> the raw character back to xemacs, and it was drawn as expected. It may
> only be in older versions that the display override was necessary, but
> in any case, this problem seems to be either in w3m or in the
> emacs-w3m options.

You are right.  I got a good advice from Hideyuki SHIRAI
<shirai (at) meadowy.org> personally that there are two improper
values in the arguments passed to w3m in the case where XEmacs
has no Mule feature.  That is, we guess you are using XEmacs
without the Mule feature and the values of the variables
`w3m-input-coding-system' and `w3m-output-coding-system' are
both `iso-8859-1'.  If it is right, the problem should be fixed
by evaluating the following form (copy it to the *scratch* buffer
and type `C-j' at the end of the last line) or adding it to your
~/.emacs-w3m.el file.

--8<---------------cut here---------------start------------->8---
;; The value was improved by SHIRAI-san.
(defconst w3m-halfdump-command-arguments
  (cond ((eq w3m-type 'w3mmee)
	 (list '(if w3m-treat-image-size
		    "-dump=half-buffer,single-row-image"
		  "-dump=half-buffer")
	       '(if (eq w3m-input-coding-system 'ctext)
		    (list "-I" "x-ctext")
		  (when (and (eq w3m-input-coding-system 'binary)
			     charset)
		    (list "-I" 'charset)))
	       "-o" "concurrent=0"))
	((eq w3m-type 'w3m-m17n)
	 (list "-halfdump"
	       "-o" "ext_halfdump=1"
	       "-o" "strict_iso2022=0"
	       "-o" "fix_width_conv=1"
	       "-o" "use_jisx0201=0"
	       "-o" "ucs_conv=1"
	       '(if (eq w3m-input-coding-system 'binary)
		    (if charset (list "-I" 'charset))
		  (list "-I" (cond
			      ((eq w3m-input-coding-system 'utf-8)
			       "UTF-8")
			      ((eq w3m-input-coding-system 'iso-8859-1)
			       "ISO-8859-1")
			      (t
			       "ISO-2022-JP-2"))))
	       "-O"
	       '(cond
		 ((eq w3m-output-coding-system 'utf-8)
		  "UTF-8")
		 ((eq w3m-output-coding-system 'iso-8859-1)
		  "ISO-8859-1")
		 (t
		  "ISO-2022-JP-2"))))
	((eq w3m-input-coding-system 'w3m-euc-japan)
	 (list "-halfdump" "-I" "e"))
	(t (list "-halfdump")))
  "Arguments passed to the w3m command to run \"halfdump\".")
--8<---------------cut here---------------end--------------->8---

I will install it in the emacs-w3m CVS repository if it does the
trick (I've already confirmed it using XEmacs 21.4.20 w/o Mule,
though).

> Do you know exactly what command line emacs-w3m sends to w3m, and how
> it's affected by the encoding variables (w3m-output-coding-system,
> etc.), so I can test this directly in w3m, outside of emacs?

The arguments passed to w3m are generated according to mainly
the values of the variables `w3m-halfdump-command-arguments' and
`w3m-halfdump-command-common-arguments'.  When XEmacs w/o Mule
is used, currently `-I ISO-2022-JP-2' and `-O ISO-2022-JP-2' are
added even if `w3m-(in|out)put-coding-system' are `iso-8859-1'.
Specifying the ISO-2022-JP-2 charset is meaningful to use with
XEmacs with Mule but is not suitable to XEmacs w/o Mule.

Regards,