Re: Feedback needed on w3m support

2004-10-11 Thread Paul Kinnucan
Kai Grossjohann writes:
  Paul Kinnucan [EMAIL PROTECTED] writes:
  
   Several days ago I submitted a fix to CVS for problem 1. That fix
   uses the intermediate file only if browse-url-browser-function
   is set to browse-url-default-windows-browser, i.e., Internet Explorer.
   The problem with that fix is that it disables the frames mode
   display for all other browsers. As I happen to like the frames
   mode display, I intend to back this fix out of CVS.
  
  Does it work to do the opposite logic?  That is, instead of using the
  intermediate file for IE only, use the intermediate file for
  everything except w3m?

Yes. That's in fact what I did.

Paul

  
  I wish emacs-w3m grokked frames.  w3m itself supports -F, but that
  does not seem to have any effect on emacs-w3m.
  
  Kai
  



RE: Feedback needed on w3m support

2004-10-05 Thread Nascif Abousalh-Neto
I had this same problem; we solved it by configuring JDEE to create the temporary 
pages in a directory relative to the user's home, something like ~/tmp, instead of the 
default /tmp.

Regards,
  Nascif

 -Original Message-
 From: Heinz-Dieter Conradi [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, October 05, 2004 3:17 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Feedback needed on w3m support
 
 hi,
 
 without knowing anything about the problems involved, i would 
 like to point out a potential problem with local files which 
 has bitten me in the
 past: the local files are usually not writeable for other 
 users. this is a problem when more than one person is working 
 on the same workstation.
 
 although i like the frame display too, i would probably go 
 for using non-local files without frames,
 
 heinz-dieter conradi
 
 


Feedback needed on w3m support

2004-10-04 Thread Paul Kinnucan
Hi,

I need some feedback on how the JDEE should support w3m, the text-mode
browser that, when used with the emacs-w3m package, enables Emacs to
render HTML in a buffer.

First, some background. The current version of the JDEE uses the
Emacs lisp function browse-url to display HTML documentation, e.g.,
Javadoc for the class at point and the JDEE user's guide. browse-url
in turn uses the function specified by the customization variable
browse-url-browser-function to display HTML. On Windows, this variable
is set to browse-url-default-windows-browser which uses the Windows
default browser, which is Internet Exploer by default. On Unix,
browse-url-browser-function is browse-url-default-browser, which
searches for the presence of one of a predetermined list of browsers
(gnome, Mozilla, Galeon, Netscape, etc.) and uses the first that it finds.

The JDEE does not display Javadoc pages directly. Instead, it creates
an intermediate  HTML file on the fly, name jde_meta.html. This URL-transfer
file causes the browser to load the target page. The original reason
for doing this was to work around a bug in the Emacs windows
implementation of browse-url-default-windows-browser that caused Emacs
to fail to forward the anchor portion of an HTML address. Later, the
intermediate file approach was used to implement display of the
multiframe view for displaying Javadoc.

Currently it is possible for you to configure the JDEE to use the w3m
browser simply by setting browse-url-browser-function to 
w3m-browse-url. However, there are problems with this approach:

  1. There seems to be a bug in the w3m implementation of URL
 forwarding on Windows. At least, the forwarding does not
 work in the latest version of emacs-w3m.el installed on
 my machine. As a result, when you ask the JDEE to display
 Javadoc for the symbol at point, the jde_meta.html, file
 appears in the buffer, with the link to the target page
 highlighted. You need to click the link to display the 
 target page.

  2. Users have reported that the Unix version of w3m cannot
 handle the URL format that the JDEE uses for Javadoc files
 stored on the local system.

  3. w3m is incapable of rendering the JDEE User's Guide because
 it uses an applet to display its TOC.

Several days ago I submitted a fix to CVS for problem 1. That fix
uses the intermediate file only if browse-url-browser-function
is set to browse-url-default-windows-browser, i.e., Internet Explorer.
The problem with that fix is that it disables the frames mode
display for all other browsers. As I happen to like the frames
mode display, I intend to back this fix out of CVS.

So now the problem is to find an easy-to-use fix for all three
problems. My inclination is to add a JDEE customization variable,
jde-help-browser-function, that would allow you to choose:

   * browse-url (default)
   * w3m-browse-url 
   * other

If you choose w3m browse-url, the JDEE will pass the target URL to
w3m-browse-url. In the other cases, it will pass the URL of the
URL-transfer file to the browser, causing the browser to load the
target file in frames or non-frame mode depending on the setting of
jde-help-use-frames. Regardless of the setting of
jde-help-browser-function, the JDEE would use
browse-url-default-windows-browser or browse-url-default-browser to
display the JDEE User's Guide.

Does this approach seem reasonable? Is there an easier way to
handle these problems?

I'd also appreciate it if someone who is using w3m on Unix would
take a look at the URL that the JDEE generates for local files and
tell me what's wrong with it and what URL would be acceptable
to w3m.


Paul





Re: Feedback needed on w3m support

2004-10-04 Thread Jason Rumney
Paul Kinnucan wrote:
I'd also appreciate it if someone who is using w3m on Unix would
take a look at the URL that the JDEE generates for local files and
tell me what's wrong with it and what URL would be acceptable
to w3m.
 

There was a thread about this last week. The problem is a double slash 
between the host part and filename part of the URL. A patch was posted, 
which I think will break things on Windows, since it replaced 
//localhost/ with //.  I think a better solution is to look at the 
filename, and if it starts with a slash (Unix), use //localhost or 
//, and if it doesn't (Windows), then use //localhost/ or ///.



Re: Feedback needed on w3m support

2004-10-04 Thread Ole Arndt

Hi Paul, 

Paul Kinnucan [EMAIL PROTECTED] writes:

 Several days ago I submitted a fix to CVS for problem 1. That fix
 uses the intermediate file only if browse-url-browser-function
 is set to browse-url-default-windows-browser, i.e., Internet
 Explorer.
 The problem with that fix is that it disables the frames mode
 display for all other browsers. As I happen to like the frames
 mode display, I intend to back this fix out of CVS.

What about using the method with the intermediate file when

,[ C-h v jde-help-use-frames RET ]
| jde-help-use-frames's value is nil
| 
| A non-nil value makes the functions:`jde-help-symbol',   
| `jde-help-class-member' and `jde-help-class' use frames when
displaying
|  the html javadocs.
`

is t and use the direct url otherwise? Since the intermediate file is
only needed for frames and w3m doesn't do frames, this seems like a
reasonable approach.

Another way to differentiate behavior based on the url is to use the 
regexp match functionality of browse-url-browser-function:

,[ C-h v browse-url-browser-function RET ]
| browse-url-browser-function's value is 
| ((jde_meta . browse-url-mozilla)
|  (file:/// . w3m-browse-other-window)
|  (.* . w3m-browse-url))
| 
| *Function to display the current buffer in a WWW browser.
| This is used by the `browse-url-at-point', `browse-url-at-mouse',
and
| `browse-url-of-file' commands.
| 
| If the value is not a function it should be a list of pairs
| (REGEXP . FUNCTION).  In this case the function called will be the
one
| associated with the first REGEXP which matches the current URL.  The
| function is passed the URL and any other args of `browse-url'.  The
last
| regexp should probably be . to specify a default browser.
`

I do not know whether this is available in a non-CVS browse-url
package, though.

Ole
-- 
Ole Arndt http://www.sugarshark.com