llvm-svn: 157789

Make ctrl-c terminate the current input line and start an empty line, instead of the previous content.

rdar://problem/11412821

llvm-svn: 156510

Move the el_source() call after the section of code which sets up the default "ctrl-r" and "ctrl-w" bindings
so that user-provided .editrc has a chance to override the lldb's default key bindings.

llvm-svn: 156314

Jason Molenda convinced me that we should make ctrl-w on the command line bind to ed-delete-prev-word.
If you have ctrl-w key binding specified with your .editrc file, it will be overridden with ed-delete-prev-word. :-)

llvm-svn: 156230

If the IOChannel has already freed out its m_driver member, and
there's still a character to be read/written (that is, the ^D
character), just skip that char instead of trying to write through
a null object pointer.

llvm-svn: 137421

llvm-svn: 137257

Also made:
(lldb) !<NUM>
(lldb) !-<NUM>
(lldb) !!

work with the history.  For added benefit:

(lldb) !<NUM><TAB>

will insert the command at position <NUM> in the history into the command line to be edited.

This is only partial, I still need to sync up editline's history list with the one kept by the interpreter.

llvm-svn: 134955

Make sure writing asynchronous output only backs up
& overwrites prompt if the IOChannel input reader is the top
input reader.

llvm-svn: 131110

Add ability to search backwards through command
history for a particular substring, using ctrl-r key.

llvm-svn: 130871

Minor cleanup:  When asynchronous output comes along,
back up over and delete the prompt before writing out the
asynchronous output, rather than just going to a new line.

llvm-svn: 130843

Make the driver listen for asynchronous output, rather than
the IOChannel, so that it can be written out even while the
IOChannel is collecting user input.

llvm-svn: 130789

This patch captures and serializes all output being written by the
command line driver, including the lldb prompt being output by
editline, the asynchronous process output & error messages, and
asynchronous messages written by target stop-hooks.

As part of this it introduces a new Stream class,
StreamAsynchronousIO.  A StreamAsynchronousIO object is created with a
broadcaster, who will eventually broadcast the stream's data for a
listener to handle, and an event type indicating what type of event
the broadcaster will broadcast.  When the Write method is called on a
StreamAsynchronousIO object, the data is appended to an internal
string.  When the Flush method is called on a StreamAsynchronousIO
object, it broadcasts it's data string and clears the string.

Anything in lldb-core that needs to generate asynchronous output for
the end-user should use the StreamAsynchronousIO objects.

I have also added a new notification type for InputReaders, to let
them know that a asynchronous output has been written. This is to
allow the input readers to, for example, refresh their prompts and
lines, if desired.  I added the case statements to all the input
readers to catch this notification, but I haven't added any code for
handling them yet (except to the IOChannel input reader).

llvm-svn: 130721

integer. Modified patch from Kirk Beitz.

llvm-svn: 125067

and end-of-file (often control-d).

llvm-svn: 119837

were causing the prompt to be stomped on, mangled or omitted occasionally.

llvm-svn: 115059

o Fixed a crasher when getting it via SBTarget.GetExecutable().

>>> filespec = target.GetExecutable()
Segmentation fault

o And renamed SBFileSpec::GetFileName() to GetFilename() to be consistent with FileSpec::GetFilename().

llvm-svn: 112308

virtual functions and caught some things and did some general code cleanup.

llvm-svn: 108299

llvm-svn: 108029

enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.

llvm-svn: 108009

to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.

To avoid this we now create instances of the lldb_private::Debugger that each 
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack

So now clients should call:

    SBDebugger::Initialize(); // (static function)

    SBDebugger debugger (SBDebugger::Create());
    // Use which ever file handles you wish
    debugger.SetErrorFileHandle (stderr, false);
    debugger.SetOutputFileHandle (stdout, false);
    debugger.SetInputFileHandle (stdin, true);

    // main loop
    
    SBDebugger::Terminate(); // (static function)
    
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.

Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.

llvm-svn: 106615

llvm-svn: 105743

llvm-svn: 105720

llvm-svn: 105619