Re: Feedback needed on w3m support
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
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 > >
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
Re: Feedback needed on w3m support
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
Re: Feedback needed on w3m support
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 "///".
Feedback needed on w3m support
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