[racket] help browser other than "open" in OS X
10 minutes ago, Jose A. Ortega Ruiz wrote:
> On Thu, Jun 02 2011, Eli Barzilay wrote:
>
> > Three hours ago, Jose A. Ortega Ruiz wrote:
> >>
> >> If i've read the code correctly, it's currently not possible, in
> >> OS X, to specify a help browser other than "open" (the system's
> >> default). Am i right? And, if so, would you accept a bug report
> >> (or even a patch) to make it configurable as in linux? (i use
> >> racket inside emacs, and is very useful to set the help browser
> >> to a specific elisp function there).
> >
> > While in general I think that it's good to have such options, this
> > one feels wrong. The thing is that `open' is itself something
> > that should be configured to use whatever browser you'd want
> > (including some emacsclient thing, if needed).
>
> Well, I disagree. In general, i don't want Emacs to be my OS X
> browser. I just want it to be my Racket documentation browser when
> i'm hacking Racket inside Emacs. Even if i wanted to set 'open' to
> emacsclient, when i browse Racket help pages i want to fine-tune how
> they're opened (e.g., reusing a single tab), and the best place to
> express such fine tunning is in an elisp function called by Racket's
> browser.
It's not impossible, still. If I really wanted to do that, I'd add
some environment variable that indicates when running inside Emacs,
then make my `open' inspect it and decide what to run. (Possibly by
installing my own script as the browser that `open' invokes.) It's
not pretty, but I'd be fine with doing something like that for such an
uncommon case. YMMV, of course.
In any case, if the winds blow towards implementing it, then the main
issue with the unix setup is that it's a bunch of half-baked hacks
that know how to invoke a set of browsers, catering to each browser's
quirks -- and I would love to see all of that go away when `xdg-open'
or whatever becomes popular enough to rely on. So if this is added,
I'd like to see it done via
* a new configuration option that has just the path to a binary to be
executed with the URL as a single command-line argument
* the option can then be ignored by drracket so it becomes a
power-user thing
* and for the same reason the simple single argument thing works: if
it's intended to be used by power users, they can just as well write
a script that will do whatever's needed.
(As you can see, I don't like the UI for setting the unix option
manually -- it has been the source of *many* confusions.)
> And, IMO, it's not only for Emacs-heads that the option is useful:
> one might want to have a dedicated browser for Racket help because,
> say, Firefox displays Rackets manuals nicer than Safari, or quicker,
> or whatever.
But that applies for all applications, and AFAICT, the ability to set
which browser an application uses is something that I didn't see in a
really long time. (Except for an occasional application on unix, like
drr.)
> I'm talking about emacs-w3m, yes. I've been using the CVS version
> for many years now, without any stability problems (of course, it's
> useless for sites that *need* flash or javascript to work at all,
> but i guess i'm lucky i don't visit many of those). At any rate,
> when using Emacs to code in Racket, i find browsing the
> documentation inside Emacs extremely convenient (and stable).
(I'm using that too, and there are some cases where it's buggy enough
that I usually just open a proper browser. And this is probably the
3rd of 4th time that I tried to use it and gave up...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!