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

[Todd Fiala]

Hey Randy,

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 :-) )


On Sun, Jul 13, 2014 at 5:50 PM, Randy Smith <rdsmith at chromium.org> wrote:

>
>
>
> On Fri, Jul 11, 2014 at 7:10 PM, Greg Clayton <gclayton at apple.com> wrote:
>
>> 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?
>>
>
> 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.
>
> Thanks for the idea!
>
> -- Randy
>
>
>> 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
>>
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140714/49fd9356/attachment.html>