Re: keeping commands out of the history

Re: keeping commands out of the history

[Todd Whitesel]

> Well, when I say hooks, I mean hooks in emacs; I'm not sure if that was clear.
> As far as gdb knows, they're normal commands.

Ah.

I'm not too familiar with the emacs/GDB hookup but I assume it involves
GDB's stdin being fed by emacs, or else you wouldn't have this problem.

The second input argument to command_line_input() (see gdb/top.c) is nonzero
to enable the return-repeat machinery. In 4.17 there is no set/show option.

You could define an escape sequence to be sent by emacs at the start of the
command, and slip some code into command_line_input() that searches for the
sequence, and if found deletes it while clearing the 'repeat' argument. That
would enable your emacs machinery to 'hide' any command that it wanted.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: keeping commands out of the history

[Todd Sabin]

Jim Blandy wrote:
> 
> As far as the command-line history is concerned, if you prefix your
> command with "server ", it won't go in the command history, it won't have
> csh-style !-expansion done, and "server" followed by nothing doesn't
> repeat the previous command.
> 
> This doesn't affect the value history, though; you'll still need to
> use "output".

Many thanks, exactly what I was looking for...  :)


Todd

Re: keeping commands out of the history

[Jim Blandy]

> This sounds good, but I also want to do 'info registers', 'where',
> and probably 'info breakpoints' in the future, so I'm really looking
> for something a little more general.

As far as the command-line history is concerned, if you prefix your
command with "server ", it won't go in the command history, it won't have
csh-style !-expansion done, and "server" followed by nothing doesn't
repeat the previous command.

This doesn't affect the value history, though; you'll still need to
use "output".

Re: keeping commands out of the history

[Todd Sabin]

Todd Whitesel wrote:
> 
> I have the code you need, but it is currently tied to a custom command we
> use here.
> 
> It is easy for me to implement a whole new command that is like 'print' or
> 'inspect' but does not add to the value history, and submit the patches.
> Would this work for you?
> 

This sounds good, but I also want to do 'info registers', 'where', and probably
'info breakpoints' in the future, so I'm really looking for something a
little more general.


Todd Sabin

Re: keeping commands out of the history

[Todd Sabin]

Todd Whitesel wrote:
> > Currently, if I type 'next' at the gdb prompt, it gets executed and my
> > hooks do, e.g., 'info registers', and put the output in a different buffer.
> > If I then type '<RET>' at the gdb prompt, it runs 'info registers' again,
> > not 'next'.  I want to it run 'next'.
> 
> Perhaps what you really want is for _hooks_ to be kept out of the value
> history. That sounds to me like a good thing, if it isn't already true.
> 

Well, when I say hooks, I mean hooks in emacs; I'm not sure if that was clear.
As far as gdb knows, they're normal commands.


Todd

Re: keeping commands out of the history

[Todd Whitesel]

> No, I'm talking about both the command and value history.  I want to
> be able to send commands to and receive output from gdb without it
> having any impact on what someone typing commands at the prompt sees.
> Currently, if I type 'next' at the gdb prompt, it gets executed and my
> hooks do, e.g., 'info registers', and put the output in a different buffer.
> If I then type '<RET>' at the gdb prompt, it runs 'info registers' again,
> not 'next'.  I want to it run 'next'.

Perhaps what you really want is for _hooks_ to be kept out of the value
history. That sounds to me like a good thing, if it isn't already true.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: keeping commands out of the history

[Tom Tromey]

>>>>> "Todd" == Todd Whitesel <toddpw@wrs.com> writes:

Todd> It is easy for me to implement a whole new command that is like
Todd> 'print' or 'inspect' but does not add to the value history, and
Todd> submit the patches.  Would this work for you?

It's already been done:

    creche. gdb
    GNU gdb 4.17.2
    Copyright 1998 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i686-pc-linux-gnu".
    (gdb) help output
    Like "print" but don't put in value history and don't print newline.
    This is useful in user-defined commands.

Tom

Re: keeping commands out of the history

[Todd Sabin]

> >>>>> "Todd" == Todd Sabin <tastas@home.com> writes:
> 
> Todd> This sounds good, but I also want to do 'info registers',
> Todd> 'where', and probably 'info breakpoints' in the future, so I'm
> Todd> really looking for something a little more general.
> 
> I don't think any of these add to the value history.
> Or was that not what you were asking for?
> 

No, I'm talking about both the command and value history.  I want to
be able to send commands to and receive output from gdb without it
having any impact on what someone typing commands at the prompt sees.
Currently, if I type 'next' at the gdb prompt, it gets executed and my
hooks do, e.g., 'info registers', and put the output in a different buffer.
If I then type '<RET>' at the gdb prompt, it runs 'info registers' again,
not 'next'.  I want to it run 'next'.


Todd

Re: keeping commands out of the history

[Todd Whitesel]

>This sounds good, but I also want to do 'info registers', 'where', and probably
>'info breakpoints' in the future, so I'm really looking for something a
>little more general.

Oops, I thought you were talking about the value history.

Command history is something else entirely.

-- 
Todd Whitesel
toddpw @ wrs.com

keeping commands out of the history

[Todd Sabin]

Hi,

I'm playing with emacs's gud.el to make it display some stuff from
gdb in other buffers.  The problem is that the commands used to get the
data go into gdb's history, which is not intended.  I looked for some
option for temporarily bypassing command history, but didn't find anything.

It seems that DDD is able to do this.  I looked at its source for a bit,
but didn't see anything special it's doing.

Does anyone know if there's a way to do what I'm talking about, or how
DDD seems to manage to do it?

TIA,


Todd

Re: keeping commands out of the history

[Todd Whitesel]

> I'm playing with emacs's gud.el to make it display some stuff from
> gdb in other buffers.  The problem is that the commands used to get the
> data go into gdb's history, which is not intended.  I looked for some
> option for temporarily bypassing command history, but didn't find anything.
> 
> It seems that DDD is able to do this.  I looked at its source for a bit,
> but didn't see anything special it's doing.
> 
> Does anyone know if there's a way to do what I'm talking about, or how
> DDD seems to manage to do it?

I have the code you need, but it is currently tied to a custom command we
use here.

It is easy for me to implement a whole new command that is like 'print' or
'inspect' but does not add to the value history, and submit the patches.
Would this work for you?

-- 
Todd Whitesel
toddpw @ wrs.com

Re: keeping commands out of the history

[Tom Tromey]

>>>>> "Todd" == Todd Sabin <tastas@home.com> writes:

Todd> This sounds good, but I also want to do 'info registers',
Todd> 'where', and probably 'info breakpoints' in the future, so I'm
Todd> really looking for something a little more general.

I don't think any of these add to the value history.
Or was that not what you were asking for?

Tom

Re: keeping commands out of the history

[Todd Whitesel]

> It's already been done:
...
>     (gdb) help output
>     Like "print" but don't put in value history and don't print newline.
>     This is useful in user-defined commands.

Not the same. print_command_1 has more intelligence (vtables, inspect_it).

-- 
Todd Whitesel
toddpw @ wrs.com