FAQ: How to spawn terminal/screen to reply to messages separately?
I saw in the archives that this is a bit of an FAQ, and it seems that to this day there's not much of an answer, sadly. The best I could do was to create an index macro that pipes the current message to a script that then: a) pipes stdin to formail, b) saves the result in a tmp file, c) starts a new instance of mutt -f that_file. Or perhaps using -H. But that's clearly not quite what I want, nor what the various users who have asked for this want. Ideas: - Add a function like but which instead of piping the message puts the message in a temp file and then allows for expansion of several parameters in the command line, including: %f (the address of the sender of the message) %r (the To: addresses of the message) %c (the Cc: addresses of the message) %a (the To: and Cc: addresses of the message) %l (the To: and Cc: addresses of the message that are lists) %R (the Reply-To: address of the message) %s (the Subject: of the message, with "Re: " prefixed if not %already) %F (the name of the file containing the message) - Same as above but also provide a Unix domain socket/door/whatever that mutt can listen on for commands from the external command. The purpose of this is to support connection sharing and avoid having to re-type IMAP/SMTP passwords. The main sub-command would be to send the message found in a given file, and also to mark a message in a folder as replied. The name of the rendezvous would be set in an environment variable and mutt would support using it. All send/save/*-hooks would be applied in the primary mutt. (This is not really needed when using SASL/GSSAPI, of course. It's primrarily useful when there are passwords to type.) Where would I start if I was to try to implement the first of the above? Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Mon, Mar 29, 2010 at 08:05:26PM -0700, Gary Johnson wrote: > I think you can do all of your first idea with a macro. The basic > idea is: It won't do: > [...] > 5. Execute a script as you did before to start mutt on that > postponed message. First, this is a bad UI since I'll have to hit 'r' (or 'g', or ...) to reply to the message in the spawned instance of mutt. This might be fixable using the -e CLI option. Second, and this is worse, is: > The tricky part is, and has always been in these discussions, making > sure the 'replied' flag on the original message is set properly. Exactly. > That seems to require the primary mutt to listen on some sort of > IPC mechanism for a command to set the 'replied' flag on the message > of a specified Message-ID as you have outlined in your second idea > above. Mutt currently checks things like the presence of new mail > upon user input or the expiry of a timer, so it seems that it could > check the IPC mechanism the same way. If mutt had CLI options naming a specific message in a specific folder to immediately reply to then the replied flag could get set correctly and then the original instance of mutt could eventually sync up. But that has the problem that there's no connection sharing and no password caching. The latter is yet more bad UI. This problem screams for a specific solution rather than trying to bend existing facilities of mutt. The archives are littered with incomplete and unsatisfying solutions. Yours sounds better than all the previous ones, and still, it's not satisfying. > I think the solution to the second problem may influence the > solution to the first, so it would be my suggestion to work on the > second problem first. I'm thinking along the same lines. But I want this to be simple. I'm thinking of doing something with Unix domain sockets (to be portable, else I'd use Solaris doors :) like so: - one main socket - spawned instances connect to the parent's main socket and request any of: - another socket on which to talk SMTP/SUBMIT or IMAP to some server In both cases the parent would hand back to the child a pipe which the parent would proxy to the real server. The parent would do all TLS and SASL work. In the case of IMAP the parent could share a single connection with its children, making sure to remap the IMAP request XIDs to avoid conflicts (or perhaps the parent could hand each child an XID namespace for itself). (IIRC IMAP requests and replies have an XID picked by the client.) - tell the parent to sync its view of some message or folder - other commands? > The child process could be a wrapper around an instance of "mutt > -H". If that mutt exits with a status of 0, the wrapper writes the > "set replied for this Message-ID" command to stdout and exits. > Otherwise, it just exits. Rather than a wrapper, of course, it > would be nice to just invoke mutt with a flag that tells it to do > all that. Yes. But I want a more complete solution. > I don't know where in the code to suggest that you start. I usually > run cscope on the source code directory tree, then run "vim -c 'grep > some_likely_string *.[hc]'" where some_likely_string is something I > expect to find associated with the code I'm interested in, and start > browsing the code from there. Unfortunately I'm very busy. I may not get to this any time soon. But I may start by reading the code. Cscope is one of my favorite tools. Thanks, Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Mon, Mar 29, 2010 at 10:11:40PM -0700, George Davidovich wrote: > Maybe I'm missing something here, but wouldn't temporarily resetting > mutt's `sendmail' variable to a custom mailer (a variation on the OP's > script, perhaps) take care of the replied flag issue? No. The sendmail thing comes too late. We want asynchrony between the point the user chooses to reply to some message and the point the reply is sent. That is, the user hits 'r' (or ...) and a new terminal pops up running a different instance of mutt to take care of invoking $editor and all that while the main instance returns to the index (where the user could then spawn another reply before even finishing the first). The way I normally work around this is to postpone drafts, go back to the index, and go from there. I'm sort-of time-slice multi-tasking the reply process. That's something computers and software are good for. (Note that I don't want a GUI MUA -- if I did I would not be here. I particularly like running things in screen(1). I solve a similar problem with cscope by using a wrapper around my $EDITOR that spawns a new screen to run my $EDITOR.) (Note also that others have referred to this problem as making mutt multi-threaded, but that's not useful unless one instance of mutt can drive multiple ptys at once. There's no need to make mutt MT for that as async I/O will do. Making mutt support multiple ptys would be nice, but I'm sure it'd involve significant changes.) Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: > On 29Mar2010 17:19, Nicolas Williams wrote: > | I saw in the archives that this is a bit of an FAQ, and it seems that to > | this day there's not much of an answer, sadly. > > Here's what I do: > set edit_headers=yes > set editor=muttedit > set autoedit=yes > > Muttedit is here: > http://www.cskk.ezoshosting.com/cs/css/bin/muttedit > > Now, muttedit mostly just runs the reply process in a screen session; it does > some work to give the session a good name. Very nice sed scripting. > If I complete the reply immediately (as now), it's all seamless. > > But if I want to defer the reply for later, I simply detach from screen > and reattach later. Here's this message in progress: But what happens on detach in the parent mutt (edit abort?)? (I've tried it, and the screen does not appear to start. > Does that workflow address your needs? Almost, but see the other e-mails in this thread. Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 10:43:08AM -0500, Nicolas Williams wrote: > On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: > > If I complete the reply immediately (as now), it's all seamless. > > > > But if I want to defer the reply for later, I simply detach from screen > > and reattach later. Here's this message in progress: > > But what happens on detach in the parent mutt (edit abort?)? (I've > tried it, and the screen does not appear to start. Oh, I got it to work. I needed to insert "env TERM=xterm-color" into the screen command-line (I'd completely forgotten). screen -ls output gets mangled, but that's screen's fault: There are screens on: [...] 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) > > Does that workflow address your needs? > > Almost, but see the other e-mails in this thread. This is the closest so far though. Thanks, Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Wed, Mar 31, 2010 at 09:44:09AM +1100, Cameron Simpson wrote: > On 30Mar2010 11:11, Nicolas Williams wrote: > | On Tue, Mar 30, 2010 at 10:43:08AM -0500, Nicolas Williams wrote: > | > On Tue, Mar 30, 2010 at 07:04:22PM +1100, Cameron Simpson wrote: > | > > If I complete the reply immediately (as now), it's all seamless. > | > > > | > > But if I want to defer the reply for later, I simply detach from screen > | > > and reattach later. Here's this message in progress: > | > > | > But what happens on detach in the parent mutt (edit abort?)? (I've > | > tried it, and the screen does not appear to start. > | > | Oh, I got it to work. I needed to insert "env TERM=xterm-color" into > | the screen command-line (I'd completely forgotten). > > That's surprising; it suggests your $TERM isn't set up right outside > mutt. It's a terminfo / libslang issue. > | screen -ls output > | gets mangled, but that's screen's fault: > | There are screens on: > | [...] > | 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) > > Cool. So, working for you now? Turns out I can screen -r , so, yes. > Glad to here it. Any specific problems remaining to address? The replied flag issue. The connection sharing and password caching issues. I can live. (Actually, _I_ don't need this, as I'm happy to postpone messages when I need to switch gears. But I know of at least one user who desperately needs a new MUA but will not adopt mutt because of this missing feature.) Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Wed, Mar 31, 2010 at 11:44:35AM +1100, Cameron Simpson wrote: > On 30Mar2010 17:51, Nicolas Williams wrote: > | > That's surprising; it suggests your $TERM isn't set up right outside > | > mutt. > | > | It's a terminfo / libslang issue. > > Lucky the screen internal terminal and xterm both base off the ANSI > stuff, eh? :) > | > | screen -ls output > | > | gets mangled, but that's screen's fault: > | > | There are screens on: > | > | [...] > | > | 3820.mutt-30mar2010-11:06 Re_Foobars_Request_1 (Detached) > | > > | > Cool. So, working for you now? > | > | Turns out I can screen -r , so, yes. > > Ah. I mostly use screen through a wrapper of my own called "scr" that > numbers the listing, so I'd be going "scr 5" or whatever. I do the same (I call my wrapper rscreen), but it gets fooled by the run-on fields above. In any case, I will not use the -m option, since I don't want a whole new screen but a new window. > | > Glad to here it. Any specific problems remaining to address? > | > | The replied flag issue. > > You could be optimistic and mark it at the point you commence the > reply. Hmmm, maybe. Or I could have a script go through my sent folder and searching for the messages they reply to just to set the replied flag. > | The connection sharing and password caching > | issues. I can live. > > Connection sharing? See other posts on this thread. > | (Actually, _I_ don't need this, as I'm happy to postpone messages when I > | need to switch gears. But I know of at least one user who desperately > | needs a new MUA but will not adopt mutt because of this missing > | feature.) > > Ah. Well I know I really wanted it too, hence the script. > I never did come to grips with the postponed folder approach. Thanks for your script and usage info, Nico --
Re: FAQ: How to spawn terminal/screen to reply to messages separately?
On Tue, Mar 30, 2010 at 08:58:20PM -0400, Patrick Shanahan wrote: > You might consider looking at tmux as a replacement for screen. I find > it much more robust and the learning curve is not much. It makes some of > screen's *features* more functional such as split screen w/o using one of > the screen numbers that allow direct access (2). Tmux uses > rather than , and allows direct access to > 10 screens, > buffers, This is all completely OT, but... using is an absolute non-starter as it's an emacs-mode editing character. I've been using screen for almost two decades now. The lack of quick access to screens past 9 is somewhat annoying, but I can live with that. Same with buffers. So I doubt I'll switch, but I may give it a try sometime just to see.
Re: Wrapping on internal pager
On Sun, Apr 11, 2010 at 06:17:24PM +, Camaleón wrote: > - Image sample of failing e-mail (it will be auto-deleted in 7 days): > http://picpaste.com/20100411_mutt_pager_wrapping.png > > - Raw code sample of failing e-mail (it will be auto-deleted in 1 day): > http://pastebin.com/4t4kPSrh (For others: Camaleón has a very long line of 'o's unbroken by space. The PNG shows this flowed to fill all available columns, plus the leading continuation marker on continuations.) This is just what mutt does. I do find markers (the leading '+' on the continuation lines) to be really obnoxious, particularly when they pollute URLs, so I turn them off. IMO the flowing algorithm could use some work. Breaks should be placed at breaking white-space, and if none is available then wrap at the _last_ column, with no marker (markers should be used, if at all, only when breaking at breaking white-space). The reason for wrapping at the last column is simple: so URLs aren't broken up (so one can mouse double click + copy to copy a URL into the clipboard). Of course, breaking only at breaking white-space means that mutt has to pick breaking points carefully so that text flows reasonably well, with the least chance of long non-breaking sequences going past the wrapmargin -- the algorithm suddenly got complex. (Piping through fmt(1) is probably not a good idea.) Nico --
Re: handling List-Id header
On Mon, Apr 12, 2010 at 10:47:21AM +0200, ilf wrote: > On 04-11 20:32, Michael Elkins wrote: > > On Sat, Apr 10, 2010 at 01:38:19AM +0200, ilf wrote: > >> I would like a workaround to use Regex in 'lists' and 'subscribe', but > >> that feels dirty. Why doesn't Mutt allow 'lists'/'subscribe' to lists > >> based on the List-Id: header? > > The List-ID header is not necessarily a valid email address. All > > that the RFC requires is that it be a unique value for each list. As > > such, it's not terribly useful for figuring out where to reply. > > I never proposed using List-Id to figure out where to reply, List-Post > is the right field for that and it's being done nicely. > > But I think Mutt could display messages as from a list (in index with %L > and %Z) automatically, if a List-Id header is present. Then I would not > need lists/subscribe at all. And also match them with ~l when searching. Maybe. (I'm not sure how that would work for IMAP.) Another possibility would be to have a tool that scans a folder for list addresses and constructs list/subscribed lists accordingly. Nico --
Re: sending to a list of undisclosed recipients
On Tue, Jul 27, 2010 at 09:57:39PM +, Grant Edwards wrote: > > Instead of going through a for i in `cat users`do mutt ... $i done > > loop I could make an alias of these users, but how do I tell to hide > > the 100 users and only show up the one addressee plus a note that > > the email went to a group of undisclosed users? > > I assume you know it's not uncommon for people to route message like > that directly into the spam folder? ssh...
Re: charsets
On Tue, Jul 27, 2010 at 10:54:42PM -0600, Paul E Condon wrote: > On 20100727_155630, Kyle Wheeler wrote: > > On Tuesday, July 27 at 12:35 PM, quoth Paul E Condon: > > > 1) The short answer does not work. My copy of Mutt informs me that > > > LC_TYPE is not a recognized variable name. > > > > The line in the web page is; > Short answer: set LC_CTYPE=en_US.ISO-8859-1. > This is not sh/bash syntax or csh/tcsh syntax, but seems to be muttrc syntax LC_* are a big hammer. You shouldn't want to use that hammer. mutt is smart enough to do codeset conversions from those used in e-mails to the one used in your terminal. Forcing your terminal's codeset to match just one of those commonly used by your correspondents is not the answer. The best thing to do, if you want[*] the most possible non-ASCII characters to be displayed correctly, is to run in a Unicode locale (e.g., en_US.UTF-8) and leave the LC_* and LANG environment variables alone, and instead follow the advice already given regarding the charset-hook (see below about iconv-hook as well). If you find this all annoying, do consider that it isn't mutt's fault, not your operating system's. > > This has been posted to the list many times, but yes, the recommended > > solution is to add the following to your muttrc: > > > > charset-hook ^unknown-8bit$ windows-1252 > > charset-hook ^x-user-defined$ windows-1252 > > charset-hook ^iso-8859-1$ windows-1252 > > charset-hook ^us-ascii$ windows-1252 > > I don't, to my knowledge have windows-1252 on my system. Is this > something that is just there by default on debian, or do I need to get > it from somewhere and install it? I ask because without something more > these four lines don't fix the problem for me. The iconv(1) command can list the codesets installed on your system. For example, on Solaris I get: % iconv -l | grep 1252 CP1252 (CP1252, CP-1252, CP_1252, WINDOWS-1252, ANSI-1252, ANSI1252, 1252), % On RHEL5 I get: % iconv -l |grep 1252 CP1252// WINDOWS-1252// % If you have those, then the above ought to work, if I understand correctly, though you may also need to add an "iconv-hook". For example, if iconv -l listed CP1252 but not WINDOWS-1252, then you might want to add this to your .muttrc: charset-hook ^unknown-8bit$ windows-1252 charset-hook windows-1252 CP1252 ... As to how to install missing iconv modules, if indeed they are missing, you'll have to ask someone who knows Debian better than I. Nico [*] Even if you don't understand them, being able to copy and paste strings with characters you don't know is nice. Of course, you could consider non-ASCII an afront (er, why?), and/or a security risk. So you might want to run in non-Unicode locales, for all I know. Indeed, confusable characters do pose real security risks, but IMO this should be handled in a system-wide fashion, such as via fonts (e.g., by ensuring that confusable characters not from the languages you are fluent with, are rendered in a non-confusable manner).
Re: charsets
On Wed, Jul 28, 2010 at 12:41:37AM -0600, Paul E Condon wrote: > Thanks for tip about iconv. I do have both WINDOWS-1252 and CP1252 on my > computer. So the second line should not be needed. While composing this > email I suddenly realized that the charset names are probably case sensitive > and my WINDOWS-1252 is not going to work with windows-1252, as used in > the advice given on this list. I changed the advice magic strings to match > what Squeeze is currently programmed to expect, and IT WORKS. Problem solved > until DDs move to what appears to be the Linux community standard of mostly > lower case in charset names. Yay! On RHEL5 iconv codeset names are all upper-case, and evidently case-sensitive (the iconv_open(3) manpage doesn't say anything about case-sensitivity). On Solaris they are mixed-case, but aliases are explicitly case-insensitive (per the output of iconv -l). So mutt can't blindly up-case charset names -- it'd have to know to do it on Linux but not elsewhere. Nico --
Re: charsets
On Thu, Jul 29, 2010 at 11:32:47AM -0600, Paul E Condon wrote:
> In this, iconv-hook is described as a method of handling a 'character
> set name' that is not known to Mutt. Is there a place where I can find
> a list of the character set names that are known to the copy of Mutt
> on my machine? Where? How? Or (gently, please) why is this a silly
> question?
FWIW, the charset.c source file says that mutt's charset names come from
http://www.isi.edu/in-notes/iana/assignments/character-sets
and that only charsets for which a preferred MIME name is given are
listed.
> The recommended additions to my .muttrc appear to use a regualar
> expression for the value of 'alias'. What part of an email system
> would insert things like unknown-8bit into the headers of an email?
See RFC1428 (Transition of Internet Mail from Just-Send-8 to
8bit-SMTP/MIME). The answer is: a mail gateway handling an email sent
by a pre-MIME client. In English: someone using a very old MUA is
sending you e-mail, and you should ask them to upgrade to modern
software. Your software can at best only guess what that someone is
sending you.
> I am certain that my system is improperly configured. I want to fix
> it. I have tried many things, well beyond what I would ask you to read
> about. But nothing, as done by me, has fixed the problem(s)
If you're seeing unknown-8bit then the configuration problem isn't
yours. When someone sends you an unknown-8bit message, it could be
coded in any of a large number of codesets, and it might even be
possible to render that message without question marks in more than one
codeset, but it may make sense in only one codeset (or none, if the
message is garbage). How can your MUA (mail client) determine which
codeset, if any, to use to display unknown-8bit?
The best an MUA could do is let you tell it what codeset you think a
peer is using (possibly the MUA could try them all, and you'd pick
whichever makes sense to you), and then the MUA could keep a little
database that it uses to map {, unknown-8bit} to a codeset later
on. It's easier for you to tell your peers to use newer software.
Nico
--
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: > Syntax has been changed: -a indicates a *list* of attachment files > ending with "--". I don't recall which version was first to boast this > new syntax, but it's the problem you're seeing right now even if it's > not related to the problem you saw earlier. > > Try: > > mutt -s test -a Bild.jpg -- m...@some.org
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 04:13:16PM -0500, Will Fiveash wrote:
> On Mon, Aug 02, 2010 at 03:49:47PM -0500, Nicolas Williams wrote:
> > On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote:
> > > Syntax has been changed: -a indicates a *list* of attachment files
> > > ending with "--". I don't recall which version was first to boast this
> > > new syntax, but it's the problem you're seeing right now even if it's
> > > not related to the problem you saw earlier.
> > >
> > > Try:
> > >
> > > mutt -s test -a Bild.jpg -- m...@some.org >
> > I recommend against this use of '--'. It makes it harder to write
> > wrapper scripts that parse the same arguments using getopt/ getopts, for
> > example. Sadly, I don't have a counter-proposal, nor am I suggesting
> > this get ripped out now.
>
> On the other hand it makes:
>
> mutt -a * -- j...@foo.bar
Really? You do that? It's kinda like rm *...
> easier which I would guess is why the change was made. You do have a
> point about -- being potentially problematic. Maybe -a should work like
> it used to (only one file per -a instance) and a new flag could take a
> list of files to attach from a file given as a arg (or stdin).
Right. There's no good convention for "end of list of arguments to an
option". There's only a good convention for "end of variable argument
list" ('--'), and since this is the closest thing...
If -a was last then you could:
% mutt -s some-subject -t some-to:-addres ... -a * < body.txt
Oddly enough there's no -t argument. The To: address(es) has(have) to
be last. You can't have two argument lists terminated by dint of being
last.
Nico
--
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 10:36:05AM +0200, Christoph Kukulies wrote: > -- has special meaning in some unix command lines to provide an > escape when names starting with a "-"-sign > are concerned. (doesn't getopt use it as an escape anyway? not sure). > > mkdir -- -foo > rmdir -- -foo -- means "end of option arguments". > How about > > mutt -a * \; j...@foo.bar > > ? Lots of conventions could be established, but none that getopt/getopts would know already. For example, using '' results in no ambiguity (you can have files named ';', but not files named ''). Either way, the matter is clearly closed for the time being. Nico --
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> On 2010-08-02, Nicolas Williams wrote:
>
> > Right. There's no good convention for "end of list of arguments to an
> > option". There's only a good convention for "end of variable argument
> > list" ('--'), and since this is the closest thing...
>
> And since there _is_ a convention that '--' ends the option list, it's
> A Bad Thing(TM) to use it for something else. I think violating the
> almost universal convention about what '--' means is a terrible idea,
> but apparently we're now stuck with it.
The convention is that '--' ends the entire option list, not a list of
arguments to a single option. Therefore mutt clearly uses something
other than the existing convention.
Nico
--
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 12:45:12PM -0500, David Champion wrote:
> * On 03 Aug 2010, Nicolas Williams wrote:
> > On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> > > On 2010-08-02, Nicolas Williams wrote:
> > >
> > > > Right. There's no good convention for "end of list of arguments to an
> > > > option". There's only a good convention for "end of variable argument
> > > > list" ('--'), and since this is the closest thing...
> > >
> > > And since there _is_ a convention that '--' ends the option list, it's
> > > A Bad Thing(TM) to use it for something else. I think violating the
> > > almost universal convention about what '--' means is a terrible idea,
> > > but apparently we're now stuck with it.
> >
> > The convention is that '--' ends the entire option list, not a list of
> > arguments to a single option. Therefore mutt clearly uses something
> > other than the existing convention.
>
> Strictly speaking, no: since mutt requires the -a option to be last,
> a '--' terminating the list of arguments to -a implicitly terminates
> the option list as well. I think this may have been part of the design
> consideration.
Ah, well, if -a has to be last then you're right. (Still feels icky,
but that's just aesthetics.)
Re: Mutt - only sets delete flag but doesn't delete
Personally I like having control over when expunges happen. Use '$' to expunge (with default index key bindings). Nico --
Re: mutt - color problem
May I suggest that trimming some of the quoted material in these messages? It'd make it easier to read the thread, and maybe help out. Nico --
Re: mutt - color problem
BTW, I use screen in gnome-terminal. I notice the following: - TERM is screen-bce; - VIM works fine, handles colors; - Mutt built with S-Lang does not start unless I set TERM to xterm or xterm-color; Mutt complains that "Key sequence is too long", "SLcurses_initscr: init failed"; - If I set TERM=xterm then VIM thinks the terminal is monochrome; - If I set TERM=xterm then Mutt does produce colors; - If I set TERM=xterm-color then both, VIM and Mutt handle color. Weird, no? This is almost certainly a result of using different APIs (VIM uses curses, Mutt uses S-Lang). I believe my colleague Will F. has shown that Mutt works fine with curses (ncurses). This is all on Solaris. Nico --
Re: mutt - color problem
On Tue, Aug 31, 2010 at 02:37:48PM -0700, Chip Camden wrote: > You could probably get mutt to start with TERM=screen-bce is termcap has > an appropriate entry for it. I found that even though mutt with slang > uses terminfo, it queries termcap on startup. screen(1) does set TERMCAP in the environment... There is a termcap entry for screen, but not for screen-bce. If I add the screen-bce entry I still get the same error, as I do if I set TERM=screen. Aha! I must unset TERMCAP to make Mutt/S-Lang happy. Nico --
Re: Searching for hook to save new read mail to its particular mailbox
On Thu, Sep 09, 2010 at 06:53:07AM -0700, Michael Elkins wrote: > On Tue, Sep 07, 2010 at 12:57:51PM +0200, j...@telefonica.net wrote: > >I'm searching about a hook that will save to its mailbox all mails with > >To: list_...@server.com after had read them, I think when changing > >mailboxes. > > > >Now, I received all mails to +spoolfile but I would like to move with a > >hook the ones coming To: list_...@server.com after had read them. > > > >I have tried with save-hook, fcc-hook, but I can't find which one will > >do that move or copy. > > Mutt does not really have any automatic filtering built in. What > most people do in this situation is to use something like procmail > to filter incoming mail into separate mailboxes per email list, then > put "mailboxes +list1 +list2" in their ~/.muttrc to be informed when > each mailbox has new mail. Mutt has a wonderful regular expression language that makes it easy to write small, powerful search expressions. Searches are filters, really (see gmail). It seems like a pity that mutt doesn't have a first-class filter. Procmail is not easy to use by comparison to mutt. Sure, sure, if you're using a text-based MUA you can write procmail filters. True. But for some use cases external programs like getmail, fetchmail and procmail all fall short. For example, I've given up on fetchmail because it dropped 30K messages once (from a 100K msg folder). I've given up on getmail because it doesn't preserve message flags, so if I've an IMAP Inbox that I want to leave a few days' worth of messages at a time for accessing from multiple MUAs (say, mobiles), then I can't use getmail to later move those off the IMAP server. (No, the getmail maintainer was not interested in patches to preserve message status/flags.) If I use IMAP, can't or don't leave mail on the server, but can use neither getmail nor fetchmail then how am I to use procmail? So I use mutt as a mail fetcher. It's easy: I've a simple macro that tags all un-deleted messages and the tag-saves them to their destination (I've posted this macro before). It'd be easy to add multiple steps, with each step tagging messages matching a given filter, then tag-saving to specific folders. Well, 'easy' is relative -- easy for me, but then, I don't file e-mail (I depend on searches). Mutt could provide this off the shelf, and then it would be really easy. Seems like a shame to have a great search language that cannot also be used for writing filters. Mutt has everything it needs to replace that getmail/fetchmail/procmail mix -- only the finishing touches are missing. Nico --
Re: Searching for hook to save new read mail to its particular mailbox
On Fri, Sep 10, 2010 at 09:49:57AM +0200, j...@telefonica.net wrote: > Nico, I will search for your macro to see what can I do with regular > expressions. For your convenience: macro index , !~D^J/path/to/some/maildir/^J^J "Move all undeleted messages to maildir folders" Then use ',' to move all undeleted mail to a maildir. Change the tag-pattern to your liking, and, of course, the save-message path. Nico --
Re: How to match all theaded emails excluding the first one?
On Mon, Sep 20, 2010 at 03:38:16PM +0200, mjsseppl-m...@yahoo.de wrote: > On 10.09.20, mjsseppl-m...@yahoo.de wrote: > > On 10.09.20, Yue Wu wrote: > > > Do "H" and look at the headers and you'll see under References: > > <20100919012315.gc36...@fbsd.t60.cpu> <20100919071840.ga26...@murdoc> > > etc. > > > > "In-Reply-To:" is also used. "In-Reply-To:" is standard, while "References:" is a Usenet-ism. Good MUAs will thread based on both. Some MUAs break threading (by including neither of those two headers), so sometimes it's necessary to match replies via subject matching. Mutt supports all of this, and uses asterisks to mark mails which break threading. (MUAs could go so far as to match quoting in mail bodies, but that's really hard.) See: http://www.jwz.org/doc/threading.html Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:13:05PM -0700, Michael Elkins wrote: > Yes, this is the problem. Mutt expects to see a FETCH response for > each message the server says EXISTS. The IMAP standard requires > that no "holes" exist in the message sequence numbers, and mutt is > not prepared to handle them. Mutt could be a lot more asynchronous though. Mutt could display a page-ful of messages, filling in slots (re-drawing as necessary) as the FETCH responses come in. Right now mutt wants to enumerate a mailbox when opening it. It has to for mbox/mh/maildir folders, given their nature. But IMAP is designed to allow for listing page-fuls of messages at a time instead of enumerating folders -- the fact that mutt doesn't do this has me sad. IMAP is also designed to allow multiple concurrent requests, that is, it's designed to allow for asynchronous operation. I've looked at mutt source code, and ISTM that it'd require massive surgery to add support for using IMAP this way. Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:32:54PM -0700, Brendan Cully wrote:
> On Thursday, 23 September 2010 at 14:13, Michael Elkins wrote:
> > On Thu, Sep 23, 2010 at 10:19:28PM +0200, Michael Williams wrote:
> > >On 23 Sep 2010, at 19:17, Christian Brabandt wrote:
> > >>>4< * 3700 FETCH (UID 17146 FLAGS (\Seen) INTERNALDATE "23-Sep-2010
> > >>>09:14:57 +0100" RFC822.SIZE 2612 BODY[HEADER.FIELDS (DATE FROM SUBJECT
> > >>>TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> > >>>REPLY-TO LINES LIST-POST X-LABEL)] {404}
> > >>>4< * 3702 FETCH (UID 17148 FLAGS (\Seen) INTERNALDATE "23-Sep-2010
> > >>>14:35:54 +0100" RFC822.SIZE 20548 BODY[HEADER.FIELDS (DATE FROM SUBJECT
> > >>>TO CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> > >>>REPLY-TO LINES LIST-POST X-LABEL)] {408}
> > >>
> > >>Here is one missing.
> > >
> > >Is this the problem? Is there a workaround or is the conclusion that mutt
> > >is not compatible with Exchange 2010 IMAP's support (or Exchange 2010 is
> > >not compatible with mutt)?
> >
> > Yes, this is the problem. Mutt expects to see a FETCH response for
> > each message the server says EXISTS. The IMAP standard requires that
> > no "holes" exist in the message sequence numbers, and mutt is not
> > prepared to handle them.
>
> We might be able to work around this by creating an empty message
> marked as expunged for the holes, then running the expunge compactor
> after the command finishes. But it does seem like there's probably
> something wrong with your mailbox on the server side. It might go away
> if the exchange server administrator runs some kind of maintenance
> tool on the problematic mailbox.
That's a good idea -- we know how many messages there are, so pretend we
know them all and fill in the details as the responses come in. The
only other part of the puzzle: how to handle curses input and IMAP async
I/O? I think doing this with minimal surgery might require a thread to
poll for curses input and another to handle IMAP responses.
Nico
--
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:45:47PM -0700, Michael Elkins wrote: > The main issue is that some popular IMAP servers (gmail, exchange), > do not support the SORT extensions, so you wouldn't be able to do > the pageful-at-a-time and still have all of Mutt's current threading > capabilities. Interesting. I'd still like to open the folder and see it in the one order quickly, with the enumeration happening in the background, so that eventually I could sort it any way I like. > You are correct that major surgery would be required to change Mutt. > A few years back I wrote a patch to lazily load the message headers, > but the lack of threading support made it mostly useless. Are you referring to pthreads or mail therading? Nico --
Re: Stuck on 97% changing mailboxes
On Thu, Sep 23, 2010 at 02:58:56PM -0700, Michael Elkins wrote: > On Thu, Sep 23, 2010 at 04:52:37PM -0500, Nicolas Williams wrote: > >Are you referring to pthreads or mail therading? > > Mail threading. That's OK. I'd be happy to live with that, since eventually the folder does get fully enumerated. And if you have a server that doesn't answer some FETCHes, as in this case, it'd be a perfect workaround.
Re: Inconsisten locale language in mutt 1.5.19
On Fri, Sep 24, 2010 at 09:30:27AM -0700, Michael Elkins wrote: > On Fri, Sep 24, 2010 at 10:06:00AM +0200, Matthias Apitz wrote: > >#: commands.c:513 > >#, fuzzy > >msgid "" > >"Sort (d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p)" > >"am?: " > >msgstr "" > >"Órden > >fech(a)/d(e)/(r)ecep/a(s)unto/(p)ara/(h)ilo/(n)ada/ta(m)año/punta(j)e: " > > The problem seems to be that gettext() ignores the translation when > the 'fuzzy' keyword appears. That attribution gets added when the > gettext tools detect that the input string has been altered, and > thus is no longer sure that the translated string is correct. > > Someone who is a Spanish speaker will have to update the translation > file in order to resolve this issue. The above translation is not incorrect, except, maybe, for the "puntaje" translation of "spam" -- "puntaje" means "grade" or "mark". But also "recep" for "recv" and "nada" for "unsort" all rub me the wrong way. A better translation of "spam" is "no deseado". The English string also sports incorrect grammar: it should be "Sort by ..." There's lots of possible translations. "Órden" is a bit weird here -- "Ordernar por" (same grammatical fix as in the English version) is better, plus "Arreglo" or "Compaginación", "Recopilación", all sound better than "Órden" to me, but they're also much longer... My version, then: "Ordenar por fech(a)/d(e)/(r)ecivido/a(s)unto/(p)ara/(h)ilo/(d)esordenado/ta(m)año/(n)o-deseado:" Note that such long messages may need to be wrapped. But mutt should always assume that all such messages may need to be wrapped (the user could be on a particularly small tty). Nico --
Re: Inconsisten locale language in mutt 1.5.19
On Fri, Sep 24, 2010 at 12:38:30PM -0700, David Ellement wrote: > On 2010-09-24, Nicolas Williams wrote > > On Fri, Sep 24, 2010 at 09:30:27AM -0700, Michael Elkins wrote: > > > On Fri, Sep 24, 2010 at 10:06:00AM +0200, Matthias Apitz wrote: > > > >#: commands.c:513 > > > >#, fuzzy > > > >msgid "" > > > >"Sort > > > >(d)ate/(f)rm/(r)ecv/(s)ubj/t(o)/(t)hread/(u)nsort/si(z)e/s(c)ore/s(p)" > > > >"am?: " > > > >msgstr "" > > > >"Órden > > > >fech(a)/d(e)/(r)ecep/a(s)unto/(p)ara/(h)ilo/(n)ada/ta(m)año/punta(j)e: " > > > > > > The problem seems to be that gettext() ignores the translation when > > > the 'fuzzy' keyword appears. That attribution gets added when the > > > gettext tools detect that the input string has been altered, and > > > thus is no longer sure that the translated string is correct. > > > > The above translation is not incorrect, except, maybe, for ... > > Does it matter that the English string offers 10 options, while the > Spanish string only offers 9 options? Oops, I missed the "s(c)ore" option. Ah, so what's missing in the Spanish version is the translation for "s(p)am". I looked at what "spam" translates to in online dictionaries, and sadly there's no good word in Spanish -- "basura" is often used, but that's also the translation for "trash", which is ambiguous in this context. I'd settled for "no deseado" (unwelcome), with a dash if need be. Nico --
Re: Usage poll for mutt on Solaris
On Mon, Sep 27, 2010 at 03:56:59PM +0200, Dagobert Michelsen wrote: > Now here is the question: Would it be more likely that > all zones share the same mutt configuration or would a > typical administrator adjust each of them individually? It has never occurred to me to edit Muttrc -- so much so that I wasn't even conscious of it. It's too bad that Muttrc/Muttrc.dist aren't empty. If Muttrc/Muttrc.dist were empty (ignoring comments), then you could just not ship it and thus avoid the issue altogether. So maybe that's the right question: why is Muttrc not empty by default? Nico --
Re: setting mutt to charset UTF-8 ?
On Wed, Oct 06, 2010 at 09:52:22AM -0500, Kyle Wheeler wrote: > On Wednesday, October 6 at 04:31 PM, quoth Matthias Apitz: > >It is converted *before* it is stored into the temp file for 'vim'; I've > >checked this with truss(1) what mutt hands over to vim (see the > >marked bytes): > > [...] > > >g...@current:~> env | egrep 'LANG|LC_' > >LANG=es_ES.UTF-8 > > Presumably, that's a valid LANG on your system. Just for giggles, make > sure. Run It is, since Matthias must be using Solaris (given the reference to truss(1)), and on Solaris es_ES.UTF-8 is very much a valid locale name. Of course, that locale might not be _installed_, so the locale -a check is still a good idea. Nico --
Re: setting mutt to charset UTF-8 ? [SEC=UNCLASSIFIED]
On Wed, Oct 06, 2010 at 11:07:28PM +0800, Wilkinson, Alex wrote: > 0n Wed, Oct 06, 2010 at 10:00:27AM -0500, Nicolas Williams wrote: > > >It is, since Matthias must be using Solaris (given the reference to > >truss(1)), > > #uname -s && which truss > FreeBSD > /usr/bin/truss > > :P Ah... OK, thanks for that. I should install FreeBSD some time to catch (it's been a decade since I last used it, at least). Nico --
Re: muttjump (was: ad: muttlearn - tool for managing multiple identities)
On Mon, Nov 29, 2010 at 11:11:11AM +0100, Christian Ebert wrote: > 5) ps has no --no-heading option here on Mac OS X (BSD-like). Does it have a -o option where terminating the format list with an '=' causes no heading to be printed? It should, at least according to this: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/ps.1.html
Re: unicode
On Sun, Nov 28, 2010 at 07:50:08PM -0600, Derek Martin wrote: > On Sun, Nov 28, 2010 at 02:52:22PM -0800, Chip Camden wrote: > > inside rxvt-unicode (urxvt) v9.07 > > > > and I can't seem to get unicode characters to display properly. I have: > > > > set charset="utf-8" > > This comes up often enough that it should probably be a FAQ... > > First off, don't set charset. You shouldn't need to, and -- unless > you're doing something very funky and you really, really know what > you're doing -- having to do this means your environment is not set up > properly. Most likely, setting this manually will only work against > you. > > [...] +1 In general, using an off-the-shelf desktop on Linux/*BSD/Solaris should cause everything to be in order, particularly if you use a UTF-8 locale to begin with. When everything's in order (you have the necessary locales and fonts installed, and you're using blessed desktops / start scripts) then you will have the locale environment variables properly setup and your tools will find their fonts/renderers and codeset conversion modules and so on. Mutt too will be able to do codeset conversions and thus display foreign characters to the best of your locale's ability. If you must use a non-UTF-8 locale yet want to be able to use UTF-8 for your mutt instances (e.g., to be able to display more characters than your locale allows, or to be able send mail using UTF-8 as your locale), then you'll want to run a terminal emulator that allows you to pick an encoding: set the encoding of the terminal where you run mutt to UTF-8, make sure to change the locale env vars accordingly in that session, and start mutt. For example, gnome-terminal allows you to set the encoding on a per-tab basis. But it's better to just use a UTF-8 locale for all your sessions and work. Nico --
Re: New tool for sending HTML mail with Mutt
On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote: > Chip Camden [2010-12-08 11:01 -0800]: > >On a related topic, is there any way to get mutt to display RTL for > >certain characters? The Hebrew characters in your signature, for > >instance, are displayed LTR in my mutt, so they read backwards. > > Not directly. For that you have to use a bidi-aware terminal. I'm > running Mutt in Mlterm terminal emulator, which can handle LTR and RTL > quiet well (but not perfectly). I agree, this is a job for the rendered, which is also why you shouldn't need your plain2html program -- the web browsers displaying your email in webmail apps should handle bi-di correctly as long as they understand UTF-8. Might the webmail backend be doing something wrong? How would I know if the Hebrew text in your signature is displaying correctly? The glyphs appear to be correct. Would inserting spaces between the characters change the order in which they appear? If so, my terminal (Terminator) is not handlint bi-di correctly :( Nico --
Re: New tool for sending HTML mail with Mutt
On Thu, Dec 09, 2010 at 07:25:11PM +0200, Amit Ramon wrote:
> Nicolas Williams [2010-12-08 13:25 -0600]:
>
> >On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:
> >>Chip Camden [2010-12-08 11:01 -0800]:
> >>>On a related topic, is there any way to get mutt to display RTL for
> >>>certain characters? The Hebrew characters in your signature, for
> >>>instance, are displayed LTR in my mutt, so they read backwards.
> >>
> >>Not directly. For that you have to use a bidi-aware terminal. I'm
> >>running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
> >>quiet well (but not perfectly).
> >
> >I agree, this is a job for the rendered, which is also why you shouldn't
> >need your plain2html program -- the web browsers displaying your email
> >in webmail apps should handle bi-di correctly as long as they understand
> >UTF-8. Might the webmail backend be doing something wrong?
>
> I don't agree... web browsers are not supposed to be able to know how
> to render bidi text. For this reason there are dir tags in
> HTML. Webmail backends are also not doing it. This is not the same as
> "understand UTF-8".
I'm not too familiar with bi-di, and I can see that a dir tag does exist
for HTML. We seem to agree that terminals (which have no HTML-like
tags) are supposed to figure out how to render bi-di correctly. Looking
around a bit I see that there are three standard ways to indicate
direction changes:
- Use Unicode control characters, most of which are discouraged, except
for the right-to-left and left-to-right marks (which are for
specifying direction for weak-directional characters relative to
surrounding strong-directional characters);
- Use HTML dir attribute or bdo element;
- Use CSS rules ('direction' and 'bidi-override' props).
The last two are for HTML docs only. The first one is the only one that
works in all contexts, while markup solutions based on anything other
than Unicode require tags/attributes to be defined.
But there is a Unicode bi-di algorithm... From what I can tell,
renderers that implement it should not require marks (except for
weak-directional characters, as mentioned above).
> >How would I know if the Hebrew text in your signature is displaying
> >correctly? [...]
>
> The first Hebrew letter in my first name is "Ayn", which looks
> schematically like this:
>
> [...]
>
> In a correct appearance you should see it at the rightmost place on
> the line that has my first name, Amit, in my signature... if it
> follows the word Amit immediately after the blank space, the terminal
> does not support bidi.
Indeed, my terminal is not displaying those in right-to-left. I see
that some applications do display properly (for example, the Bluefish
editor does, but vim/gvim does not).
Nico
--
