racket-open-require-path should ignore stderr

[greghendershott]

From Slack:

samth [5:18 PM]
@greg I think racket-mode should ignore output on stderror
greg [5:28 PM]
@samth IIRC Emacs shell processes get stdout and stderr mixed together, so can't "unsplit" and filter there.
But the racket-mode back-end could parameterize `current-error-port` to `open-output-nowhere` in the first place, I guess.
But.
Do you mean ignore as in don't show it to the user? And if so, why?
samth [5:29 PM]
I mean, it shouldn't get confused by spurious output when that output is on stderr
greg [5:31 PM]
I agree that racket-mode shouldn't get confused :smile: but I'm not sure what problem you mean?
Is there some specific example?
samth [5:38 PM]
Put a eprintf inside some racket/base code. Then use C-c x f
It will complain
Because it'll see the extra output
greg [5:45 PM]

```#lang racket/base
(eprintf "Hi\n")```

I do `C-c x f` and get the "Open require path: " prompt. I type things. It works.
I don't follow.
samth [7:36 PM]
@greg sorry I missed this. I mean add that to racket/base.rkt
So that it prints during the code that racket-mode runs
greg [9:24 PM]
Ah. Interesting. So I _can_ reproduce _that_.
Note it's limited to how that `C-c C-x C-f` aka `racket-open-require-path` command works.
It actually runs this racket file -- https://github.com/greghendershott/racket-mode/blob/master/racket/find-module-path-completions.rkt -- and pipes text back and forth.
To that file I tried parameterizing `error-output-port` to `open-output-nowhere` -- but `racket/base.rkt` is loaded and does the `eprintf` before that parameterization has taken effect.
So I'll have to do this -- filter stderr -- on the Emacs side.
That didn't use to be possible or at least easy AFAIK but I"ll check again.
@samth ^
samth [9:25 PM]
@greg where did you put the parameterization?
greg [9:25 PM]
Inside the `main` submodule around its entire contents.
samth [9:26 PM]
ok and you just run that with `racket find-module-path-completions.rkt`?
greg [9:26 PM]
Yes.
samth [9:26 PM]
So here's an answer which you might or might not like
greg [9:27 PM]
This predates the newer "command server" where things go via TCP, is one reason it does this.
Also I want the typing speed to be fast, and I'm not sure even the new way would be as fast as direct text pipe.
But I could try.
samth [9:27 PM]
write that file in '#%kernel around a submodule that does the work that's written in `racket/base`
greg [9:27 PM]
Oh.
That seems straightforward.
samth [9:28 PM]
so `(module completions '#%kernel (module go racket/base ...) (module* main '#%kernel (dynamic-require '(submod "completions.rkt" go) #f)`
and then put the parameterize around the `dynamic-require`
except that you can't use parameterize in '#%kernel
so you could either mutate the parameter and feel dirty, or use the expansion of `parameterize` and feel dirty
also `open-output-nowhere` isn't actually in '#%kernel
also that doesn't help when I add eprintf to the runtime system
greg [9:30 PM]
I was going to ask, what if you or Matthew does an `eprintf` in `#%kernel`, but at least it would help with racket/base.
Well, maybe I should look again how to tackle it on the Emacs side.
samth [9:31 PM]
certainly it would help my current issue which is just the use of `racket/match`
because the printouts are in the contract system
greg [9:31 PM]
Plain vanilla process buffers mix them, but there's probably a lower-level way I didn't know about when I last looked at this N years ago.