This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [pushed] Fix PR tui/21216: TUI line breaks regression


On 03/10/2017 05:27 PM, Jan Kratochvil wrote:
> On Fri, 10 Mar 2017 18:20:18 +0100, Pedro Alves wrote:
>> Or maybe do something different.
> 
> Yes, I do know all these problems.  This is why I was going to separate TUI
> output to a different project (with its own non-TCL testsuite) along with
> separating MI, and replacing it all by some sane RPC variant later.
> 	https://git.jankratochvil.net/?p=gdbmicli.git;a=summary
> 

How you love pulling things out of context.  

Bringing up the separation-into-processes issues again suggests you're
thinking of testing at the core <-> TUI interface level.
We could have that too, by writing a unit test.  I thought of writing
one that exercised the tui_file class.  I may still write one.
Thing is, this case calls for a black-box test, to make sure that
final terminal output is how we intended.  That's why I spent the effort
to write the test, and more effort to try to preserve it.  How TUI
communicates with the core of the debugger is completely irrelevant
here.  Whatever testing you think would be appropriate for testing
TUI/ncurses _output_ in your project, we can consider for GDB too.  If
you have ideas for that, please share them.

> But you ditched that 

I didn't "ditch it".  I explained to you, with detail, why in my
opinion that wouldn't be a design we'd want.

> and you were right, there are other debuggers which
> already do it the right way.

I don't think I ever said such a thing.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]