Re: Asian fonts / xterm with Mutt
Thanks for the input Derek, On 10/23/07 01:12, Derek Martin wrote: The key to displaying all of those languages simultaneously is UTF-8. Your locale should look something like this: $ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=C LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= I have the same settings in my locale Using this, I can type Korean, Japanese, and Chinese (though I know very little Japanese, and almost no Chinese at all): いただきます！ (Itadakimasu!) This must be Chinese, I see them all except the last character is square. 잘 먹으세요!(Jal Mogeuseyo!) This Korean one displays correctly as well. 你好！ (Ni hao!) If this is Japanese, it doesn't show at all. They are all squares, I know I don't have any Japanese fonts. I can't tell you what packages to install to get this font on your OS though... since I don't know what it is, and since I can't even figure out which package I installed to get it on *my* distro... ^^; I can tell you, there are two particular fonts I have that display these characters, and I can tell you the font resources I use to get xterm to use them: XTerm*font: -misc-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-* XTerm*font5: -Misc-Fixed-Medium-R-Normal--18-120-100-100-C-90-ISO10646-1 Do you have .Xauthority file in your home directory? [snip] So, I think, all this Asian fonts are just mutter of correct font being installed on the system. They display correctly even in my Nano editor. -- #Joseph GPG KeyID: ED0E1FB7
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Mon 22.Oct'07 at 20:45:53 +0200 -=
HTML mails, hmm. Bad thing. I don't like, nor do I write them
myself, but receiving them (because some suppliers think they
don't have to follow my wish if I ask them to not do so) is very
uncomfortable in mutt. But its just that. Whereas I repeatedly
explained why an external application does not work for return
receipts. It does not very good for HTML mails, but it at least
_does_.
You make a difference, we don't: for us it has the same annoyance
level as well as functional solution for those needing it
desperately nevertheless (and sufficiently convenient once it works).
{...}
But if it is featured by _every_ mail client in business
environments then it should probably be supported.
{...}
BTW. this whole discussion again does not have anything to do,
with what this all is about.
You're mistaken, because for us it has.
You want a more convenient solution for what is already possible as
it is now. The same is for all the other given examples: they
_could_ be more convenient, but need not be for either there are
better external tools for it (news, mailcap conversion, ...) or some
muttrc construct works well enough.
Not all that is popular in numbers in business means good in general
to make it convenient to use with mutt, see TOFU (which is range in
the same level as return-receipt for me: exceptionally necessary,
but not generally desired, same with HTML).
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Derek Martin wrote on Mon 22.Oct'07 at 11:46:26 -0400 -= But still, I want my mailer to do everything related to the normal processing of mail, mostly without any fuss from me. I should only have to make a fuss if what I want to do is unusual -- which this isn't. a) how to determine usual factor? b) not everything that is usual is desirable (but even annoying). c) the fuss is ... required for mostly anything advanced that you want to do, because very little (i.e. basic functionality) works with defaults, and even that not in all environments. If it does, then you happen to be lucky to have admins who prepared everything well enough. This then leads to: what is basic, what is advanced? What should work out of the box and what will/ should always require tweaking? -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Derek Martin wrote on Wed 17.Oct'07 at 10:58:52 -0400 -= On Wed, Oct 17, 2007 at 07:52:03AM -0600, Charles Cazabon wrote: Actually, one of the things that makes mutt suck less than other MUAs is that it *doesn't* have additional hundreds of little-used features to cause bloat, bugs, user confusion, and UI complication for no real added benefit. Actually I think this is a fine example of why that argument is total nonsense. Since SMTP support has been added, in what measurable way has it caused Mutt to suck more? Is the memory footprint *substantially* larger? Has it caused mutt to become noticably slower? Note, Charles wrote about hundreds of little-used features, while you counter with a single example. Add up all the hundreds little-used features waiting to be included, then tell again. Nobody denies that any _single_ such feature means little impact, but why add this SMTP or return-receipt and not all the other little goodies? Convenience applies for all equally. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Wed 17.Oct'07 at 16:48:24 +0200 -= After all its not too hard to achieve all this, but its wasted effort, as with a lot of care you cannot guarantee that this will run in a few days, weeks or months because admin could decide to remove just one of the tools you need to achieve what you need. Remember: Not every user of mutt is the admin of the machine. Yes, but I think you're too paranoid or haven't noticed the required tools for such a solution: they are _basic_ unix tools like ls, which no sane admin would consider removing. If your admin is not sane, then you have bigger problems than this. Usually one automates rather complex processes, while we are talking about a pretty simple function ... Your assumption is wrong: automation is not a matter of size but of repetition. Especially simple stuff can be quickly implemented easily without having to hardcode. ... if integrated into mutt, but a rather complex if you need to establish the functionality standalone. It appears complex to you, but in fact it _is_ simple. It is like removing 'ls' from a shell and saying: You could write your own ls, because thats possible and a shell really should not implement a ls command on its own. Nobody is removing anything, actually you're being given something that didn't exist before: ls2. it *doesn't* have additional hundreds of little-used features to cause You keep claiming that it is little-used but thats just not true. It is wideley supported, wideley used and commonly expected. So all your arguments that are based on this wrong premises actually are _wrong_. Little used, wildly used, no side can prove its point by numbers. We only have gut feelings about our personal experience. So this can't ever be a valid argument, for either side. As a related example, I'm still disappointed SMTP support got added. Well, feel free to not compile it with SMTP support, then. Thats far easier then maintaining a patch outside of upstream for years. No patching would ever be needed if you accepted that SMTP functionality doesn't belong to mutt and is _safely_ handled by whatever you specify in $sendmail. YOU are disappointed about it, while I am quiet happy about this, because I don't like the idea to configure a bloated MTA on every system (including laptops and workstations) for no added benefit. It has no benefit for _you_! :) Anyway, you don't need to use bloated MTAs, you can use http://WIKI.mutt.org/?LightSMTPagents -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Derek Martin wrote on Wed 17.Oct'07 at 7:33:46 -0400 -=
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.
Hmm, why should mutt aim for the masses rather than the quality?
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.
I say it depends on what those features are.
Not all that is popular demand is desirable to make it a habit for all.
{...} 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.
Maybe you're expecting too much from mutt, as much as I am in the
other direction.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Derek Martin wrote on Tue 16.Oct'07 at 18:32:00 -0400 -= If your pet feature is minimal code, but the developers don't want to include it because what you're asking is already possible another way -- just maintain a local patch for it. So have I, and it sucks. I agree, in general. But for this specific case, no code patch is even required, it works with the current code. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Derek Martin wrote on Tue 16.Oct'07 at 17:39:49 -0400 -=
If a function is e-mail related, and commonly supported by other
mailers, then it seems to me Mutt should have built-in support for
it too. Mutt is a Mail USER Agent (not a mail DEVELOPER agent),
and it should interoperate with other mailers, and should do
everything that users commonly want to do with mail without a lot
of fuss.
Including spam management, sorting/ filtering, mime handling, ...?
News is so similar to mail, and all the other mailers do that, too,
why not mutt? It's not mail-related enough for you? But it's sooo
close...
You mistake configurability and the need to do so with the users
having to be somehow special. If a little rtfm disqualifies users
for mutt ... that's sad, but they shouldn't use mutt then, and mutt
shouldn't change to become a product for a mindless mass, that's
what OL is for. ;)
The only things that should require fuss are things that are not
commonly wanted by common mail users. 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...
Common here, value there, no proof anywhere.
{...}
especially if you have to deploy 1000 Unix workstations that don't
come with any of the helper programs you need to make your
application work in your environment (and most especially if they
need different configurations, preventing one from easily
creating, say, a tarball with all the required software).
The same can happen with hardcode: it sucks when you have no ssl,
curses or other libs installed. Want that all built-in?
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Mon 22.Oct'07 at 15:37:45 +0200 -= I don't think that the term 'harmful' needs an explination in whats mutt about. Harmful is what affects mutt in any negative way. Thats not about philosophy, but about technical matters. Well, ... your viewpoint is limited to your single specific case. Taking into consideration that your request is only one among many makes it a strategical decision how to handle all of them. Broaden your view. A mailer for freaks and nerds == willing to adjust it to personal needs rather than relying on (hardcoded) defaults; to use it for all We are not talking about defaults. Ok, default functionality. Can you accept that even though it doesn't support it out of the hardcode box, the functionality can be _added_ by mutt means with the help of basic unix tools? So this is pointless. Also adjusting something to someones personal needs is not implementing the whole feature, it is about setting some settings, like save-hooks, folder-hooks or whatever. *sigh* That's a matter of perspective. The solution given to you is exactly that: use of muttrc commands. Using mutt's power which it already provides before hardcoding features (mistaken as adding, because it is already possible). Arrgh. After about 100 mails about this topic (and with several _different_ posters describing to you the same thing) you have not understood that mutt does _not_ have the requested feature. You exaggerate: significantly 100, and IIRC it was only you and Derek. It stands to define what support a feature means with a highly flexible tool like mutt. You (and Derek) seem to take it differently than several others here. However, I never denied there is a difference in convenience, although only at the beginning to implement it once, not to use it everyday once you source the finished solution. a) You're mistaken, there are requests to include a wide range of functionality into mutt that wasn't assumed to be part of mutt, so We are not talking about this, in _this_ discussion. Yes, we are, because you want a little bit, while all the other likewise only want a little bit. Why is your little bit more useful, wider used, qualifies in any sense more than any of the others? No. It is not important to _me_. It is important, because it is wideley used in business environments and supported by _every_ mua used in business environments, which makes it potentially used, which makes it important if you want to communicate with other people having the feature. You can only make assumptions about how many use return receipts in the real world, so you cannot use numbers to figure who actually uses is and so you need to rely on the fact that it is there in every mua and _could_ be used. - every mua used in business, that would be which? Lotus, OL, TB, what else? - again, likewise all other wannabe inclusion candidates _could_ be used, and some more likely, still they are not in. - if there were no other way, then let it be. - if it's just convenience ... compare with other candidates. mail users I'm unsure people _willingly_ use that feature because they see a gain in their everyday usecase rather than being a preset default, not caring enough to change. Ehh. It is not a default. In _no_ known mail client. It is an opt-in feature. Always. Even if it could nag you with a message, you must not click Yes to send the message. No, I mean on the sender side, producing them. non-automated environment they are rather annoying (to me, much like We are not talking about TOFU posting, so this is pointless. But if you feel annoyed by return receipts then don't use them. The good thing about this feature is, that you can choose on a case-by-case basis _or_ disable it at all. I cannot disable people, that are writing TOFU, to get back to your example. The problem with TOFU, HTML and RR (return-receipts) is not solved for me when _I_ stop using it! The problem exists because others sending to me find it's easy to produce it and don't give a ... about what I think about it (before I can tell them, but worse even thereafter). When it's easy to get by, it becomes a quasi standard, and I can't do anything about it. So I have to step in early before it becomes a standard, by not making it too easy, so only those really needing it diehard would implement it for themselves. It's not that I don't want it to, but because users' demands are too different to be satisfied all by a single tool. Right. But if you can't support *everything* you should support the smallest supported subset + the things _you_ (as developer) want to support. Exactly, but this we don't know yet, since they haven't declared their policy officially so far. As long as mutt doesn't offer that, people using those tools for exactly those features won't switch to mutt until mutt does so, too. Then let them. They have the free choice, but in _this_
Re: How to send a return receipt
On Tue, Oct 23, 2007 at 06:14:48PM +0200, Rado S wrote: Yes, but I think you're too paranoid or haven't noticed the required tools for such a solution: they are _basic_ unix tools like ls, which I don't know who you process headers with basic unix tools, but I don't care. Because i face the fact that it is _impossible_ to convince you. You exepect us to prove that the feature request is valid, but you don't prove what you use to tell that we are wrong. You ignore arguments being said, but you always repeat the nonsense that it is just a matter of configuration, what it isn't. You are not even possible to tell how it is configurable, without reinventing the wheel (by recoding whats already implemented in mutt), but you keep teelling this. So all you've done until now is: Saying that _you_ don't like the feature and that it it will not be included for this reason. Thats all. You did not really argue, but you are in an authoritive position, so this discussion could be endless or one of us could give up. A consense is impossible to reach. And its impossible that you would give up. So I do it. EOT from me. Regards, Patrick
Re: Updating to Ubuntu Gutsy no longer shows message counts
On Mon, Oct 22, 2007 at 10:50:49PM +0300, Petteri wrote: but there the counts were *never* shown. So, I'm a bit baffled considering that the debian/changelog does indeed have the message you quoted above. I'm using Debian unstable and I'm see the counts. Strange. Are you using imap over ssl? (imaps://) I built the full Debian source package on Ubuntu and still no luck. So, I find that very odd. My .muttrc didn't change. My imap server didn't change (different machine). And the fact that when I built mutt from the repository the numbers show up -- but only once -- makes the assume it has to be a bug in mutt. Further, If I start the version I build from the mutt repo as: mutt -y all zeros are shown. Yet, if I start mutt and then hit tab when showing the list of mailboxes the numbers show (again, just once). -- Bill Moseley [EMAIL PROTECTED]
Re: Updating to Ubuntu Gutsy no longer shows message counts
On Monday, 22 October 2007 at 12:21, Bill Moseley wrote: On Mon, Oct 22, 2007 at 09:54:30AM +0300, Petteri wrote: After upgrading my laptop from Feisty to Gutsy today when I get a list of mailboxes (c-?-tab) it shows all my subscribed mail boxes but with zero counts. Debian had similar problem couple of months ago, but it was fixed. Don't know if its related to yours, but you could always try building you package from debians (unstable) sources and see if that helps. Changelog of the fix (http://packages.debian.org/changelogs/pool/main/m/mutt/mutt_1.5.16-3/changelog): mutt (1.5.16-3) unstable; urgency=medium * Fix the maildir-mtime patch change in 1.5.14+cvs20070403-1 that broke new mail message count in IMAP folders. (Closes: #421468, #428734, #433275) Huh. Well, I first downloaded source via Mercurial: hg clone http://dev.mutt.org/hg/mutt Due to a bug in the conversion from CVS, this may not give you the most recent change. Try hg update -C HEAD to bring yourself up to date (and 'hg pull -u' to keep yourself there). Having said that, there are some bugs in new mail detection over IMAP that I hope to get to soon (I've been swamped for a couple of months, but the load has just lightened a bit). pgpTw8uIKGSXn.pgp Description: PGP signature
Re: How to send a return receipt
=- Derek Martin wrote on Sun 21.Oct'07 at 20:55:07 -0400 -=
{...} with its major goal being to suck less than the other mail
clients. It says the latter explicitly on its home page. Inasmuch
as it does not implement standard features offered by other
clients, it is a failure in that goal.
Uhm ... not all that is widely supported is good.
PLEASE NOTE: a power user of e-mail is not necessarily a power
user of *anything else*.
Aye, agree, but then ... mutt is not for the faint of heart
either. :)
If a not hardcoded solution is offered ready to source, let them
have it.
... as stated elsewhere: adding up has more of an effect than
just the sum of its parts.
This is not a reason not to do something.
Right, that's why I gave solutions.
And this total effect can be bad despite all the partial good
effects.
This also is not a reason not to do something... It is, however, a
good reason not to do something badly. Integrating support for
this feature into Mutt is, from the user's standpoint,
unquestionably the better way than relying on hacks which are not
well-implemented or poorly integrated into Mutt.
Remeber the mh solution?
Actually, if mutt were a complete CORBA constructable tool, I'd be
happy with it letting everybody construct it's components as
desired, all hardcoded if you prefer.
That is, if CORBA were anywhere practicable or in wide use.
That's not the point at all. The point is that the feature being
missing in Mutt is forcing some people who use Mutt in business,
and want to continue to do so, to move to something else, because
the features they NEED -- features supported by virtually every
other mailer in the known universe -- are missing from Mutt.
Ok, they _are_ missing, until somebody implements my (and other
mutters') suggestions.
Some of those users might be willing and able to implement the
needed functionality themselves... But you would (obviously) be
surprised by the number of people who use Mutt who can not or
don't want to.
Can not: why? Once the solution is published, simply source.
Want not: tough luck for them, no loss when they switch.
They exist so that the receiver can say, I know you saw my
e-mail, I have the return receipt. It's about accountability...
it's the same reason the post office offers registered/certified
mail. Mail (both kinds) is inherently unreliable -- you send off
your e-mail, and you have no way to know if the recipient actually
received it... unless they're using some return receipt feature.
Then, the recipient can not say, hey, I never received your
mail. The sender has proof that he did.
... if this were about legal cases, easy forging such
return-receipts makes it vulnerable, you'd need more for that.
But then DSN and server logfiles do the same service.
MUTT DOES NOT HAVE RETURN RECEIPT SUPPORT. Mutt has support for
letting the user customize and extend mutt in a variety of ways. This
is very much NOT the same thing as having return receipt support.
Has mutt complete ssl and curses support? Is relying on external
binary libs any better than relying on external unix tools?
It means it's already there, waiting for the user to use it. If it
requires the user to code logic (as opposed to simply turning on
settings), then it is not supported.
source path-to/contrib/rr.mutt
done
That's how it works with pgp, too.
On an individual (per-solution) basis, it needs roughly as much
maintenance as it would need if it were implemented in Mutt directly;
Right, so this no reason to switch to hardcode.
But, your method will not require just 2 or 3 developers to
maintain it... instead it will require hundreds or perhaps
thousands of users to maintain it individually.
Uh, when you have to upgrade the mutt binary for RR, this isn't
anything less of a burden than to adjust a little source'ed script
included in /contrib.
This discussion is not about those features. It's about return
receipts. Decisions about whether to add a feature can only
logically be made on a case-by-case basis.
Discussions about drawing lines are pointless and fruitless. From
the standpoint of the user, none of your arguments against
allowing this feature to be added to mutt are compelling.
By this line all other features should be included, too.
Definitely a no-go.
Once you look at every individual case isolatedly, mutt will
eventually become a cross-breed clone of all the other bulky
software out there: Lotus, OL, TB, Pine all in one.
You haven't come up with a single technical or logical reason
besides this why Mutt shouldn't have this feature.
You've nailed it: there is more to coding than just code.
It appears that the only valid concern you have is that you simply
don't like the feature. But this is not a defensible reason for
denying the feature from the portion of the user community who
NEED it.
I don't like it: true.
I deny it for those needing: false.
I deny it being hardcoded: true.
Just because stuff
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 23.Oct'07 at 20:28:41 +0200 -= Because i face the fact that it is _impossible_ to convince you. You exepect us to prove that the feature request is valid, No, I see your point, you don't have to convince me nor prove anything. I'm absolutely clear about your position, and that is nothing more or less than I have: an opinion, a preference. It's just different from yours. You've given reasons why the rulers should do it your way, I have given mine for my. I hope they'll choose mine, I fear your chances are better though (argumentatively judging from the past), but most probably nothing will happen too soon either way. but you don't prove what you use to tell that we are wrong. You are not wrong with your opinion, it is valid and alright. Just not for me and other mutters. If you mean the final implementation with what you use, then you're right, I haven't so far, because I left it to the do-it-yourself guys to try. You are not even possible to tell how it is configurable, without reinventing the wheel (by recoding whats already implemented in mutt), but you keep teelling this. It's not needed to reinvent the wheel, because it doesn't have to work as you are used to it, as long as it works. So all you've done until now is: Saying that _you_ don't like the feature and that it it will not be included for this reason. No. You did not really argue, but you are in an authoritive position, so this discussion could be endless or one of us could give up. Well, I gave you my reasons, just they don't mean much to you, because you pay more attention to other aspect than I do. A consense is impossible to reach. And its impossible that you would give up. So I do it. EOT from me. No need to give up. Accepting to disagree is a valid result. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: Updating to Ubuntu Gutsy no longer shows message counts
On Tue, Oct 23, 2007 at 11:44:17AM -0700, Brendan Cully wrote: Due to a bug in the conversion from CVS, this may not give you the most recent change. Try hg update -C HEAD Thanks, that updated 124 files. But, now the counts are never shown :-( I just built 1.4.2.3 and that works fine. 1.5.16 doesn't. Thanks, -- Bill Moseley [EMAIL PROTECTED]
Mutt Quick Reference v.1.03 (addition from Markus Miedaner)
Mutt Quick Reference v.1.03 - updated. http://www.sys-concept.com/Mutt_connections.html This contribution is from: Markus Miedaner of Germany Thank Markus for Great Job! It is looking better every time :-) -- #Joseph GPG KeyID: ED0E1FB7 pgp8XeUw9NVl7.pgp Description: PGP signature
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: Mutt Quick Reference v.1.03 (addition from Markus Miedaner)
El día Tuesday, October 23, 2007 a las 02:19:12PM -0600, Joseph escribió: Mutt Quick Reference v.1.03 - updated. http://www.sys-concept.com/Mutt_connections.html This contribution is from: Markus Miedaner of Germany Thank Markus for Great Job! It is looking better every time :-) Nice work. Now we need someone who could bring a subset of the Reference Card onto a coffee mug. I've already have one for the most used 'vi' commands which was sold for ~10 euros years ago :-) Thx matthias -- Matthias Apitz Manager Technical Support - OCLC PICA GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e [EMAIL PROTECTED] - w http://www.oclcpica.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/
