[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: w3m-clear-display-while-reading vs w3m-view-header on link
On 2018-05-25 18:03, Kevin Ryde wrote:
> Boruch Baum <boruch_baum@xxxxxxx> writes:
> > I still have no luck reproducing your report, but upon re-reading maybe
> > we have different expectations of what the command should do. Per the
> > docstring, function `w3m-view-header` ... Display the header of the
> > *current page*, not the header of the url at point. Is that the
> > confusion?
> Maybe, but if you nose around the code in `w3m-about-header' you can see
> how it's supposed to report info from the current page concerning link
> and/or image at point. Fixed in any case now in w3m-process-stop hopefully.
I just did now take a look at the code with the debugger, and see what's
going on with me, which is puzzling. My copy of the function includes
1 (let (anchor anchor-title
2 image-url image-alt image-size)
3 (with-current-buffer w3m-current-buffer
4 (when (equal url w3m-current-url)
5 (setq anchor (w3m-anchor)
6 anchor-title (w3m-anchor-title)
7 image-url (w3m-image)
8 image-alt (w3m-image-alt)
9 image-size (w3m-get-text-property-around 'w3m-image-size))))
10 (if anchor
11 (insert "\nCurrent Anchor: " anchor))
12 (if anchor-title
13 (insert "\nAnchor Title: " anchor-title))
14 (if image-url
15 (insert "\nImage: " image-url))
16 (if image-alt
17 (insert "\nImage Alt: " image-alt))
18 (if image-size
19 (insert (format "\nImage Size: %sx%s"
20 (car image-size) (cdr image-size)))))
For me, the 'equal' test on line 4 always fails because the value of
`w3m-current-url' is nil(!) at that point, in that context. I was
surprised, but when I double-checked in the debugger by switching to the
`w3m-current-buffer', the location bar at the top was blank! Also, point
had moved to (point-min), so all the assignments on lines 5-9 returned
nil. All was restored at some point before the command completed,
though. So, at some point, the code is for me temporarily messing with
That explains why my output doesn't include the header data that you
get, but I haven't found why the behavior is happening.
> > In order to get a link's page header information, we would
> > need to post a GET request for that page, which would give us the entire
> > page along with the header, so it would be the same as loading the link.
> Yes, no, no fetching, just what the current page has about the link.
The fetching may possibly happen because the call to w3m-goto-url is
being made without the RELOAD arg set to 'redisplay, which I understand
means that if the page has expired, it will fetch. That seems the
correct behavior, but just so you know.
> I sometimes like a HEAD to look at a link to check how massive before
> downloading but let's not confuse ourselves with a separate topic :-)
Nice idea, especially for us North Americans living in a country with
third-world minus internet speeds.
> Personally I'm happy in the same buffer, and it's uncommon anyway.
Fine by me.
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0