[Pythonmac-SIG] Re: On-line help; webbrowser problems

[Russell E Owen]

I reported that I could not get file://...#anchor URLs (such as 
"file:///Users/rowen/PythonRO/TUI/TUIHelp/Telescope.html#skywidget" 
or 
"file://localhost/Users/rowen/PythonRO/TUI/TUIHelp/Telescope.html#skywidget") 
to open in a web browser. I tried the webbrowser package, the "open 
location <url>" applescript and "open -a <browser> <url>" in the 
command line and all did the same thing:
- opened the file in its original creator (which might be a text 
editor or a browser, but is not the favored browser in Internet 
settings).
- ignored the #anchor portion of <url>.

Jack Jansen (I believe; I can't get to the mail right now) suggested 
I try the ic module. I actually had already found that on Friday 
after I posted my message (in the process of trying to learn how to 
send applescript commands directly to a web browser--something I'm 
still looking into). Unfortunately, ic.launchurl(<url>) works the 
same as all the other solutions. MacOS seems hell-bent on treating 
file://...#anchor as opening a file as if from Finder, rather than 
telling a browser to open a file and passing it the #anchor. 
Consistency is good, but clearly it can be overdone.

Any suggestions on workarounds or alternate ways to convince a 
browser to open a file at a particular anchor (thus avoiding the need 
for a web server)?

Other ideas include:
- modify pydoc to serve the data; at least that web server is built 
in and preconfigured (I've only looked very briefly into this)
- implement on-line help in some entirely different way (such pity to 
have to recreate or lose all the great HTML navigation)
- use applescript to talk directly to a user-specified browser. I'm 
sure this would work, but not sure if I can make it tolerably 
maintainable (apparently I'll have to create an apple event 
dictionary object for any browser my users may want to use, which 
sounds like a pain)

-- Russell