Content-Disposition: attachment

Content-Disposition: attachment

[Per Abrahamsen]

Why are text/plain mime parts with

        Content-Disposition: attachment

shown inline by default?

Re: Content-Disposition: attachment

[David S. Goldberg]

Because the default value of mm-attachment-override-types contains text/plain.
-- 
Dave Goldberg
Post: The Mitre Corporation\MS B325\202 Burlington Rd.\Bedford, MA 01730
Phone: 781-271-3887
Email: dsg@mitre.org

Re: Content-Disposition: attachment

[Yair Friedman (Jerusalem)]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Why are text/plain mime parts with
> 
>         Content-Disposition: attachment
> 
> shown inline by default?

In article  <uln98gbmd.fsf@lanber.cam.citrix.com>
 Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:
> 
> `mm-inline-media-tests' specifies what *can* be inlined.
> `mm-inlined-types' specifies what *should* be inlined.
> `mm-automatic-display' specifies what should be inlined *initially*.
> `mm-attachment-override-types' controls *attachment* inlining.

mm-attachment-override-types's value is ("text/plain" "text/x-vcard") by
default.  This is to overcome broken mailers who send all parts as
attacments.

Hope this helps,
--
Yair Friedman.

Re: Content-Disposition: attachment

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Why are text/plain mime parts with
> 
>         Content-Disposition: attachment
> 
> shown inline by default?

If they are of type text/plain, then that is because it is overriden
by mm-attachment-override-types.  Lars promised to remove `text/plain'
from the default value of that variable, but never got around to do
that.  It is achieved by this patch:

--- mm-decode.el.orig	Mon Sep 27 18:59:14 1999
+++ mm-decode.el	Mon Sep 27 18:59:28 1999
@@ -139,7 +139,7 @@
     "message/rfc822")
   "A list of MIME types to be displayed automatically.")
 
-(defvar mm-attachment-override-types '("text/plain" "text/x-vcard")
+(defvar mm-attachment-override-types '("text/x-vcard")
   "Types that should have \"attachment\" ignored if they can be displayed inline.")
 
 (defvar mm-automatic-external-display nil

Re: Content-Disposition: attachment

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> If they are of type text/plain, then that is because it is overriden
> by mm-attachment-override-types.  Lars promised to remove `text/plain'
> from the default value of that variable, but never got around to do
> that.

How weird.  I seem to remember removing that, but perhaps I forgot to
commit it to the CVS or something.  It's gone now, though -- did you
remove it?

(I need to learn how to query the CVS to find out who did what.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Content-Disposition: attachment

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > If they are of type text/plain, then that is because it is overriden
> > by mm-attachment-override-types.  Lars promised to remove `text/plain'
> > from the default value of that variable, but never got around to do
> > that.
> 
> How weird.  I seem to remember removing that, but perhaps I forgot
> to commit it to the CVS or something.  It's gone now, though -- did
> you remove it?

Yes; eventually, I did.

> (I need to learn how to query the CVS to find out who did what.  :-)

In this case, it's documented in the ChangeLog:

1999-09-27  Hrvoje Niksic  <hniksic@srce.hr>

	* mm-decode.el (mm-attachment-override-types): Exclude text/plain.

Re: Content-Disposition: attachment

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (I need to learn how to query the CVS to find out who did what.  :-)

Maybe you could do `cvs annotate' to find out which lines are from
which version, and then you could use `cvs log' to find out who did
what in that version.

I've never used `cvs annotate', though.  So I'm not really sure what
it does.

kai
-- 
This gubblick contains many nonsklarkish English flutzpahs,
but the overall pluggandisp can be glorked from context. -- David Moser

Re: Content-Disposition: attachment

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> In this case, it's documented in the ChangeLog:
> 
> 1999-09-27  Hrvoje Niksic  <hniksic@srce.hr>
> 
> 	* mm-decode.el (mm-attachment-override-types): Exclude text/plain.

Yeah, I saw that, but I thought perhaps it was a patch from you that I 
had applied or something...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Content-Disposition: attachment

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe you could do `cvs annotate' to find out which lines are from
> which version, and then you could use `cvs log' to find out who did
> what in that version.

Ah, yes:

----------------------------
revision 5.54
date: 1999/10/27 10:43:52;  author: hniksic;  state: Exp;  lines: +1 -1
Exclude text/plain from mm-attachment-override-types.
----------------------------

Neat.

And as for "cvs annotate" (which is not mentioned in the cvs manual): 

5.46         (larsi    04-Jul-99):   "A list of MIME types to be displayed autom
atically.")
5.37         (larsi    27-Jan-99): 
5.54         (hniksic  27-Oct-99): (defvar mm-attachment-override-types '("text/
x-vcard")
5.37         (larsi    27-Jan-99):   "Types that should have \"attachment\" igno
red if they can be displayed inline.")
5.9          (larsi    11-Sep-98): 

Even cooler.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

CVS

[Per Abrahamsen]

I'd feel safer if there were some rules for cvs writes.  

For auctex, I use:

1. People can update the files they "own", but should post to the list
   when they do.

2. Updates to shared files requeres an ok from me.  Not for the
   specific code, just for the idea.

Re: CVS

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I'd feel safer if there were some rules for cvs writes.  
> 
> For auctex, I use:
> 
> 1. People can update the files they "own", but should post to the list
>    when they do.
> 
> 2. Updates to shared files requeres an ok from me.  Not for the
>    specific code, just for the idea.

Ok, these are the rules:

1. You have full responsibility for the files you "own"

2. Fix any bugs you want.  (Especially you, Shenghuo.  :-)

3. New features or major stuff should either have an OK from me before
   they are checked in, or they should be discussed here, and people here
   should think it's a good idea.  (If I really hate it, I'll back it out
   again, anyway)

4. If you're unsure, ask me or ask here before checking in

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Denys Duchier]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> 1. People can update the files they "own", but should post to the list
>    when they do.

For our own development work we have arranged for all cvs log messages
to be also forwarded to a special newsgroup.  By reading the newsgroup
it is really easy to be kept informed of what's going on.  Also it has
no expiration and thus functions as an additional very convenient
archive.  A great advantage of this set up is that you don't have to
remember to inform the others; it just happens automatically.

Cheers,

-- 
Dr. Denys Duchier			Denys.Duchier@ps.uni-sb.de
Forschungsbereich Programmiersysteme	(Programming Systems Lab)
Universitaet des Saarlandes, Geb. 45	http://www.ps.uni-sb.de/~duchier
Postfach 15 11 50			Phone: +49 681 302 5618
66041 Saarbruecken, Germany		Fax:   +49 681 302 5615

Re: CVS

[Lars Magne Ingebrigtsen]

Denys Duchier <Denys.Duchier@ps.uni-sb.de> writes:

> For our own development work we have arranged for all cvs log messages
> to be also forwarded to a special newsgroup.

We could set up a ding-cvs mailing list, and then route it to a
newsgroup on Quimby as well.  How does one make cvs mail out the log
messages?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Eric Marsden]

>>>>> "lmi" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

  lmi> We could set up a ding-cvs mailing list, and then route it to a
  lmi> newsgroup on Quimby as well. How does one make cvs mail out the
  lmi> log messages?

in CVSROOT/loginfo add a line such as

   ALL /usr/lib/cvs/contrib/log %s -m ding-cvs@quimby.org -f $CVSROOT/CVSROOT/cvs.log

-- 
Eric Marsden

Re: CVS

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ok, these are the rules:
> 
> 1. You have full responsibility for the files you "own"
> 
> 2. Fix any bugs you want.  (Especially you, Shenghuo.  :-)
> 
> 3. New features or major stuff should either have an OK from me before
>    they are checked in, or they should be discussed here, and people here
>    should think it's a good idea.  (If I really hate it, I'll back it out
>    again, anyway)
> 
> 4. If you're unsure, ask me or ask here before checking in

How about:

5. Commit patches that Lars promised to apply, but didn't find the
   time to.

That's what I did here.

Re: CVS

[Shenghuo ZHU]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic@iskon.hr> writes:

Hrvoje> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Ok, these are the rules:
>> 
>> 1. You have full responsibility for the files you "own"
>> 
>> 2. Fix any bugs you want.  (Especially you, Shenghuo.  :-)

I did so.

>> 3. New features or major stuff should either have an OK from me before
>> they are checked in, or they should be discussed here, and people here
>> should think it's a good idea.  (If I really hate it, I'll back it out
>> again, anyway)

How about a directory named `contrib/' or `utils/', where to put Gnus-
related stuff before merged to Gnus.

>> 4. If you're unsure, ask me or ask here before checking in

Hrvoje> How about:

Hrvoje> 5. Commit patches that Lars promised to apply, but didn't find the
Hrvoje>    time to.

Hrvoje> That's what I did here.

-- 
Shenghuo ZHU

Re: CVS

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@iskon.hr> writes:

> 5. Commit patches that Lars promised to apply, but didn't find the
>    time to.

That's always a good idea.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Lars Magne Ingebrigtsen]

Shenghuo ZHU <zsh@cs.rochester.edu> writes:

> >> 2. Fix any bugs you want.  (Especially you, Shenghuo.  :-)
> 
> I did so.

:-)

> How about a directory named `contrib/' or `utils/', where to put Gnus-
> related stuff before merged to Gnus.

I've now added that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Lars Magne Ingebrigtsen]

Eric Marsden <emarsden@mail.dotcom.fr> writes:

>   lmi> We could set up a ding-cvs mailing list, and then route it to a
>   lmi> newsgroup on Quimby as well. How does one make cvs mail out the
>   lmi> log messages?
> 
> in CVSROOT/loginfo add a line such as
> 
>    ALL /usr/lib/cvs/contrib/log %s -m ding-cvs@quimby.org -f $CVSROOT/CVSROOT/cvs.log

Ok.  Someone had a script that would make the logs look more pretty?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ok.  Someone had a script that would make the logs look more pretty?  

Yeah, sorry, got distracted by LISA.  Here it is.  See the stuff marked
CHANGETHIS that should be customized for your setup.  The code that
replaces repository paths with module names won't work for particularly
complex modules.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>


#!/usr/bin/perl
$ID = q$Id: cvslog,v 1.11 1999/11/11 06:38:06 eagle Exp $;
#
# cvslog -- Mail a CVS log message to a given address.
#
# Written by Russ Allbery <rra@stanford.edu>
# Copyright 1998, 1999 Board of Trustees, Leland Stanford Jr. University
#
# This program is free software; you can redistribute it and/or modify it
# under the same terms as Perl itself.
#
# This program is designed to run from CVS's loginfo administrative file and
# takes a log message, massaging it and mailing it to the address given on
# the command line.  It's a modified version of the log script that comes
# with CVS, but tries to do less (it doesn't do cvs status).
#
# It should be run from loginfo with something like:
#
#       ^leland         $CVSROOT/CVSROOT/cvslog %s
#       ^leland/dbmodel $CVSROOT/CVSROOT/cvslog -a ls-dbmodel@lists %s
#
# Note that it mails everything to the address configured at the top of this
# file in addition to any other addresses given on the command line with -a.

# Mail all reports to this address.
$COMMIT = 'cvs-commits@example.com';  # CHANGETHIS

# Add this string to the beginning of the subject header of each message.
$PREFIX = 'CVS update of ';

# The path to the repository.
($REPOSITORY) = ($0 =~ m%^(.*)/CVSROOT/cvslog$%);
$REPOSITORY ||= '/full/path/to/repository';  # CHANGETHIS

require 5.003;

use POSIX qw(strftime);

use strict;
use vars qw($COMMIT $ID $PREFIX $REPOSITORY);

# Clean up $0 for errors.
$0 =~ s%^.*/%%;

# Grab the address to mail this report to.
my $address;
if ($ARGV[0] eq '-a') {
    shift;
    $address = shift or die "$0: -a given but no address specified\n";
}

# The next arguments are from %s; first the relative path in the repository
# and then the list of files modified.
my @files = split (' ', shift);
my $module = shift @files or die "$0: no module specified\n";
if ("@files" eq '- New directory') {
    @files = ('[new]');
} elsif ("@files" eq '- Imported sources') {
    @files = ('[import]');
} elsif (!@files) {
    die "$0: no files specified\n";
}

# Try to map the relative path to a module name.  We do this by looking in
# the modules file, finding the last "word" on each line, making sure it
# contains a / (and is therefore assumed to be a directory), and seeing if
# it's a prefix of the module path.
if (open (MODULES, "$REPOSITORY/CVSROOT/modules")) {
    while (<MODULES>) {
        next if /^\s*\#/;
        next if /^\s*$/;
        my ($name, @rest) = split;
        my $path = pop @rest;
        next unless ($path =~ m%/%);
        if ($module =~ s%^$path(\Z|/)%%) {
            $module = '/' . $module if $module;
            $module = "<$name>$module";
            last;
        }
    }
    close MODULES;
} else {
    warn "$0: can't open $REPOSITORY/CVSROOT/modules: $!\n";
}

# Figure out who is doing the update.
my $user = (getpwuid $<)[0] || $<;

# Decide how to report the files modified.  Try to keep the Subject under 60
# characters.
my $length = 56 - length ($PREFIX) - length ($module);
if ($length < 8) { $length = 8 }
my $files;
if (@files == 1 && $files[0] =~ /^\[\S+\]$/) {
    $files = "@files";
} elsif (length ("@files") > $length) {
    $files = '(' . @files . (@files > 1 ? " files" : " file") . ')';
} else {
    $files = "(@files)";
}

# The first line of the log message will be "Update of ..."; grab the path.
my $path = <STDIN>;
$path =~ s/^Update of //;
$path =~ s/\s*$//;

# Now comes the path to the local working directory.  Grab it and clean it
# up, and then ignore the next blank line.
$_ = <STDIN>;
my ($local) = /directory (\S+)/;
$local =~ s/^([^.]+)\.example\.com:/$1:/i;  # CHANGETHIS
$local =~ s/\s*$//;
<STDIN>;

# If the paths are too long, trim them.
while (length ($path) > 69) {
    $path =~ s%^\.\.\.%%;
    last unless $path =~ s%^/[^/]+%...%;
}
while (length ($local) > 69) {
    $local =~ s%^([\w.-]+:)\.\.\.%$1%;
    last unless $local =~ s%^([\w.-]+:)/[^/]+%$1...%;
}

# Build the headers (mail and body).
my (@header, @output);
my $date = strftime ('%A, %B %e, %Y @ %T', localtime time);
$date =~ s/  / /;
if ($address) {
    push (@header, "To: $address\n", "Cc: $COMMIT\n");
} else {
    push (@header, "To: $COMMIT\n");
}
push (@header, <<"EOH");

    Date: $date
  Author: $user
EOH
push (@output, "Update of $path\n", "     from $local\n", "\n") if @files;

# Extract the file lists and tag.  We assume that all files will be
# committed with the same tag; probably not the best assumption, but it
# seems workable.
my ($tag, @added, @modified, @removed, $current);
while (<STDIN>) {
    last if /^Log Message/;
    $tag = $1, next if /^\s*Tag: (\S+)\s*$/;
    if    (/^Added Files:\s*$/)    { $current = \@added      }
    elsif (/^Modified Files:\s*$/) { $current = \@modified   }
    elsif (/^Removed Files:\s*$/)  { $current = \@removed    }
    else                           { push (@$current, split) }
}

# Generate file lists, wrapped at 74 columns, with the right prefix for what
# type of file they are.
sub wrap {
    my ($prefix, @files) = @_;
    local $_ = "@files";
    my $output = '';
    while (length > 64) {
        if (s/^(.{0,64})\s+// || s/^(\S+)//) {
            $output .= (' ' x 10) . $1 . "\n";
        } else {
            last;
        }
    }
    $output .= (' ' x 10) . $_;
    $output =~ s/\s*$/\n/;
    $prefix = (' ' x (8 - length ($prefix))) . $prefix;
    $output =~ s/^ {10}/$prefix: /;
    $output;
}
push (@output, wrap ('Added',    @added))    if @added;
push (@output, wrap ('Modified', @modified)) if @modified;
push (@output, wrap ('Removed',  @removed))  if @removed;

# Now construct the subject line, since we know the tag (if any).  Only put
# the tag in the Subject header if it isn't a version number.
if ($tag && $tag =~ /[^\d.]/) {
    unshift (@header, "Subject: $PREFIX$tag $module $files\n");
} else {
    unshift (@header, "Subject: $PREFIX$module $files\n");
}
push (@header, "     Tag: $tag\n") if $tag;
unshift (@output, "\n") if @files;
unshift (@output, @header);

# Open our mail program.
open (MAIL, '| /usr/lib/sendmail -t -oi -oem')
    or die "$0: cannot fork sendmail: $!\n";

# Now, print out the output so far and the log message.
print MAIL (@output, "\n");
print MAIL while <STDIN>;

# Make sure sending mail succeeded.
close MAIL;
unless ($? == 0) { die "$0: sendmail exit status " . ($? >> 8) . "\n" }

Re: CVS

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> Yeah, sorry, got distracted by LISA.  Here it is.  See the stuff marked
> CHANGETHIS that should be customized for your setup.  The code that
> replaces repository paths with module names won't work for particularly
> complex modules.

I don't seem to have any "modules" file in CVSROOT, so, er, like.

Anyway, the newsgroup is called gnus.cvslog, and it's on
quimby.gnus.org.  The messages look neat:

--------
    Date: Friday, November 12, 1999 @ 07:11:34
  Author: cvs

Update of /usr/local/cvsroot/gnus/lisp
     from quimby:/tmp/cvs-serv22273/lisp

Modified: nnslashdot.el nnultimate.el

Final test
--------

But that "Author" -- will all these come from "cvs", or will the CVS
user names be used?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I don't seem to have any "modules" file in CVSROOT, so, er, like.

For a single-project CVS repository, that's not as useful; you could
probably comment that part out.

> But that "Author" -- will all these come from "cvs", or will the CVS
> user names be used?

If you're using pserver, it'll always be cvs.  With ssh or the like, it
can hunt up the actual username, but unfortunately CVS doesn't pass its
internal usernames to loginfo programs, so far as I know.  So that's just
from getuid.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: CVS

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> > I don't seem to have any "modules" file in CVSROOT, so, er, like.
> 
> For a single-project CVS repository, that's not as useful; you could
> probably comment that part out.

Ok.

> > But that "Author" -- will all these come from "cvs", or will the CVS
> > user names be used?
> 
> If you're using pserver, it'll always be cvs.  With ssh or the like, it
> can hunt up the actual username, but unfortunately CVS doesn't pass its
> internal usernames to loginfo programs, so far as I know.  So that's just
> from getuid.

When I say "cvs log <some-file.el>, I get stuff like:

revision 5.54
date: 1999/10/27 10:43:52;  author: hniksic;  state: Exp;  lines: +1 -1
Exclude text/plain from mm-attachment-override-types.

Could the author be picked out from that, I wonder?  Does anybody have 
code for doing that?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: CVS

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> When I say "cvs log <some-file.el>, I get stuff like:

> revision 5.54
> date: 1999/10/27 10:43:52;  author: hniksic;  state: Exp;  lines: +1 -1
> Exclude text/plain from mm-attachment-override-types.

> Could the author be picked out from that, I wonder?  Does anybody have
> code for doing that?

Ooo, good point.  Actually, the loginfo syntax lets you get the version
number of the new commit, and armed with the version number and the tag
you can pull the user out of the RCS file directly without much work.
That may be an easier parse than cvs log, and the latter would require
keeping a checked-out copy somewhere to run cvs log against (there are
also some annoying locking issues with running CVS commands from loginfo,
but they're dealable-with).

The trick is to make sure to pull the correct user in the case of a commit
to a branch.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: CVS

[Sudish Joseph]

Russ Allbery writes:
> Ooo, good point.  Actually, the loginfo syntax lets you get the version
> number of the new commit, and armed with the version number and the tag
> you can pull the user out of the RCS file directly without much work.
> That may be an easier parse than cvs log, and the latter would require
> keeping a checked-out copy somewhere to run cvs log against (there are
> also some annoying locking issues with running CVS commands from loginfo,
> but they're dealable-with).

> The trick is to make sure to pull the correct user in the case of a commit
> to a branch.

If you use the patch at <URL:http://www.cyclic.com/cvs/dev-user.txt>,
you can use "$CVS_USER || $USER" (or something to that effect,
depending upon your script) to get at the pserver user name.

As you mention, the locking issues in getting at the cvs log info from 
a loginfo script can be onerous to work around -- the patch works
around that problem, fwiw.

-- 
Sudish Joseph                                          MindSpring Enterprises