Patch: operate-and-get-next

Patch: operate-and-get-next

[Tom Tromey]

One of my favorite features in Bash is called operate-and-get-next.
This is a readline function bound to Control-o.  It lets you easily
repeat a sequence of commands from history.

What you do is use C-p to find the first command in a sequence.  You
use C-o to execute it (like pressing Enter), and when the next prompt
comes up, the next command from history is already inserted for you.

This makes it really easy to repeat something like a loop or other
complex sequence -- just find the start and hit C-o many times until
it is done.

I still use the Insight console quite a bit, and I really miss this
feature.  So today I implemented it.  The patch is appended.  Is this
ok to commit?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* library/console.itb (Console::_operate_and_get_next): New method.
	(Console::_setprompt): Insert next history element if requested.
	(Console::_build_win): Bind C-o to _operate_and_get_next.
	* library/console.ith (_operate_and_get_next): Declare.
	(_pendingHistElement): New variable.

Index: library/console.itb
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/console.itb,v
retrieving revision 1.11
diff -u -r1.11 console.itb
--- library/console.itb 2001/06/01 20:05:55 1.11
+++ library/console.itb 2001/09/28 16:12:42
@@ -65,9 +65,6 @@
   #
   bind $_twin <Return> "$this invoke; break"
 
-  # disable this
-  bind_plain_key $_twin Control-o "break"
-
   # History control.
   bind_plain_key $_twin Control-p "[code $this _previous]; break"
   bind $_twin <Up> "[code $this _previous]; break"
@@ -77,7 +74,8 @@
   bind $_twin <Home> "[code $this _first]; break"
   bind $_twin <Meta-greater> "[code $this _last]; break"
   bind $_twin <End> "[code $this _last]; break"
-  
+  bind_plain_key $_twin Control-o "[code $this _operate_and_get_next]; break"
+
   # Tab completion
   bind_plain_key $_twin KeyPress-Tab "[code $this _complete]; break"
   
@@ -244,6 +242,21 @@
 }
 
 #-------------------------------------------------------------------
+#  METHOD:  _operate_and_get_next - Invoke the current command and,
+#           if this command came from the history, arrange for the
+#           next history command to be inserted once this command
+#           is finished.
+# ------------------------------------------------------------------
+body Console::_operate_and_get_next {} {
+  if {$_histElement >= 0} {
+    # _pendingHistElement will be used after the new history element
+    # is pushed.  So we must increment it.
+    set _pendingHistElement [expr {$_histElement + 1}]
+  }
+  invoke
+}
+
+#-------------------------------------------------------------------
 #  METHOD:  _previous - recall the previous command
 # ------------------------------------------------------------------
 body Console::_previous {} {
@@ -368,6 +381,12 @@
   $_twin insert {insert linestart} $prompt prompt_tag
   $_twin mark set cmdmark "insert -1 char"
   $_twin see insert
+
+  if {$_pendingHistElement >= 0} {
+    set _histElement $_pendingHistElement
+    set _pendingHistElement -1
+    _next
+  }
 }
 
 #-------------------------------------------------------------------
Index: library/console.ith
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/console.ith,v
retrieving revision 1.5
diff -u -r1.5 console.ith
--- library/console.ith 2001/05/31 20:32:57 1.5
+++ library/console.ith 2001/09/28 16:12:42
@@ -50,6 +50,7 @@
     variable _saved_insertion ""
     variable _running 0
     variable _saw_tab 0
+    variable _pendingHistElement -1
 
     method _build_win {}
     method _complete {}
@@ -59,6 +60,7 @@
     method _first {}
     method _last {}
     method _next {}
+    method _operate_and_get_next {}
     method _paste {{check_primary 1}}
     method _previous {}
     method _reset_tab {}

Re: Patch: operate-and-get-next

[Keith Seitz]

On 28 Sep 2001, Tom Tromey wrote:

> One of my favorite features in Bash is called operate-and-get-next.
> This is a readline function bound to Control-o.  It lets you easily
> repeat a sequence of commands from history.

Nope, sorry. I cannot accept this. This would be a new feature, and we
cannot implement new features until the sun goes super-nova. Sorry.

> What you do is use C-p to find the first command in a sequence.  You
> use C-o to execute it (like pressing Enter), and when the next prompt
> comes up, the next command from history is already inserted for you.

This is too cool. I never even knew this existed! :-)

> I still use the Insight console quite a bit, and I really miss this
> feature.  So today I implemented it.  The patch is appended.  Is this
> ok to commit?

I use the console quite a bit, too, but I do it 75% of the time because it
helps elide problems with gdb and insight getting out of sync.(Try up/down
in the console window. It doesn't work properly.)

I have one very little nit...

>  #-------------------------------------------------------------------
> +#  METHOD:  _operate_and_get_next - Invoke the current command and,
> +#           if this command came from the history, arrange for the
> +#           next history command to be inserted once this command
> +#           is finished.
> +# ------------------------------------------------------------------

Could you change this to the "new" comment format? I know, this isn't
documented anywhere... I started doing this in regwin.it[hb] when I
tweaked the register window. I'm gonna try to stay consistent in its use
for new work. This'll help me track what has been touched recently and
what is still "legacy" code.

Something like:

# ------------------------------------------------------------------
#  NAME:         ConsoleWin::_operate_and_get_next
#  DESCRIPTION:  Invokes the current command and, if this
#                command came from the history, arrange for
#                the next history command to be inserted once this
#                command is finished.
#
#  ARGUMENTS:    None
#  RETURNS:      Nothing
# ------------------------------------------------------------------

Otherwise, APPROVED! :-) (Wow, a new feature. Where's my champagne?)

Now all we need to do is get ^R working...
Keith

Re: Patch: operate-and-get-next

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

>> What you do is use C-p to find the first command in a sequence.  You
>> use C-o to execute it (like pressing Enter), and when the next prompt
>> comes up, the next command from history is already inserted for you.

Keith> This is too cool. I never even knew this existed! :-)

Yeah.  I've used it every day since I first found out about it.

Keith> I use the console quite a bit, too, but I do it 75% of the time
Keith> because it helps elide problems with gdb and insight getting
Keith> out of sync.(Try up/down in the console window. It doesn't work
Keith> properly.)

Yeah.  I've noticed other things like this, but offhand I don't recall
what they are.  I'll try to start submitting PRs when I find them.  I
know the console is a low priority; that's fine.  But we should still
keep track of these problems.  I'll submit the up/down one.

Keith> Could you change this to the "new" comment format? I know, this
Keith> isn't documented anywhere... I started doing this in
Keith> regwin.it[hb] when I tweaked the register window.

No problem, especially given that you wrote it for me :-)

Keith> Otherwise, APPROVED! :-) (Wow, a new feature. Where's my
Keith> champagne?)

It's in.

Keith> Now all we need to do is get ^R working...

That would be a lot more work :-(

Tom

Re: Patch: operate-and-get-next

[Keith Seitz]

On 28 Sep 2001, Tom Tromey wrote:

> Yeah.  I've noticed other things like this, but offhand I don't recall
> what they are.  I'll try to start submitting PRs when I find them.  I
> know the console is a low priority; that's fine.  But we should still
> keep track of these problems.  I'll submit the up/down one.

Good thinking. I really need to browse through the db and see what's in
there! (Ahem!) O:-)

> Keith> Otherwise, APPROVED! :-) (Wow, a new feature. Where's my
> Keith> champagne?)
>
> It's in.

THANKS!!! Wow, I feel good suddenly.

Keith

Re: Patch: operate-and-get-next

[John R. Moore]

Keith, Tom,

I've used this feature in tcsh (using emacs syntax) and one
uses ESC-p and ESC-n to get at the historical command. I've
wondered how to do it in bash, but never bothered to look.

Now that I'm enlighten'd, I might use bash more often. :-)

BTW, there is C-n  to go up the history (if you go too many C-p's)

Don't forget to implement the C-n as well!!

Cheers,

John Moore

-------------------------------

On Fri, 28 Sep 2001, Keith Seitz wrote:

> On 28 Sep 2001, Tom Tromey wrote:
>
> > One of my favorite features in Bash is called operate-and-get-next.
> > This is a readline function bound to Control-o.  It lets you easily
> > repeat a sequence of commands from history.
>
> Nope, sorry. I cannot accept this. This would be a new feature, and we
> cannot implement new features until the sun goes super-nova. Sorry.
>
> > What you do is use C-p to find the first command in a sequence.  You
> > use C-o to execute it (like pressing Enter), and when the next prompt
> > comes up, the next command from history is already inserted for you.
>
> This is too cool. I never even knew this existed! :-)
>
> > I still use the Insight console quite a bit, and I really miss this
> > feature.  So today I implemented it.  The patch is appended.  Is this
> > ok to commit?
>
> I use the console quite a bit, too, but I do it 75% of the time because it
> helps elide problems with gdb and insight getting out of sync.(Try up/down
> in the console window. It doesn't work properly.)
>
> I have one very little nit...
>
> >  #-------------------------------------------------------------------
> > +#  METHOD:  _operate_and_get_next - Invoke the current command and,
> > +#           if this command came from the history, arrange for the
> > +#           next history command to be inserted once this command
> > +#           is finished.
> > +# ------------------------------------------------------------------
>
> Could you change this to the "new" comment format? I know, this isn't
> documented anywhere... I started doing this in regwin.it[hb] when I
> tweaked the register window. I'm gonna try to stay consistent in its use
> for new work. This'll help me track what has been touched recently and
> what is still "legacy" code.
>
> Something like:
>
> # ------------------------------------------------------------------
> #  NAME:         ConsoleWin::_operate_and_get_next
> #  DESCRIPTION:  Invokes the current command and, if this
> #                command came from the history, arrange for
> #                the next history command to be inserted once this
> #                command is finished.
> #
> #  ARGUMENTS:    None
> #  RETURNS:      Nothing
> # ------------------------------------------------------------------
>
> Otherwise, APPROVED! :-) (Wow, a new feature. Where's my champagne?)
>
> Now all we need to do is get ^R working...
> Keith
>
>
>
>

Re: Patch: operate-and-get-next

[Tom Tromey]

>>>>> "John" == John R Moore <jmoore@redhat.com> writes:

John> BTW, there is C-n  to go up the history (if you go too many C-p's)
John> Don't forget to implement the C-n as well!!

The Insight console has had C-n and C-p bindings for traversing
history for a long time -- from when it was first written.  My patch
just adds the C-o binding.

Tom

Re: Patch: operate-and-get-next

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

Keith> (Try up/down in the console window. It doesn't work properly.)

I looked into this a bit.  It turns out we already have some of the
machinery in place to make it work correctly.  All that remains is
making selected_frame_level_changed_hook do a little more work.

I came up with the appended patch.

Unfortunately, if you try this patch you'll see weird behavior.  When
you first run your program the source window will go through a few
gyrations, first displaying nothing, then briefly (for me anyway)
displaying some assembly, before finally settling on the breakpoint on
main().

I think this is distracting enough to make this patch not acceptable :-(.
I really don't know how to fix it.

(Checking that gdb_selected_frame_level != -1 in
gdbtk_tcl_selected_frame_changed helps, but still doesn't suffice.)

Any ideas?

Tom

Index: ChangeLog
from  Tom Tromey  <tromey@redhat.com>
	* library/stackwin.itb (StackWin::change_frame): Don't call
	gdbtk_update.
	* library/srcwin.itb (SrcWin::stack): Don't call gdbtk_update.
	* generic/gdbtk-hooks.c (gdbtk_selected_frame_changed): Invoke
	gdbtk_tcl_selected_frame_changed.
	* library/interface.tcl (gdbtk_tcl_selected_frame_changed): New
	proc.

Index: generic/gdbtk-hooks.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-hooks.c,v
retrieving revision 1.18
diff -u -r1.18 gdbtk-hooks.c
--- generic/gdbtk-hooks.c 2001/08/16 15:48:14 1.18
+++ generic/gdbtk-hooks.c 2001/09/28 17:10:24
@@ -769,6 +769,7 @@
      int level;
 {
   Tcl_UpdateLinkedVar (gdbtk_interp, "gdb_selected_frame_level");
+  Tcl_GlobalEval (gdbtk_interp, "gdbtk_tcl_selected_frame_changed");
 }
 
 /* Called when the current thread changes. */
Index: library/interface.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/interface.tcl,v
retrieving revision 1.29
diff -u -r1.29 interface.tcl
--- library/interface.tcl 2001/08/13 18:30:36 1.29
+++ library/interface.tcl 2001/09/28 17:10:25
@@ -1751,3 +1751,8 @@
   GDBEventHandler::dispatch $e
   delete object $e
 }
+
+# The selected frame changed.  Inform the UI.
+proc gdbtk_tcl_selected_frame_changed {} {
+  gdbtk_update
+}
Index: library/srcwin.itb
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/srcwin.itb,v
retrieving revision 1.16
diff -u -r1.16 srcwin.itb
--- library/srcwin.itb 2001/08/24 00:11:06 1.16
+++ library/srcwin.itb 2001/09/28 17:10:26
@@ -480,7 +480,6 @@
   if {[catch {gdb_cmd "$cmd"} message]} {
     dbug E "STACK ERROR: $message"
   }
-  gdbtk_update
   gdbtk_idle
 }
 
Index: library/stackwin.itb
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/stackwin.itb,v
retrieving revision 1.5
diff -u -r1.5 stackwin.itb
--- library/stackwin.itb 2001/08/20 19:14:09 1.5
+++ library/stackwin.itb 2001/09/28 17:10:26
@@ -120,11 +120,6 @@
     set size [$itk_component(slb) size]
     set frame_num [expr {$size - $sel - 1}]
     catch {gdb_cmd "frame $frame_num"}
-    
-    # Run idle hooks and cause all widgets to update
-    set protect_me 1
-    gdbtk_update
-    set protect_me 0
     gdbtk_idle
   }
 }

Re: Patch: operate-and-get-next

[Keith Seitz]

On 28 Sep 2001, Tom Tromey wrote:

> I looked into this a bit.  It turns out we already have some of the
> machinery in place to make it work correctly.  All that remains is
> making selected_frame_level_changed_hook do a little more work.

Did I mention that I, too, have a patch to fix this? Well, I have
something, but it's not good enough. Basically, we've got to rewrite the
command line to use some interface that allows for notifications.

The machinery for this in gdb is very, very twisted. (Be forewarned that
very soon gdbtk_update will be DEPRECATED: a nop.)

In any case, at one time I recall thinking that I knew of a way to "fix"
this, even if it is ugly. The problem is, we really only want to know when
the user changes the frame on us. NOT when gdb's internals change the
frame on us. This is the subtlety that I shoehorned around, adding event
notifiers to up/down command. :-)

Keith

Re: Patch: operate-and-get-next

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

Keith> Did I mention that I, too, have a patch to fix this? Well, I
Keith> have something, but it's not good enough. Basically, we've got
Keith> to rewrite the command line to use some interface that allows
Keith> for notifications.

Ok, I'll drop my patch.  Thanks.

Keith> The problem is, we really only want to know when the user
Keith> changes the frame on us. NOT when gdb's internals change the
Keith> frame on us. This is the subtlety that I shoehorned around,
Keith> adding event notifiers to up/down command. :-)

Good idea.  Sounds like a pain though.

Tom

Re: Patch: operate-and-get-next

[Keith Seitz]

On 28 Sep 2001, Tom Tromey wrote:

> Keith> The problem is, we really only want to know when the user
> Keith> changes the frame on us. NOT when gdb's internals change the
> Keith> frame on us. This is the subtlety that I shoehorned around,
> Keith> adding event notifiers to up/down command. :-)
>
> Good idea.  Sounds like a pain though.

It is. That's why I stopped fiddling with it. As it is, I am still sitting
on the uiout builder for Insight and some other changes which will whack
TONS of code. I barely remember some of that stuff, but I'm afraid to do
too many engaging things: I seem to be forgetting a lot of things, never
getting any of them done. I guess I'm gettin' old. ;-)

Keith