Buffer and print also what follows the last newline

[JereLeppanen]

_print() saves in cli->buffer whatever follows the last newline, but
then just throws it away on the next call. Use cli->buffer by copying
it in front of the new input.

[RobSanders]

I see what you are seeing - the regular prints will ensure the entire buffer is displayed. However if you call cli_bufprint() then while processing that buffer anything after the last newline is dropped, or if there is no newline at all it is also dropped.
Will merge into the upcoming 1.10.8 release.

[RobSanders]

Quick secondary question before I merge this - any specific reason you didn't do a realloc() instead of the malloc() and then manually copying things? Not saying it should be done that way, just curious....

[JereLeppanen]

No reason that I can recall. realloc() would probably be slightly better. I can change that, if you wish.

[RobSanders]

If you want to - go for it. Otherwise I can clean that up in the staging branch.

[RobSanders]

One of the things I've been meaning to do is to make libcli screen dimension aware. Our app that uses libcli does this for output before calling cli_print, so we can do pagination. I'd like to get libcli able to pull screen dimensions from the telnet connect, or from the terminal settings (like from ssh). I had some demo code showing I could get that info (if provided). I'd also provide override so the user could specify the screen settings. Initially this would be for output only, but ideally I'd like to get the line editting to be screen size aware also. Just a matter of finding time. Our team would like this, but it rather far down the list of to-dos.....

[JereLeppanen]

Yeah, we could have pretty long commands at some point, so editing long lines on a narrow screen would be very useful.

I changed the malloc() to realloc(). Also, after changing my test a little I noticed that something was missing from my commit. We need to include the terminating null in the memmove(). Fixed that as well.

[RobSanders]

Do you have an email account you would like me to use in the spec file change log to recognize your contribution? Or I can use my email, but in the comment reference your github handle.

[JereLeppanen]

I see that other github handles have been mentioned in the spec file, so that's fine for me too.