Re: Cannot paste to XJed with Mutt/KDE
On Mon, Aug 23, 1999 at 01:02:10PM -0500, David DeSimone wrote: > rex <[EMAIL PROTECTED]> wrote: > > > > Pasting to Xjed running as Mutt's editor worked under RH5.2. With > > RH6.0 and KDE it does not -- nothing happens. Pasting _from_ Xjed > > while composing a message still works, but usually I want to go the > > other way. > > Mutt just runs in an xterm, or rxvt, or whatever you want, and *that* > program is what handles the cuts and pastes. How can it be Mutt's > fault? I didn't mean to suggest that it is a problem with Mutt, but a Usenet search was fruitless and I though someone here might have run into the problem. Mutt is running in a KDE Konsole (which can I paste to), but Mutt is calling XJed in another window (I don't know what it is -- xterm? -- or how to change it) and pasting does not work there from a KDE Konsole or KDE Terminal or xterm window. However, if I start Mutt from an xterm window or KDE Terminal window instead of a KDE Konsole window, pasting into XJed when I'm composing a message works. So it appears to be a problem with KDE Konsole not allowing pasting to a spawned window. I guess a work-around is not to use Konsole for Mutt. Thanks for the reply -rex
Re: GnuPG and Mutt
On Wed, Sep 01, 1999 at 01:37:04PM +0200, J Horacio MG wrote: > > > set pgp_long_ids > > This one was unset, and there was a warning not to change this setting > (??). > > > set pgp_gpg="/usr/bin/gpg" > > > > set pgp_default_version="gpg" > [...] > > No value was with quotations except the key id for setting the default > signing key: set pgp_sign_as="0x42337AE6" It still doesn't work. Mark
Re: IMAP folder path
Brendan, et al -- Thanks for your clarification and extension of my little picture. I'm still not too IMAP-savvy and was thinking in terms of a local folder browser (hence the files, instead of messages, in the bottom section). I admit that I'd very much like to have such a browser available for ordinary files/folders, too. I'm not even going to wonder what it would take to code it for now *four* types of folders :-) :-D -- David Thorburn-Gundlach * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] Helping out at Pfizer http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! "Why2k? Well, I didn't think at the time that I could charge any more!" Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: GnuPG and Mutt
> > I'm running GnuPG 0.9.10-2. Gpg is the default in ~/.muttrc, and gpgm > > is a symbolic link to gpg. But sending my public key or encrypting > > still doesn't work. Mutt always asks for a key ID but every input > > seems to be wrong. > It still doesn't work. Can you elaborate a bit more? I assume you know that ... hold it! It just happened to me, I tried to send an encrypted mail to myself and at the key id prompt, it got stack ... then I pressed ^C, and when asked whether I wanted to leave mutt, I answered «no». Then pressed «Y» again for sending the message again, and it offered me the menu with all my keys. It worked. I tried to send another encrypted message, and it went fine. The former two attempts were made using my old (though still working) email address ([EMAIL PROTECTED]). All my keys still have that address as the main address. A third attempt, encrypting to my current address, took a while to show the key id prompt. This time I just pressed and it finally showed a menu with the WHOLE public keyring. Don't know, may be due to the fact that my current address is not the primary address for my keys. Strange behviour though. Anyone got an idea about what's going on? I'm using Mutt 0.95.6i (1999-06-03) and (GnuPG) 0.9.8 Regards, -- Horacio [EMAIL PROTECTED] Valencia - ESPAÑA
A feature request
Hello, mutt is wonderful. However there is nothing perfect in this world (for me, that is), so I'd like to talk a bit about ignore_list_reply_to variable. We have a couple of local (in geographical sense) mailing lists in which mails come with a huge variance in To: fields, e.g. To: [EMAIL PROTECTED] To: "Programming mailing list" <[EMAIL PROTECTED]>" To: My Good Friend [EMAIL PROTECTED], [EMAIL PROTECTED] and even To: "Someones Real Name" <[EMAIL PROTECTED]> (there are three aliases instead of one fixed domain name, so [EMAIL PROTECTED] above is always the same mailing list). It is now being voted if Reply-To should contain just the mailing list address (one of the three), or both mailing list and original sender address. Unfortunately, this renders mutt's `ignore_list_reply_to' completely useless. But wouldn't it be better if mutt just parsed the Reply-To field in this way: if any of the addresses there belongs to a mailing list AND it is also mentioned in the To field, then it is simply ignored as if it wasn't there at all. Also, does anybody know what `Content-Type: text/plain, charset="utf-7"' mean? I do know UTF-8, but I can only guess what UTF-7 is. AFAIK both Netscape and Internet Explorer support it. I recently received a couple of mails in this encoding (mailer: MS Outlook Express 5.00) and the only thing that looked strange was quoting string: `+AD4- '. Unfortunately, mutt does not support it. Still, mutt is wonderful. Any chances of porting it to Win32 so I could comfortably read my mail at work too? :) Best Regards, Marius Gedminas -- Cheap, Fast, Good--pick two.
Spoolfile permissions
Hi. I've got a seemingly major problem with my spoolfile. The permissions are 600 and the file belongs to me, but mutt just keeps telling me that the mailbox is readonly. When I use pine, there are no problems. But I want to use mutt, pine sucks :-) Does anyone have a clue as to where the solution to my problem might be? thanx -Dennis --- Dennis Hammer UNIX Administration Tech-Consult Salzburg Jakob-Haringer-Str. 1, 5020 Salzburg mailto:[EMAIL PROTECTED]http://www.tcs.co.at ---
Re: A feature request
> Also, does anybody know what `Content-Type: text/plain, charset="utf-7"' > mean? I do know UTF-8, but I can only guess what UTF-7 is. AFAIK both > Netscape and Internet Explorer support it. I recently received a couple > of mails in this encoding (mailer: MS Outlook Express 5.00) and the only > thing that looked strange was quoting string: `+AD4- '. Unfortunately, > mutt does not support it. Based on responses (or lack thereof) the last two times I brought up the subject, I am the only other person on mutt-users who has ever seen UTF-7. ;) UTF-7 is a 7-bit clean version of unicode. It is described in rfc1642. UTF-8 is the more standard way of handling unicode. AFAIK, outlook express is the only program which sends UTF-7, and even then it seems that only some installs of outlook express do it. My solution was to find a program called u7tou8 which does conversion from UTF-7 to UTF-8, which is understood by mutt. Then I added the following to my .procmailrc: :0 f * ^Content-Type:.*charset="utf-7" | u7tou8 | formail -i "Content-Type: text/plain; charset=\"utf-8\"" This would of course break things like PGP/MIME signatures, but who's going to be sending you PGP/MIME from inside of Outlook Express? ;) I'm having a bit of trouble finding where you can get this conversion program. Last time I think I found it by searching through the Linux Chinese-HOWTO. Ah, here it is (the HOWTO comes through again): ftp://ftp.ifcss.org/pub/software/unix/convert/utf7.tar.gz Good luck. Brian
reading mail while composing
I'm trying mutt after having used rmail in Emacs and various other MUAs in the past. One thing I find I keep wanting to do is consult other e-mails while composing an e-mail. Is there a neat way of doing this, apart from postponing the e-mail, or running another mutt in another xterm for browsing purposes (assuming that file locking will protect me from accidents)? It would be quite nice if the xterm I'm running mutt in could remain active while my editor (Emacs) uses its own window. (Either exmh or Netscape's MUA works like that, as I recall.) Edmund
defining alias via pipe?
I just read through section 3.2 of the manual, and didn't see anything on this topic, so I thought I'd ask the list. I have a handful of group-aliases that can be very lengthy (over 20 email addresses in one alias, etc.). Rather than list them all out in my .mutt/aliases file, especially since the lists can change rather frequently, I'd like to keep the lists in a text file. From there, I'd like to run a quick script over the file to format it into a comma-delimited list and define the alias as the output of that script. I stabbed in the dark by trying: alias somelist `getlist.pl` The alias was defined, but empty when I ran mutt (1.0pre2i). Anyone have something similar working? Is there a feature I'm not exploiting? TIA. - Forrest -- || Forrest Carpenter "God was not a top-down structured programmer." || [EMAIL PROTECTED] -- Dexter Pratt || http://spite.com/
Re: reading mail while composing
Hi! On Thu, Sep 02, 1999 at 05:53:28PM +0100, Edmund GRIMLEY EVANS wrote: > I'm trying mutt after having used rmail in Emacs and various other > MUAs in the past. One thing I find I keep wanting to do is consult > other e-mails while composing an e-mail. Is there a neat way of doing > this, apart from postponing the e-mail, or running another mutt in > another xterm for browsing purposes (assuming that file locking will > protect me from accidents)? Yes, put your editor/mutt in the background and view a mailbox with another mutt running in _this_ xterm ... but seriously, there isn't a way, execpt when you are in the compose menu, you can call the attach-message function without actually attaching something. > It would be quite nice if the xterm I'm running mutt in could remain > active while my editor (Emacs) uses its own window. (Either exmh or > Netscape's MUA works like that, as I recall.) Yes, but this requires major changes in the code structure. Don't expect this anytime soon, unless you want to join mutt-dev and do the work. Gero
Re: reading mail while composing
On Thu, Sep 02, 1999 at 05:53:28PM +0100, Edmund GRIMLEY EVANS cogitated: > I'm trying mutt after having used rmail in Emacs and various other > MUAs in the past. One thing I find I keep wanting to do is consult > other e-mails while composing an e-mail. Is there a neat way of doing > this, apart from postponing the e-mail, or running another mutt in > another xterm for browsing purposes (assuming that file locking will > protect me from accidents)? Actually, you bring up a good point on file locking...I installed under linux from tarball and compiled it --with-flock --without-fcntl ...and I can run 2 mutt sessions on the same mailbox and have one alter it, and then when you go back to the other, it says it's been modified. Something seem incorrect about the locking there? kernel 2.0.36. mark-> -- Fairlight-> |||[EMAIL PROTECTED] | Fairlight Consulting __/\__ ||| "I'm talking for free... | http://www.fairlite.com <__<>__> ||| It's a New Religion..." | [EMAIL PROTECTED] \/||| PGP Public Key available via finger @iglou, or Key servers
Re: pgp autosign
Joshua Weage <[EMAIL PROTECTED]> wrote: > > IMO, it would make more sense to have things temporary for sending > mail, but if a generic send-hook is required, then I will use that. Doubtless it would make more sense to you, and probably everyone else, if it worked that way, but the fact is that what you describe, while very simple to conceive of in your head, is very difficult to enact within Mutt, because Mutt allows absolutely *any* command to be run, including aliases, hooks, color commands, etc, and undoing that is not as trivial as it sounds. It is also a fact that, while the current system may be harder to learn, it can be just as flexible and useful as the scheme you describe, and can be made to do exactly what you want to do, with a little forethought. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: reading mail while composing
Fairlight <[EMAIL PROTECTED]> wrote: > > Actually, you bring up a good point on file locking...I installed > under linux from tarball and compiled it --with-flock --without-fcntl > ...and I can run 2 mutt sessions on the same mailbox and have one > alter it, and then when you go back to the other, it says it's been > modified. Something seem incorrect about the locking there? You modified the folder in one Mutt, and the other Mutt noticed this, and told you about it. Why is that a problem? Locking only occurs when the folder is first opened, and when it is being written. Mutt does not leave the folder locked for the entire time that you were reading mail; that would prevent new mail from being delivered. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: defining alias via pipe?
E Forrest Carpenter <[EMAIL PROTECTED]> wrote: > > alias somelist `getlist.pl` > > The alias was defined, but empty when I ran mutt (1.0pre2i). What you describe should have worked. Perhaps you didn't have your script output a trailing new-line (\n) character? -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: defining alias via pipe?
> > alias somelist `getlist.pl` > > > > The alias was defined, but empty when I ran mutt (1.0pre2i). > > What you describe should have worked. Perhaps you didn't have your > script output a trailing new-line (\n) character? That did it, thanks. Incidentally, why is the newline character required? There's a newline after the second back-tick, right? No denial of ignorance here. -- || Forrest Carpenter "God is not a top-down structured programmer." || [EMAIL PROTECTED] -- Dexter Pratt || http://spite.com/
Re: reading mail while composing
On Thu, Sep 02, 1999 at 12:30:20PM -0500, David DeSimone cogitated: > Fairlight <[EMAIL PROTECTED]> wrote: > > > > Actually, you bring up a good point on file locking...I installed > > under linux from tarball and compiled it --with-flock --without-fcntl > > ...and I can run 2 mutt sessions on the same mailbox and have one > > alter it, and then when you go back to the other, it says it's been > > modified. Something seem incorrect about the locking there? > > You modified the folder in one Mutt, and the other Mutt noticed this, > and told you about it. Why is that a problem? > > Locking only occurs when the folder is first opened, and when it is > being written. Mutt does not leave the folder locked for the entire > time that you were reading mail; that would prevent new mail from being > delivered. I guess I figured it would work somewhat differently...perhaps because of the way elm (which I used for 10 years and just dropped for mutt) handled at least your main spool folder, and would complain to you if /tmp/mbox.fairlite was present and you tried firing up a new session, etc. Your delivery example does show the flaw in my logic, especially keeping in mind WHY elm used /tmp/mbox.fairlite :) And that was only on the main spool. At least mutt is polite and just informs you of a change, and doesn't bail on a "corrupt" mailbox. :) :) For what it's worth, I did talk to someone else about this and they said if you open, say: 1) mutt -f folders/blip 2) mutt -f folders/blip 3) mutt -f folders/blip And if you make any changes, if you close 3 and then 2, and then 1, you're fine, and notified appropriately, etc. But if you close 1 first, 2 and 3 will core dump. At least that was my understanding, and I haven't seen this exhibition of behaviour personally. I thought I'd mention it while we're on a similar topic. I'm actually more worried about the double-message index display but I caught the other day. :) Thanks for straightening out the locking deal for me. mark-> -- Fairlight-> |||[EMAIL PROTECTED] | Fairlight Consulting __/\__ ||| "I'm talking for free... | http://www.fairlite.com <__<>__> ||| It's a New Religion..." | [EMAIL PROTECTED] \/||| PGP Public Key available via finger @iglou, or Key servers
Re: reading mail while composing
On 1999-09-02 13:11:07 -0400, Fairlight wrote: > Actually, you bring up a good point on file locking...I installed > under linux from tarball and compiled it --with-flock > --without-fcntl ...and I can run 2 mutt sessions on the same > mailbox and have one alter it, and then when you go back to the > other, it says it's been modified. Something seem incorrect about > the locking there? kernel 2.0.36. Not at all. The folder is locked while mutt reads from or writes to it. And, just as any local mail delivery agent can append messages to a mail folder while you are reading your messages, another instance of mutt can modify that folder. Mutt goes to some lengths to merge the changes from different sessions gracefully, which works quite well in most cases.
Re: defining alias via pipe?
E Forrest Carpenter <[EMAIL PROTECTED]> wrote: > > > > alias somelist `getlist.pl` > > > > Perhaps you didn't have your script output a trailing new-line (\n) > > character? > > That did it, thanks. Incidentally, why is the newline character > required? There's a newline after the second back-tick, right? Mutt's parser requires full lines to be read. You will see the same effect if your editor doesn't put a newline character at the end of your .muttrc file; that final command will be ignored. In this case, though, Mutt is reading the .muttrc just fine; it's when it reads the piped output from your "getlist.pl" script, the same parser is used, and it wants to read full lines of output. If your script fails to output a final newline character, the last (unfinished, in Mutt's eyes) line of output will be ignored. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: IMAP folder path
Quoting Brendan Cully <[EMAIL PROTECTED]>:
> I've been thinking some more about this. I don't really want two keys to
> operate on folders, one for selecting and one for descending. Most users
> have folders that contain *either* subfolders *or* messages, but not
> both. Making them two keys for folders that really only have one action
> available to them is counterintuitive.
>
It'd only be counterintuitive if not done right. Rather than
completely separating these two functions on to two separate keys
("list subfolders" on and "list messages" on some other key),
why not have list the subfolders if it's on a folder that is
capable of subfolders, and list the messages, otherwise? That way,
the other key would only need to be used if you wanted to view the
messages in a folder that could have both.
-Brandon :)
Re: Spoolfile permissions
Dennis -- Take a look at your spool dir permissions and the mode of mutt_dotlock (you are using a fairly recent version of mutt, aren't you?). mutt itself does not need to be set with any special permissions, while mutt_dotlock should be root.mail and 02555 (g+s); you rmail spool is probably also root.mail and 0775 so that folks not in the mail group cannot write to it. If that's not the answer, please send us more details -- system flavor, mutt flavor, and more... :-D -- David Thorburn-Gundlach * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] Helping out at Pfizer http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! "Why2k? Well, I didn't think at the time that I could charge any more!" Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Cannot compile mutt :-(
Hi everybody,
got the latest from www.mutt.org and was trying to compile it, but as
in pre1, the same error persists:
/usr/src/mutt-1.0pre2-us# /usr/src/mutt-1.0pre2-us/configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... missing
checking host system type... configure: error: can not guess host
type; you must specify one
/usr/src/mutt-1.0pre2-us#
I have a standard Pentium 90, Debian Linux 2.1 (slink), the "old"
mutt-0.95.4 compiled fine at the time, but now also gives the same
error. Am I doing something wrong here?
Kind regardsFrederick
Re: Cannot compile mutt :-(
On Thu, Sep 02, 1999 at 09:51:27PM +0200, Frederick Page wrote:
> Hi everybody,
>
> got the latest from www.mutt.org and was trying to compile it, but as
> in pre1, the same error persists:
>
> /usr/src/mutt-1.0pre2-us# /usr/src/mutt-1.0pre2-us/configure
> creating cache ./config.cache
> checking for a BSD compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking whether make sets ${MAKE}... yes
> checking for working aclocal... found
> checking for working autoconf... found
> checking for working automake... found
> checking for working autoheader... found
> checking for working makeinfo... missing
> checking host system type... configure: error: can not guess host
> type; you must specify one
> /usr/src/mutt-1.0pre2-us#
>
> I have a standard Pentium 90, Debian Linux 2.1 (slink), the "old"
> mutt-0.95.4 compiled fine at the time, but now also gives the same
> error. Am I doing something wrong here?
Hmm.. I don't think it's something that you're doing wrong, but that
configure can't find the host type from the places that it should find it
(correct me if I'm wrong here, everyone. :) )
I had the same problem, when someone at the ISP I helped to create,
had changed permissions on gcc, to only be accessible by root. So, I grabbed
my own binary for gcc, and added --host as an option to configure. When it
asked for the host, I grabbed that from the directory in /usr/lib/gcc-lib
(slackware box). Once I had that ( --host=machinetype ) configure went through
the normal routine, and mutt compiled.
You may want to give that a try (YMMV).
BL.
--
Brad Littlejohn | Email:[EMAIL PROTECTED]
Unix Systems Administrator, |[EMAIL PROTECTED]
WebMaster, NewsMaster.. Smeghead! :)| http://www.omnilinx.net/~tyketto
PGP: 1024/E9DF4D85 67 6B 33 D0 B9 95 F4 37 4B D1 CE BD 48 B0 06 93
Re: Cannot compile mutt :-(
On Thu, Sep 02, 1999 at 09:51:27PM +0200, Frederick Page wrote:
> Hi everybody,
>
> got the latest from www.mutt.org and was trying to compile it, but as
> in pre1, the same error persists:
>
> /usr/src/mutt-1.0pre2-us# /usr/src/mutt-1.0pre2-us/configure
> creating cache ./config.cache
> checking for a BSD compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking whether make sets ${MAKE}... yes
> checking for working aclocal... found
> checking for working autoconf... found
> checking for working automake... found
> checking for working autoheader... found
> checking for working makeinfo... missing
> checking host system type... configure: error: can not guess host
> type; you must specify one
> /usr/src/mutt-1.0pre2-us#
>
> I have a standard Pentium 90, Debian Linux 2.1 (slink), the "old"
> mutt-0.95.4 compiled fine at the time, but now also gives the same
> error. Am I doing something wrong here?
>
> Kind regardsFrederick
I may be way-off here, but it looks like a problem with uname...
make sure it's in your path and you can execute it. (output from
it might also be helpful, here... config.guess specifically seems
to run it with -m, -r, -s and -v (at different times).
Hopefully that might be enough to help...
This
--
Russell M. Van Tassell
[EMAIL PROTECTED]
It is a sad commentary on today's society that this fortune has to be
classified as "offensive" simply because it contains the word "fuck".
postponed
i have a simple question. every now and then i need to postpone a message. i have mutt configured to put messages in a postponed file. unfortuneatly, it goes in my home directory and not into my mail directory. how do i change this? tia, -e
Re: postponed
erik [[EMAIL PROTECTED]] wrote: > i have a simple question. every now and then i need to postpone a > message. i have mutt configured to put messages in a postponed file. > unfortuneatly, it goes in my home directory and not into my mail > directory. how do i change this? set postponed="=postponed" -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: defining alias via pipe?
David DeSimone <[EMAIL PROTECTED]> wrote on Thu, 02 Sep 1999: > Mutt's parser requires full lines to be read. You will see the same > effect if your editor doesn't put a newline character at the end of your > .muttrc file; that final command will be ignored. Any particular reason why this is so? I would think that an EOF instead of EOL would work as line ending. And I don't immediately see any drawbacks in this either. I guess my question is whether this is by design, or just because that's the way it is? Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs / 2 + 2 = 4 (for the time being)
Re: Cannot paste to XJed with Mutt/KDE
At 8:35 PM EDT on August 28 rex sent off: > > > Pasting to Xjed running as Mutt's editor worked under RH5.2. With > > > RH6.0 and KDE it does not -- nothing happens. Pasting _from_ Xjed > > > while composing a message still works, but usually I want to go the > > > other way. > > Mutt is running in a KDE Konsole (which can I paste to), but Mutt is > calling XJed in another window (I don't know what it is -- xterm? -- > or how to change it) and pasting does not work there from a KDE > Konsole or KDE Terminal or xterm window. However, if I start Mutt from > an xterm window or KDE Terminal window instead of a KDE Konsole > window, pasting into XJed when I'm composing a message works. So it > appears to be a problem with KDE Konsole not allowing pasting to a > spawned window. I guess a work-around is not to use Konsole for Mutt. I think you've encountered an annoying oddity/feature of jed's default mouse handling. Try holding down the shift key while you do your mouse operations in (x)jed, i.e. shift-middle button to paste. HTH. -- Because we don't think about future generations, they will never forget us. - Henrik Tikkanen Robert I. Reid <[EMAIL PROTECTED]> http://astro.utoronto.ca/~reid/ PGP Key: http://astro.utoronto.ca/~reid/pgp.html
Re: Cannot compile mutt :-(
Hi Tyketto, you wrote on Thu, Sep 02 1999: >> (...) >> checking for working autoheader... found >> checking for working makeinfo... missing >> checking host system type... configure: error: can not guess host >> type; you must specify one >> /usr/src/mutt-1.0pre2-us# >Hmm.. I don't think it's something that you're doing wrong, but that >configure can't find the host type from the places that it should >find it (correct me if I'm wrong here, everyone. :) ) I'm also suspicious about the line preceeding the error: "checking for working makeinfo... missing". I recently upgraded my Debian 2.0 to 2.1, on my "old" 2.0 the compile (scripts config.guess) worked fine. >So, I grabbed my own binary for gcc, and added --host as an option to >configure. When it asked for the host, I grabbed that from the >directory in /usr/lib/gcc-lib (slackware box). Once I had that ( >--host=machinetype ) configure went through the normal routine, and >mutt compiled. > >You may want to give that a try (YMMV). Ouch! I came to Linux quite a short time ago, I am afraid, that this stuff is kind of too advanced for me :-( I was more hoping, someone would tell me "you need to install package XY" or something a linux newbie like me could handle more easily ;-) Anyway: thanks for your feedback! Kind regardsFrederick -- They are a perfect couple: He is a proctologist and she is a pain in the ass.
Re: Cannot compile mutt :-(
Hi Russell, you wrote on Thu, Sep 02 1999: >> checking for working makeinfo... missing >> checking host system type... configure: error: can not guess host >> type; you must specify one >I may be way-off here, but it looks like a problem with uname... That's in my path and executable (I tried compiling mutt as root). >(output from it might also be helpful, here... config.guess >specifically seems to run it with -m, -r, -s and -v (at different >times). Quoting from "man uname": If the -a option is given, the selected information is printed in the order `snrvm' with a space between items. ~# uname -a Linux thebetteros 2.0.34 #1 Fri Jan 29 01:44:57 CET 1999 i586 unknown ~# I was not able to isolate the "unknown", machine is i586 (Pentium 90). >Hopefully that might be enough to help... Thanks for your feedback, I'm a little worried about that "unknown", that might indeed be the cause for my troubles, wonder what's wrong here. Kind regardsFrederick -- The major difference between an oral and rectal thermometer is the taste.
Re: Spoolfile permissions
Dennis Hammer <[EMAIL PROTECTED]> wrote: > > I've got a seemingly major problem with my spoolfile. The permissions > are 600 and the file belongs to me, but mutt just keeps telling me > that the mailbox is readonly. The mutt_dotlock program needs permission to create a dot-lock file in the mail spool directory. That means that the directory must be writable in some way. THE PARENT DIRECTORY of your spool file. The permissions of your spool file itself don't affect how it can be locked. Mutt is supposed to examine the permissions of your spool directory and react accordingly. If the permissions are 1777, then mutt_dotlock needs no extra permissions. If the permissions are 775, then mutt_dotlock needs to be owned by the same group that owns the spool directory, and needs to be setgid. If the permissions are 755 or worse, then there is no recourse; mutt_dotlock shouldn't be installed or used for locking. This is really getting to be a FAQ around here. Why is this happening? Did someone package up an RPM that just blithely assumes it knows what locking method is supposed to be applied on everyone's system? > When I use pine, there are no problems. There are two possibilities: 1. Pine is installed incorrectly and is failing to lock your spool file in a way that prevents other programs from corrupting it. 2. Pine is doing everything correctly, and Mutt is trying to lock the spool in a way that's not possible, or necessary. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson UX WTEC Engineer |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: Cannot compile mutt :-(
On Fri, Sep 03, 1999 at 01:09:11AM +0200, Frederick Page wrote: > >(output from it might also be helpful, here... config.guess > >specifically seems to run it with -m, -r, -s and -v (at different > >times). > > Quoting from "man uname": > > If the -a option is given, the selected information is printed in the > order `snrvm' with a space between items. > > ~# uname -a > Linux thebetteros 2.0.34 #1 Fri Jan 29 01:44:57 CET 1999 i586 unknown > ~# > > I was not able to isolate the "unknown", machine is i586 (Pentium 90). Well, config.guess doesn't execute "uname -a" but actually: UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown (BTW, isn't "uname -m" (machine hardware) depracated for -p (processor) in newer architectures?) So, judging from your manpage output, you'd get: UNAME_MACHINE: unknown UNAME_RELEASE: 2.0.34 UNAME_SYSTEM: Linux UNAME_VERSION: i586 I'm guessing that it REALLY would prefer: UNAME_MACHINE: i586 UNAME_RELEASE: 2.0.34 UNAME_SYSTEM: Linux UNAME_VERSION: unknown (then again, the manpage is probably out of date) (it would appear as though, possibly, some of the uname arguments might be fubar'd in config.guess (not that I've looked at it quite that long as to definitely point at that -- I'd most likely guess that it's a slight variation in Linux, first...)) So, execute the following and get it back to me and I'd be happy to try to help you further (unless you can debug it yourself): uname -m uname -r uname -s uname -v ld -help (all of these can be found in "./config.guess" line 495-627 or so) > >Hopefully that might be enough to help... > > Thanks for your feedback, I'm a little worried about that "unknown", > that might indeed be the cause for my troubles, wonder what's wrong > here. Actually "unknown" is ok, in some spots... -- Russell M. Van Tassell [EMAIL PROTECTED] "For NASA, space is still a high priority." -- VP Dan Quayle
Re: reading mail while composing
On Thu, Sep 02, 1999 at 05:53:28PM +0100, Edmund GRIMLEY EVANS wrote: > One thing I find I keep wanting to do is consult other e-mails > while composing an e-mail. Is there a neat way of doing this? The only thing that I have been able to come up with is to returm to the compose screen, press 'A' in the compose screen and then from the special browser screen, pipe the mail you want to cat >> /tmp/mutt-ms-[some number] But you have to remember the number from the compose screen. There is some file completion. Mutt experts, is there some variable that will give me the name of the file mutt created for my editor so I can reduce the key strokes with a macro? -- Greg Matheson The Internet from time Chinmin College, Taiwan to time claims this [EMAIL PROTECTED] address does not exist
"Delivered-To:" hdr on bounced mails?
>From the 1.0pre2i manual: 6.3.19. bounce_delivered Type boolean Default: set When this variable is set, mutt will include Delivered-To headers when bouncing messages. Postfix users may wish to unset this variable. Why unset for Postfix users? My ISP uses Postfix (I use my ISP's mutt), and the headers on a bounced mail are the same whether I set bounce_delivered or not. In both cases, four "Resent: ___" headers are added, but there is no "Delivered-To:" header. (Just trying to understand how the new variable works.)
