https://bugzilla.novell.com/show_bug.cgi?id=462256 Stephan Binner changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |max@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=462256 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=462256#c2 --- Comment #2 from Eduardo Chappa 2009-01-23 22:30:42 MST --- (In reply to comment #1)

The default comes from the text/html entry in /etc/mailcap, which pine uses when no url-viewers have been specified. This is not really correct, as that entry only means "a program that is able to display a HTML document" rather than "a web browser".

Here is a question. What is a mailcap entry supposed to do with a ".doc" file? Display its contents or also let you interact with the content? If you think it is the first, then antiword is your friend. Otherwise, openoffice is your friend. Similarly, what is the correct behavior to open a text/html file? If the intent is that the mailcap entry be only a viewer of the content, then no entry should let you interact with the displayed content (e.g. the image viewer should be in read-only mode, etc.) I do not know what the policy in SuSe is, but it seems to me that as long as it is consistently used, there is no problem. The code in Alpine assumes that the html viewer is more than that, that you also want to interact with the content (e.g. follow links in that content)

I think I'll fix it by adding an /etc/pinerc to the package next time I touch it and put some browser finding magic in there.

That is certainly one way to solve this issue. It seems reasonable, given the circumstances. -- Eduardo -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=462256 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=462256#c4 --- Comment #4 from Eduardo Chappa 2009-01-24 01:27:37 MST --- (In reply to comment #3)

Hi Eduardo,

The problem I saw was not a lack of interaction with the content. I was unable to *view* URLs, because once a formatted page was dumped on the console the "viewer" exited and alpine immediately redrew the screen.

Yes. The problem is that Alpine expects the viewer to take control of the screen. In this case, the viewer exits, so Alpine is returned control of the screen. This is normal. What SuSe should have done is what you suggested in an earlier message, but apparently they have other reasons to not to do what seems the obvious thing. Nevertheless, and entry in /etc/pinerc would solve this problem. -- Eduardo -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=462256 User chappa@washington.edu added comment https://bugzilla.novell.com/show_bug.cgi?id=462256#c6 --- Comment #6 from Eduardo Chappa 2009-01-31 09:18:11 MST --- (In reply to comment #5)

(In reply to comment #2)

...

The code in Alpine assumes that the html viewer is more than that, that you also want to interact with the content (e.g. follow links in that content)

I understand your point about display vs. interaction, but URLs add another dimension to this. /etc/mailcap is about files that are already stored on the local machine (see the definition of %s in mailcap(4) as being the name of a file that contains the actual content to be displayed) and whose file format is known. In contrast, a URL describes a way to fetch the content, and you won't know the file format until you fetch at least the header (in case of HTTP).

I agree with you 100%, but that does not mean that I endorse your conclusions, because there are other considerations to take into account. The "-dump" option does not allow the user to interact with the content. If you go through the mailcap file in SuSe you will see that many entries do allow interaction with the content (not just display). Probably it would be good to know why SuSe did not allow the user to interact with the content, and just parse it. One way to solve this issue is to eliminate the "-dump" from there. Maybe you can find out why it is there, and why SuSe will not eliminate it. That I would be interested to know.

So, I still think alpine is wrong in assuming that a program that is specified as being able to display (or edit) a local HTML document is also able to retrieve and display the content behind arbitrary URLs.

That I agree in principle, but practice is so different. Do you know any program that only displays html files that does not let you interact with them? (or for that matter a program that displays pictures that does not let you edit them? - well answering my own question, a web browser, but that is not what SuSe adds to the mailcap file). It's not a black or white issue. I would like to know what motivated SuSe to add the -dump option to w3m. That is more to the point of this discussion. -- Eduardo -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.