Re: Subject that ends with UTF-8, 85 or A0 e.g.:

On Wed, Aug 03, 2022 at 02:37:00PM +0900, Kenichi Asai wrote: Yes, and it solved the problem!!! Thank you very much! I haven't compiled mutt by myself for long, so I rewrote the homebrew formula to use the patch and let homebrew recompile (mutt 2.2.3). Thank you Kenichi and Dennis for confirm

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

On Tue, Aug 02, 2022 at 08:55:53PM -0700, Kevin J. McCarthy wrote: > - while (ISSPACE (*buf)) > + while (is_email_wsp (*buf)) I was also able to reproduce the issue (on macOS) and can also confirm that with this patch, the issue no longer occurs. Dennis

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

> Darn, that was my best guess. After I sent the email, I even found some old > bug reports that 0xa0 was considered "space" on MacOS (e.g. > https://bugs.python.org/issue7072) > > Still, perhaps there is something different about the way Mutt was built > versus the quick compile. > > Have you e

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

On Wed, Aug 03, 2022 at 12:21:09PM +0900, Kenichi Asai wrote: asai@bigsur % cat test.c #include #include int main () { printf("%d\n", isspace(0xa0)); printf("%d\n", isspace(0x85)); printf("%d\n", isspace(0x0a)); return 0; } [...] asai@bigsur % ./test 0 0 1 asai@bigsur % Darn, that was

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

> Would you mind creating a script to use for $editor. Something like: > > - - - - myeditor.sh - - - - > #!/bin/bash > > cp $1 ~/before.txt > vim $1 > cp $1 ~/after.txt > - - - - end myeditor.sh - - - > > set editor = "~/myeditor.sh" > > Then, if you put 加 at the end of the subject w

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

> > I try to send this e-mail out in 7bit mode (with υ at the end of > > Subject). > > Why would you do that when the discussion seems to be about UTF-8 > glyphs ? I'm curious. I just thought that quoted printable did some work on the Subject line, but I was wrong. -- Kenichi Asai

Re: Subject that ends with UTF-8, 85 or A0 e.g.:

On Wed, Aug 03, 2022 at 09:53:42AM +0900, Kenichi Asai wrote: * In the step: "- enter some e-mail address and a subject." if instead, you put a 加 at the end of the subject here, before running vim, does 加 show up in vim? Yes. If you then don't modify the subject while still in vim, does

Re: Subject that ends with UTF-8, 85 or A0 : �

> > This e-mail has υ at the end of Subject. I will send it out. > > Somehow, the previous e-mail did not contain the replacement character > at the end of Subject. I don't know why. Because the e-mail was > quoted perhaps? > > [text/plain, quoted, utf-8, 1.3K]

Re: Subject that ends with UTF-8, 85 or A0 e.g.: �

> This e-mail has υ at the end of Subject. I will send it out. Somehow, the previous e-mail did not contain the replacement character at the end of Subject. I don't know why. Because the e-mail was quoted perhaps? [text/plain, quoted, utf-8, 1.3K] Bastian's e-mail is 7bit (as i

Re: Subject that ends with UTF-8, 85 or A0 e.g.: �

nal steps, what does the email look like if you send directly > after returning from vim? The replacement character is sent as seen in Bastian's e-mail: Date: Tue, 2 Aug 2022 12:39:06 +0200 From: Bastian To: mutt-users@mutt.org Subject: Re: Subject that ends with UTF-8, 85 or A0 �� (I

Re: Subject that ends with UTF-8, 85 or A0 e.g.: υ

On 8/2/22 13:58:37, Kevin J. McCarthy wrote: On Tue, Aug 02, 2022 at 03:52:51PM +0900, Kenichi Asai wrote: When the subject ends with a character whose last byte in UTF-8 is either 85 or A0, it appears the character collapses. > I'm having trouble duplicating this problem on Debian T

Re: Subject that ends with UTF-8, 85 or A0

On Tue, Aug 02, 2022 at 03:52:51PM +0900, Kenichi Asai wrote: When the subject ends with a character whose last byte in UTF-8 is either 85 or A0, it appears the character collapses. To reproduce: - prepare .mutt/muttrc containing only the following line: set edit_headers=yes - launch mutt and

Re: Subject that ends with UTF-8, 85 or A0 �

t of the problem? I.e. Editors think the text files is > an us-ascii or iso-2022-jp encoded file, and convert non-interpretable > characters to utf-8 replacement? I don't think so. If the editor thinks the file is us-ascii, then it must not insert a UTF-8 replacement character. Furthermor

Re: Subject that ends with UTF-8, 85 or A0 加

send with Content-type's charset is us-ascii and Kenichi's email is iso-2022-jp. Is it part of the problem? I.e. Editors think the text files is an us-ascii or iso-2022-jp encoded file, and convert non-interpretable characters to utf-8 replacement? -- Danh

Re: Subject that ends with UTF-8, 85 or A0 加

On Tue, Aug 02, 2022 at 12:39:06PM +0200, Bastian wrote: > I see it in the subject now. > There are two U+FFFD chars. > >> | System: Darwin 21.6.0 (arm64) >> | ncurses: ncurses 6.3.20220625 (compiled with 6.3) >> | libiconv: 1.16 >> | hcache backend: lmdb LMDB 0.9.70: (December 19, 2015) >> | >>

Re: Subject that ends with UTF-8, 85 or A0 ��

> > I can't reproduce either. > > I can reproduce the issue. In vim the character 0x52a0 is still present: > > > > After quitting vim, mutt displays the unicode replacement character > 0xfffd instead of 0x52a0: I see it in the subject now. There are two U

Re: Subject that ends with UTF-8, 85 or A0 �

On Tue, Aug 02, 2022 at 04:04:07PM +0700, Đoàn Trần Công Danh wrote: > On 2022-08-02 10:06:08+0200, Bastian wrote: >> On 02Aug22 15:52+0900, Kenichi Asai wrote: >> > Would it be possible to somehow avoid this problem? I cannot avoid >> > creating e-mails with Japanese characters in Subject a

Re: Subject that ends with UTF-8, 85 or A0 加

On 02Aug22 16:04+0700, Đoàn Trần Công Danh wrote: > On 2022-08-02 10:06:08+0200, Bastian wrote: > > υ 0x3C5 > > ％ 0xFF05 > > ｅ 0xFF45 > > ム 0x30E0 > > 加 0x52A0 > > > > So only the last matches your description 'last byte is A0&#

Re: Subject that ends with UTF-8, 85 or A0 加

subject. > > - vim launches. > > - edit Subject line so that it ends with a character such as: > > υ or ％ or ｅ (whose last byte of their UTF-8 code is 85) or > > ム or 加 (whose last byte of their UTF-8 code is A0). > > The mail I received shows the characters

Re: Subject that ends with UTF-8, 85 or A0 加

s with a character such as: > υ or ％ or ｅ (whose last byte of their UTF-8 code is 85) or > ム or 加 (whose last byte of their UTF-8 code is A0). The mail I received shows the characters you gave here as examples as: υ 0x3C5 ％ 0xFF05 ｅ 0xFF45 ム 0x30E0 加 0x52A0 So on

Subject that ends with UTF-8, 85 or A0

When the subject ends with a character whose last byte in UTF-8 is either 85 or A0, it appears the character collapses. To reproduce: - prepare .mutt/muttrc containing only the following line: set edit_headers=yes - launch mutt and type m to create a new mail. - enter some e-mail address and a

Re: utf-8 characters not shown

On Mon, May 09, 2016 at 03:00:10AM -0400, Grady Martin wrote: > On 2016年04月27日 12時04分, Florian Lohoff wrote: > >I am using ROXTerm - And it shows correctly in vim so i know its in > >the font and the utf-8 console setup is correct. But viewing the mail > >in mutt the signatur

Re: utf-8 characters not shown

On 2016年04月27日 12時04分, Florian Lohoff wrote: I am using ROXTerm - And it shows correctly in vim so i know its in the font and the utf-8 console setup is correct. But viewing the mail in mutt the signature does not show a Cat and Mice, not even a blank box - but it simple weeds out the character

Re: utf-8 characters not shown

On Tue, Apr 26, 2016 at 11:07:48PM +0100, Ken Moffat wrote: > On Tue, Apr 26, 2016 at 08:08:23AM +0200, Florian Lohoff wrote: > > UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away > > Looking at your sig in mutt in urxvt, and in vim in urxvt, I get > outlined bo

Re: utf-8 characters not shown

fonts to display them. 🐋 🐁 Regards, Luis On Tue, Apr 26, 2016 at 08:08:23AM +0200, Florian Lohoff wrote: > > Hi, > > i found the below utf-8 string in perl6 examples and thought that it would be > a > good test in a signature - I immediatly found my own mutt wouldnt disp

Re: utf-8 characters not shown

On Tue, Apr 26, 2016 at 08:08:23AM +0200, Florian Lohoff wrote: > > Hi, > > i found the below utf-8 string in perl6 examples and thought that it would be > a > good test in a signature - I immediatly found my own mutt wouldnt display it. > I > see it correctly in vim

utf-8 characters not shown

Hi, i found the below utf-8 string in perl6 examples and thought that it would be a good test in a signature - I immediatly found my own mutt wouldnt display it. I see it correctly in vim editing the mail. Locale is UTF-8, everythings fine. I send the email and find the utf8 characters in the

Re: decoding UTF-8

On Tue, Mar 15, 2016 at 11:18:47AM +0100, Ionel Mugurel Ciobîcă wrote: > On 14-03-2016, at 17h 30'55", Jon LaBadie wrote about "decoding UTF-8" > > I frequently find headers (mostly Subject, but also From/To) > > that I assume are some representation form for

Re: decoding UTF-8

On Tue, Mar 15, 2016 at 01:23:37PM +0100, Gabriel Philippe wrote: > > Quite funny, I spent some time on it yesterday... > > This is rfc2047 encoding [1]. It can probably use other charsets (not > only UTF-8). > > The best way I found is to pipe it through perl -MEncode -ne

Re: decoding UTF-8

On Mon, Mar 14, 2016 at 10:30 PM, Jon LaBadie wrote: > I frequently find headers (mostly Subject, but also From/To) > that I assume are some representation form for a UTF-8 encoded > string as they start with "=?UTF-8?" and end with "=?= ". > For example: > >

Re: decoding UTF-8

Hi, That should work automatically. If after =?UTF-8 there is ?Q then the non-ascii characters (and =) are represented by their hexadecimal representation, for example ç is =C3=A7. If after =?UTF-8 there is ?B then all characters are encoded using an algorithm that takes 6bits at the time. You

Re: decoding UTF-8

On 2016-03-14 at 17:30, Jon LaBadie wrote: > Is my assumption correct? What is the representation called? Is there a > tool to regain the original string? I believe my video system can display > the larger character set. You are correct, it's just the UTF-8 encoding. There is a

decoding UTF-8

I frequently find headers (mostly Subject, but also From/To) that I assume are some representation form for a UTF-8 encoded string as they start with "=?UTF-8?" and end with "=?= ". For example: To: =?UTF-8?B?Z3VuZGk=?= Is my assumption correct? What is the representatio

Re: Encoding switching from UTF-8 to Latin1 before being sent

gt; > contains latin characters with acute, like 'é', but no unicode character not > > covered by latin1. The text editor -- Emacs, but I tested with others too -- > > will correctly set it to UTF-8. > > > > file /tmp/mutt-... > > > > will co

Re: Encoding switching from UTF-8 to Latin1 before being sent

e character not > covered by latin1. The text editor -- Emacs, but I tested with others too -- > will correctly set it to UTF-8. > > file /tmp/mutt-... > > will confirm this. > > When I close the editor, thus swithing back to Mutt, it sees the content as > iso885

Encoding switching from UTF-8 to Latin1 before being sent

oo -- will correctly set it to UTF-8. file /tmp/mutt-... will confirm this. When I close the editor, thus swithing back to Mutt, it sees the content as iso8859-1. This is on the "Mutt Compose" screen, right before actually sending the mail. Of course I can convert it at this very same

Re: built-in pager and utf-8

e lib is buggy though... Programs using the non-w version might work by virtue of the fact that they're just dumping the raw bytes to your terminal, which is interpreting the UTF-8 sequences correctly. > Okay, basically the problem is solved. And I like the GNU Unifont. Me too. :) >

Re: built-in pager and utf-8

On Mon, Jul 23, 2012 at 12:55:38PM -0500, Derek Martin wrote: > I'm at a loss... Everything looks to be configured right on your > system, and the e-mail displays correctly in Mutt for me; the hex dump > was also not especially helpful. I would normally be inclined to > point to your font, b

Re: built-in pager and utf-8

o hex dump it to look at the raw bytes.) > > See attached file `file-modification-times'. > > -- > Harald Weis > From help-gnu-emacs-bounces+hawei=free...@gnu.org Sun Jul 1 08:26:42 2012 > Return-Path: > Delivered-To: unknown > Received: from pop.free.fr (212.27.48.3) by pollux.lo

Re: built-in pager and utf-8

26.free.fr (HELO lists.gnu.org) (212.27.42.86) by mrelay2-g25.free.fr with SMTP; 1 Jul 2012 01:20:12 - Received: from lists.gnu.org ([208.118.235.17]) by mx1-g20.free.fr (MXproxy) for ha...@free.fr; Sun, 1 Jul 2012 03:20:12 +0200 (CEST) X-ProXaD-SC: state

Re: built-in pager and utf-8

On Tue, Jul 17, 2012 at 04:12:03PM +0200, Harald Weis wrote: > > Following the FreeBSD Handbook, I use login classes set in /etc/login.conf. > > If I remember correctly, nothing else is required. > > me@pollux:~ % setenv |grep UTF > > MM_CHARSET=UTF-8 > > LANG

Re: built-in pager and utf-8

Harald Weis wrote: > Does everybody think - when reading this message - > that my case is hopeless ? I don't see why. I don't have any problems reading UTF-8 in the pager - see attached. This is a pretty bog standard mutt on Debian; mutt -v gives Mutt 1.5.21 (2010-09-15) Copyrig

Re: built-in pager and utf-8

If you did want to use 1.5.21, the mutt-devel port is usually > > up-to-date. > > > > Did you check your locale settings? Mine are as follows: > > > > LANG=ja_JP.UTF-8 > > LC_ALL=ja_JP.UTF-8 > > LC_CTYPE=ja_JP.UTF-8 > >

UTF-8/ISO problems only in message subject

Hi, When I receive messages from an specific user, the subject come with \234 instead the latin1 character. However, in the body, the characters is displayed correct. Please, see the attached message. How I could workaround this issue? Thank you very much! -- Marcelo Brasil (Brazil, for Eng

Re: built-in pager and utf-8

s follows: > > LANG=ja_JP.UTF-8 > LC_ALL=ja_JP.UTF-8 > LC_CTYPE=ja_JP.UTF-8 > > You probably don't want Japanese, but some sort of locale setting with > "UTF-8" in the name ought to do you. I can confirm these settings are > working on my FreeBS

Re: built-in pager and utf-8

id want to use 1.5.21, the mutt-devel port is usually up-to-date. Did you check your locale settings? Mine are as follows: LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 LC_CTYPE=ja_JP.UTF-8 You probably don't want Japanese, but some sort of locale setting with "UTF-8" in the nam

Re: built-in pager and utf-8

On Mon, Jul 02, 2012 at 10:42:39AM -0500, Derek Martin wrote: > On Mon, Jul 02, 2012 at 05:09:21PM +0200, Harald Weis wrote: > > I assume if you paste the equations with a mouse to emacs, the > > subscripts would be displayed correctly. > > > > > What I can't guess is what *you* are see

Re: built-in pager and utf-8

On 2012-07-01, Patrice Levesque wrote: > > > > Mutt's built-in pager does not seem to understand utf-8. > > Example copied from a gnu-emacs mailing list: > > [...] > > t₁ = 65536×h₁ + l₁ > > 0 ≤ h₁ < 65536 > > 0 ≤ l₁ < 65536 > &g

Re: built-in pager and utf-8

On Sun, Jul 01, 2012 at 11:48:37AM -0400, Patrice Levesque wrote: > in mutt, you'll need to configure 'set charset="UTF-8"' NO YOU DO NOT, and in fact you should generally never do this. If your locale is set correctly, Mutt will take care of this for you automat

Re: built-in pager and utf-8

> Mutt's built-in pager does not seem to understand utf-8. > Example copied from a gnu-emacs mailing list: > [...] > t₁ = 65536×h₁ + l₁ > 0 ≤ h₁ < 65536 > 0 ≤ l₁ < 65536 Both display here just fine under mutt-1.5.21-r9 (gentoo). Make sure all the component

Re: built-in pager and utf-8

On Mon, Jul 02, 2012 at 05:09:21PM +0200, Harald Weis wrote: > I assume if you paste the equations with a mouse to emacs, the > subscripts would be displayed correctly. > > > What I can't guess is what *you* are seeing which causes you to > > query it ? > > I see character-size rectangles

Re: built-in pager and utf-8

On Mon, Jul 02, 2012 at 02:14:21PM +0100, Ken Moffat wrote: > On Sun, Jul 01, 2012 at 04:59:51PM +0200, Harald Weis wrote: > > My muttrc sets editor to "joe". > > > > Mutt's built-in pager does not seem to understand utf-8. > > > &

Re: built-in pager and utf-8

On Sun, Jul 01, 2012 at 04:59:51PM +0200, Harald Weis wrote: > My muttrc sets editor to "joe". > > Mutt's built-in pager does not seem to understand utf-8. > > Example copied from a gnu-emacs mailing list: > > The first time is charact

Re: built-in pager and utf-8

On Mon, Jul 02, 2012 at 10:19:56AM +0900, Daniel P. Wright wrote: > The example works fine in my mutt. > > You might find it's a result of your compile settings -- try "mutt -v" > to see them. In particular, look for +HAVE_WC_FUNCS. If you don't have > widechar funcs, try recompiling agains

Re: built-in pager and utf-8

sw or slang. Harald Weis (Sun, Jul 01, 2012 at 04:59:51PM +0200) >> > My muttrc sets editor to "joe". > > Mutt's built-in pager does not seem to understand utf-8. > > Example copied from a gnu-emacs mailing list: > >

Re: built-in pager and utf-8

On Sun, Jul 01, 2012 at 04:59:51PM +0200, Harald Weis wrote: > My muttrc sets editor to "joe". > > Mutt's built-in pager does not seem to understand utf-8. Yes, it does. I read UTF-8 mail in non-Latin charsets all the time. There is, however, a bug in how Mutt deals w

built-in pager and utf-8

My muttrc sets editor to "joe". Mutt's built-in pager does not seem to understand utf-8. Example copied from a gnu-emacs mailing list: The first time is characterized with this syst

Re: Good Unicode support in fonts (was: Re: Just converted to UTF-8. Line graphics don't work. :-()

Quoth Aaron Toponce on Thursday, 12 May 2011: > On Thu, May 12, 2011 at 04:08:24PM +, Alan Mackenzie wrote: > > I suspect the font I'm using is lacking support for the line graphics, > > and the driver for the screen is helpfully outputting an ASCII > > represent

Re: Just converted to UTF-8. Line graphics don't work. :-(

putting an > > ASCII representation of the 3 UTF-8 bytes which code up the line > > graphic code. > If your environment is indeed properly set up as UTF-8, that should > not ever happen. The console driver should recognize that its font > has no glyph for the UTF-8 character which it

Re: Just converted to UTF-8. Line graphics don't work. :-(

On Thu, May 12, 2011 at 04:08:24PM +, Alan Mackenzie wrote: > I suspect the font I'm using is lacking support for the line graphics, > and the driver for the screen is helpfully outputting an ASCII > representation of the 3 UTF-8 bytes which code up the line graphic code. If yo

Re: Just converted to UTF-8. Line graphics don't work. :-(

I suspect the font I'm using is lacking support for the line graphics, and the driver for the screen is helpfully outputting an ASCII representation of the 3 UTF-8 bytes which code up the line graphic code. > > Are these line drawing glyphs in Unicode, anywhere? > Yes. Mutt displays pe

Re: Just converted to UTF-8. Line graphics don't work. :-(

, I recommend the LatGrkCyr variant (which should also be available pre-built in the next version of 'kbd'). The tarball also has some example data to help identify which unicode glyphs *any* font covers (ignoring non-alphabetic languages, of course). I'm glad to find someone still usin

Re: Just converted to UTF-8. Line graphics don't work. :-(

e). Mutt has nothing to do with it. Your system provides a number of fonts which are loadable on the console. How you do that has changed a number of times though. > Are these line drawing glyphs in Unicode, anywhere? Yes. Mutt displays perfectly fine on my UTF-8 console, for what it

Re: Just converted to UTF-8. Line graphics don't work. :-(

r application use", which is a shame - there're 2^31 codes to go round, after all. I hate unicode, especially UTF-8. Perhaps it would be best for me to go back to good old ISO 8859-1. > Nick -- Alan Mackenzie (Nuremberg, Germany). > On Mon, May 09, 2011 at 02:45:32PM +00

Re: Just converted to UTF-8. Line graphics don't work. :-(

4 5 6 7 3 > I run mutt 1.5.21 on a Linux virtual terminal (NOT in X). Yesterday I > converted my system software from ISO-8859-1 to UTF-8. Now I find that > the line graphics in the message index, rather than looking like lines, > look something l

Just converted to UTF-8. Line graphics don't work. :-(

Hi, mutt! 1 2 3 4 5 6 7 3 I run mutt 1.5.21 on a Linux virtual terminal (NOT in X). Yesterday I converted my system software from ISO-8859-1 to UTF-8. Now I find that the line graphics in the message index, rather than looking like lines

Re: setting mutt to charset UTF-8 ?

w? [...] > > Xterm (ISO-8859-1) and 'vim' > > encoding=utf-8 > fileencoding=latin1 > fileencodings=ucs-bom,utf-8,default,latin1 > termencoding=latin1 > > urxvt (UTF-8) and 'vim': > > encoding=utf-8 > fileencoding=utf-8 > file

Re: setting mutt to charset UTF-8 ?

, the Spanish char á > > (0xe1 in ISO) and I do a reply then: > > > > with xterm (ISO-8859-1) and 'vim' the á is correctly presented as > > > > > > > > á > > > > with urxvt (UTF-8) and 'vim' the á is presented as

Re: setting mutt to charset UTF-8 ?

On Wed, Oct 06, 2010 at 10:00:27AM -0500, Nicolas Williams wrote: > It is, since Matthias must be using Solaris (given the reference to > truss(1)), and on Solaris es_ES.UTF-8 is very much a valid locale name. > Of course, that locale might not be _installed_, so the locale -a check > is still a go

Re: setting mutt to charset UTF-8 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, October 6 at 05:07 PM, quoth Matthias Apitz: >You are right, but only half way :-) >In parts it is written in ISO-8859-1 > >I found the reason. From .muttrc the $attribution was inserted as > > El día %d, %n escribió:\n" Ahhh, I

Re: setting mutt to charset UTF-8 ? [SEC=UNCLASSIFIED]

On Wed, Oct 06, 2010 at 11:07:28PM +0800, Wilkinson, Alex wrote: > 0n Wed, Oct 06, 2010 at 10:00:27AM -0500, Nicolas Williams wrote: > > >It is, since Matthias must be using Solaris (given the reference to > >truss(1)), > > #uname -s && which truss > FreeBSD > /usr/bin/truss > > :

Re: setting mutt to charset UTF-8 ?

El día Wednesday, October 06, 2010 a las 10:00:27AM -0500, Nicolas Williams escribió: > It is, since Matthias must be using Solaris (given the reference to > truss(1)), and on Solaris es_ES.UTF-8 is very much a valid locale name. > Of course, that locale might not be _installed_, so the locale -a

Re: setting mutt to charset UTF-8 ?

El día Wednesday, October 06, 2010 a las 09:52:22AM -0500, Kyle Wheeler escribió: > Well, of course it is. When mutt reads an email message, it reads it > into it's own local memory, transforms it into a form that is > convenient to think about (in this case, utf-8), an

Re: setting mutt to charset UTF-8 ? [SEC=UNCLASSIFIED]

0n Wed, Oct 06, 2010 at 10:00:27AM -0500, Nicolas Williams wrote: >It is, since Matthias must be using Solaris (given the reference to >truss(1)), #uname -s && which truss FreeBSD /usr/bin/truss :P -Alex IMPORTANT: This email remains the property of the Department of Defence

Re: setting mutt to charset UTF-8 ?

) and 'vim' the á is correctly presented as > > > > > á > > with urxvt (UTF-8) and 'vim' the á is presented as > > > > > á > > Why is this? In each of your two vim

Re: setting mutt to charset UTF-8 ?

On Wed, Oct 06, 2010 at 09:52:22AM -0500, Kyle Wheeler wrote: > On Wednesday, October 6 at 04:31 PM, quoth Matthias Apitz: > >It is converted *before* it is stored into the temp file for 'vim'; I've > >checked this with truss(1) what mutt hands over to vim (see the > >marked bytes): > > [...]

Re: setting mutt to charset UTF-8 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wednesday, October 6 at 04:31 PM, quoth Matthias Apitz: >> It's because vim isn't *told* what character set the input file >> will be; it has to guess. Mutt is handing it a UTF-8 file (because >> mutt converts mai

Re: setting mutt to charset UTF-8 ?

> > What combination of terminal and editor should be used now? When I'm > > receiving an ISO-8859-1 message with, for example, the Spanish char > > á (0xe1 in ISO) and I do a reply then: > > > > with xterm (ISO-8859-1) and 'vim' the á is correctly pre

Re: setting mutt to charset UTF-8 ?

now? When I'm > receiving an ISO-8859-1 message with, for example, the Spanish char > á (0xe1 in ISO) and I do a reply then: > > with xterm (ISO-8859-1) and 'vim' the á is correctly presented as > > > á > >with urxvt (UTF-8) and 'vim' the

Re: setting mutt to charset UTF-8 ?

7;vim' the á is correctly presented as > > á with urxvt (UTF-8) and 'vim' the á is presented as > > á Why is this? I would like tro switch to urxvt (UTF-8) to see/read real UTF-8 messages too; Thanks matthias -- Matthias Apitz

Re: setting mutt to charset UTF-8 ?

El día Wednesday, October 06, 2010 a las 09:55:08AM +0200, Matthias Apitz escribió: > The ./configure was indeed done without pointing it to the location of > libiconv and so iconv support was mapped out. I corrected this now, but: > > when I run ./configure as: > > # ./configure --enable-imap

Re: setting mutt to charset UTF-8 ?

El día Tuesday, October 05, 2010 a las 02:25:03PM -0500, Kyle Wheeler escribió: > On Tuesday, October 5 at 08:58 PM, quoth Matthias Apitz: > >In the output of mutt -v it says (among other stuff): > > > >-HAVE_ICONV > >-ICONV_NONTRANS > > Ahhh, there you go. The ./configure was indeed done witho

Re: setting mutt to charset UTF-8 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tuesday, October 5 at 08:58 PM, quoth Matthias Apitz: >In the output of mutt -v it says (among other stuff): > >-HAVE_ICONV >-ICONV_NONTRANS Ahhh, there you go. >but nothing positiv/negativ about UTF-8. I can't check

Re: setting mutt to charset UTF-8 ?

El día Tuesday, October 05, 2010 a las 10:19:29AM -0500, Kyle Wheeler escribió: > On Tuesday, October 5 at 11:58 AM, quoth Matthias Apitz: > >Error in /home/guru/.muttrc, line 70: Invalid value for option > >send_charset: "us-ascii:iso-8859-1:utf-8" > > > >

Re: setting mutt to charset UTF-8 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tuesday, October 5 at 11:58 AM, quoth Matthias Apitz: >Error in /home/guru/.muttrc, line 70: Invalid value for option >send_charset: "us-ascii:iso-8859-1:utf-8" > >I double checked this against the man page and even cut

Re: setting mutt to charset UTF-8 ?

El día Monday, October 04, 2010 a las 11:06:22PM -0500, Kyle Wheeler escribió: > I've been using mutt as a UTF-8 "enabled" program for... gosh, > probably four years now. So, it works, and it works well. Here are > some things to consider, though: > > 1. A

Re: setting mutt to charset UTF-8 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Monday, October 4 at 11:25 AM, quoth Athanasius: >> I'm unsure if I should completely switch to UTF-8 already, maybe >> this would cause big disaster in the receiving sites, mailing lists >> etc. What is the opinion ab

setting mutt to charset UTF-8 ?

Hello, At the moment I still have set the xterm for mutt to ISO-8859-1, i.e. receiving and sending messages in ISO. More and more I receive email now in UTF-8 and to read them I open another terminal 'urxvt' with the LANG set to es_ES.UTF-8 to read such message... I'm uns

Re: setting mutt to charset UTF-8 ?

On 04.10.10 11:35:03, Matthias Apitz wrote: > At the moment I still have set the xterm for mutt to ISO-8859-1, i.e. > receiving and sending messages in ISO. More and more I receive email now > in UTF-8 and to read them I open another terminal 'urxvt' with the LANG > set to es

Re: setting mutt to charset UTF-8 ?

On Mon, Oct 04, 2010 at 11:35:03AM +0200, Matthias Apitz wrote: > At the moment I still have set the xterm for mutt to ISO-8859-1, i.e. > receiving and sending messages in ISO. More and more I receive email now > in UTF-8 and to read them I open another terminal 'urxvt' wit

Re: setting mutt to charset UTF-8 ?

On 04.10.10,11:35, Matthias Apitz wrote: > > Hello, > > At the moment I still have set the xterm for mutt to ISO-8859-1, i.e. > receiving and sending messages in ISO. More and more I receive email now > in UTF-8 and to read them I open another terminal 'urxvt' with t

Re: OT: sendmail && UTF-8

x27; contains some header lines, especially To: > Subject: and From: and as well the body of the mail; all is in UTF-8 > and I know I have to encode the header lines and says something about > the body. With Perl it goes like this: > > #!/usr/bin/perl > > use utf8; > use

OT: sendmail && UTF-8

mail; all is in UTF-8 and I know I have to encode the header lines and says something about the body. With Perl it goes like this: #!/usr/bin/perl use utf8; use Encode; open (MAIL, "|/usr/lib/sendmail -t"); $x="Subject: ... with some UTF-8 chars"; $x_for_header = Enco

Viewing manual.txt.gz in a non-UTF-8 terminal

How do you view manual.txt.gz in a non-UTF-8 terminal ? "iconv --from utf-8 --to iso-8859-1" bombs at line 11 and recode utf-8..latin-1" at line 2769. -- André Majorel http://www.teaser.fr/~amajorel/

Re: regex and UTF-8

Thanks to all who responded. Though I'm not quite convinced that this is really a mutt bug, and not a peculiarity of mutt interacting with my system, I think I will have to file it as a bug to get any further with it anyway. In the mean time, I think I'm just going to work around it by rewriting

Re: regex and UTF-8

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Friday, October 30 at 07:36 PM, quoth Kevin Kammer: >On Fri, Oct 30, 2009 at 08:43:21AM -0500, Kyle Wheeler wrote: >> Are you using your system's regex library, or the one that comes with >> mutt? It's possible that your system's regex library has

Re: regex and UTF-8

locale > ls |LC_ALL=C sort# case sensitive > Yes, ls |sort executed in my shell, with the default UTF-8 locale, is case insensitive. Regex searches in the shell or other programs behave as expected (i.e. lower-case search patterns are insensitive, whereas mixed-case patterns on

Re: regex and UTF-8

On Fri, Oct 30, 2009 at 08:43:21AM -0500, Kyle Wheeler wrote: > Are you using your system's regex library, or the one that comes with > mutt? It's possible that your system's regex library has a bug in it > (and it would be nice to eliminate that before blaming mutt for the > problem). > > ~Kyl

Re: regex and UTF-8

On Fri, 30 Oct 2009, Kevin Kammer wrote: > $ LC_ALL=C mutt AFAIK, gnu sort perform case sensitive sort for POSIX or C locale, compare output from ls |sort # case insensitive in my locale ls |LC_ALL=C sort# case sensitive -- regards, ==

Re: regex and UTF-8

I also use utf-8 as system locale and charset in muttrc. But I have no problem in default case-insensitive search. eg. ~f kevin can match Kevin. -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys

  1   2   >