Q: Mutt and Email Lists
Hi, I currently subscribe to my email lists with the address of my primary email machine (which is a company _internal_ email address). However, my email address is transitioning to a different domain. Furthermore, my company prefers external email be sent to our "external" email address. How do I get mutt to send subscription requests so that the list management software believes the email is coming from my external email address? I tried sending a subscription request after changing the From: field; but the list software still interpreted it as a request from my current internal email address? The list in question has a specific email address to send requests to, and the message can be empty. I looked through the mutt manual, but didn't see anything covering this topic. Thanks in advance. -- Mun
Re: Q: Mutt and Email Lists
Hi, On Sat, Apr 01, 2000 at 12:22 PM PST, Gary Johnson wrote: GJ> I ran into this problem, too. Same company even. GJ> GJ> The vim mailing list uses ezmlm. When I tried subscribing to the list Same company, same mailing list :) ... Stuff Deleted ... GJ> I sent a message to [EMAIL PROTECTED] and it GJ> worked great. Worked for me too! Thanks for the tip. BTW, do I need to do anything special if I want to send email to the list? Thanks to all who replied. -- Mun
Re: deleted box
Hi all, I believe the author's name is Jeff Dubrule. I use the patch too, and it works great! I've included Jeff's text that went along with the patch: > Ok, a long time ago I griped about the lack of a "trash" mailbox to which > deleted messages would get moved. I was directed to: > > unset confirmappend > folder-hook . "macro index d 's=trash\n'" > folder-hook . "macro pager d 's=trash\n'" > folder-hook trash "bind index d delete-message" > folder-hook trash "bind pager d delete-message" > > This annoyed me because it was slow, didn't handle ^D (delete-thread), and > could cause me to make >1 copy of something if I hit 'd' on it more than > once. Finally, this is distinctly non-obvious to the casual user. As a > solution, I present this patch, which saves deleted messages to a designated > mail-folder. > > While this feature is not traditionally included with Unix MUAs, I find it > invaluable: I get too much mail to pay great attention to each one I delete. > If I make a mistake, I'll never be able to recover that message. This way, > I can move 'em all to a 'trash' folder, have a cron-job clean up the old > messages, so I have a week to realize that I screwed up. > > OK, the details: > > Include "set trash = +trash" (or whatever) in your .muttrc, and when the > mailbox syncs, it'll copy all the deleted messages to the trash mailbox > before zapping it. This behaviour does not occur, however, if the trash > mailbox itself is selected. > > This patch works with all mailbox types. > > -igor -- Mun
locale for Sun
Hi, I've had to switch from HP-UX to Solaris, and am trying to figure out the correct locale settings to use. I used to use "LANG=en_US.iso88591" on the HP workstation, therefore I thought "LANG=en_US.ISO8859-1" would be the appropriate Sun setting. However, umlauts don't display correctly. I get what looks like Chinese characters being displayed. Suggestions would be appreciated. -- Mun
Re: locale for Sun
Hi, On Wed, Feb 20, 2002 at 12:21 PM PST, Mun Johl wrote: MJ> I've had to switch from HP-UX to Solaris, and am trying to figure out MJ> the correct locale settings to use. I used to use "LANG=en_US.iso88591" MJ> on the HP workstation, therefore I thought "LANG=en_US.ISO8859-1" would MJ> be the appropriate Sun setting. However, umlauts don't display MJ> correctly. I get what looks like Chinese characters being displayed. I tried another test and fired up mutt in dtterm instead of rxvt. dtterm displayed the umlauts correctly, so I don't understand why the characters get messed up in rxvt when I use the same locale settings. BTW, here's the complete locale settings used in this experiment (but LANG takes precedence, right?): LANG=C LC_COLLATE=en_US.ISO8859-1 LC_CTYPE=en_US.ISO8859-1 LC_MESSAGES=C LC_MONETARY=en_US.ISO8859-1 LC_NUMERIC=en_US.ISO8859-1 LC_TIME=en_US.ISO8859-1 -- Mun
Re: locale for Sun
Hi, Thanks for the replies. It turns out that I decided to compile the rxvt sources myself, rather than using the executable that came with the system. That fixed my problem. -- Mun
Mutt & 256 colors re-re-re-visited
Hi, First of all, my apologies for bringing up this topic again. I am trying to get Mutt working with 256 colors on my Solaris 8 system. I've tried both rxvt and mrxvt terminal emulators. I'm currently compiling with ncurses (mainly because compile attempts with slang fail). Both terminal emulators report 256 color support when I execute 'tput colors'. However, when I try to set a color to something like color100, mutt complains thusly: 100: color not supported by term I read through some old email threads regarding 256 color support. Even though I found some good tips and information, I still can't seem to get Mutt working with 256 colors. Any assistance would be appreciated. P.S. Along the same lines... Any thoughts of taking the gvim approach and integrating a graphic terminal into mutt? -- Mun
Re: Mutt & 256 colors re-re-re-visited
Hi, Thanks for the reply. Please see my comments below. On Sun, Jan 28, 2007 at 03:29 PM PST, cga2000 wrote: ... Text Deleted ... c> > I read through some old email threads regarding 256 color support. Even c> > though I found some good tips and information, I still can't seem to get c> > Mutt working with 256 colors. c> > c> > Any assistance would be appreciated. c> c> $ TERM=term-256color mutt c> c> IOW when mutt see stuff like color100 it uses the "active" terminfo c> entry to verify that your terminal supports 256 colors. c> c> Is that it..? Unfortunately, no. When I run mutt I do first set TERM=rxvt prior to launching mutt. I have verified via executing a shell command from mutt that the TERM is in fact set to rxvt. I have also verified via a shell command that the output of 'tput colors' is 256 . c> > P.S. Along the same lines... Any thoughts of taking the gvim approach c> > and integrating a graphic terminal into mutt? c> c> No, thanks. Oh well, just a thought. It's just that using colors in gvim is so easy; but in mutt, so hard (at least, for me). Sigh. -- Mun
Re: Mutt & 256 colors re-re-re-visited
Hi, On Sun, Jan 28, 2007 at 06:22 PM PST, cga2000 wrote: c> On Sun, Jan 28, 2007 at 06:50:31PM EST, Mun Johl wrote: ... Text Deleted ... c> > c> > Any assistance would be appreciated. c> > c> c> > c> $ TERM=term-256color mutt c> > c> c> > c> IOW when mutt see stuff like color100 it uses the "active" terminfo c> > c> entry to verify that your terminal supports 256 colors. c> > c> c> > c> Is that it..? c> > c> > Unfortunately, no. When I run mutt I do first set TERM=rxvt prior to c> > launching mutt. I have verified via executing a shell command from mutt c> > that the TERM is in fact set to rxvt. I have also verified via a shell c> > command that the output of 'tput colors' is 256 . c> c> $ infocmp rxvt | grep colors c> c> What does it say? colors#256, cols#80, it#8, lines#24, pairs#32717 -- Mun
Re: Mutt & 256 colors re-re-re-visited
Hi Kyle, et al.,
Thanks for the constructive feedback. With your help, I first started
looking into my ncurses implementation. I cleaned things up best I
could and then downloaded and installed ncurses v5.6 compiled with 256
color support. That alone did not resolve my issue; but I do believe it
helped.
The rxvt terminfo file I was using came with my terminal emulator and
was supposed to support 256 colors, but it appears there is some issue
with that file. I tried setting my TERM var to xterm-256color. That
appears to have done the trick! I can now use the colorN technique to
access all 256 colors. I'm one happy camper :)
Thanks again for all the help.
--
Mun
On Mon, Jan 29, 2007 at 04:42 PM PST, Kyle Wheeler wrote:
KW> On Monday, January 29 at 07:18 PM, quoth cga2000:
KW> >> As you can see, when parsing something like "color34", *col becomes
KW> >> 34, and is checked against the value of COLORS. COLORS is a value
KW> >> defined by ncurses and slang.
KW> >
KW> >Yes, but wouldn't these libraries obtain the value of COLORS from
KW> >the terminfo entry pointed to by the process's TERM environment
KW> >variable?
KW>
KW> Yes and no. If the library only supports up to 16 colors (for
KW> example), then it can accurately set COLORS for xterm, vt100, and
KW> xterm-16color, but not for xterm-256color.
KW>
KW> >But then .. where did this rxvt terminfo entry that specifies 256
KW> >colors come from .. ?? I thought that would be part of the curses
KW> >package and should therefore by in sync' with the librar{y|ies} .. ?
KW>
KW> Hmm, could be he hand-modified his own rxvt terminfo in an attempt to
KW> get 256 colors working. Other than that, I don't know. I *can* tell
KW> you that the default rxvt on Solaris doesn't do 256 colors, though.
KW>
KW> ~Kyle
KW> --
KW> Difference of opinion leads to enquiry, and enquiry to truth; and I am
KW> sure...we both value too much the freedom of opinion sanctioned by our
KW> Constitution, not to cherish its exercise even where in opposition to
KW> ourselves.
KW> -- Thomas Jefferson to P.H. Wendover, 1815
Re: Mutt & 256 colors re-re-re-visited
Hi cga2000, On Tue, Jan 30, 2007 at 05:06 AM PST, cga2000 wrote: c> On Tue, Jan 30, 2007 at 01:42:36AM EST, Mun Johl wrote: c> > Hi Kyle, et al., c> > c> > Thanks for the constructive feedback. With your help, I first started c> > looking into my ncurses implementation. I cleaned things up best I c> > could and then downloaded and installed ncurses v5.6 compiled with 256 c> > color support. That alone did not resolve my issue; but I do believe it c> > helped. c> > c> > The rxvt terminfo file I was using came with my terminal emulator and c> > was supposed to support 256 colors, but it appears there is some issue c> > with that file. I tried setting my TERM var to xterm-256color. That c> > appears to have done the trick! I can now use the colorN technique to c> > access all 256 colors. I'm one happy camper :) c> > c> > Thanks again for all the help. c> c> ok for a test .. to narrow down your problem .. c> c> but other things are likely to break. c> c> The terminfo entry describes your terminal's capabilities to the c> "system". And there's lots of stuff in a terminfo entry apart from the c> number of colors that is likely to be quite different between rxvt and c> xterm. c> c> So for regular every day use you either want to install a proper c> rxvt-256color terminfo entry .. or, switch to 256-color xterm. Thanks for the tip. I'll definitely take switching to a 256-color xterm under consideration. -- Mun
lbdb and m_muttalias usage issue
Hi, I've installed and configured lbdb-0.35.1 on my SPARC/Solaris 8 system and am not having any luck querying my mutt alias files. When I execute lbdbq, it always returns "no matches". I validated (via 'set -x') that m_muttalias is being called, and that my MUTTALIAS_FILES are being grep'd. But apparently nothing is returned--even though there should be matches. My alias entries are of the following format: alias aliasname "First Last" <[EMAIL PROTECTED]> Anyone have any debug hints as to why lbdbq may not be working? If not, I guess I'll delve into m_muttalias's regexs. Thanks in advance. -- Mun
Re: lbdb and m_muttalias usage issue
Hi Christian, Thanks for your reply. I updated my copy of m_muttalias to use GNU sed and GNU grep. That did the trick! Thanks for the suggestion. Regards, -- Mun On Mon, Jul 23, 2007 at 04:36 PM PDT, Christian Ebert wrote: CE> * Mun Johl on Monday, July 23, 2007 at 15:00:04 -0700 CE> > I've installed and configured lbdb-0.35.1 on my SPARC/Solaris 8 system CE> > and am not having any luck querying my mutt alias files. CE> > CE> > When I execute lbdbq, it always returns "no matches". CE> CE> Had the same problem on MacOS X. CE> CE> > I validated (via 'set -x') that m_muttalias is being called, and that my CE> > MUTTALIAS_FILES are being grep'd. But apparently nothing is CE> > returned--even though there should be matches. My alias entries CE> > are of the following format: CE> > CE> > alias aliasname "First Last" <[EMAIL PROTECTED]> CE> > CE> > Anyone have any debug hints as to why lbdbq may not be working? If not, CE> > I guess I'll delve into m_muttalias's regexs. CE> CE> I found out that sed shipped with MacOS can't cope with CE> m_muttalias. Perhaps it's similar for Solaris. Installing GNU sed CE> solved the problem. -- I didn't have the nerve to try and adapt CE> m_muttalias to the sed on my machine. Some day when I have time CE> ... CE> CE> c CE> -- CE> Python Mutt utilities <http://www.blacktrash.org/hg/muttils/>
Re: putting current entry at the top of the screen/window
Hi, You can put something like this (to emulate vim) in your .muttrc file: bind index z\n current-top -- Mun On Wed, Jul 15, 2009 at 12:56 PM PDT, Michael Tatge wrote: MT> MT> MT> * On Wed, Jul 15, 2009 11:16AM -0700 mala...@us.ibm.com (mala...@us.ibm.com) muttered: MT> > Is is possible to put the current mail entry at the top of my screen in MT> > mutt? Looking for something like "z" command in VIM. MT> MT> not exactly what you're looking for. MT> MT> HTH, MT> MT> Michael MT> -- MT> The computer is to the information industry roughly what the MT> central power station is to the electrical industry. MT> -- Peter Drucker MT> MT> PGP-Key-ID: 0xDC1A44DD MT> Jabber: init...@amessage.de
