Re: Fwd: Re: ports/156189: [new port] mail/muttils: python utilities for console email clients
Quoth Jason Helfman on Thursday, 12 May 2011: > Woo hoo! muttils has been committed to FreeBSD! > > :) > From: w...@freebsd.org > To: jhelf...@experts-exchange.com, w...@freebsd.org, w...@freebsd.org > Subject: Re: ports/156189: [new port] mail/muttils: python utilities for > console email clients > Date: Thu, 12 May 2011 23:43:03 GMT > > Synopsis: [new port] mail/muttils: python utilities for console email clients > > State-Changed-From-To: open->closed > State-Changed-By: wxs > State-Changed-When: Thu May 12 23:43:03 UTC 2011 > State-Changed-Why: > Committed. Thanks! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156189 > Excellent -- thanks for doing the port, Jason! -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpw2AMsivbLi.pgp Description: PGP signature
Fwd: Re: ports/156189: [new port] mail/muttils: python utilities for console email clients
Woo hoo! muttils has been committed to FreeBSD! :) --- Begin Message --- Synopsis: [new port] mail/muttils: python utilities for console email clients State-Changed-From-To: open->closed State-Changed-By: wxs State-Changed-When: Thu May 12 23:43:03 UTC 2011 State-Changed-Why: Committed. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=156189 --- End Message ---
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 > > representation of the 3 UTF-8 bytes which code up the line graphic code. > > This is just an FYI based on personal experience, so take it as you will, > but I've personally found the following fonts to have good overall Unicode > support for my needs (your needs might be different): > > 0) DejaVu > 1) Liberation > 2) Courier > > Some fonts that I have found lack good (if any at all) Unicode support are: > > 0) Calibri, Cambria, Candara, Constantia, Consolas and Corbel > 1) Bitstream > 2) Most standard "free" fonts installed by default > > I was surprised that the Vista fonts were as lacking as they were. They're > essentially just Latin, Greek and Cyrillic fonts, which is disappointing. I > would expect more from a major organization with deep pockets. Awards or no > awards, they are seriously lacking. > > I prefer DejaVu for my font rendering almost everywhere. It's clean, > supports a substantial number of glyphs, is updated frequently, and is > licensed under a free license. > > Anyway, thought I would share. > > -- > . o . o . o . . o o . . . o . > . . o . o o o . o . o o . . o > o o o . o . . o o o o . o o o +1 on DejaVu. For the unusual unicode glyphs, I use Code2000 as a backup font. But line-drawing characters are included in DejaVu. -- .O. | Sterling (Chip) Camden | http://camdensoftware.com ..O | sterl...@camdensoftware.com | http://chipsquips.com OOO | 2048R/D6DBAF91 | http://chipstips.com pgpBSN7Zdp9pd.pgp Description: PGP signature
Re: Just converted to UTF-8. Line graphics don't work. :-(
Hi, Derek. On Thu, May 12, 2011 at 11:42:39AM -0500, Derek Martin wrote: > 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 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 is trying to print, and > print a diamond instead. The behavior you are seeing is that the > console is treating this as three separate ASCII characters. > > I decoded M-b~T~T to 0xe29494 -> 0x2514. I found a Unicode decoder, and > > it does indeed say that 0x2514 is the appropriate line glyph. > Those two behaviors are consistent with this: > > Indeed, my mutt is linking with libncurses.so. I also have a > > libncursesw.so on my system. How do I persuade mutt to build with > > ncursesw? There doesn't seem to be a flag in Gentoo's configuration to > > force this. Maybe I should ask on the Gentoo mailing list. > I guess it depends how you're installing Mutt. If you have the > ncursesw *devel* bits installed, IIRC mutt will notice them when you > configure it (i.e. manual compile). I've worked out what happened. Up until last Sunday I had the Gentoo build configuration flag "unicode" disabled. So before that I didn't have an ncursesw, only an ncurses. mutt thus linked itself with the existing ncurses. When I enabled "unicode" and rebuilt "everything", libncursesw appeared, but mutt wasn't rebuilt, due to an error in its build script. So I was still using an 8-bit mutt. I've just rebuilt mutt, and now everything works as desired, including the line graphics and non-ASCII characters in people's names. > > Does mutt use the environment variables like LANG and LC_ to > > determine how to output stuff? > Yes, absolutely. [Generally you want to set LANG properly and let the > LC_* vars inherit from it.] In the past though, you did have to do > things to tell the kernel that you wanted to use a UTF-8 console. That > seems to have changed, as I don't need to do this on either my Fedora > or Ubuntu installs... But I haven't built a custom kernel since the > 2.4 days; so I can't say whether there's some required configuration > option in the kernel config stuff that you may need to enable to make > it work properly. You can configure language options in the file system section. I think that's just for non-ASCII filenames, not their contents. > But there's a fairly easy test for this: If you have a file lying > around which contains umlauts or other diacritic characters and which > you're sure is encoded using UTF-8, just cat it on the console. If it > displays properly, or if you see diamonds in positions where non-8-bit > UTF-8 characters should be, then your console is fine. Done this, it is. > No problem. I went through all this long ago when the software was > still poor and the docs were poorer, so I feel your pain. You have it > relatively easy now. ;-) Indeed! Thanks again. > -- > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -- Alan Mackenzie (Nuremberg, Germany).
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 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 is trying to print, and print a diamond instead. The behavior you are seeing is that the console is treating this as three separate ASCII characters. > I decoded M-b~T~T to 0xe29494 -> 0x2514. I found a Unicode decoder, and > it does indeed say that 0x2514 is the appropriate line glyph. Those two behaviors are consistent with this: > Indeed, my mutt is linking with libncurses.so. I also have a > libncursesw.so on my system. How do I persuade mutt to build with > ncursesw? There doesn't seem to be a flag in Gentoo's configuration to > force this. Maybe I should ask on the Gentoo mailing list. I guess it depends how you're installing Mutt. If you have the ncursesw *devel* bits installed, IIRC mutt will notice them when you configure it (i.e. manual compile). Gentoo's software management is pretty unique, and I have no experience with it, but if you're using emerge then I would expect the same thing *should* be true. So the key is to make sure that you have the development portion of the ncursesw library installed. There are probably gentoo savvy people here, but you may get a faster response by asking on their list instead. > > If your system is actually recent then telling us what it is and how > > you converted it may provide some useful clues as to what's missing. > > Up to date Gentoo. Can't help here either, for the same reason. > Does mutt use the environment variables like LANG and LC_ to > determine how to output stuff? Yes, absolutely. [Generally you want to set LANG properly and let the LC_* vars inherit from it.] In the past though, you did have to do things to tell the kernel that you wanted to use a UTF-8 console. That seems to have changed, as I don't need to do this on either my Fedora or Ubuntu installs... But I haven't built a custom kernel since the 2.4 days; so I can't say whether there's some required configuration option in the kernel config stuff that you may need to enable to make it work properly. But there's a fairly easy test for this: If you have a file lying around which contains umlauts or other diacritic characters and which you're sure is encoded using UTF-8, just cat it on the console. If it displays properly, or if you see diamonds in positions where non-8-bit UTF-8 characters should be, then your console is fine. Probably fixing mutt's build will make it work properly, I would guess. > A very great deal, thanks! No problem. I went through all this long ago when the software was still poor and the docs were poorer, so I feel your pain. You have it relatively easy now. ;-) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpZdZxifstZK.pgp Description: PGP signature
Re: mairix search
On Sun, May 08, 2011 at 05:10:22PM -0400, Tim Gray thus spake:
On May 08, 2011 at 10:47 PM +0200, Christian Ebert wrote:
$ time mairix -v -p
I bet that was my problem. I don't think I ever used -p, so there were
a lot of dead messages floating around in my db.
The times I'm getting now are pretty good. Notmuch seems to be faster,
but the times are all low enough that I don't have a problem with any of
them.
mairix -v -p
real0m17.682s
user0m4.911s
sys 0m8.524s
notmuch new
---
real0m5.152s
user0m0.067s
sys 0m0.261s
Searches for the two showed a similar gap. Again, neither was slow
enough for me to lose any sleep over.
mairix: 0m3.044s
notmuch: 0m0.410s
This is an interesting discussion though. I might play around with
mairix a bit more again. I still see mu and notmuch having a major
advantage of being built on proper database tools. I get a lot of
errors about messages not being indexed by mairix, and that whole
recommended dance of removing the lock file before a search, etc. is
annoying as well. Furthermore, the thing that excites me about notmuch
that the others don't have is the fact that it's built as a library. An
enterprising developer could integrate it into a mail client (other than
the emacs thing they have going on) and it would be pretty great in my
mind. Remember, notmuch isn't just an indexing tool - it also lets you
tag messages and search on tags, etc.
Does anyone use notmuch for FreeBSD? If so I have created a port, and would
like to try it out, but I don't have my mail locally sync'd, yet to verify
if this actually works.
Anyone willing to try out the attached shell archive? Just run /bin/sh
against the attachment, then:
cd notmuch; make install (as root, or use sudo)
Thanks,
Jason
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# notmuch/
# notmuch/Makefile
# notmuch/pkg-descr
# notmuch/distinfo
#
echo c - notmuch/
mkdir -p notmuch/ > /dev/null 2>&1
echo x - notmuch/Makefile
sed 's/^X//' >notmuch/Makefile << 'daed98e951f4e6015a65d45ec4b2a91d'
X# New ports collection makefile for: muttils
X# Date created:April 2 2011
X# Whom:Jason Helfman
X#
X# $FreeBSD$
X#
X
XPORTNAME= notmuch
XPORTVERSION= 0.5
XCATEGORIES=mail python
XMASTER_SITES= http://notmuchmail.org/releases/
X
XMAINTAINER=jhelf...@experts-exchange.com
XCOMMENT= Mail indexing tool
X
XLIB_DEPENDS= gmime-2.4:${PORTSDIR}/mail/gmime24 \
X talloc.2:${PORTSDIR}/devel/talloc
XBUILD_DEPENDS+=xapian-config:${PORTSDIR}/databases/xapian-core
XRUN_DEPENDS+= xapian-config:${PORTSDIR}/databases/xapian-core
X
XPLIST_FILES= bin/notmuch \
X man/man1/notmuch.1.gz
XUSE_GMAKE= yes
X
Xdo-install:
X ${INSTALL_PROGRAM} ${WRKSRC}/notmuch ${PREFIX}/bin
X ${INSTALL_DATA} ${WRKSRC}/notmuch.1.gz ${PREFIX}/man/man1
X
X.include
daed98e951f4e6015a65d45ec4b2a91d
echo x - notmuch/pkg-descr
sed 's/^X//' >notmuch/pkg-descr << '96faee797c242a96d3f25e49bbbd52d1'
XNotmuch is a command-line based program for indexing, searching, reading,
Xand tagging large collections of email messages.
X
XWWW: http://notmuchmail.org
96faee797c242a96d3f25e49bbbd52d1
echo x - notmuch/distinfo
sed 's/^X//' >notmuch/distinfo << '38ecdd5c0c83491813eed1b00316c9dd'
XSHA256 (notmuch-0.5.tar.gz) =
c7eeb95c89c5b9cb22cc0b90abce5f923c20c982d607bf32829c989e905ff1a9
XSIZE (notmuch-0.5.tar.gz) = 340156
38ecdd5c0c83491813eed1b00316c9dd
exit
pgp7NbcKDEP5v.pgp
Description: PGP signature
Re: Just converted to UTF-8. Line graphics don't work. :-(
Hi, Derek. On Wed, May 11, 2011 at 05:54:38PM -0500, Derek Martin wrote: > On Wed, May 11, 2011 at 09:41:32PM +, Alan Mackenzie wrote: > > On Mon, May 09, 2011 at 02:16:23PM -0700, Nick wrote: > > > The font you are using likely doesn't support the line glyphs. > > > I've found Envy Code R to be a good all-purpose font that supports > > > a good number of glyphs. > > Surely it would have to be included as part of mutt. I think the > > font's author doesn't permit this. > Not at all... The console uses the same font no matter what program > you're running (unless it's a program to set the console font, I > suppose). 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. 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 perfectly fine on my UTF-8 console, for what it's > worth. I decoded M-b~T~T to 0xe29494 -> 0x2514. I found a Unicode decoder, and it does indeed say that 0x2514 is the appropriate line glyph. > > I hate unicode, especially UTF-8. Perhaps it would be best for me to > > go back to good old ISO 8859-1. > Not likely. The world is moving (or, by and large, has already moved) > to Unicode; eventually the older encoding schemes will very likely > disappear entirely, and you'll run into all sorts of problems. > There's no reason to hate UTF-8; it is just yet another encoding > system which now very well supported and superior technically to > ISO-8859-1. Don't hate technological advancement because you chose > not to keep up with it... :) I don't agree that new things are always better than old. Unicode has its disadvantages too, but I suspect here isn't really the place to hack out the argument. Feel free to take it to email, though. ;-) > > > > 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. > What does that mean, exactly? What kernel/distro release/version are you > running, and how did you convert? It seems very likely that there are > pieces missing from whatever procedure you followed. I've got linux-2.6.37 running in an up-to-date Gentoo (which has a "rolling release" system). See below for details of my conversion. > One other possibility is that mutt is not built suitably to support > UTF-8. Look at the output of this command: > ldd /path/to/mutt > replacing /path/to/mutt with the actual path to your mutt binary. If > you see libncurses instead of libncursesw, it means mutt was built > without support for wide characters, and will need to be rebuilt. > In that case, most likely you will need to install the correct > ncursesw libraries, including the development bits. This problem has > bitten me a few times in the past. Indeed, my mutt is linking with libncurses.so. I also have a libncursesw.so on my system. How do I persuade mutt to build with ncursesw? There doesn't seem to be a flag in Gentoo's configuration to force this. Maybe I should ask on the Gentoo mailing list. > > > > Is there a proper solution to this dilemma? > There definitely is, . You may need to install some console > fonts and utilities to load them, etc. depending on the current state > of your system. > If your system is actually recent then telling us what it is and how > you converted it may provide some useful clues as to what's missing. Up to date Gentoo. I converted by editing the boot-up scripts /etc/conf.d/consolefont and /etc/conf.d/keymaps, and creating two new UTF-8 locales (one of which I've set to the default by setting LANG="en_GB.UTF-8" in /etc/env.d/02locale). The font now in use is called default8x16.psfu.gz. I don't know if this contains 0x2514 and friends. Does mutt use the environment variables like LANG and LC_ to determine how to output stuff? > Hope that helps. A very great deal, thanks! > -- > Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -- Alan Mackenzie (Nuremberg, Germany).
Can I set the pgp sign file name?
Hi I want to know can I set the sign file's name? now the gpg sign name is "noname". thanks pgprEvIpuACAg.pgp Description: PGP signature
