On Mon, Dec 01, 2003 at 05:07:36PM +0900, henry nelson wrote: > On Mon, Dec 01, 2003 at 12:36:41AM -0500, David Yitzchak Cohen wrote: > > On Fri, Nov 28, 2003 at 10:27:28AM +0900, henry nelson wrote: > > > On Wed, Nov 26, 2003 at 03:38:15PM -0500, David Yitzchak Cohen wrote: > > > > On Tue, Nov 25, 2003 at 07:51:34PM +0900, henry nelson wrote: > > > > > I've been trying reply-hook's and send-hook's like: > > > > > '~h "(iso-2022-jp|euc-jp)"' my_hdr 'From: \"MyJaName\" > > > > > <netb@xxxxx=3D > > > > > but I get the error that 'h' is not supported in this mode. > [...] > > Those two questions were related. Theoretically, ~h _should_ work > > in that mode, since the header structure is available at that point. > > That was my interpretation wrt " reply-hook." "Send-hook," maybe not. What's a reply-hook? I can't find it anywhere :-( > > However, we've noticed some interesting troubles with IMAP at least, > > where the entire message is fetched when trying to match on ~h ... which > > I can reaffirm that I do not use IMAP. I use the mailbox format, and > will be replying to a mail in either the default /var/mail/$LOGNAME box > or various mailboxes sorted by procmail. All mailboxes are already on > the local machine. Okey, so it's safe to say your problem has nothing to do with IMAP weirdness. That's one source of possible confusion eliminated :-) > > > > My original plan had been to add a speaks: field to my aliases file, > > >=20 > > > This is what I'm doing now in a way, adding specific From: headers accord= > > ing > > > to "~t" patterns. It works quite well for people I know. > > > > =2E..except that my idea (making my makealiasesrc use the speaks: field) > > automates the whole process ... if you're willing to use it, I'm willing > > to implement the feature :-) > > I have to admit that I do not really understand what you had in mind. > Sorry. Are you saying that Mutt would set certain headers, signature, > etc. based on a sourced "alias" file that would contain a list of > recipient addresses matched with a "language", so-called "speaks: field"? What I already have [1] produces an RC file that Mutt sources. It currently generates a whole bunch of alias entries, and that's it. However, I've put a fair amount of work into a similar script [2] lately, and the file it produces [3] shows off the type of power that an autogenerated RC file can have. That particular example has a complete From: header generated in send-hooks on a per-list basis, and the entire file is 100% autogenerated by my script [2] from a data file [4] not unlike the aliases source file. I can easily add send-hook generation to my makealiasesrc [1] script, but there's no point in doing it unless somebody's gonna use it. (To be honest, I'll probably use it myself, but I'm too lazy to implement it for myself alone, at this point.) > Sounds like a terrible amount of work, but if it were user friendly I > suspect it would be useful to bi- or multi-lingual Mutt users. It's extremely user-friendly: you simply feed it the data file on stdin, and it spits back an RC file on stdout. You can either use my Makefile [5] entries, or you can source the output of the script (source "makealiasesrc <aliases |") every time. > > > Well, the best general pattern (i.e., not relying on an alias) I've been > > > able to come up with is right out of the manual: "~t .*\.jp$". Problem > > > > Well, here's another problem you just reminded me of: how about if you > > detect a .jp guy in the To: field, but there's also a .us guy in the > > It already happened to me. :( It's important to stress that my send-hook solution won't solve this problem at all. I'm still thinking on a way to send data from Mutt to an external script; if I can do that, I'll be able to write a negotiate_language script that'll decide on the best language for a given email based on its recipients. > > I like > > the idea of a custom editor since it'll be able to look at the speaks: > > fields of the two (or more) guys, and pick a sensible name for you based > > on the list of languages spoken by each recipient. > > I don't understand what you mean by "custom editor". By "custom editor," I mean to set editor="my_custom_editor" instead of vim or whatever. my_custom_editor will be a script that'll look at the message and make all sorts of automated changes (changing From: based on the recipients, subject, etc.; formatting footnotes; picking a sensible signature; etc.) before and/or after calling your actual editor. > > (Note that doing > > this purely with hooks isn't too easy, AFAICT.) For most of what you say below, hooks seem to me to be totally inadequate. > I'm beginning to think you are right. At least for me, anyway, country > does not indicate the language. Either of my solutions would work around that problem quite nicely (since each contact would have a speaks: field, anyway). > The content-type/charest header would > be fairly close. I can't afford to make decisions based on that for reasons I've already stated. I prefer to use a heuristic (e.g. spell checking) to determine what the "primary" language of the original mail was and/or to determine what the "primary" language of my own email is. Either way, the test itself would be abstracted into something like a what_language_is_this script, which you could replace with anything you want (including a simple test of the charset). > I will be writing in one or other language depending > on what language the mail is that I am replying to. Forget about using hooks on that. Only the custom editor works there, AFAIK. > I will be initiating > a mail in one or other language depending on whom I am writing to. That's the only case that the hooks handle gracefully (and fully automatically, if I patch up my makealiasesrc script). > In > either case, I want the From: header and signature to match the language > of the message body. yup, same here :-) - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpMF8D5JNMrT.pgp
Description: PGP signature