On Mon, Apr 22, 2024 at 10:49:29PM +0000, Justin Stitt wrote:
Hi,
On Mon, Apr 22, 2024 at 05:35:53PM +0100, Daniel Thompson wrote:
Inspired by a patch from [Justin][1] I took a closer look at kdb_read().
Despite Justin's patch being a (correct) one-line manipulation it was a tough patch to review because the surrounding code was hard to read and it looked like there were unfixed problems.
This series isn't enough to make kdb_read() beautiful but it does make it shorter, easier to reason about and fixes two buffer overflows and a screen redraw problem!
Signed-off-by: Daniel Thompson daniel.thompson@linaro.org
Seems to work nicely.
There is some weird behavior which was present before your patch and is still present with it (let >< represent cursor position):
[0]kdb> test_ap>< (now press TAB)
[0]kdb> test_aperfmperf>< (so far so good, we got our autocomplete)
[0]kdb> test_ap><erfmperf (now, let's move the cursor back and press TAB again)
[0]kdb> test_aperfmperf><erfmperf
This is because the autocomplete engine is not considering the characters after the cursor position. To be clear, this isn't really a bug but rather a decision to be made about which functionality is desired.
For example, my shell (zsh) will just simply move the cursor back to the end of the complete match instead of re-writing stuff.
Interesting observation. I hadn't realized zsh does that. FWIW default settings for both bash and gdb complete the same way as kdb. Overall that makes me OK with the current kdb behaviour.
However I was curious about this and found "skip-completed-text" in the GNU Readline documentation. I think that would give you zsh-like completion in gdb if you ever want it!
At any rate, Tested-by: Justin Stitt justinstitt@google.com
Thanks.
Daniel.