[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: yet more term.el fixes #2
From: |
Miles Bader |
Subject: |
Re: yet more term.el fixes #2 |
Date: |
Wed, 22 Sep 2004 13:47:08 +0900 |
Dan Nicolaescu <address@hidden> writes:
> Looking closer, the characters > 158 decimal have char-width 4 in my
> setup.
>
> Use this to print all the widths:
Hmmm, using that code I get simular (odd) results: the result of
`char-width' seems to be completely unrelated to the actual displayed
width of the characters -- some values are displayed as a single column
character, but have a `char-width' value of 4, and some are displayed as
a 4-column escape-sequence, but have a `char-width' value of 1!!
Here's a version that uses `decode-coding-string' to get correct
results; probably term.el should be using something like that:
(defun print-width ()
(interactive)
(let ((i 0))
(while (< i 256)
(let ((decoded (decode-coding-string (string i) 'iso-8859-1)))
(insert (format "%d %d %s\n" i (string-width decoded) decoded)))
(setq i (1+ i)))))
Using this, all the char-width values match the displayed representation.
When simply inserting raw character values in to the buffer, it seems
that some sort of default decoding takes place at insert/display time,
but an equivalent default decoding is not done by `char-width'; whether
that represents a bug, and if so, where, I don't know, but I think it's
probably always safer to be explicit as in the above code.
-Miles
--
The secret to creativity is knowing how to hide your sources.
--Albert Einstein
- yet more term.el fixes #2, Dan Nicolaescu, 2004/09/21
- Re: yet more term.el fixes #2, Miles Bader, 2004/09/21
- Re: yet more term.el fixes #2, Dan Nicolaescu, 2004/09/22
- Re: yet more term.el fixes #2,
Miles Bader <=
- Re: yet more term.el fixes #2, Stefan Monnier, 2004/09/22
- Re: yet more term.el fixes #2, Dan Nicolaescu, 2004/09/22
- Re: yet more term.el fixes #2, Stefan Monnier, 2004/09/22
- Re: yet more term.el fixes #2, Dan Nicolaescu, 2004/09/22
- Re: yet more term.el fixes #2, Stefan, 2004/09/23
- Re: yet more term.el fixes #2, Stefan Monnier, 2004/09/23