[emacs-w3m:13327] Re: Another approach to improve w3m-doenload
TSUCHIYA Masatoshi <[email protected]>
| Newsgroups | gmane.emacs.w3m |
|---|---|
| Message-ID | <[email protected]> |
Hi, I prefer the third option: adding a new option to w3m command. If --dump_extra outputs the progress information into the standard error and output the content into the standard output, it will be possible to eliminate using awk command from the second option, I think. >> On Thu, 04 Apr 2019 15:26:17 +0900 >> [email protected] (Katsumi Yamaoka) said as follows: >I worked on the two kinds of approaches to improve w3m-download. >Both feature: >Fully asynchronous operation >Allow parallel downloads at a time >Progress indicator(s) in the mode-line >Not eat much Emacs' memory, only a header is cached >[1] is a version to use a timer that watches the size of a local >file being downloaded for the progress indicator. This version >runs w3m twice separately; runs with the -dump_head option to get >the header of the remote contents to know the file size and the >timestamp, and runs with the -dump_source option to download the >contents directly to a local file. The latter starts the timer. >[2] is a version to divide the output of `w3m -dump_extra' to >two streams using awk; one is for the progress indicator fed to >an Emacs' process buffer and the other is for the contents of a >remote file redirecting directly to a local file. >The both codes are almost complete, however either ones have an >unavoidable issue on the progress indicator. >As for [1] the indicator starts to increase after w3m starts to >write the remote contents to a local file. It is the time when >w3m has buffered the contents fully in a local memory, not at >w3m starts to download. >Contrary, [2] starts the indicator to increase when w3m starts to >download, and finishes when w3m has buffered the remote contents >fully in a local memory, but time w3m takes thereafter to save >the contents to a local file is not necessarily negligible. This >is just the current version's behavior except for the slowness of >saving though. This version is equipped with a trick that blinks >the indicator for a while after the indicator's value gets still. >The one suitable to a slow connection would be [2], and of which >perfection is higher. >Here are two patches according to those two ways respectively. >Both are aimed to apply to the latest git master. -- TSUCHIYA Masatoshi