| 1 |
On Wed, Jul 27, 2005 at 10:24:23AM -0300, Fernando Canizo wrote: |
| 2 |
> Cool, so i can discard that the problem comes from vim + libncurses. |
| 3 |
> |
| 4 |
> In other mails from the thread we've reached to the point of knowing |
| 5 |
> that mutt is reencoding the chars. Since you seem to know about |
| 6 |
> libraries and calls to functions, do you know a method to track this |
| 7 |
> issue? I've been thinking maybe an strace to mutt, but y don't know |
| 8 |
> what to search for, and strace gives lots of info. |
| 9 |
|
| 10 |
strace gives lots of information, but sometimes you can reduce it by |
| 11 |
looking only at specific calls. Usually what I'm interested in from |
| 12 |
strace in this type of problem is the exec's and open's it shows. |
| 13 |
|
| 14 |
I'm not sure what mutt's doing either. But if it's recoding the information, |
| 15 |
it's doing either via runtime library or via an external program. |
| 16 |
|
| 17 |
Another tool is ltrace, which would (like strace, a lot of information) |
| 18 |
show the library calls mutt makes. That's useful in this sense to see |
| 19 |
if it's doing something with iconv. |
| 20 |
|
| 21 |
> So the question is: what would you do to track this problem? |
| 22 |
|
| 23 |
I'd probably poke at the strace and ltrace results enough to get a sense |
| 24 |
of generally what it's doing, then grep through mutt's sources to see |
| 25 |
where it's doing _that_. |
| 26 |
|
| 27 |
-- |
| 28 |
Thomas E. Dickey |
| 29 |
http://invisible-island.net |
| 30 |
ftp://invisible-island.net |
Archives