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

[Randy Smith]

On Mon, Jul 14, 2014 at 11:01 AM, Todd Fiala <tfiala at google.com> wrote:

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

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.

-- Randy


>
> 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/7c64747e/attachment.html>