[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mh-v

From: rader
Subject: Re: [Nmh-workers] mh-v
Date: Sat, 10 Nov 2012 06:49:21 -0600

 > > When I'm running MH-V on localhost's display, I then do 'v' to have
 > > MH-V execute "mhstore" to save the image attachment and do e.g.
 > > "firefox -browser file:///home/rader/.mh_cache/23.2.jpeg &" to bring
 > > it up in my browser. 
 > Is -browser needed?

Donno.   I don't use firefox.  I use a version of Seamonkey I build from
scratch to get purely native vi-like key bindings and I use...

 seamonkey -remote "openURL(%url,new-window)"

...to get a window to popup (instead of a new tab.)

Playing around with my (poor ol?) Firefox 3.6.13 on SL54, it seems that firefox
-browser doesn't work right: it opens the URL in a tab and opens a new window
with the startup home page!  So I guess that should change to just "firefox"?

 > > When I'm remote and have fast X11 forwarding, I do 'v', and MH-V sees
 > > I have the SSH_CLIENT env var set, and it thus does "firefox -browser
 > > http://some.domain.name/~rader/mh_cache/23.2.jpeg &" (because file:///
 > > is not local/available.)
 > What's the difference between fast and slow X11 forwarding?

...like fast ethernet or better vs 8Mbps cable broadband.  

Over 8Mbps, doing seamonkey -remote "openURL(%url,new-window)" takes about 8,
9 seconds, which is yet another reason why I ditched EXMH.  I can do 's',
'^w' ("web browser") in my ol' vtwm window manager and click on a bookmark
and "23.2.jpeg" in about 2 seconds.  (Humm, having typed this, I see where
I could save a click here.)

 > I'd expect that remote Firefox to see a local Firefox is running (thanks
 > to X properties on its windows) and have the local one open the URL?
 > Have you considered having the remote Firefox open a
 > http://localhost:4242/23/2.jpeg URL which the local one opens on its
 > behalf, and port 4242 is forwarded securely over SSH, thanks to
 > ~/.ssh/config, from the local machine to mh-v listening on the remote
 > machine where it responds to the HTTP request?  It would avoid needing a
 > HTTP server on remote that's listening on a public interface.

Nice!  I'll certainly vet that--I hadn't consider it because I already had
httpd listening on the remote end.

Thanks for the input.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]