diff options
author | Pedro Alves <palves@redhat.com> | 2019-06-13 00:06:52 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2019-06-13 00:06:52 +0100 |
commit | 00b56dbe7016bc33f882525a47faab943fdeda9a (patch) | |
tree | ddf551efcbf295a750aaa6880eee2704b579b37e /README | |
parent | e4c4ac46e8e7ef92311181f85b193af369897151 (diff) | |
download | fsf-binutils-gdb-00b56dbe7016bc33f882525a47faab943fdeda9a.zip fsf-binutils-gdb-00b56dbe7016bc33f882525a47faab943fdeda9a.tar.gz fsf-binutils-gdb-00b56dbe7016bc33f882525a47faab943fdeda9a.tar.bz2 |
Fix latent bug in custom word point completion handling
Without this fix, if we switch the "print" completer to custom word
point handling, we regress gdb.base/completion.exp like this:
(gdb) p "break1.c FAIL: gdb.base/completion.exp: complete 'p "break1' (timeout)
The problem is that completing an expression that starts with double
quotes, and resolves to a filename, like this:
(gdb) p "break1[TAB]
would change from this, with current master:
(gdb) p "break1.c"|
^^^^^^^^^^|
\- cursor here
to this:
(gdb) p "break1.c |
^^^^^^^^^^|
\- quote replaced by space
The issue is that completer.c:advance_to_completion_word misses
telling the completion tracker to emulate readline's handling of
completing a string when rl_find_completion_word returns a delimiter.
This commit fixes the latent bug.
gdb/ChangeLog:
2019-06-13 Pedro Alves <palves@redhat.com>
* completer.c (advance_to_completion_word): Handle delimiters.
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions