[lldb-dev] Seeking guidance on fixing an IOHandlerEditLine Hide/Refresh problem

[Greg Clayton]

One option would be to redirect stdin/out/err when you launch your process:

(lldb) process launch --stdin /path/to/stdin.txt --stdout /path/to/stdout.txt --stderr /path/to/stderr.txt

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!

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?

Greg

> On Jul 11, 2014, at 12:33 PM, Randy Smith <rdsmith at chromium.org> wrote:
> 
> 
> [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.]
> 
> 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.
> 
> 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().
> 
> 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.  
> 
> Anyone have any thoughts?  (Including "This is minor and fixing it would be a hassle; live with it" :-})
> 
> -- Randy
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev