On Tuesday, 26 February 2013 at 07:17:49 UTC, Lars T. Kyllingstad
wrote:
On Monday, 25 February 2013 at 21:06:54 UTC, Vladimir Panteleev
wrote:
On Monday, 25 February 2013 at 20:06:19 UTC, Lars T.
Kyllingstad wrote:
That is also incredibly obscure. I'd venture a guess that
only ~10% of D's user base have even heard of Lynx. Everyone
knows firefox, and will understand what the example is
supposed to illustrate. (I admit that the ls/grep examples
will also be rather incomprehensible to someone not familiar
with the *NIX command line, and I will replace them with
something else. The D toolchain, as you suggest below, is a
very good idea.)
I still think using Firefox is a bad idea, but I've already
presented my arguments.
BTW, browse() should never have been added to std.process, in
my opinion. Maybe to some other utility module, but then it
should at least be done right, and be properly documented.
What would you improve about it?
1. I would document it properly.
2. As long as it runs in the background, I would return some
kind of process ID from it. (Yes, most browsers today may just
signal another instance to open a new tab and then return, but
would be surprised if they *all* do.)
(3. Maybe put it in a different module, I'm not sure.)
4. I would design it so that if I do browse("foo.txt") it opens
foo.txt in the web browser. Correct me if I'm wrong, but it
currently seems that it will open it in the user's text editor on
Windows. (On POSIX systems, too, if $BROWSER isn't set.)
1a. I would document that it uses $BROWSER on POSIX, as that is
not even remotely standard. (It is not set on my Ubuntu 11.10
machine, for instance.) I would document that it uses xdg-open
on Linux if $BROWSER is not set, as xdg-open will only exist on
systems that conform to FreeDesktop standards.
Even if it turns out that browse() is the "best" way to implement
this feature, it is not perfect by a long shot, and as such its
shortcomings should be well documented.
Lars
