Re: xdg-open

Jerry James writes:  > A few suggestions have been floated on how to deal with this.  First,  > take xdg-open support back out again.  Second, stop removing temporary  > files; Whether or not to remove temporary files should be an option of browse-url anyway.  It seems to me that a 3-way option should be available: - fetch to $TMPDIR then view and finally clean up - fetch to $TMPDIR then view - fetch to $SAVEASDIR then view xdg-open should be special-cased to either never clean up, or (if it accepts URLs) configured to do the fetching itself, thus delegating cleanup to it or its inferior process.  > as long as they are in /tmp, the tmpreaper will get them sooner  > or later (which, of course, is not feasible across all platforms  > supported by XEmacs). This is just too bad for platforms without tmpreapers.  > Third, ask upstream to make us a new tool or modify xdg-open to  > have a synchronous mode (which would require having synchronous  > tools to invoke). xdg-open can't be that complicated.  (Er, can it?  :-þ)  If it's GPLv2-compatible, we could fork our own version (and keep it in lib-src a la oobrowser).  If we do it as an option, we could contribute the patch upstream for them to do as they see fit.