Re: Mutt locking up, how to trace?
On Thu, Nov 22, 2012 at 11:40:33PM +0100, Richard wrote: $gdb #attach pid-mutt #bt This is a good suggestion, but depending on the optimization used when compiling mutt, it may be a little difficult to pinpoint the exact problem. But it may be enough to start looking in the right place.
Re: email has changed, you won't change everyone, and you don't have to
On Thu, Nov 22, 2012 at 07:22:03PM -0500, Peter Davis wrote: .snip. > >>Nope. Totally wrong. The responsibility is entire with the design > >>and the code, and never with the user. Otherwise it's a failed > >>product. > >You're absolutely right...as soon as they make programmers capable of > >predicting every mistake an end user will make...or the depth of every > >end user's laziness and/or stupidity. Good luck! > Apparently you're unaware of the last 30 or 40 years of human > factors and usability research, or the fact that other people are > using computers besides a bunch of ivory tower geeks who think users > will follow whatever strictures and protocols they decide to impose. Now they have mind reading software? Citation please. -- Bob Holtzman If you think you're getting free lunch, check the price of the beer. Key ID: 8D549279 signature.asc Description: Digital signature
Re: Default subject "Re: your mail" when replying to empty-subject e-mails
* On 21 Nov 2012, Marcelo Laia wrote: > On 21/11/12 at 07:00pm, David Champion wrote: > > > > You could create a personal translation, I guess. > > Have any idea how to do? Only roughly (I haven't done it): create your own mutt.po file, override the right message in it, compile it with msgfmt, choose a locale name, put the resulting mutt.mo file in the proper location, set your locale to your custom locale name, run mutt. It turns out I'm wrong anyway though. "Re: your mail" is not localized in mutt's code. -- David Champion • d...@bikeshed.us
Re: email has changed, you won't change everyone, and you don't have to
On 11/22/12 3:13 PM, Robert Holtzman wrote: On Tue, Nov 20, 2012 at 03:34:13PM -0500, Peter Davis wrote: On 11/20/12 3:18 PM, Rado Q wrote: Software can't do magic, or make up for human failures. Sometimes the responsibility is with the user, not the code. Nope. Totally wrong. The responsibility is entire with the design and the code, and never with the user. Otherwise it's a failed product. You're absolutely right...as soon as they make programmers capable of predicting every mistake an end user will make...or the depth of every end user's laziness and/or stupidity. Good luck! Apparently you're unaware of the last 30 or 40 years of human factors and usability research, or the fact that other people are using computers besides a bunch of ivory tower geeks who think users will follow whatever strictures and protocols they decide to impose. Good luck with that! -pd -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com
Re: Mutt locking up, how to trace?
On Thu, Nov 22, 2012 at 06:42:27PM +, John Long wrote: > My mutt on Linux has been locking up lately. I didn't compile it with debug > support. Is there any way to figure out why this is happening? I sometimes > lock up in the middle of composing a long email or when mutt has been open > for awhile. This didn't happen until this week and I suspect my email > provider is messing up but I don't know how to check it. Once in awhile mutt > becomes non-responsive and there's nothing I can do but kill it or close the > terminal window. It doesn't respond to any keypresses. first thing to try is "strace -p pid-mutt" from a different terminal. You could also try $gdb #attach pid-mutt #bt - should give at least a backtrace where it is hanging on most architectures. If you suspect server problem try wireshark. Richard --- Name and OpenPGP keys available from pgp key servers
Re: email has changed, you won't change everyone, and you don't have to
On Tue, Nov 20, 2012 at 09:45:05PM +0100, Rado Q wrote: .snip.` > > Ok, we disagree on basic principles, because I require responsible > and respectful users for any tool, no matter how well or badly > it's coded. > > People kill people, guns are just their tools for it. > You'll never make a foolproof gun to avoid misuse. +10! -- Bob Holtzman If you think you're getting free lunch, check the price of the beer. Key ID: 8D549279 signature.asc Description: Digital signature
Re: email has changed, you won't change everyone, and you don't have to
On Tue, Nov 20, 2012 at 03:34:13PM -0500, Peter Davis wrote: > > On 11/20/12 3:18 PM, Rado Q wrote: > >Software can't do magic, or make up for human failures. Sometimes > >the responsibility is with the user, not the code. > > Nope. Totally wrong. The responsibility is entire with the design > and the code, and never with the user. Otherwise it's a failed > product. You're absolutely right...as soon as they make programmers capable of predicting every mistake an end user will make...or the depth of every end user's laziness and/or stupidity. Good luck! -- Bob Holtzman If you think you're getting free lunch, check the price of the beer. Key ID: 8D549279 signature.asc Description: Digital signature
Mutt locking up, how to trace?
My mutt on Linux has been locking up lately. I didn't compile it with debug support. Is there any way to figure out why this is happening? I sometimes lock up in the middle of composing a long email or when mutt has been open for awhile. This didn't happen until this week and I suspect my email provider is messing up but I don't know how to check it. Once in awhile mutt becomes non-responsive and there's nothing I can do but kill it or close the terminal window. It doesn't respond to any keypresses. mutt -v and muttrc follow. Thank you. Mutt 1.5.21 (2010-09-15) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.29.6 (x86_64) ncurses: ncurses 5.7.20081102 (compiled with 5.7) libidn: 1.5 (compiled with 1.5) hcache backend: GDBM version 1.8.3. 10/15/2002 (built Sep 29 2008 00:46:22) Compile options: -DOMAIN -DEBUG -HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP +USE_SSL_OPENSSL -USE_SSL_GNUTLS +USE_SASL -USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT -ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/bin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" -MIXMASTER To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. muttrc with private stuff deleted for this email: set imap_pass= set imap_user= set folder= set imap_check_subscribed set smtp_url= set smtp_pass= set mail_check=60 set timeout=60 set check_mbox_size=yes set pager_index_lines=11 unset user_agent set abort_nosubject=no set include=yes set from= set hostname= set signature= set sort=threads set strict_threads=yes set mbox_type=Maildir set spoolfile=+INBOX set record=~/.mutt/sent set postponed=~/.mutt/postponed set header_cache=~/.mutt/cache set message_cachedir=~/.mutt/msgcache set certificate_file=~/.mutt/certs set editor="emacs +8 %s -nw" set edit_headers=yes set fast_reply=yes set content_type="text/enriched; charset=us-ascii" source ~/.mutt/gpg.rc source ~/.mutt/score -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: so many useless text
* horse_rivers [11-21-12 20:28]: > > >You can also hide header lines with 'display-toggle-weed' which is by default > >bound to the key 'h' ... > > > >HTH > >Stefan > > thanks! here is another question:how can I modify the default > key-binding of move-down by line? the default key is ,I want > to change it to "down" direction key . man muttrc search for bind search google for example .muttrc and look and the examples for binding a key/macro-to-a-key -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535@ http://linuxcounter.net
Re: Please set your line wrap to a sane value (was ... Re: Is there any gmane.org user in the list?)
On 2012-11-21, Jim Graham wrote: > On Wed, Nov 21, 2012 at 05:02:50PM +, Tony's unattended mail wrote: > >> LF means "begin next line now". So as an author posting text to a >> forum, at what point do you need an LF? Not after XX width, >> because that makes poor assumptions about the readers medium (is it >> an LCD, or a phone?). > > So you don't make an assumption about the e-mail client of any > reader on the list...not even that their MUA displays very long > lines correctly, right? So, you can't assume that it wants very > short lines, or likes very long lines, or somewhere in-between. I'm not making any assumptions based on a fixed length, short or long. Post 90s, accommodating *variable* width is more sensible than a width that is fixed. > I guess that means you can't send the message at all, right? > Somewhere, you have to make as assumptino. An author need not assume any particular fixed width. > At this time, the generally accepted assumption is to wrap at around > 72--76 characters Right.. one million smokers can't be wrong. > (with the obvious exception of posting code, etc., where lines may > often end up longer unless you escape the newline and continue the > line of code (indented, of course) on the next line. This is the problem with the fixed width approach -- the exception is not syntactically distinct from LFs that try to guess at the readers display. > As others have also mentioned, lines that don't wrap---not everyone > uses Mutt or other smart MUAs, and even if you do, in a wider xterm, > the longer lines can be much more difficult to read---they are for > me, anyways, so I usually just delete the message without even > bothering with it (if I'm using a wider xterm or an e-mail client > that doesn't correct the line length, or gets it wrong). This is where I make an assumption. When the need for an assumption arises as to whether others have poor quality tools or high quality tools, I do not assume the other party has poor quality tools if the approach that caters for poor quality tools will hinder users of high quality tools in some way. Punishing users who have high quality tools to favor lesser quality software serves as an enabler for lousy quality to proliferate. If we didn't think along the bandwagon lines of going with the crowd, developers would have some pressure to improve the tool.
