[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: link or page not rendered



On 2019-07-01 03:36, andrés ramírez wrote:
> Hi Boruch.
>
> > 4] In order to focus on the 'second' half of the problem, the rendering
> >    problem, I saved the html locally, and performed the following when
> >    loading the local copy.
>
> Out of my curiosity. What have been You using for loading the html
> --8<---------------cut here---------------start------------->8---
> w3m-buffer or w3m-find-file?
> --8<---------------cut here---------------end--------------->8---

I used w3m-goto-url ~/Notes.....html, ie. 'g'

I should try the two methods you mention, but I really do need to get
some shut-eye.

> w3m-buffer Does the job on my workstation.

> w3m-find-file never renders the page.

Never is a long time to wait. How long did you wait?

> So this also confirm your discoveries. the rendering is the issue and
> not the w3m process.

That wasn't my conclusion at all. Both are issues, and each is
responsible for about half of the total delay (I said so in paragraph
three of my post). I chose to drill down and pursue the second part, the
rendering, because it's much easier to trace and debug.

One thing that I may try tomorrow is to perform some general
web-browsing with the function w3m-fix-illegal-blocks disabled, and see
how that works. It may be that when the function was written it was a
necessity, but no longer due to some change in w3m or something else.
Maybe one of the core developers will tell us, but they seem to be busy
with other things such as the modernize branch these past few weeks.

If it turns out that function *is* still a necessity, a next step is to
look to optimize it. Either way, that's only addresses the second half
of the problem, but for me that's still a ~40 second improvement!

Since the url was of interest to you, and you were presumably going to
read it / 'use' it anyway, do everyone a favor and please try loading it
using my suggestion in paragraph seven, ie. first comment out
(w3m-fix-illegal-blocks) in function w3m-rendering-buffer, evaluate
function w3m-rendering-buffer, re-load the url, 'use' it, and report
back if there are any deficiencies in the result without using function
fix-illegal-blocks.

Solving this may also solve a long-standing annoyance I have with the
rendering time for long wikipedia pages, so the effort may well be very
useful for most emacs-w3m users. Who knows - this may be a reason people
in the past have tried and rejected emacs-w3m.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0