You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
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
avoid repetitiveness.
w3m--unsupported-display: repetitive
w3m--prompt-for-unknown-content-type: clarity
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).
w3m-external-view-file bugs
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"
or "foo.1.3.gzip"
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.
https://github.com/emacs-w3m/emacs-w3m/pull/55
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.