This PR fixes several longstanding bugs that manifest when a URL's
content-type is unrecognized:
When a content-type is not recognized, w3m prompts with a list using
completing-read, but that list was mal-formed
The car of the list was bad.
The completing-read set REQUIRE-MATCH to t, but further processing
was handling the mis-match of an empty string.
In cases such as when a content-type is not recognized, after an
external program or a download was performed, the former buffer was
not reverted from its state of having a progress message.
I carved two sub-functions from w3m-create-page for clarity and to
Function w3m-create-page wasn't properly handling the cases for
'unsupported displays', eg. when operating in a non-X11 environment
and clicking on a PDF or image link.
Function w3m-external-view was ignoring the user's request to
download, even after explicitly selecting that option from
w3m-create-page (now w3m--prompt-for-unknown-content-type).
Parent function w3m-external-view calls this in one case with the
FILE argument explicitly set to nil, but the function was
accounting for that case.
The regex for finding a filename's extension (suffix) was failing
for files with more than one period in its name, eg. "foo.bar.abc"
The function expects that a command spec associated with a content
type use the symbol file to mark where to substitute the
filename; However, it pulls associations from the OS environment,
and X-freedesktop compliant ones use a different method,
substituting the string "%s", sometimes quoted, for the filename.
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.