mm-default-directory not honoured

mm-default-directory not honoured

[Adrian Lanz]

Hi

Since the last update of emacs_snapshot on debian/sid
gnus-mime-save-part does not honour the mm-default-directory set in
.gnus.el.

Exporting/saving an attachment (mime part), by moving the cursor over
the attachment (link) in the article buffer, and pressing "o" results in
saving the mime part in the (default?) directory ~/ (in my case), while
it has been directory mm-default-directory in earlier versions of gnus.

I consider the new behaviour a bug. Documentation says: The default
directory where mm will save files.  If not set, `default-directory'
will be used.

Thanks, Adrian.


GNU Emacs 24.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1) of
2010-10-01 on elegiac, modified by Debian

Gnus v5.13

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

> Since the last update of emacs_snapshot on debian/sid
> gnus-mime-save-part does not honour the mm-default-directory set in
> .gnus.el.

The code is:

    (setq file
          (read-file-name (or prompt
			      (format "Save MIME part to (default %s): "
				      (or filename "")))
                          (or mm-default-directory default-directory)
			  (or filename "")))

And it works for me.  Could the snapshot be old?
                          
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: mm-default-directory not honoured

[Adrian Lanz]

>>>>> On Tue, 05 Oct 2010 19:04:15 +0200
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    > Adrian Lanz <lanz@wsl.ch> writes:
    >> Since the last update of emacs_snapshot on debian/sid
    >> gnus-mime-save-part does not honour the mm-default-directory set
    >> in .gnus.el.

    > The code is:

    >     (setq file
    >           (read-file-name (or prompt
    > 			      (format "Save MIME part to (default %s): "
    > 				      (or filename "")))
    >                           (or mm-default-directory
    >                           default-directory)
    > 			  (or filename "")))

    > And it works for me.  Could the snapshot be old?

    
Don't think so. I have the snapshots of 01-OCT-2010 on two different
machines (32 Bit and 64 Bit). Same effect on both mchines.

If I instrument mm-save-part for debugging, the above function returns
the filename alone (without directory path). The function call is
(assuming mm-default-directory is "/my-dir/")

(read-file-name "save MIME part to (default foo.bar): " "/my-dir/"
"foo.bar")

and the variable file is "foo.bar". Shouldn't variable file be
"/my-dir/foo.bar"?


Afterwards in line

    (setq mm-default-directory (file-name-directory file))

(file-name-directory file) returns nil and mm-default-directory is set
to nil. Does it really work for you as expected?


BTW, now that I have a look into this code: as a user I never liked the
effect of this line (setq mm-default-directory (file-name-directory
file)).

I think, the user configured default place for saving mime parts
(mm-default-directory) should not be changed on the fly...


In my daily work, mm-default-directory is really the (quick and dirty
and fast and first) place, where I save all my attachments when reading
through the new mail. Later, when I start or continue to work on some
project, I get/copy/move the relevant documents from the
mm-default-directory into the project's directory tree.


From time to time, I save an attachments directly to some other place,
because I have time to do so, and/or because I want the file (only) at
that specific place. But with the above code, the default directory is
lost and all the following attachments get saved to this new
place. Often, I do not realise this immediately. I am getting upset a
couple of days or hours later, when I do not find the documents at the
usual place (mm-default-directory).

Of course, the implemented behaviour can be considered a feature. For
me, it would be nice to have a switch. Something like
"mm-default-directory-fixed" and t would mean do not change
mm-default-directory and nil would indicate the current implementation.

Cheers, Adrian.

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

> Afterwards in line
>
>     (setq mm-default-directory (file-name-directory file))
>
> (file-name-directory file) returns nil and mm-default-directory is set
> to nil. Does it really work for you as expected?

Ah, right.  So it works the first time, but not the second.  I've now
fixed this.

> BTW, now that I have a look into this code: as a user I never liked the
> effect of this line (setq mm-default-directory (file-name-directory
> file)).

Yeah, it does seem a bit annoying.  But, on the other hand, if you're
saving five attachments and want them all to go to the same directory,
it's quite convenient.  So I don't know...

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

Re: mm-default-directory not honoured

[Adrian Lanz]

>>>>> On Thu, 07 Oct 2010 21:33:53 +0200
>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> Adrian Lanz <lanz@wsl.ch> writes:
    >> Afterwards in line
    >> 
    >> (setq mm-default-directory (file-name-directory file))
    >> 
    >> (file-name-directory file) returns nil and mm-default-directory
    >> is set to nil. Does it really work for you as expected?

    LMI> Ah, right.  So it works the first time, but not the second.
    LMI> I've now fixed this.
    

Works, I confirme. Many thanks.

    >> BTW, now that I have a look into this code: as a user I never
    >> liked the effect of this line (setq mm-default-directory
    >> (file-name-directory file)).

    LMI> Yeah, it does seem a bit annoying.  But, on the other hand, if
    LMI> you're saving five attachments and want them all to go to the
    LMI> same directory, it's quite convenient.  So I don't know...
    

Yes. I see the point. It depends how (most) people are handling mail
attachements.

I keep all attachments in a single directory: for me, it is a quick and
dirty export of the files while going throug my new mail. BTW a new
feature for the wishlist: I would even like, I think, Gnus providing an
(optional) mechanism, which would automatically extract mail attachments
(by type?) from all new mail messages (incoming mails or, better, while
reading an unread message?).


Afterwards I filter (copy/move) documents (attachments) by hand into
thematic directories (projects). Of course, one could imagine a
splitting of mail attachments into directories the Gnus (magic) way,
like it's done with mail messages (based on mail headers). But this
might be a little bit exagerated? Any need for that? (I vote for it,
without high priority.)

Best, Adrian.

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

> I keep all attachments in a single directory: for me, it is a quick and
> dirty export of the files while going throug my new mail. BTW a new
> feature for the wishlist: I would even like, I think, Gnus providing an
> (optional) mechanism, which would automatically extract mail attachments
> (by type?) from all new mail messages (incoming mails or, better, while
> reading an unread message?).

`X m' does that, I think.

> Afterwards I filter (copy/move) documents (attachments) by hand into
> thematic directories (projects). Of course, one could imagine a
> splitting of mail attachments into directories the Gnus (magic) way,
> like it's done with mail messages (based on mail headers). But this
> might be a little bit exagerated? Any need for that? (I vote for it,
> without high priority.)

It sounds like it would make sense in some use cases, but I think this
probably wouldn't be used much.

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

Re: mm-default-directory not honoured

[Adrian Lanz]

>>>>> On Thu, 07 Oct 2010 21:33:53 +0200
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    > Adrian Lanz <lanz@wsl.ch> writes:
    >> Afterwards in line
    >> 
    >> (setq mm-default-directory (file-name-directory file))
    >> 
    >> (file-name-directory file) returns nil and mm-default-directory
    >> is set to nil. Does it really work for you as expected?

    > Ah, right.  So it works the first time, but not the second.  I've
    > now fixed this.

Thanks. But, there is still a change to the old behaviour, I am quite
sure. Or, if not, I propose the following change.

The user should be prompted for "<directory>/<filename>", not just
"<directory/". The reason is, that this way a user can easily change the
filename, if needed, not only the directory name.

I get quite often revised versions of documents under the same filename,
for instance, or documents with the same filename from different users
(minutes.doc, index.html, screen.png, calendar.ics, ...), which I would
like to change easily (and after mm-file-name-rewrite-functions has been
applied). What do you think?

Best, Adrian.

 

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

> The user should be prompted for "<directory>/<filename>", not just
> "<directory/". The reason is, that this way a user can easily change the
> filename, if needed, not only the directory name.

I may be misremembering how this works, but doesn't `M-p' give you the
directory and file name so that you can edit it?  I think that's how all
these file prompting commands are supposed to work these days...

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

Re: mm-default-directory not honoured

[Adrian Lanz]

>>>>> On Sat, 30 Oct 2010 01:01:01 +0200
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    > Adrian Lanz <lanz@wsl.ch> writes:
    >> The user should be prompted for "<directory>/<filename>", not
    >> just "<directory/". The reason is, that this way a user can
    >> easily change the filename, if needed, not only the directory
    >> name.

    > I may be misremembering how this works, but doesn't `M-p' give you
    > the directory and file name so that you can edit it?  I think
    > that's how all these file prompting commands are supposed to work
    > these days...

That's right, a lot is improving these days... That's great. Many thanks
for this ,and for this hint. But, it seems, M-p prompts for previously
used filenames, not for the (current default) name of the file in which
the MIME part should be copied.

My work case is the following: I often just want to slightly modify the
name of incoming mail attachments. Say, some draft document is sent
out. Revisions come in from many people, all (most) under the original
file name of the draft. In such cases, I used to add initials or numbers
(or whatever) to filenames to keep the different versions of the
modified document in the same directory. Until recently, I think, Gnus
did prompt for the <directory>/<filename> and it was easy to change both
by just editing the string in the mode line. In general, this option is
(was) useful in cases where the default filename needs to be (slightly)
changed (based on the default filename).

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

>     > I may be misremembering how this works, but doesn't `M-p' give you
>     > the directory and file name so that you can edit it?  I think
>     > that's how all these file prompting commands are supposed to work
>     > these days...
>
> That's right, a lot is improving these days... That's great. Many thanks
> for this ,and for this hint. But, it seems, M-p prompts for previously
> used filenames, not for the (current default) name of the file in which
> the MIME part should be copied.

Sorry, I meant `M-n'.  That's the convention -- the default is placed in
the "next" slot.

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

Re: mm-default-directory not honoured

[Adrian Lanz]

>>>>> On Mon, 01 Nov 2010 12:54:16 +0100
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    > Adrian Lanz <lanz@wsl.ch> writes:
    >> > I may be misremembering how this works, but doesn't `M-p' give
    >> > you the directory and file name so that you can edit it?  I
    >> > think that's how all these file prompting commands are supposed
    >> > to work these days...
    >> 
    >> That's right, a lot is improving these days... That's great. Many
    >> thanks for this ,and for this hint. But, it seems, M-p prompts
    >> for previously used filenames, not for the (current default) name
    >> of the file in which the MIME part should be copied.

    > Sorry, I meant `M-n'.  That's the convention -- the default is
    > placed in the "next" slot.

Great! Sorry for the noise. I can not (easily) change the directory name
AND the filename, but I might find out... Many thanks, Adrian.

Re: mm-default-directory not honoured

[Lars Magne Ingebrigtsen]

Adrian Lanz <lanz@wsl.ch> writes:

> Great! Sorry for the noise. I can not (easily) change the directory name
> AND the filename, but I might find out...

Ah, right.  I've now fixed this, and `M-n' now works more sanely for
me.  And I don't think I broke anything.  I hope.  :-)

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