<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 11:01 AM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank" class="cremed">tfiala@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Randy,<div><br></div><div>If you end up sharing what you do with emacs, I'd love to have a look at some point. (I've spent a good part of my life in emacs :-) )</div>
</div></blockquote><div><br></div><div>I'm happy to share with individuals currently (I'll send you a separate email). I'm holding off on upstreaming/general distribution partially for soak time and partially because I'm not sure what the best way to upstream is (upstream->lldb ==> breakage as emacs moves, upstream->emacs ==> same (though probably not as bad), "best" answer is refactoring gud.el so that there's a tight interface to underlying debuggers and upstreaming only lldb specific code to lld). So I want to be comfortable that it's actually of general value before going through the hassle.</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"><div class="gmail_extra"><div><div class="h5">
<br><br><div class="gmail_quote">On Sun, Jul 13, 2014 at 5:50 PM, Randy Smith <span dir="ltr"><<a href="mailto:rdsmith@chromium.org" target="_blank" class="cremed">rdsmith@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>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><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><span><font color="#888888"><div><br></div><div>-- Randy</div></font></span><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><br>
> On Jul 11, 2014, at 12:33 PM, Randy Smith <<a href="mailto:rdsmith@chromium.org" target="_blank" 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" target="_blank" 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></div><br></div></div>
<br>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" 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><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'">
<tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank" class="cremed"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a class="cremed">650-943-3180</a></font></td></tr></tbody></table><br></div>
</font></span></div>
</blockquote></div><br></div></div>