World: r4wp

At least that's the stated reason. There is likely a better approach.

https://github.com/0branch/r3/commits/browse-macosx

http://issue.cc/r3/1991- BROWSE none

https://github.com/0branch/r3/commit/8eea3cf8217bd8f05ea5190fa81f5e8d8ed41cad

MarcS, with mainline R3 browse doesn't currently work on OSX, right?

Right

Unless, I guess, you have XQuartz installed with xdg-open or x-www-browse

http://issue.cc/r3/1992- BROWSE doesn't work on OSX

Great.

So should I submit pull requests referencing these tickets?

Squash the two 1992-related commits into one, and also mention the 
CureCode ticket in the commit message (something like "This fixes 
CureCode issue #1992.") and submit a pull for that.

To squash I need to rebase locally then repush?

Yes, exactly (push --force).

Okay

For #1991 se need a better approach. We aren't at the point where 
we would need to disable a feature while we wait to figure it out, 
at least for something you have to explicitly call.

Hope you don't mind the cosmetics :)

Andreas: np, just testing the squashed changeset

For #1991, we should at least get the crash removed right away.

Sufficient detail, https://github.com/rebol/r3/pull/101?

Looks good.

https://github.com/rebol/r3/pull/102

Let's hope Haiku has fork/exec :)

Again, the second pull won't fly as-is.

If you can isolate the unset changes alone, that'd be great.

Np.

I figured I might as well submit the request so the code is more 
visible.

Okay, that's fine, thanks. Just to have expectations aligned :)

Meanwhile I might merge that fix into my browse-macosx branch.

Just don't push the merged branch to Github again, as this will also 
affect the pull request.

Oh, right

A third browse branch it is!

(As you might have gathered, I'm not much of a Githubber)

For NONE I see the following options to fix the crash right away: 
either remove the NONE feature altogether (removing functionality 
that currently sometimes works on Win32), or use http:// on POSIX 
(as a not totally reliable workaround), or move the early exit to 
the POSIX specific code (creating a cross-platform incompatibility 
between Win32 and POSIX platforms).

Re: Haiku, http://code.metager.de/source/xref/haiku/headers/posix/unistd.h#212

Anyway, the subtree is named 'posix' :)

Good, thanks for looking that up. I can try building on Haiku later 
on.

Great

Git question: can I ignore changes to makefile without modifying 
.gitignore?

With how the repository is currently set up: I don't know of a way 
how to do that. Just don't add the makefile changes before you commit.

Sure, I'm not staging them.

I seem to recall that there's a global ignore setting

(Which I'd likely be abusing, but might be suitable.)

I don't think that comes into play with files already present in 
the repo.

.git/info/exclude is a per-repository ignore list.

Aha, thanks

Just found that https://help.github.com/articles/ignoring-fileshere

Cool. So --assume-unchanged helps :)

git update-index --assume-unchanged make/makefile

Oh good stuff -- the exclude list doesn't

Since already committed

Hopefully one remembers having marked a file with --assume-unchanged 
when actually _trying_ to stage changes from that file :)