[PATCH] Fix 5-line offset of edit command

[PATCH] Fix 5-line offset of edit command

[Gary Johnson]

When gdb is paused at a line and I open the current file with the
edit command, gdb uses vim to open the file at the current line, but
the line number given to vim is always too high by 5.

For example, using gdb-12.1 and the gdb-12.1 source, cd to
gdb-12.1/gdb and run gdb on itself.

    $ gdb gdb
    (gdb) b main
    (gdb) run

Gdb will stop at line 25.

    (gdb) edit

will open vim at line 30.  Executing

    :ps -fH

confirms that vim was started with the argument "+30".

The problem appears to be in the edit_command() function in
cli-cmds.c, at line 966 in version 12.1.  The solution is to
delete that line.  The patch is below.

Regards,
Gary

--------------------------------------------------------------------
--- cli-cmds.c.orig     2022-05-01 11:46:31.000000000 -0700
+++ cli-cmds.c  2023-02-11 00:54:01.695108617 -0800
@@ -963,7 +963,6 @@
     {
       if (sal.symtab == 0)
        error (_("No default source file yet."));
-      sal.line += get_lines_to_list () / 2;
     }
   else
     {

Re: [PATCH] Fix 5-line offset of edit command

[Eli Zaretskii]

> Date: Sat, 11 Feb 2023 02:08:14 -0800
> From: Gary Johnson <garyjohn@spocom.com>
> 
> When gdb is paused at a line and I open the current file with the
> edit command, gdb uses vim to open the file at the current line, but
> the line number given to vim is always too high by 5.
> 
> For example, using gdb-12.1 and the gdb-12.1 source, cd to
> gdb-12.1/gdb and run gdb on itself.
> 
>     $ gdb gdb
>     (gdb) b main
>     (gdb) run
> 
> Gdb will stop at line 25.
> 
>     (gdb) edit
> 
> will open vim at line 30.  Executing
> 
>     :ps -fH
> 
> confirms that vim was started with the argument "+30".
> 
> The problem appears to be in the edit_command() function in
> cli-cmds.c, at line 966 in version 12.1.  The solution is to
> delete that line.  The patch is below.

This is probably editor-specific?

But I admit I cannot understand that addition, either.  I could
understand if we were _subtracting_ half the number of lines to list,
for those editors which place the line at the top of the display.

Re: [PATCH] Fix 5-line offset of edit command

[Gary Johnson]

On 2023-02-11, Eli Zaretskii wrote:
> > Date: Sat, 11 Feb 2023 02:08:14 -0800
> > From: Gary Johnson <garyjohn@spocom.com>
> > 
> > When gdb is paused at a line and I open the current file with the
> > edit command, gdb uses vim to open the file at the current line, but
> > the line number given to vim is always too high by 5.
> > 
> > For example, using gdb-12.1 and the gdb-12.1 source, cd to
> > gdb-12.1/gdb and run gdb on itself.
> > 
> >     $ gdb gdb
> >     (gdb) b main
> >     (gdb) run
> > 
> > Gdb will stop at line 25.
> > 
> >     (gdb) edit
> > 
> > will open vim at line 30.  Executing
> > 
> >     :ps -fH
> > 
> > confirms that vim was started with the argument "+30".
> > 
> > The problem appears to be in the edit_command() function in
> > cli-cmds.c, at line 966 in version 12.1.  The solution is to
> > delete that line.  The patch is below.
> 
> This is probably editor-specific?

No, it's not editor-specific.  The command to run the editor is
created at the end of the edit_command() function:


  if ((editor = getenv ("EDITOR")) == NULL)
    editor = "/bin/ex";

  fn = symtab_to_fullname (sal.symtab);

  /* Quote the file name, in case it has whitespace or other special
     characters.  */
  gdb::unique_xmalloc_ptr<char> p
    = xstrprintf ("%s +%d \"%s\"", editor, sal.line, fn);
  shell_escape (p.get (), from_tty);


Specifying the line number to jump to after opening a file by
prefixing the line with a + was standard with early Unix editors and
I think most editors today still support it for compatibility with
programs such as gdb.

> But I admit I cannot understand that addition, either.  I could
> understand if we were _subtracting_ half the number of lines to list,
> for those editors which place the line at the top of the display.

Maybe in some other situation, but not in the situation where the
user wants to open an external editor _at_ a specific line.

As I recall, this used to work long ago, then something changed and
the editor was always opened at line 6, then around 2020 it changed
again to open at the current line plus 5.  I suspect
a copy-and-paste error, but I haven't looked into the history of
that function.

I intended to send this to gdb-patches, but it looks like I wasn't
paying attention to the address and sent it to the general gdb list
instead.

Regards,
Gary

Re: [PATCH] Fix 5-line offset of edit command

[Eli Zaretskii]

> Date: Sat, 11 Feb 2023 14:52:33 -0800
> From: Gary Johnson <garyjohn@spocom.com>
> 
> > > The problem appears to be in the edit_command() function in
> > > cli-cmds.c, at line 966 in version 12.1.  The solution is to
> > > delete that line.  The patch is below.
> > 
> > This is probably editor-specific?
> 
> No, it's not editor-specific.  The command to run the editor is
> created at the end of the edit_command() function:

I meant the effect is editor-specific.  IOW, what exactly does each
editor display when passed a line number.

> As I recall, this used to work long ago, then something changed and
> the editor was always opened at line 6, then around 2020 it changed
> again to open at the current line plus 5.  I suspect
> a copy-and-paste error, but I haven't looked into the history of
> that function.

I tried to look into the history with "git log -L", but got stuck at
the commit that moved the function from another file.  Maybe some Git
expert could suggest how to cross that line?

> I intended to send this to gdb-patches, but it looks like I wasn't
> paying attention to the address and sent it to the general gdb list
> instead.

Yes, it is best to resent to gdb-patches.

Re: [PATCH] Fix 5-line offset of edit command

[Andreas Schwab]

On Feb 12 2023, Eli Zaretskii via Gdb wrote:

> I tried to look into the history with "git log -L", but got stuck at
> the commit that moved the function from another file.  Maybe some Git
> expert could suggest how to cross that line?

There is no preceding history.  The command was added in that commit.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."