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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16243 in the body.
You can then email your comments to 16243 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
Date: Tue, 24 Dec 2013 19:30:33 +0200

To reproduce:

  emacs -Q
  M-x load-library RET shr RET
  M-x shr-visit-file RET /some/file.html RET
  M-: default-directory RET

You will see that the default-directory of the buffer where the file
is rendered is not the directory of that file.

Why is this a problem?  Because shr.el binds keys to commands that
expect the buffer's directory to be set correctly.  For example, RET
is bound to shr-browse-url, which (at least on Windows) needs to
expand the linked file name relative to the directory of the file that
is displayed in the buffer.

So: any reasons not to set default-directory in shr-visit-file?

Thanks.


In GNU Emacs 24.3.50.181 (i686-pc-mingw32)
 of 2013-12-24 on HOME-C4E4A596F7
Bzr revision: 115731 eliz <at> gnu.org-20131224172106-220c4vpxm3ysr12m
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0
 -gdwarf-2 -g3''

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

Message #8 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Tue, 24 Dec 2013 21:14:58 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Why is this a problem?  Because shr.el binds keys to commands that
> expect the buffer's directory to be set correctly.  For example, RET
> is bound to shr-browse-url, which (at least on Windows) needs to
> expand the linked file name relative to the directory of the file that
> is displayed in the buffer.

`shr-visit-file' was a half-assed command I added before I did eww, and
it should probably be removed.  It's not very useful any more.

But if we keep the command, then it should be altered to pass the
directory in as the HTTP base URL, which would make the URLs point to
the right thing without altering default-directory.

But setting default-directory might also be nice -- do "special mode"
buffers usually do so or not?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #11 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Tue, 24 Dec 2013 22:56:01 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16243 <at> debbugs.gnu.org
> Date: Tue, 24 Dec 2013 21:14:58 +0100
> 
> But if we keep the command, then it should be altered to pass the
> directory in as the HTTP base URL, which would make the URLs point to
> the right thing without altering default-directory.

Not really sure what you meant here.  shr-visit-file is about local
files, right?  So what URL and which HTTP are relevant here, and why?

> But setting default-directory might also be nice -- do "special mode"
> buffers usually do so or not?

Which special mode buffers?  I actually don't quite understand why
buffer-file-name isn't set to the name of the file we visit.

Message #14 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Tue, 24 Dec 2013 22:02:46 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Not really sure what you meant here.  shr-visit-file is about local
> files, right?  So what URL and which HTTP are relevant here, and why?

To make relative URLs expand correctly, file://directory/file/is/in
should be passed in as the base directory.

> Which special mode buffers?  I actually don't quite understand why
> buffer-file-name isn't set to the name of the file we visit.

`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.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #17 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 05:48:24 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16243 <at> debbugs.gnu.org
> Date: Tue, 24 Dec 2013 22:02:46 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Not really sure what you meant here.  shr-visit-file is about local
> > files, right?  So what URL and which HTTP are relevant here, and why?
> 
> 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.

Either that, or change the function invoked by RET to let-bind the
buffer's directory to the right value.

> > Which special mode buffers?  I actually don't quite understand why
> > buffer-file-name isn't set to the name of the file we visit.
> 
> `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.

Message #20 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 09:19:14 +0100

Eli Zaretskii <eliz <at> 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.

>> `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.  As it isn't in most special
mode buffers.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #23 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 19:40:03 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16243 <at> debbugs.gnu.org
> Date: Wed, 25 Dec 2013 09:19:14 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Message #26 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 18:42:57 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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"

I think we're talking past each other here.  HTML documents use URLs
like "file:///home/foo" or "http://fsf.org" as base addresses to expand
relative URLs.  These URLs are never fed to `expand-file-name' or
anything like it.

>> 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.

The problem here is that the command `shr-visit-file' exists.  It
shouldn't.  It was just used to simple debugging while developing shr,
and should be removed.  That the buffer is in `fundamental-mode' is
another symptom.  >"?

Instead there could be an `eww-find-file' that would do the right thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #29 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 18:45:29 +0100

And it already exists: `eww-open-file'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #32 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 21:39:23 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16243 <at> debbugs.gnu.org
> Date: Wed, 25 Dec 2013 18:42:57 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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"
> 
> I think we're talking past each other here.  HTML documents use URLs
> like "file:///home/foo" or "http://fsf.org" as base addresses to expand
> relative URLs.

But shr-visit-file visits a local file, not an HTML document.

> These URLs are never fed to `expand-file-name' or anything like it.

But shr-browse-url, bound to RET on a link created by shr-visit-file,
does just that.

> The problem here is that the command `shr-visit-file' exists.  It
> shouldn't.

Then remove it, and let's move on.

Message #35 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 21:40:04 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 16243 <at> debbugs.gnu.org
> Date: Wed, 25 Dec 2013 18:45:29 +0100
> 
> And it already exists: `eww-open-file'.

Yeah, and was broken on Windows until yesterday.

Message #38 received at 16243 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16243 <at> debbugs.gnu.org
Subject: Re: bug#16243: 24.3.50;
 shr-visit-file doesn't set the buffer's default-directory
Date: Wed, 25 Dec 2013 20:38:29 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The problem here is that the command `shr-visit-file' exists.  It
>> shouldn't.
>
> Then remove it, and let's move on.

I've now removed it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.