Re: Mutt Quick Reference v.1.00
On Wed, Oct 17, 2007 at 11:13:11AM EDT, Joseph wrote: > Since I couldn't find one I created Mutt Quick Reference v1.0 (PDF file) > especially useful for new users. > It is just two pages reference and looks best when you print it on a > Color Printer. > > I wanted to add a link to MuttWiki but I think it is locked. > Anyhow, you can view it and download it from: > http://www.sys-concept.com/Mutt-Quick-Reference-Letter.pdf (Letter > format) > http://www.sys-concept.com/Mutt-Quick-Reference-A4.pdf (A4 > format > > Most information I collectd from Mutt manual. > If you would like me to add/expand some entires with additional > information just let me know. > eg. under Patterns there is: > ~d [MIN]-[MAX] messages with ``date-sent'' in a Date range > > I've added: > Dates must be in DD/MM/YY format (month and year are optional, > defaulting to the current month and year).eg.~d 20/1/95-31/10; -DD/MM/YY > all messages before the given date will be selected; DD/MM/YY- all > messages after the given date will be selected. You can add error > margins to absolute dates. An error margin is a sign (+ or ? or * = + - > or < > =), followed by a digit, followed by one of the following units: > y years; m months; w weeks; d days Thank you for this excellent reference card. I know nothing of them but the following site seems to act as an unofficial repository for quality reference cards such as yours and it appears they don't have one for mutt. http://www.digilife.be/quickreferences/quickrefs.htm In order to give your reference card maximum exposure it might be worth contacting them and finding out if their policies in terms of copyright etc. are compatible with your organization? Thanks, cga
Re: How to send a return receipt
On Wed, Oct 17, 2007 at 07:33:46AM EDT, Derek Martin wrote: > On Tue, Oct 16, 2007 at 10:04:34PM -0400, cga2000 wrote: > > On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: > > > Maintaining patches for features that lots of people want is a stupid > > > waste of work. If the maintainers don't want to maintain the code, > > > then they probably should stop being maintainers. > > > > Please be more specific. What are those "features that lots of > > people want" and that are absent from mutt? I have used mutt for > > about three years and I never once had the feeling that anything was > > missing. > > If you actually require an answer to this, then you apparently have > not been reading this thread, and have simply chosen just to pick out > one particular comment that you can respond to with what you think is > some clever, quipy remark that in actuality is neither valuable to the > discussion, nor sensible in any regard. I suggest you re-read the > thread, and in particular the original poster's messages, and also the > part where I wrote: > > On Tue, Oct 16, 2007 at 05:39:49PM -0400, Derek Martin wrote: > > And don't forget that just because YOU don't find any value in a > > feature, that doesn't mean it's not a feature that common users > > want... > > The folks who both use mutt and are likely to hang out on a mailing > list are almost by definition not common mail users. But lots of > people who use Mutt want the power it offers them to process a wide > variety of mail in interesting ways, but don't want to hack their > mailer; and they shouldn't have to, if the feature they want is > commonly implemented in other mailers. > > Being able to say, "Mutt can do that, if you write a script to do it, > and write a macro to invoke the script and..." does not constitute > support for a feature in Mutt. Mutt should implement features that > are commonly implemented in other mailers so that users of Mutt can > interoperate with people who don't use Mutt, which is by far the > majority of mail users. > > Mutt's claim is that it sucks less than all other mailers, which was > once true; but IMO with each new feature that other mailers implement > that Mutt does not, this becomes less and less the case, and I'm not > sure if that is still true anymore. It certainly does still offer > some powerful mail-processing features that most other mailers don't > offer; but some mailers do offer a lot of them now... To be honest I > think the ONLY reason I still use mutt is because I do most of my > personal mail reading remotely, and Mutt still DOES suck less than the > rest of TEXT-BASED mailers... But I wonder if it isn't only a matter > of time before even that isn't true anymore. As a perfectly content user of mutt I felt it my best interest to seize upon this opportunity to state that mutt does precisely what I want and does it the way I want. As I wrote earlier, I have absolutely no idea what features you are missing. Every time I need to do something, much to my delight, it is there for me .. implemented in the smartest and most natural possible way. This humble subscriber to the list is simply saying he does not want mutt to become yet another Microsoft Outlook clone. I must add that I agree with everything Charles and Rado posted to this thread as to why adding new so-called "features" to mutt is not a decision lightly to be taken and why I feel such enhancements will turn out not be such a wonderful idea after all. Sorry, but I have neither the time nor the desire to argue further. Thanks, cga
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: [..] > Maintaining patches for features that lots of people want is a stupid > waste of work. If the maintainers don't want to maintain the code, > then they probably should stop being maintainers. Please be more specific. What are those "features that lots of people want" and that are absent from mutt? I have used mutt for about three years and I never once had the feeling that anything was missing. Thanks, cga
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 11:18:05AM EDT, Jing Xue wrote: > > Quoting Charles Cazabon <[EMAIL PROTECTED]>: > > >The concept of mail receipts is poorly designed; there is no way to > >implement > >a reliable receipt notification system with SMTP mail. *Many* of the > >better > >mail packages therefore do not implement support for it -- why have a > >feature > >if you *know* it can never work properly? > > I think it's an overstatement to say that "it can never work > properly". It's actually "it _might not_ work properly". It still > serves its purpose when it does work - see below. > > >It's also seen as an invasion of privacy. > > It certainly creates some annoyance on the recipient end. But I don't > see how it is an invasion of privacy as long as the MUA has my consent > before sending a receipt. > > >Mail receipts are essentially one of those features that commercial MUA > >vendors include as a marketing checkbox feature, but which serve little or > >no > >useful purpose in the real world. > > Well, in the corporate* world where people communicate over Lotus > Notes or Outlook, they tend to use mail receipts a lot. And _because_ > they all communicate over the same MUA that supports the feature, it > actually does work and become useful. > > Now _I_ don't use these mail receipts, nor do _I_ like getting them, > because of the annoyance factor. But then I respect it when others > request one - at least before they start abusing it. > > My 2 cents. My #1 worry under these circumstances is that when I do accept to send a receipt I would like to be notified that the recipient actually received (and read) my receipt. Is there any way this can be done with mutt? Or Lotus Notes, Outlook? cga
Re: Colors and... nano or native pager??
On Mon, Sep 24, 2007 at 11:18:49AM EDT, [EMAIL PROTECTED] wrote: > On Mon, Sep 24, 2007 at 10:23:48AM -0400, Chris Bannister wrote: > > > Just put: > > set editor=/usr/bin/vim > > in your .muttrc > > > > Personalise your colours for vim in your .vimrc > > (Obviously, this is the wrong mailing list for discussions on vim as > > would discussions on mutt be on a vim mailing list.) > > Well, I can do that now, having dropped nano and installed vim, (1) http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html (2) http://www.cs.cmu.edu/~maverick/VimColorSchemeTest/ The first link has all the vim basics and a few extras explained in very simple visual terms. Should get you up to speed in a few days. The second has a huge collection of vim "themes" called color schemes. Unfortunately, most require the GUI version of vim. Have fun! cga
Re: Colors and... nano or native pager??
On Sun, Sep 16, 2007 at 07:19:11PM EDT, [EMAIL PROTECTED] wrote: > On Mon, Sep 17, 2007 at 12:59:26AM +0200, Eyolf ?strem wrote: > > > > 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 > > Learning vim, as I just said in my previous message, is one of my > future plans... At this time I would like to concentrate on > learning mutt, and doing it well. If you plan to switch to vim at some point in the future, why would you want to bother about such trivial aspects as nano coloring? Don't waste time fine-tuning a car that's headed for the junkyard.
Re: Colors and... nano or native pager??
On Sun, Sep 16, 2007 at 03:21:29PM EDT, [EMAIL PROTECTED] wrote: > On Sun, Sep 16, 2007 at 11:25:05AM -0400, John wrote: > > > > Here's one way of doing it, mostly lifted from the efforts of > > others. You can fiddle with colors to suit yourself, of course. > > Thank you so very much, John. Actually, right after looking at > your code I started fiddling with it as suggested, and I came up > with something quite satisfactory to my taste. > > The only thing, at this line: > > > color normalblack default > > I had to change "default" to "white" in order to get a white > background. > > Also changed a few others things... and this totally takes care of > my first question. Thanks again! It's been very much appreciated. > > As to the other question, mutt's vs. an external text editor, if I > were to keep nano for the time being, how would I go about making > nano display the same color pattern I have already achieved in > mutt? Dunno about nano but you certainly could do it with vim. http://www.geocities.com/fcky1000/fcky/pager.png http://www.geocities.com/fcky1000/fcky/editor.png Time to switch?
Re: Mutt & 256 colors re-re-re-visited
On Sun, Jan 28, 2007 at 01:05:11AM EST, Mun Johl wrote: > 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. $ infocmp $(echo $TERM) | g 256 colors#256, cols#80, it#8, lines#24, pairs#32767, .. does your terminfo specify 256 colors? > P.S. Along the same lines... Any thoughts of taking the gvim approach > and integrating a graphic terminal into mutt? Hopefully .. someone would fork the code? Thanks, cga
Re: Mutt & 256 colors re-re-re-visited
On Tue, Jan 30, 2007 at 01:42:36AM EST, Mun Johl wrote: > 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. ok for a test .. to narrow down your problem .. but other things are likely to break. The terminfo entry describes your terminal's capabilities to the "system". And there's lots of stuff in a terminfo entry apart from the number of colors that is likely to be quite different between rxvt and xterm. So for regular every day use you either want to install a proper rxvt-256color terminfo entry .. or, switch to 256-color xterm. Thanks, cga.
Re: Mutt & 256 colors re-re-re-visited
On Mon, Jan 29, 2007 at 07:42:52PM EST, Kyle Wheeler wrote:
> On Monday, January 29 at 07:18 PM, quoth cga2000:
> >> As you can see, when parsing something like "color34", *col becomes
> >> 34, and is checked against the value of COLORS. COLORS is a value
> >> defined by ncurses and slang.
> >
> >Yes, but wouldn't these libraries obtain the value of COLORS from
> >the terminfo entry pointed to by the process's TERM environment
> >variable?
>
> Yes and no. If the library only supports up to 16 colors (for
> example), then it can accurately set COLORS for xterm, vt100, and
> xterm-16color, but not for xterm-256color.
>
> >But then .. where did this rxvt terminfo entry that specifies 256
> >colors come from .. ?? I thought that would be part of the curses
> >package and should therefore by in sync' with the librar{y|ies} .. ?
>
> Hmm, could be he hand-modified his own rxvt terminfo in an attempt to
> get 256 colors working. Other than that, I don't know. I *can* tell
> you that the default rxvt on Solaris doesn't do 256 colors, though.
.. sounds like Solaris 8 is even more conservative than debian/linux.
Thanks,
cga.
Re: Mutt & 256 colors re-re-re-visited
On Mon, Jan 29, 2007 at 10:44:32AM EST, Kyle Wheeler wrote:
> On Sunday, January 28 at 10:15 PM, quoth Mun Johl:
> >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
>
> What matters here is not the terminal, but the library.
>
> The code in mutt that makes this decision is in color.c, around line
> 325:
>
> if (ascii_strncasecmp (s, "color", 5) == 0)
> {
> s += 5;
> *col = strtol (s, &eptr, 10);
> if (!*s || *eptr || *col < 0 ||
> (*col >= COLORS && !option(OPTNOCURSES) && has_colors()))
> {
> snprintf (err->data, err->dsize,
> _("%s": color not supported by term"), s);
> return (-1);
> }
> }
>
> As you can see, when parsing something like "color34", *col becomes
> 34, and is checked against the value of COLORS. COLORS is a value
> defined by ncurses and slang.
Yes, but wouldn't these libraries obtain the value of COLORS from
the terminfo entry pointed to by the process's TERM environment
variable?
Or in other words, in the event the colors# in the terminfo entry is <
color100 .. wouldn't that result in the same snprintf?
> If the library doesn't support large numbers of colors, then mutt
> won't either.
I use a 256-color capable xterm rather than rxvt but I find it strange
that the "rxvt" entry in the OP's terminfo database should default to
256 colors mainly because supporting this mode is a new functionality
and I don't see the maintainer changing the old "rxvt" entry .. might
break things .. I would have thought that same as for xterm he would
have added a new rxvt-256color entry to the database.
That's why I initially suspected the OP's problem was that his terminfo
entry did not correctly specify the terminal's 256-color capability.
But then the OP stated elsewhere that he is running Solaris 8 and that
may very well come with ncurses/slang libraries that do not support 256
colors ..
But then .. where did this rxvt terminfo entry that specifies 256 colors
come from .. ?? I thought that would be part of the curses package and
should therefore by in sync' with the librar{y|ies} .. ?
Thanks.
cga
Re: Mutt & 256 colors re-re-re-visited
On Sun, Jan 28, 2007 at 06:50:31PM EST, Mun Johl wrote: > 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 . $ infocmp rxvt | grep colors What does it say?
Re: Mutt & 256 colors re-re-re-visited
On Sun, Jan 28, 2007 at 01:05:11AM EST, Mun Johl wrote: > 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. $ TERM=term-256color mutt IOW when mutt see stuff like color100 it uses the "active" terminfo entry to verify that your terminal supports 256 colors. Is that it..? > P.S. Along the same lines... Any thoughts of taking the gvim approach > and integrating a graphic terminal into mutt? No, thanks.
