bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16243@debbugs.gnu.org
> Date: Wed, 25 Dec 2013 09:19:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> To make relative URLs expand correctly, file://directory/file/is/in
> >> should be passed in as the base directory.
> >
> > I'm not sure such a directory value will do what we want.  The value
> > should be a local file name.  E.g., on Windows typing RET on a link
> > will eventually call a function that needs to be able to produce an
> > absolute file name by calling expand-file-name.
> 
> file:// specifies a local file.

But expand-file-name doesn't support it.  On MS-Windows:

  (expand-file-name "file:///d:/usr/lib")
    => "d:/gnu/bzr/emacs/trunk/file:/d:/usr/lib"

On GNU/Linux:

  (expand-file-name "file:///home/e/eliz/bzr")
    => "/home/e/eliz/bzr/emacs/trunk/file:/home/e/eliz/bzr"

> >> `shr-visit-file' doesn't really visit a file.  It just does a rendering
> >> based on it.  If `buffer-file-name' is set to the file, and you save
> >> what you see, you destroy the .html file you see a rendering of.
> >
> > Then don't allow to save.
> 
> That's why `buffer-file-name' isn't set.

There are other methods to prevent accidental saving, which don't mess
up with buffer-file-name or default-directory.  After all, the user
can always specify the file to save explicitly, so you cannot make
this 100% idiot-proof anyway.  The way things are now, we punish the
innocent majority on behalf of a crazy minority.  That doesn't sound
right to me.