<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 11, 2014 at 7:10 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank" class="cremed">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One option would be to redirect stdin/out/err when you launch your process:<br>
<br>
(lldb) process launch --stdin /path/to/stdin.txt --stdout /path/to/stdout.txt --stderr /path/to/stderr.txt<br>
<br>
Not sure if you could make a new emacs buffer that could hook up the in/out/err file handles to the inferior process? If you do that, then no eBroadcastBitSTDOUT will be sent!<br>
<br>
I don't know much about the emacs, but it seems like this might be nice to get all of your process input/output in a separate window?<br></blockquote><div><br></div><div>Hmm.  Yes, that's probably the right choice.  it doesn't fit with how emacs currently wraps its debuggers, but that wrapping is sort of half IDE/half CLI, rather than one or the other (it puts the debugger CLI in what's effectively a shell window, and eavesdrops on communications to keep the source window pointing at the right code).  This would be a better user experience, and would be the right choice for a "real" IDE, so it's likely the right answer as far as LLDB is concerned.  </div>
<div><br></div><div>Thanks for the idea!</div><div><br></div><div>-- Randy</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Greg<br>
<div><div class="h5"><br>
> On Jul 11, 2014, at 12:33 PM, Randy Smith <<a href="mailto:rdsmith@chromium.org" class="cremed">rdsmith@chromium.org</a>> wrote:<br>
><br>
><br>
> [Caveat: This is a minor issue, but it's annoying to me, so I'd like to at least explore how to fix it properly before giving up.]<br>
><br>
> So my standard use of lldb is inside of gud-mode in emacs.  In that mode, I believe line editing is disabled (the output of lldb is a dumb terminal that emacs wraps).  As a result, IOHandlerEditLine::Hide and Refresh are not balanced; Hide() does nothing, and Refresh() re-prints the prompt.<br>

><br>
> The result of this is that when I'm debugging an inferior that has a lot of output, I get many copies of the (lldb) prompt interwoven with the output.  I've traced this behavior to Debugger::HandleProcessEvent() being called repeatedly with event_type Process::eBroadcastBitSTDOUT.  In such a situation, it calls HideTopIOHandler(), copies the output out, and then calls RefreshTopIOHandler().<br>

><br>
> The behavior that I personally think would be ideal in this configuration would be for the prompt only to be refreshed if an inferior event *other* than stdout or stderr occurs.  And I can code that in Debugger::HandleProcessEvent() pretty easily by only calling refresh if some other event is occurs, but that's clearly the wrong architectural choice (because it breaks the Hide/Refresh contract on IOHandler).  Maybe adding an argument to RefreshTopIOHandler indicating if the refresh was requested because anything other than output was copied?  I'm almost tempted to just pass in the event type, but it doesn't really make sense that IOHandlers know about the Process broadcast constants.<br>

><br>
> Anyone have any thoughts?  (Including "This is minor and fixing it would be a hassle; live with it" :-})<br>
><br>
> -- Randy<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" class="cremed">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div></div>