* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
@ 2013-12-24 17:30 Eli Zaretskii
2013-12-24 20:14 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-24 17:30 UTC (permalink / raw)
To: 16243
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@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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-24 17:30 bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory Eli Zaretskii
@ 2013-12-24 20:14 ` Lars Ingebrigtsen
2013-12-24 20:56 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-24 20:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
Eli Zaretskii <eliz@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-24 20:14 ` Lars Ingebrigtsen
@ 2013-12-24 20:56 ` Eli Zaretskii
2013-12-24 21:02 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-24 20:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16243
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16243@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-24 20:56 ` Eli Zaretskii
@ 2013-12-24 21:02 ` Lars Ingebrigtsen
2013-12-25 3:48 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-24 21:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
Eli Zaretskii <eliz@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-24 21:02 ` Lars Ingebrigtsen
@ 2013-12-25 3:48 ` Eli Zaretskii
2013-12-25 8:19 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-25 3:48 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16243
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16243@debbugs.gnu.org
> Date: Tue, 24 Dec 2013 22:02:46 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 3:48 ` Eli Zaretskii
@ 2013-12-25 8:19 ` Lars Ingebrigtsen
2013-12-25 17:40 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-25 8:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
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.
>> `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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 8:19 ` Lars Ingebrigtsen
@ 2013-12-25 17:40 ` Eli Zaretskii
2013-12-25 17:42 ` Lars Ingebrigtsen
2013-12-25 17:45 ` Lars Ingebrigtsen
0 siblings, 2 replies; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-25 17:40 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16243
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 17:40 ` Eli Zaretskii
@ 2013-12-25 17:42 ` Lars Ingebrigtsen
2013-12-25 19:39 ` Eli Zaretskii
2013-12-25 17:45 ` Lars Ingebrigtsen
1 sibling, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-25 17:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
Eli Zaretskii <eliz@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 17:40 ` Eli Zaretskii
2013-12-25 17:42 ` Lars Ingebrigtsen
@ 2013-12-25 17:45 ` Lars Ingebrigtsen
2013-12-25 19:40 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-25 17:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
And it already exists: `eww-open-file'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 19:39 ` Eli Zaretskii
@ 2013-12-25 19:38 ` Lars Ingebrigtsen
0 siblings, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2013-12-25 19:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 16243
Eli Zaretskii <eliz@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 17:42 ` Lars Ingebrigtsen
@ 2013-12-25 19:39 ` Eli Zaretskii
2013-12-25 19:38 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-25 19:39 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16243
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16243@debbugs.gnu.org
> Date: Wed, 25 Dec 2013 18:42:57 +0100
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory
2013-12-25 17:45 ` Lars Ingebrigtsen
@ 2013-12-25 19:40 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2013-12-25 19:40 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16243
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 16243@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.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-12-25 19:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-24 17:30 bug#16243: 24.3.50; shr-visit-file doesn't set the buffer's default-directory Eli Zaretskii
2013-12-24 20:14 ` Lars Ingebrigtsen
2013-12-24 20:56 ` Eli Zaretskii
2013-12-24 21:02 ` Lars Ingebrigtsen
2013-12-25 3:48 ` Eli Zaretskii
2013-12-25 8:19 ` Lars Ingebrigtsen
2013-12-25 17:40 ` Eli Zaretskii
2013-12-25 17:42 ` Lars Ingebrigtsen
2013-12-25 19:39 ` Eli Zaretskii
2013-12-25 19:38 ` Lars Ingebrigtsen
2013-12-25 17:45 ` Lars Ingebrigtsen
2013-12-25 19:40 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).