Re: Change mail folder without pressing = first?
On 15.05.2008 (15:07), David Champion wrote: macro index c change-folder= Arggh -- was it that simple... Thanks a lot. Eyolf -- Cogito cogito ergo cogito sum -- I think that I think, therefore I think that I am. -- Ambrose Bierce, The Devil's Dictionary
Change mail folder without pressing = first?
The subject line hopefully says it all: the one thing that bothers me most in mutt is that I have to press = before changing mail folders. Is there a way to change this behaviour, so that I can type c and then directly the name of the mailbox? On my keyboard (norwegian), the = key is a shift+number key, which is quite awkward, especially if I do it frequenty (which I do). I'd be happy to trade it for typing some prefix if I want to change to some folder in the file system, which I don't do that often. My apologies in advance if this is already well-documented; I haven't found it. Eyolf -- Because of the one-pointed Time awareness in which the conventional mind remains immersed, humans tend to think of everything in a sequential, word-oriented framework. This mental trap produces very short-term concepts of effectiveness and consequences, a condition of constant, unplanned response to crises. -- Liet-Kynes, The Arrakis Workbook
Re: Replying to Email / Removing previous signature
On 04.03.2008 (15:34), Chris Bannister wrote: So in your .muttrc do you have something like: set editor =vim -u mutt-vimrc or ...? The -u option skips all other initialisation, which would mean options like 'textwidth= ' would be lost. Yes, something like that. I've been playing around with various options; I figured I don't need to load all the plugins for latex or html when I just want to write a mail, so I have a mutt-vimrc file as you say, with only the essential settings, such as textwidth. However, I've often found myself needing the plugins even when editing mail, so I'm changing my mind on this, going for settings in ~/.vim/after/mail instead. Eyolf -- The only really good place to buy lumber is at a store where the lumber has already been cut and attached together in the form of furniture, finished, and put inside boxes. -- Dave Barry, The Taming of the Screw
Re: Replying to Email / Removing previous signature
On 27.02.2008 (17:37), Breen Mullins wrote: Since my suggested mapping map ,ds :.,/^-- $/-1dCRO only makes sense if I'm editing a mail, I pulled it from my .vimrc and dropped it into ~/.vim/after/syntax/mail.vim . For what it's worth, I have the following in my mutt-vimrc file: imap leaderff esc:/^-- $/+1,$dcresc:r !fortune -ecrc-o nmap leaderff :/^-- $/+1,$dcresc:r !fortune -ecrc-o imap leaderdd esc:,/^-- $/-2dcri nmap leaderdd :,/^-- $/-2dcri The first changes the fortune cookie if I'm not happy with it and leaves the cursor in place, the second removes everything from the cursor to the signature (old top-posters leftovers, etc.), and leaves the editor in insert mode (optional, but that's the way I like it). Eyolf -- They will only cause the lower classes to move about needlessly. -- The Duke of Wellington, on early steam railroads.
Re: Using Mairix
On 18.10.2007 (11:57), Paul Hoffman wrote: Yes, it's possible -- I've done it using namazu instead of mairix and it works well, And On 18.10.2007 (13:54), Ajeet wrote: Yes it is! Use the script mairix_query.sh attached as follows: Thanks to both of you! Only problem now is figuring out which of the scripts to use... :-) Eyolf -- ... but hey, this is Linux, isn't it meant to do infinite loops in 5 seconds? -- Jonathan Oxer in the apt-cacher ChangeLog
Re: Using Mairix
On 17.10.2007 (20:50), Rem P Roberti wrote: I just installed Mairix, and the program works fine, except that I don't seem to be able to access the mfolder from within Mutt. When I do a search Mairix creates the requiste mfolder containing cur, new, and tmp, and the result of the search is placed in the new subdirectory. But I am unable to access the results of the search in the Mutt index. The mfolder shows up in the index, but it is empty. Anyone tell me what I am doing wrong? I remember having the same kind of problem in the beginning, but I can't remember how I solved it. I *think* it was down to having a bad syntax in my search terms, so that the search didn't catch anything. Perhaps also because I hadn't set the search areas properly. Here's what I have in my .mairixrc: base=~/Mail maildir=*... omit=spam omit=trash omit=mairix database=~/.mutt/mairix-db mfolder=mairix And the macros in .muttrc: macro index,pager \em shell-escapemairix Run a Mairix search macro index,pager \ef change-folder-readonly=mairix\n Search results On that note: can someone tell me if there is a way to combine the two into one? I would like to go automatically to the mairix folder once the search is over, instead of having to go there manually. Is that possible? Eyolf -- An Irishman is never at peace except when he's fighting.
Re: Using Mairix
On 18.10.2007 (11:19), Patrick Shanahan wrote: * Eyolf Østrem [EMAIL PROTECTED] [10-18-07 10:58]: macro index,pager \ef change-folder-readonly=mairix\n Search results ^^ Why readonly? Mairix copies search matches into its own folder for display. Only with mbox format, I think: When writing to a mfolder in maildir or MH format, mairix will populate it with symbolic links pointing to the paths of the real messages that were matched by the search expression. If a message in a mbox folder matches, mairix will copy the message contents to a single file in the mfolder directory. As for the readonly -- I'm not sure anymore. It's not something I've come up with myself, certainly. I think I found it on this page: http://larve.net/people/hugo/2003/scratchpad/VirtualFoldersInMutt.html I remember to have read something somewhere about the necessity of using readonly, but I can't remember where, nor why... e -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org -- Ben (Obi-Wan) Kenobi: The Force can have a strong influence on a weak mind.
Re: Mutt Quick Reference v.1.00
On 17.10.2007 (09:13), Joseph wrote: Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) especially useful for new users. Excellent work! If you would like me to add/expand some entires with additional information just let me know. As for mutt-internal stuff, I don't have any requests. (that would have to be the various flags for the index/status line -- how to read them and how to write them in the muttrc. I was wondering, though: I guess not everybody uses mairix and abook, but what about some of the commands for interaction with them in an appendix or something...? It particularly bugs me that the flag syntax for mairix is different from that of mutt -- it took me a while to remember it. Also: would you mind making the source files available (whatever format they're in)? eyolf -- There's certainly precedent for that already too. (Not claiming it's *good* precedent, mind you. :-) -- Larry Wall in [EMAIL PROTECTED]
Re: Generate Reply / New Mail in new shell session
On 05.10.2007 (10:05), Christian Ebert wrote: * Eyolf Østrem on Friday, October 05, 2007 at 01:07:39 +0200 a lilyponder ;) Yep! The following works in a dirty way -- It didn't quite work for me, still. I may play around with different flags and such, but in the end, it isn't really *that* important to me. But thanks for the script anyway. Eyolf -- The faster we go, the rounder we get. -- The Grateful Dead
Re: Which spam filter do you use?
On 05.10.2007 (02:08), Kyle Wheeler wrote: On Friday, October 5 at 08:06 AM, quoth M. Fioretti: Besides some MTA-level filtering, I am using bogo instead of spamassassin because of one simple reason: lack of maintenance. I've read several times that SA rules must be constantly updated and added, otherwise they get half-useless every few weeks. Is this still true? Bah; SpamAssassin is the swiss-army-knife of spam filters. It includes a bayesian filter (not to mention things like razor and dcc, which are constantly up-to-date), and as such, does not require updating the rules. Updating the rules can *help*, but it is not required to continue functioning at a reasonably high level. The real criticism I'd level against SpamAssassin as compared to bogofilter is that SpamAssassin's bayesian classifier is relatively simple. To my knowledge, it doesn't tokenize word-pairs and phrases, but just single words; thus, something that uses more advanced bayesian techniques (I presume bogofilter fits this description?) may well beat it at that particular game---which is where updating the rules can help as a compensating factor. It's not like a virus-scanner where an out-of-date database is worthless. So this does in fact mean that without that extra time tending the rules, SA may actually let more spam through? It's not that I'm dissatisfied with my current situation. My #1 concern is actually with false negatives; I've since long given up browsing through the CapturedSpam folder to check for them before I delete everything. I haven't had any complaints from people who think I neglect them (unless the complaints also end up in the filter...), but in one comparison I read, it seemed that SA had absolutely 0 of that, whereas bogo might have one or two (out of I don't remember how many thousand). All in all, it may not be such a bad thing; if there IS some mail I haven't answered but should have, I can always say sorry, never got your mail, it must have been trapped in the filter. I'd hate to lose that excuse... :-) eyolf -- And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. (By Linus Torvalds, [EMAIL PROTECTED])
Re: Which spam filter do you use?
On 05.10.2007 (15:30), Holger Weiss wrote: * eyolf østrem [EMAIL PROTECTED] [2007-10-05 13:22]: It's not that I'm dissatisfied with my current situation. My #1 concern is actually with false negatives; I've since long given up browsing through the CapturedSpam folder to check for them before I delete everything. So you mean false positives :-) Uhm... yes... positive, negative, who's to know what's what in the long run? Anyway, thanks for all the feedback (I sortof knew when I sent it off that I'm starting a long thread here). I think I'll start by training mr bogo and ask him to be careful with those false whatever. e -- The seven eyes of Ningauble the Wizard floated back to his hood as he reported to Fafhrd: I have seen much, yet cannot explain all. The Gray Mouser is exactly twenty-five feet below the deepest cellar in the palace of Gilpkerio Kistomerces. Even though twenty-four parts in twenty-five of him are dead, he is alive. Now about Lankhmar. She's been invaded, her walls breached everywhere and desperate fighting is going on in the streets, by a fierce host which out-numbers Lankhamar's inhabitants by fifty to one -- and equipped with all modern weapons. Yet you can save the city. How? demanded Fafhrd. Ningauble shrugged. You're a hero. You should know. -- Fritz Leiber, The Swords of Lankhmar
Re: Generate Reply / New Mail in new shell session
On 03.10.2007 (21:57), Joseph wrote: It would be nice if it was possible to start a New Email or Replies in a new shell session and close it automatically when a mail is sent, without, going through postpone. Is it possible? Sometimes I have to look up/collect some information from several older emails so this kind of functionality would really be handy. I was missing that functionality too. I solved it the other way around: open a new instance of mutt. It's a one-keypress thing (I have a desktop keyboard shortcut win-m set up to run xterm -e mutt), and the effect is, I believe, the same as what you describe. One thing I can't do that way is to tag several messages and add them to what I'm replying to, but how often do I do that...? Eyolf -- Life does not begin at the moment of conception or the moment of birth. It begins when the kids leave home and the dog dies.
Which spam filter do you use?
I've been using bogofilter ever since I first installed KDE/Kmail and the potentially hassle-free configuration of SpamAssassin led to constant crashes. I belive it has been solved by now, and in any case Kmail is ancient history, but I was wondering what experiences the list people have with various filters. From what I've read, bogo is quicker than the other contenders, but lets more spam through. While the speed was a concern in Kmail, since the filtering was done in the app itself, which meant that it was unresponsive for a while while the filtering was going on, that is not so much of a concern now, when that is taken care of by procmail. That leaves me with c. 10-15 spam mails a day that slip through (out of c. 150-200). So, should I switch? I'm quite happy with bogo, especially with the current setup with some macros I borrowed from an article in linux journal (I think it was), but I would very much like to hear what your experiences are in this respect. Eyolf -- Unceasing warfare gives rise to its own social conditions which have been similar in all epochs. People enter a permanent state of alertness to ward off attacks. You seethe absolute rule of the autocrat. All new things become dangerous frontier districts-new planets, new economic areas to exploit, new ideas or new devices, visitors-everything suspect. Feudalism takes firm hold, sometimes disguised as a politbureau or similar structure, but always present. Hereditary succession follows the lines of power. The blood of the powerful dominates. The vice regents of heaven or their equivalent apportion the wealth. And their know they must control inheritance or slowly let the power melt away. Now, do you understand Leto's Peace? -- The Stolen Journals
Re: More on non-ascii chars in headers
On 27.09.2007 (09:11), Kyle Wheeler wrote: set assumed_charset =us-ascii:windows-1252:latin-1:utf-8 For what it's worth, this setting is pretty pointless for most Westerners. The best setting for Westerners is: set assumed_charset=windows-1252 The reason this is better than what you had is: 1. There's no advantage to assuming a message is us-ascii instead of windows-1252. Windows-1252 is a superset of us-ascii, so any message in us-ascii can be assumed to be windows-1252 without loss. Point taken. 3. Along similar lines, windows-1252 contains the entire set of possible values, 0 to 255, and has a character assigned to each. Thus, no email will *ever* not match windows-1252. The way mutt figures out that a message isn't in a specific character set is if there are values in the message that aren't valid in the character set. For example, in Latin-1, values 0x00 through 0x1F are unused; thus if they appear in an email, it cannot be encoded in Latin-1. Windows-1252 may not always be the *right* character set, but there's no way for mutt to know that. But should I still remove utf8 from that list? What if I receive a message with characters which are NOT in Windows-1252 but in utf8? or will mutt then fall back on the locale settings and manage in any case? (not that it happens very often, I think, but one never knows...) Will they then still match Windows-1252 but with the wrong characters? eyolf -- System going down in 5 minutes.
Re: More on non-ascii chars in headers
On 27.09.2007 (12:22), Kyle Wheeler wrote: If someone took a utf-8-encoded email (read: sequence of bytes) and handed it to a file reader that only understood windows-1252, it would get rendered, it would just look wrong. For example, this character: ☺ That character is not in windows-1252. In UTF-8, that character is encoded as three bytes, with the values 226, 152, and 186 (or, in hexadecimal, 0xE2, 0x98, and 0xBA). If this sequence of bytes is not labeled as utf-8, that character is indistinguishable from the windows-1252 letters ☺. Now, those three letters look like junk to you and me, but mutt doesn't know that, and can't. What I didn't get at first, was that that setting only applies to messages without character encoding information, as it says in the manual. That makes sense. Thanks for your patience :-) Eyolf -- Wenn also die KDE-Arbeit nochmal gemacht wird bei GNOME, hat das die Entwicklungszeit für ein freies Desktop-System verkürzt. Hast Du auch irgendwo die passende Algebra zu der Rechnung? -- Sascha Ziemann in de.comp.os.unix.linux.misc
Re: How to resend message multiple times effectively
On 25.09.2007 (01:10), Jiang Qian wrote: I'm sure we can write some kind of poor man's python script or shell/sed/awk script to add or remove address from this. You can then invoke this on the BCC field. But the question was how to make them appear, one by one, in separate mails, in the TO field. Something like: 1. Have a file with a list of addresses, 2. Have a message ready to be sent, only waiting for the TO line, 3. Have a script (sed?) which scans the address file line by line, and for each line inserts it in the appropriate place in the mail, sends it off, and goes to the next item. In other words some kind of mail-merge function, right? -- We are Pentium of Borg. Division is futile. You will be approximated. (seen in someone's .signature)
Re: More on non-ascii chars in headers
On 25.09.2007 (04:13), Jiang Qian wrote: Not so nice to look at... Is there still some setting I should make/change, or is this down to marc.info's inability to handle unicode characters? Your name appears(including Ø) fine on my mutt display. My default encoding is unicode($LANG=en_US.UTF-8). Of course I cannot be sure for other inferior clients, but this is not the place to ask about outlook or thunderbird for I assume everyone on this list is using mutt:) Just to be clear: this was how it appeared in the web interface of the marc.info list search. The name appears fine in all mail clients I've tried it on, so I'm guessing that marc.info doesn't do the character conversion thoroughly enough or something. e -- A tall, dark stranger will have more fun than you.
Re: More on non-ascii chars in headers
On 25.09.2007 (09:02), Kyle Wheeler wrote: The answer is, unfortunately, no. There's no way to specify alternatives in your From header. Plus, even if there was, it's doubtful that marc.info would support them, given that it doesn't seem interested or capable of decoding the existing RFC. You have to either send your name correctly encoded and just realize that old and/or broken software (like marc.info) is going to get it wrong OR convert your name into all-ascii for sending to mailing lists (i.e. Oestrem). That's ok -- I just didn't want to look like a n00b who doesn't know how to set up his mail client :-) I don't depend on old/broken software... I created a cron job to remind me of the Alamo. -- Arun Rodrigues That's the funniest fortune I've seen in a long time. -- asuffield a workstation is anything you can stick on somebodies desk and con them into using -- in #debian-devel
Re: Colors and... nano or native pager??
On 16.09.2007 (15:36), [EMAIL PROTECTED] wrote: What I still would like to know is, do I have to accept using nano (as Mutt's email editor) in black white, or is it possible to make nano display the same colors (as mutt displays based on the .muttrc configuration file?) Is this perhaps the place to suggest a switch to vim...? Not only is it the best editor in existence, it also has any color scheme imaginable (and then some). For nano, you could google nanorc. At dotfiles, there are some. I don't know how they work, though. Try them out: http://www.dotfiles.com/index.php?cat_id=9 -- Our timetable will achieve the stature of a natural phenomenon. A planet's life is a vast, tightly interwoven fabric. Vegetation and animal changes will be determined at first by the raw physical forces we manipulate. As they establish themselves, though, our changes will become controlling influences in their own right -- and we will have to deal with them, too. Keep in mind, though, that we need control only three percent of the energy surface -- only three percent -- to tip the entire structure over into our self-sustaining system. -- PARDOT KYNES, Arrakis Dreams
Re: Subject üî
On 10.09.2007 (17:38), [EMAIL PROTECTED] wrote: Thanks for the link and info. I may play around with it, but I'm hesitant, because xterm's colors are just fine *unless* I either (1) call uxterm, or (2) call the factory xterm from Apple as opposed to the one I built myself. If I tweak color defs in order to get uxterm to look correct, I don't want to mess them up for regular xterm. You can specify settings specifically for uxterm: UXterm*termName: xterm-color , eg. -- Try to remove the color-problem by restarting your computer several times. -- Microsoft-Internet Explorer README.TXT
Re: Subject üî
On 10.09.2007 (19:38), [EMAIL PROTECTED] wrote: Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) As a matter of fact, I don't seem to have .Xdefaults *anywhere* on my machine. There is something called .Xauthority in my home dir, but it is a blank file. You can create it; once it's there, X will (on most systems) find it during startup. Settings there will not take effect immediately. You will first have to merge the new values into the settings database with the command xrdb -merge ~/.Xdefaults Then the changes should be reflected in any NEW shell you open. If you're not satisfied, go back and change and merge again. Note, however, that if you want to remove the new value completely, you can't just delete it from the .Xdefaults file, since the xrdb command just reads what is there, not what is not. There are ways to remove settings - see man xrdb. The easiest way is to restart X. Eyolf -- Acting is not very hard. The most important things are to be able to laugh and cry. If I have to cry, I think of my sex life. And if I have to laugh, well, I think of my sex life. -- Glenda Jackson
(Auto-)extracting forwarded mail
I have a mail address at work which is bound to a Windws/Outlook server that I can't access directly from my own machine, only through webmail. I have set up an auto-forwarding filter at the server, so I get all the mail to my regular box, but all the mails look as if they are from me. Is there a way to automatically remove the outer message and only see the original message when it arrives in my inbox, e.g. through procmail or something? What about encodings, headers, etc - are there things to be aware of there? If I just remove everything up to where the original message begins, it appears in the index with a date in feb 1970 and with the = line dividers in place. (Se below for full message, with addresses masked). what I would like to see is what the message looks like in the pager: - Forwarded message from Eyolf Østrem xxx - Date: Sun, 9 Sep 2007 20:48:55 +0200 Subject: FW: Test From: Eyolf Østrem xx To: [EMAIL PROTECTED] X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.1.5 --- From: Eyolf Østrem[SMTP:x] Sent: Sunday, September 09, 2007 8:21:24 PM To: Eyolf Østrem Subject: Test Auto forwarded by a Rule And this is the test. -- A wizard cannot do everything; a fact most magicians are reticent to admit, let alone discuss with prospective clients. Still, the fact remains that there are certain objects, and people, that are, for one reason or another, completely immune to any direct magical spell. It is for this group of beings that the magician learns the subtleties of using indirect spells. It also does no harm, in dealing with these matters, to carry a large club near your person at all times. -- The Teachings of Ebenezum, Volume VIII - End forwarded message - # # raw version of forwarded mail # From xx Sun Sep 9 20:50:05 2007 Return-Path: xxk Delivered-To: unknown Received: from xx by eyo with IMAP4; 09 Sep 2007 18:50:05 - etc --- loads of headers deleted for brevity X-MS-TNEF-Correlator: Thread-Topic: Test thread-index: AcfzEhKgr+Lo9bkQShGJVTx4yaxSAgS+ From: =?iso-8859-1?Q?Eyolf_=D8strem?= xx To: x X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.1.5 --- From: Eyolf =D8strem[SMTP:x] Sent: Sunday, September 09, 2007 8:21:24 PM To: Eyolf =D8strem Subject: Test Auto forwarded by a Rule And this is the test. --=20 A wizard cannot do everything; a fact most magicians are reticent to = admit, let alone discuss with prospective clients. Still, the fact remains = that=20 there are certain objects, and people, that are, for one reason or = another,=20 completely immune to any direct magical spell. It is for this group of beings that the magician learns the subtleties of using indirect spells. It also does no harm, in dealing with these matters, to carry a large = club near your person at all times. -- The Teachings of Ebenezum, Volume VIII
Re: (Auto-)extracting forwarded mail
On 09.09.2007 (17:04), Patrick Shanahan wrote: * Eyolf Østrem [EMAIL PROTECTED] [09-09-07 15:28]: I have a mail address at work which is bound to a Windws/Outlook server that I can't access directly from my own machine, only through webmail. I have set up an auto-forwarding filter at the server, so I get all the mail to my regular box, but all the mails look as if they are from me. Is there a way to automatically remove the outer message and only see the original message when it arrives in my inbox, e.g. through procmail or something? What about encodings, headers, etc - are there things to be aware of there? If I just remove everything up to where the original message begins, it appears in the index with a date in feb 1970 and with the = line dividers in place. (Se below for full message, with addresses masked). what I would like to see is what the message looks like in the pager: Forward an email to yourself as an attachment at an address accessable via mutt, the save the attachment to a mail directory (or anywhere for that matter), then open than mail/file with mutt. That's what I'm doing now - my question was if there is a way to automatically remove the wrapper mail and only see the original message. I assume this can be done in procmail or something, but I haven't figured out how. eyolf -- Paired opposites define your longings and those longings imprison you. -- The Zensunni Whip
Terminfo settings et al. (was: Subject üî)
It seems to me that my own problems are related to this thread, so I'll chime in here (with a Was:... change of the subject line). I've found some really useful information, both in the reply to my intial mail a few days back, and in this thread, but my attempts at changing things here and there have been too random to be useful, so I've decided to take a step back and review my options, hopefully with some guidance from you knowledgeable people. PROBLEM: getting screen to work with 256 colors, without having any of the following problems: - function keys w/modifiers (shift, ctrl, alt) don't work, at least not as expected. In vim: c-f10 sends something that turns the five following characters uppercase. All the f-keys do something similar: move somewhere on the line, and make sth uppercase. If I enter the function keys directly, either after a command line prompt or in vim through ^v, the output is the same, first in an xterm with TERM=xterm-256color, then in an xterm with screen running and TERM=screen-256color-s. In both cases, the command line says 1;5~ and in vim it says: ^[[21;5~ c-f10, then, apparently sends 'esc1;5~', and vim behaves accordingly: moves five characters forwards and changes their case. So am I right in guessing, then, that when it doesn't work in screen, it's because the preceding ^[[2 is not interpreted as I expect it to, and that this would be where I would search for an answer? - colors: some (ncurses based?) apps like mutt, don't display backgrounds correctly in areas without text, as I described in my previous post. - screen refreshing after leaving apps: should get back to the state it was before entering e.g. vim, but now just scrolls up the screen (as described in this thread by Kyle; does the solution apply to settings for xterm too?). - I don't know if this is related: on the console, many commands make some color code being displayed on the screen. E.g.: in a clean shell, directly after logon: $echo $TERM $linux $vim in vim: pressing ':' gives ':2;blue' on the command line == Questions: == Where and how should I set the TERM variable? I guess there are five possible levels here: environment/shell, Xterm, Screen, ncurses, and application. My distro's wiki (Archlinux) says that it's a bad idea to set the TERM variable in .bashrc, but that applications should be able to figure it out for themselves. So, which of these possible values of TERM do I put where? xterm xterm-256color screen-256color screen-256color-s screen-256color-bce screen-256color-bce-s Should it be the same everywhere I set it? Or does e.g. screen translate screen-256color to xterm-256color or vice versa? Or override xterm's choice (xterm-256color) with its own? What exactly does that setting do anyway? Tell applications what to load from the terminfo database? about how to translate input (keypresses) to output? How do I make changes to the terminfo database? Are they dangerous? Can i corrupt anything? Will experimenting cause damage? How do I revert? How much does this have to do with curses? More concretely: - how do I get my function keys back? - which escape code is responsible for the missing colour refreshing in mutt etc.? - dito for the refreshing of the screen after leaving a (ncurses-based?) program. - and, RTFM oriented, which parts of the system do I need to know more about - terminfo? Screen? I wouldn't want to spend a week reading up on terminfo if the solution is to change a single variable somewhere My system is Archlinux, XTerm(229), Screen version 4.00.03 (FAU) 23-Oct-06, both of which are compiled with 256 color support. I realize that this ended up not having that much to do with the original thread, but I did change the subject line... Eyolf -- Everything that can be invented has been invented. -- Charles Duell, Director of U.S. Patent Office, 1899
Re: Terminfo settings et al
On 07.09.2007 (16:45), Kai Grossjohann wrote: But this depends on whether ~/.Xdefaults is read in your environment... It is. To specify $TERM for screen, you can specify -t or -T on the command line (forget which), or term foo or so in ~/.screenrc. I lost track of what you already tried. For the interim, you can explicitly set $TERM with TERM=foo; export TERM from the shell. Have you tried that in various situations and do you now know what the terminal needs to be? For a screen-less xterm, TERM=xterm-256color is the right thing: everything works as I expect it to do. The problem is when screen enters the picture. I've tried both TERM=xterm-256color and TERM=screen-256color (with additional -bce, -s, or -bce-s), but with no luck - they all behave the same: as in the problem description in my previous mail. Eyolf -- Microsoft Zen - Become one with the blue screen. -- From a Slashdot.org post
Re: Terminfo settings et al
First of all: thanks for your reply - here, and to the previous post. Much helpful. I will have to read up on terminfo, I can tell... And test some settings. Phew... On 07.09.2007 (10:10), Gary Johnson wrote: When using screen, however, the application is communicating with your terminal through screen, so while screen should sit transparently between your terminal and the application, screen does have to know something about the character sequences being used to control the terminal. Does this mean that I could make a terminfo entry called, say, 'my-screen-in-xterm', based on that for xterm-256color, and set that in .screenrc? That would tell screen exactly which capabilities the terminal has, wouldn't it? But why then doesn't it work to set 'term xterm-256color' directly? Also, there are some applications that are hard-coded to recognize certain terminal names. They may know what to do with xterm but not xterm-256color. Is this the reason? That mutt and mocp (and vim?) know about xterm but not xterm-256color? How much does this have to do with curses? Everything. Applications often use a curses library to interface with the terminal they're running in. That library uses the terminfo database to figure out what character sequences to send to the terminal in order to execute a particular curses function. So terminfo is only relevant for applications that use ncurses? Things that can go wrong include: - The TERM value is incorrect for the terminal being used. And when I run screen, what is 'the terminal being used' - is it screen(-256color) or the terminal which screen runs in? Or both? This is one of the things I haven't fully grasped yet: does the information pass serially through the full chain application ncurses screen xterm system (so that e.g. mutt will have to know about screen's capabilities, and screen about xterm's?), or are there shortcuts? Also: are the values simply transFERRED from one level to the next, or are they also transLATED, so that, e.g. c-F10 is called 'apple' in mutt and 'orange' in xterm, and ncurses knows how to translate between them? - The terminfo database entry for TERM is missing, incomplete or otherwise doesn't contain accurate information for the terminal being used. It sounds as if this is the case, then? since ... - The curses library used by the application is old, broken or otherwise doesn't allow the application access to all of the terminfo capabilities. ... the curses version is 5.6.20061217, and ... - The application uses its own idea of a terminal's capabilities instead of or in addition to the terminfo database. ... the problem occurs in many different applications, so unless they all make the same assumptions, the problem should lie somewhere else, no? HTH, Very much so. Thanks again. Eyolf -- linux: the choice of a GNU generation ([EMAIL PROTECTED] put this on Tshirts in '93)
Re: Terminfo settings et al
On 07.09.2007 (20:59), Christian Ebert wrote: Here term term-256color in screenrc works Just to make sure: do you mean term screen-256color? or ... and in screenrc: term screen-256color ...? Eyolf -- Parents often talk about the younger generation as if they didn't have much of anything to do with it.
Re: Mutt with Screen - problems with colors
On 05.09.2007 (15:37), Gary Johnson wrote: I had a similar problem for a while when I was getting my 16-color xterm up and running on a number of systems. I think the solution should be applicable to your case as well, with modifications to suit. Here are the notes I took at the time. [snip] Thank you for your reply. I'll keep it and try it out if I end up needing it. In the end, I found out that if I change the entry in both .screenrc and .zshrc to term screen-256color-s it works. Apparently it works even if I'm not running screen too. Some day I'll have to sit down calmly with a manual for terminfo... Right now, I'm just tired of all those escape strings... Eyolf -- A hippie is someone who looks like Tarzan, walks like Jane and smells like Cheetah.
Mutt with Screen - problems with colors
Termcap - terminfo - $TERM - xterm-color, xterm-256color, screen-256color, screen-256color-bce - phew, my head is swimming, and I'm beginning to hate things like 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm Here's the problem: I want to have the full color palette of xterm-256color. Running mutt under xterm with the TERM variable set to xterm-256color works fine, but once I run it in a screen session in that xterm, the background color is messed up in areas without text, such as in the index and the title bar of the pager. Here's a screenshot: http://oestrem.com/tmp/mutt.png. Relevant settings: - in zshrc: export TERM=xterm-256color - in .screenrc: term screen-256color-bce termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' defbce on - in .muttrc: all backgrounds are set to white, except the indicator (yellow), the headers (cyan) and the status bar (blue). In my searces for a solution, I've come across numerous tips about termcap/terminfo entries in the screenrc file, and I've tried'em all, but with no luck. (Hopefully, I haven't wrecked anything?) I'd be eternally grateful for some help on this from some of you knowledgeable people. I need mutt, I need screen, and I need nice colors - now, I can only have two of the three... Eyolf -- I can't decide which WRONG TURN to make first!! I wonder if BOB GUCCIONE has these problems!
Re: Subject charset issue (was: merging/linking tagged messages
On 29.08.2007 (07:08), Kyle Wheeler wrote: Hmm... Presumably, that's set in your muttrc via 'set realname=...', right? My first guess would be that you need to tell mutt what charset you've encoded the muttrc file in (it assumes ascii unless you set config_charset to something). You'll need to set the config_charset before mutt reads any non-ascii characters (i.e. before you set realname). Hey! That's interesting! I've always made sure I only use ascii-ified versions of my last name in that kind of fields, just in case, but this seems to work. At least a test mail I sent to myself did. Let's see how this one fares... -- That's the difference between me and the rest of the world! Happiness isn't good enough for me! I demand euphoria! -- Calvin
