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

Re: Editing non-local files [PATCH]



On 2017-12-11 13:33, Katsumi Yamaoka wrote:
> Great.  I've installed your patch.  Thanks.
> It might be nice to say something (in the echo area or the main
> window) if a page has many images that takes long time to download
> till a user becomes able to edit it, I think.

I missed that, because on my personal system I have emacs-w3m set to
default to save html only.

I'm happy to code a message to display after the save begins, or a
warning message before the save begins. Then, a next question would be
whether to have either message appear only for `w3m-edit-url' or for
all save operations.

Let's consider a case of `w3m-edit-url' always saving only the html
source, or defaulting to saving only the html source, with an option to
saving images. The user wants to edit the remote page, asks to edit
the source, performs the edit, and saves the edit. At this point, the
user is sitting in front of a non-emacs-w3m buffer, just a normal emacs
buffer, so he needs to switch back to emacs-w3m, and needs to have the
presence of mind to load the local copy, not to reload the existing
emacs-w3m buffer with the original remote copy.[1] Loading the local copy
will *probably* reload the remote images, and *should* exploit local
copies in the emacs-w3m cache[2]. At that point, or at any future point,
the user can save the page again with the images, as a normal explicit save.

At this point, I'm still unsure how a normal user's work-flow would
progress when dealing with images.

Footnotes:
━━━━━━━━━━
[1] I thought maybe to automatically delete the original buffer pointing
    to the remote copy, but then considered that the user might want to
    compare the original to the edit side-by-side, or refer to the
    original while editing the source.

[2] Hmm. You may have come across a bug in the emacs-w3m cache. Saving
    the images from the cache shouldn't take noticeable time.
    Was emacs-w3m re-fetching from the network in your case?


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