Re: slrn-style header-coloration still not in mutt
On 1999-11-03 22:08:12 -0500, Russell Hoover wrote: > Forgive me if something more complicated is involved (I don't know > much about C-language coding, though clearly it's time to learn), > but this would seem to be another no-brainer -- a question of > looking at how it's done in slrn and copying that code, perhaps > with some minor modifications, into mutt. While I don't know slrn's code for this, a proper approach to add something along these lines to mutt would require some new control sequences to be added to some format strings - remember, with mutt, the index display is freely configurable. Additionally, this may mix very badly with the pattern-dependent index coloring. However, please note that you are welcome to figure out a clean approach and submit a patch. Remember, mutt is free software. -- http://www.guug.de/~roessler/
Re: read only /var/spool/mail/(user)
Rejo Zenger <[EMAIL PROTECTED]> wrote on Thu, 04 Nov 1999: > >-rw-rw 1 paul mail 422603 Oct 23 12:16 /var/spool/mail/paul > -^^-- > > Eeeuh... i'm not sure, but those persissions don't look that good at > all. Now any user in the group mail could read and write to this > mailbox and i guess only user paul is supposed do so. That's a normal setup. mail is not a user group. Any users should not belong to that group normally, only setgid programs which then get access to read/write files in the mail spool dir. Of course, YMMV, but there's nothing unusual about those permissions themselves. 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 / Many people quit looking for work when they find a job.
Clutter & Contention
Hi all, Two more quibbles from an elm diehard who's made the plunge. 1) One nice thing about elm was that the screen was not so "busy". Altho the screen was horizontally full, which is undeniably functional, there was white space top and bottom. Mutt OTOH tries to cram as many messages as possible into the display, creating a display that is vertically full-to-bursting. Any chance of a configuration variable that would offer control over this ? Or maybe even a source patch ? (If software is an artifact of the times in which it was written, then I guess elm was written in a time when the average mailbox was not so overwhelmed ;-) 2) If you suspend elm (^z) and then some time later OOPS accidently start another instance, the second instance detects the temp file that belongs to the first instance and refuses to start. Mutt has no such qualms, and some point I get a message that the mailbox has changed, which makes me queasy about the possibility of file corrup- tion. Is this by design, or could it be a problem with file locking ? thanks to all, fred baube -- F.Baube(tm)* "Geese, I'm led to understand, make G'town U. MSFS '88 * excellent watchdogs. Which is good [EMAIL PROTECTED] * because Rottweillers make lousy poultry." +358 (40) 737 6934 * http://www.brunching.com/ratings/ #include *rate-farmanimals.html
Re: Clutter & Contention
F.Baubetm" <[EMAIL PROTECTED]> wrote on Thu, 04 Nov 1999: > Any chance of a configuration variable that would offer control > over this ? Or maybe even a source patch ? There's a patch called "blank-line.patch" at http://www.murkworks.to/blank-line.patch, it was linked from the mutt.org links page. It may or may not do what you want, there's no documentation... > Mutt has > no such qualms, and some point I get a message that the mailbox has > changed, which makes me queasy about the possibility of file corrup- > tion. Is this by design, or could it be a problem with file locking ? It's indeed a feature, not a bug. Mutt tries it best to keep itself in synch of mail folders are edited by something else. If you know you're browsing the same mail folder from two instances, the % key is handy (toggles write folder on exit off/on). If you don't write the changes out then there's nothing to synch for the other instance of Mutt. 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 / I don't want the whole world, I just want your half.
Classifying nested quotes
The algorithm of classifying quotes in mutt's pager is really
interesting, but sometimes it gives an unexpected result (to those who
do not know the algorithm used ;). For instance, if only second level
(or deeper) quotes are visible on screen initially, they are highlighted
like first level quotes. After scrolling down they suddenly change
their color when lower level quotes become visible. I had thought this
was a bug in mutt before I started studying the code.
There are also other questionable situations, like this:
somebody wrote this:
> me> said this
> me> said this
> yes, I agree
another one wrote that:
> > that
> no, I don't agree
third one wrote:
> > > > > > > > send me money
> me too!
Lines beginning with "> me>" and with "> >" are in the same level, but
they will be colored differently. And the one "> > > ..." is quite
deeply nested, but, as there are not all possible prefixes, it will be
classified as level three (actually, four, because "> >" already got
level three as it is different from level-two prefix "> me>").
This behavior may be useful to some (even if not intuitive from the
description in the manual), but class shifting is disturbing (to say the
least).
An alternative approach would be to use quote_regexp to identify
individual quoting levels, like this:
set quote_regexp = "[ ]?[a-zA-Z]{0,2}[ ]?[>]"
and determine the level of quoting by matching this pattern repeatedly
at the beginning of the line.
This way quoting levels can be specified strictly with an regexp and
there is no more need to store prefix trees in memory.
Are there important shortcomings of this approach? Any clever
quote_regexp hacks that can be implemented with current algorithm but
not with the alternative? Or maybe someone just loves the current
behavior and would hate to have another?
(Of course, there could be an option, e.g. smart_quote_parsing).
I think I'll try to implement this alternative unless someone more
familiar with the source likes this idea. Or someone suggests of a way
to force mutt preparse the whole message (i.e. construct the full quote
prefix tree) before displaying it, to avoid `class shifting' problem.
Maybe this should have been sent to mutt-dev?
Best Regards,
Marius Gedminas
--
Westheimer's Discovery:
A couple of months in the laboratory can
frequently save a couple of hours in the library.
Re: "User-Agent" header still not in stable branch
Russell Hoover [[EMAIL PROTECTED]] wrote: > Since the "User-Agent" header is now the RFC-defined standard (and not just > "window-dressing"), could we please finally have it replace the "X-Mailer" > header by default in the next stable, publicly-released version of mutt? > > "User-Agent" appears to have replaced "X-Mailer" in the last several > development versions, but for some reason hasn't made it yet to the stable > branch. > > I should think this would be a no-brainer -- the code is already there. > It just has to be copied from the latest development version, no? If you're so concerned, and you're sure it's a no-brainer, why don't you just fix it and submit the patch? -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- "If Microsoft can change and compete on quality, I've won." -- L. Torvalds PGP signature
Re: "User-Agent" header still not in stable branch
Jeremy Blosser <[EMAIL PROTECTED]> wrote on Thu, 04 Nov 1999:
> If you're so concerned, and you're sure it's a no-brainer, why don't you
> just fix it and submit the patch?
I'd like to see this happen too, so here you go (patch attached).
What's the procedure for submitting a patch to the developers? I have
no idea what's the status of the last patch I wrote and sent to
mutt-dev.
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 /
ERROR! CAT reader seems to be conflicting with the mouse.
diff -ur mutt-1.0.orig/acconfig.h mutt-1.0/acconfig.h
--- mutt-1.0.orig/acconfig.hThu Sep 2 19:28:42 1999
+++ mutt-1.0/acconfig.h Thu Nov 4 16:58:06 1999
@@ -17,8 +17,8 @@
/* Does your version of PGP support the PGPPASSFD environment variable? */
#define HAVE_PGPPASSFD
-/* Disable the X-Mailer header? */
-#undef NO_XMAILER
+/* Disable the User-Agent header? */
+#undef NO_USERAGENT
/* What is your domain name? */
#undef DOMAIN
diff -ur mutt-1.0.orig/sendlib.c mutt-1.0/sendlib.c
--- mutt-1.0.orig/sendlib.c Tue Sep 28 19:44:30 1999
+++ mutt-1.0/sendlib.c Thu Nov 4 16:58:38 1999
@@ -1346,11 +1346,11 @@
mutt_write_mime_header (attach, fp);
}
-#ifndef NO_XMAILER
+#ifndef NO_USERAGENT
if (mode == 0)
{
/* Add a vanity header */
-fprintf (fp, "X-Mailer: Mutt %s\n", MUTT_VERSION);
+fprintf (fp, "User-Agent: Mutt %s\n", MUTT_VERSION);
}
#endif
mailcap entry for attachments of application/x-binary
hi, I got a mail with Content-Type: binary header. But the contents of this mail is text/plain. The only way I can view this mail is press 'v' and pipe the message to less. pressing 'v' shows the message as 1 [applica/x-binary, 7bit, 58K] Is there some other solution for this like some mailcap entries or something like that? An example of such a mail is the linux-kernel digest. Thanks in advance, Raju - Get free email from CNN Sports Illustrated at http://email.cnnsi.com/
Re: slrn-style header-coloration still not in mutt
On Thu 11/04/99 at 11:00 AM +0100, Thomas Roessler <[EMAIL PROTECTED]> wrote: > While I don't know slrn's code for this, a proper approach to add > something along these lines to mutt would require some new control > sequences to be added to some format strings - Maybe not -- I don't know the slrn code for it either, but the way you do the setup for it in slrnrc is, for example: color header_name cyan black % "From:", "Date:" etc at top of articles. color headers yellow black % The *value* of the article headers. (The percent sign being, in the slrnrc, the comment-character, not a control-sequence prefix.) > remember, with mutt, the index display is freely configurable. Actually the headers I was referring to are the ones (From, Date, Subject, To, etc), in the pager. > Additionally, this may mix very badly with the pattern-dependent index > coloring. But not if it's the headers in the pager only that your doing it for, right? -- // [EMAIL PROTECTED] //
Re: "User-Agent" header still not in stable branch
Mikko Hänninen <[EMAIL PROTECTED]> wrote: > > +fprintf (fp, "User-Agent: Mutt %s\n", MUTT_VERSION); Is this the right format for the User-Agent header? I thought it was supposed to be "agent-name/version-num". Something like this: User-Agent: Mutt/0.96.6i -- 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: viewing html
Rüdiger Kuhlmann <[EMAIL PROTECTED]> wrote: > > > > > text/html; /usr/bin/lynx -dump -force_html %s; \ > > > > copiousoutput; nametemplate=%s.html > > Maybe because you tell lynx to read the file %s while telling mutt to > write it to %s.html? If that's really what's going on, then I contend that Mutt is broken. Mutt should use the "nametemplate" to come up with a reasonable name for its temporary file, and then pass the name of that temp file as the "%s" argument in the command string. -- 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: Saving files
Caglar Girit <[EMAIL PROTECTED]> wrote:
>
> I want some of the email that I read to remain in the spool until I
> decide to either delete or save it.
So, don't move them out of the spool. "set move=no" ought to do that.
> Currently, when I press 's' to save, it only saves the selected
> message and prompts me.
Mutt has a tag-prefix command (";" by default) which causes the
following command to apply to all tagged messages. So, if you press
"s", the current message is saved. If you press ";s", then all tagged
messages will be saved.
> In my folders, I want all read messages to be deleted when I exit the
> folder.
So, press the "d" key as you read them, and they will be marked for
deletion as you go through them. Simple.
> Also, how do I exit the folder without having to change folders to
> /var/spool/mail/{$USER}?
If you want to "exit" a folder, you need to be "going" someplace else.
You either (c)hange to another folder, or you (q)uit Mutt entirely.
Your choice.
By the way, you don't have to type "/var/spool/mail/$USER", you can
simply give the shortcut "!" instead.
> Also, I want to save copies of all outgoing mail to a 'saved' folder.
set copy=yes
set record=+saved
> Can someone help me do all of these things?
You tell me. :)
--
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: viewing html
On Thu, 4 Nov 1999, David DeSimone wrote: > If that's really what's going on, then I contend that Mutt is broken. > Mutt should use the "nametemplate" to come up with a reasonable name for > its temporary file, and then pass the name of that temp file as the "%s" > argument in the command string. Well, since my error message is coming back from metamail, it would seem that somehow it is being invoked. It shouldn't be. Mike
Re: slrn-style header-coloration still not in mutt
On Wed 11/03/99 at 10:08 PM -0500, I <[EMAIL PROTECTED]> wrote: > Every so often on mutt-users, someone asks for slrn-style header-coloration > > (where the name of the header -- everything to the left of the colon -- > can be defined as one color, and the value of the header -- to the right > of the colon -- as another color). > Can't this be put on the agenda for one of the next versions of mutt? After thinking about it a bit, I'm not so sure this is the best idea after all for the pager-headers, since it would make it hard to have (as is currently the case) an entire header line appear in one color to distinguish it from the others (for example to have the "Subject:" line stand out in its own color from the rest of the headers. You can pattern-match on an "X-" header, for example, or on "From:", "Subject:" etc, but I don't know how you'd be able to match on or define a color for the *value* of a header (the text to the right of the colon), since you don't know what it's going to be. The way mutt handles this now is preferable, I think, to slrn's article-header coloring, which is less flexible. -- // [EMAIL PROTECTED] //
