Comment 43 for bug 25830

Good points, Boris. How about designating one app as the external text viewer,
and giving it a pick-helper-app button of its own?

The analogous thing, for the faraway ideal of input helper apps, would be to
have an editor specified as the general INPUT TYPE=FILE ACCEPT=(unrecognized)
situation. There, you could have different editors depending on the major type
name.

This suggests the question for when the external text "viewer" is offered. In
the traditional situation, View Source..., there was a time when the OS text
selection and copy was disabled on windows. Not a user-centered feature, and a
not-very-best laid plan that went astray to the point of absurdity.

To add insult to injury, someone came up with the idea of putting "Open Link in
Composer" next to "Open Link in new Window." Many of us with control over
content-sensitive menus might consider a seperator there.

In short, I want to be able to open anything, even binary files, in any editor
I specify, but I don't want to do so when I am trying to open it in a new
navigator window. I suggest a new menu item, at least ten pixels from "open
link in new window" with "open in ________" where the blank is filled from a
preference. Maybe multiple such global viewers. And, when I click on
something purporting to be text/x-quadruple-byte-klingon, I want to chose
between all my global viewers, and navigator, and something else to be
specified in further dialog. And if I choose the latter option, I want to be
able to add the selected application to be the default for the specific type,
the default for unrecognized major types -- e.g. text/(unrecognized) -- or a
new global viewer to add to my context-sensitive menu.