From: Elena Zannoni <ezannoni@redhat.com>
To: Mark Kettenis <kettenis@chello.nl>
Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFA] Fix operate-and-get-next when history list is full
Date: Sat, 17 Aug 2002 17:02:00 -0000 [thread overview]
Message-ID: <15710.58251.750626.979632@localhost.redhat.com> (raw)
In-Reply-To: <200208171003.g7HA3E40042404@elgar.kettenis.dyndns.org>
Mark Kettenis writes:
> Hi Elena,
>
> The attached patch fixes a problem with operate-and-get-next when the
> history list is full. In that case, when executing a command, the
> oldest entry is removed from the history, all other entries are moved
> "up", and a new entry is put at the end of the list. In that case we
> shouldn't increase the current line by one the find the next line.
> bash contains similar code as my patch adds.
>
> OK to apply?
>
Sure.
Elena
> Mark
>
>
> Index: ChangeLog
> from Mark Kettenis <kettenis@gnu.org>
>
> * top.c (gdb_rl_operate_and_get_next): Make sure
> operate-and-get-next functions correctly even when the history
> list is completely filled.
>
> Index: top.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/top.c,v
> retrieving revision 1.65
> diff -u -p -r1.65 top.c
> --- top.c 24 Jul 2002 17:58:46 -0000 1.65
> +++ top.c 17 Aug 2002 09:58:17 -0000
> @@ -1082,6 +1082,8 @@ gdb_rl_operate_and_get_next_completion (
> static int
> gdb_rl_operate_and_get_next (int count, int key)
> {
> + int where;
> +
> if (event_loop_p)
> {
> /* Use the async hook. */
> @@ -1094,8 +1096,20 @@ gdb_rl_operate_and_get_next (int count,
> rl_pre_input_hook = (Function *) gdb_rl_operate_and_get_next_completion;
> }
>
> - /* Add 1 because we eventually want the next line. */
> - operate_saved_history = where_history () + 1;
> + /* Find the current line, and find the next line to use. */
> + where = where_history();
> +
> + /* FIXME: kettenis/20020817: max_input_history is renamed into
> + history_max_entries in readline-4.2. When we do a new readline
> + import, we should probably change it here too, even though
> + readline maintains backwards compatibility for now by still
> + defining max_input_history. */
> + if ((history_is_stifled () && (history_length >= max_input_history)) ||
> + (where >= history_length - 1))
> + operate_saved_history = where;
> + else
> + operate_saved_history = where + 1;
> +
> return rl_newline (1, key);
> }
> \f
next prev parent reply other threads:[~2002-08-18 0:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-17 3:03 Mark Kettenis
2002-08-17 17:02 ` Elena Zannoni [this message]
2002-08-18 5:39 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15710.58251.750626.979632@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox