Loading ...
Sorry, an error occurred while loading the content.

RE: VimGDB future

Expand Messages
  • Xavier de Gaye
    On Tue, 30 Mar 2004, Bram Moolenaar wrote: [...] ... Not exactly. GDB commands are entered through the Vim command line with `:call gdb( GDB_command ) or with
    Message 1 of 29 , Apr 2, 2004
    • 0 Attachment
      On Tue, 30 Mar 2004, Bram Moolenaar wrote:

      [...]

      > > The gdb console is a Vim window. It gets syntax color
      > > highlighting, can be resized and pointed to by the mouse as
      > > a regular Vim window and buffer. This is simple. Maybe I
      > > miss what you mean by colors, mouse pointer, resizing.
      >
      > I didn't look into VimGDB, but I assume it was implemented using a Vim
      > buffer to show the gdb output and enter new gdb commands. Thus you are
      > simulating a terminal through a Vim buffer.
      >

      Not exactly.

      GDB commands are entered through the Vim command line with
      `:call gdb("GDB_command")' or with a "GDB_command" typed in a
      window input-line.
      When characters are typed in the gdb console window, they
      just get inserted in the buffer, that's all. The gdb console
      is really a regular Vim window.

      Also, the gdb console is not frozen when Vim is busy with
      something in normal mode. When the user types "12345"
      followed by <Escape>. "12345^[" disappears from the command
      line after the normal 'timeoutlen' time out while in the
      mean time VimGDB displays output from GDB in the gdb console.

      [...]

      > What is done with NetBeans and Agide is to add the menus and toolbar
      > items in Vim. You only need a window to run gdb in, and filter out the
      > annotations.
      >
      > Sketch:
      >
      > +==============+ +==============+
      > | | | |
      > | gdb window | | VIM window |
      > | | | |
      > +==============+ +==============+
      > | (1) | (2)
      > | |
      > +--------------+ +--------------+
      > | | | |
      > | VimGDB' |---------| VIM |
      > | | (3) | |
      > +--------------+ +--------------+
      > | (4)
      > |
      > +--------------+
      > | |
      > | gdb |
      > | |
      > +--------------+
      >
      >
      > And then have "gdb window" and "VIM window" run in a split xterm. Or
      > two xterms, or an xterm and gvim, that doesn't really matter.
      >
      > (1) gdb terminal I/O (with annotations filtered out)
      > (2) Vim terminal I/O
      > (3) client-server or NetBeans interface
      > (4) gdb terminal I/O (including annotations)
      >
      > Of these only (3) may need to be improved.
      >
      > --

      In your sketch:

      The "gdb window" needs features such as scrolling and
      searching. It needs also displaying the current state of
      GDB. When VimGDB supports management of GDB variables, the
      "gdb window" needs some kind of windowing capabilities, and
      maybe highlighting to indicate a changed or out of scope
      variable. When VimGDB supports setting breakpoints in
      assembly code and stepi(ing) through this code, the
      "gdb window" needs also windows and maybe something like Vim
      signs.

      It is important to have the "gdb window" preserve Vim
      look-and-feel.

      A solution is to have all those windows (gdb console, asm
      windows, variables window) displayed in "VIM window" instead
      of in the "gdb window". Those windows are controlled
      (created, updated) by VimGDB through (3). This does follow
      your sketch. The "gdb window" user interface is mainly
      reduced to just one command line, the one used to type GDB
      commands.

      From a functional point of view, the drawbacks of this
      solution as compared to the features currently supported
      by VimGDB patch 6 (the Vim feature included into Vim, see
      http://skawina.eu.org/mikolaj/vimgdb/gdb.html) are:

      . a requirement for two terminals or a tool such as
      "screen"

      . when using "screen" with a split screen, 3/4 lines are
      lost (2 are screen window status lines, 1/2 is the
      "gdb window" command line); however, "screen" can
      also be unsplit in two screens from a split
      screen when GDB is not used for a while, no lines
      are lost then

      . there is no syntax highlighting when typing GDB
      commands in the "gdb window" (there could be, but
      the effort to implement that seems disproportionate)

      . it may be felt that using a command line where all
      standard output goes to another application is unusual

      Does this setup fulfills the expectations of those of us
      who prefer to use Vim and GDB without an IDE ?

      Xavier...



      __________________________________________________________________
      Introducing the New Netscape Internet Service.
      Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

      Netscape. Just the Net You Need.

      New! Netscape Toolbar for Internet Explorer
      Search from anywhere on the Web and block those annoying pop-ups.
      Download now at http://channels.netscape.com/ns/search/install.jsp
    • Bram Moolenaar
      ... I can see this is useful to be able to create mappings that invoke gdb commands, but I would really want be able to type gdb commands and use the clever
      Message 2 of 29 , Apr 2, 2004
      • 0 Attachment
        Xavier de Gaye wrote:

        > > > The gdb console is a Vim window. It gets syntax color
        > > > highlighting, can be resized and pointed to by the mouse as
        > > > a regular Vim window and buffer. This is simple. Maybe I
        > > > miss what you mean by colors, mouse pointer, resizing.
        > >
        > > I didn't look into VimGDB, but I assume it was implemented using a Vim
        > > buffer to show the gdb output and enter new gdb commands. Thus you are
        > > simulating a terminal through a Vim buffer.
        >
        > Not exactly.
        >
        > GDB commands are entered through the Vim command line with
        > `:call gdb("GDB_command")' or with a "GDB_command" typed in a
        > window input-line.

        I can see this is useful to be able to create mappings that invoke gdb
        commands, but I would really want be able to type gdb commands and use
        the clever completion that gdb offers. And have the gdb commands and
        their output in sequential order.

        > When characters are typed in the gdb console window, they
        > just get inserted in the buffer, that's all. The gdb console
        > is really a regular Vim window.

        Thus a window that only shows the gdb output, not being able to type gdb
        commands there? I would think that's a bit strange for someone who has
        used gdb in a terminal.

        > [...]
        >
        > > What is done with NetBeans and Agide is to add the menus and toolbar
        > > items in Vim. You only need a window to run gdb in, and filter out the
        > > annotations.
        > >
        > > Sketch:
        > >
        > > +==============+ +==============+
        > > | | | |
        > > | gdb window | | VIM window |
        > > | | | |
        > > +==============+ +==============+
        > > | (1) | (2)
        > > | |
        > > +--------------+ +--------------+
        > > | | | |
        > > | VimGDB' |---------| VIM |
        > > | | (3) | |
        > > +--------------+ +--------------+
        > > | (4)
        > > |
        > > +--------------+
        > > | |
        > > | gdb |
        > > | |
        > > +--------------+
        > >
        > >
        > > And then have "gdb window" and "VIM window" run in a split xterm. Or
        > > two xterms, or an xterm and gvim, that doesn't really matter.
        > >
        > > (1) gdb terminal I/O (with annotations filtered out)
        > > (2) Vim terminal I/O
        > > (3) client-server or NetBeans interface
        > > (4) gdb terminal I/O (including annotations)
        > >
        > > Of these only (3) may need to be improved.
        >
        > In your sketch:
        >
        > The "gdb window" needs features such as scrolling and
        > searching.

        You should be able to use the scrolling features of the terminal. I
        never really missed being able to search in gdb output, but I can see it
        could be useful.

        > It needs also displaying the current state of GDB.

        Normally there is a prompt when gdb is ready for input. Anything else?

        > When VimGDB supports management of GDB variables, the
        > "gdb window" needs some kind of windowing capabilities, and
        > maybe highlighting to indicate a changed or out of scope
        > variable.

        Do you mean that variables can be watched? Yes, that would require
        another window or a split window. If you ever used the "ddd" debugger,
        it has a nice solution for this, also showing what pointers point to.
        That does require a GUI though.

        > When VimGDB supports setting breakpoints in assembly code and
        > stepi(ing) through this code, the "gdb window" needs also windows and
        > maybe something like Vim signs.

        I would think anything related to text and moving through it is done in
        a Vim window.

        > It is important to have the "gdb window" preserve Vim look-and-feel.

        Or keep the "gdb look-and-feel". Depends on what you are trying to do.

        > A solution is to have all those windows (gdb console, asm
        > windows, variables window) displayed in "VIM window" instead
        > of in the "gdb window". Those windows are controlled
        > (created, updated) by VimGDB through (3). This does follow
        > your sketch. The "gdb window" user interface is mainly
        > reduced to just one command line, the one used to type GDB
        > commands.

        You are jumping to conslusions here. I know having it all done inside
        Vim is a solution, but it conflicts with the principle that Vim is an
        editor, and not much more. We should at least try to come up with a
        modular solution and avoid that gdb-specific code is included in Vim.

        > From a functional point of view, the drawbacks of this
        > solution as compared to the features currently supported
        > by VimGDB patch 6 (the Vim feature included into Vim, see
        > http://skawina.eu.org/mikolaj/vimgdb/gdb.html) are:
        >
        > . a requirement for two terminals or a tool such as
        > "screen"

        True, instead of having Vim do window management you need something
        else.

        > . when using "screen" with a split screen, 3/4 lines are
        > lost (2 are screen window status lines, 1/2 is the
        > "gdb window" command line); however, "screen" can
        > also be unsplit in two screens from a split
        > screen when GDB is not used for a while, no lines
        > are lost then

        I think that's only a detail.

        > . there is no syntax highlighting when typing GDB
        > commands in the "gdb window" (there could be, but
        > the effort to implement that seems disproportionate)

        Since the GDB commands are genrally short, it's not a script you are
        editing, I don't think highlighting them is important. I never missed
        it. Command completion is much more important for me.

        > . it may be felt that using a command line where all
        > standard output goes to another application is unusual

        I don't understand this one. I would think having gdb run in a terminal
        is what most people are used to.

        --
        hundred-and-one symptoms of being an internet addict:
        242. You turn down a better-paying job because it doesn't come with
        a free e-mail account.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
      • Xavier de Gaye
        ... You do have all that: the clever completion that gdb offers and the gdb commands and their output in sequential order. ... The input-line window pops up
        Message 3 of 29 , Apr 5, 2004
        • 0 Attachment
          Bram Moolenaar <Bram@...> wrote:

          >
          >Xavier de Gaye wrote:
          >
          >> > > The gdb console is a Vim window. It gets syntax color
          >> > > highlighting, can be resized and pointed to by the mouse as
          >> > > a regular Vim window and buffer. This is simple. Maybe I
          >> > > miss what you mean by colors, mouse pointer, resizing.
          >> >
          >> > I didn't look into VimGDB, but I assume it was implemented using a Vim
          >> > buffer to show the gdb output and enter new gdb commands. Thus you are
          >> > simulating a terminal through a Vim buffer.
          >>
          >> Not exactly.
          >>
          >> GDB commands are entered through the Vim command line with
          >> `:call gdb("GDB_command")' or with a "GDB_command" typed in a
          >> window input-line.
          >
          >I can see this is useful to be able to create mappings that invoke gdb
          >commands, but I would really want be able to type gdb commands and use
          >the clever completion that gdb offers. And have the gdb commands and
          >their output in sequential order.
          >


          You do have all that: the clever completion that gdb offers
          and the gdb commands and their output in sequential order.


          >> When characters are typed in the gdb console window, they
          >> just get inserted in the buffer, that's all. The gdb console
          >> is really a regular Vim window.
          >
          >Thus a window that only shows the gdb output, not being able to type gdb
          >commands there? I would think that's a bit strange for someone who has
          >used gdb in a terminal.


          The input-line window pops up just below the gdb console window.
          You type GDB commands in this window.
          You have completion in this window.
          I do not think this is very much different from typing commands
          in a terminal. It's just few lines below and you benefit from the
          history provided by the input-line window, so it's even a little
          bit better.


          >
          >> [...]
          >>
          >> > What is done with NetBeans and Agide is to add the menus and toolbar
          >> > items in Vim. You only need a window to run gdb in, and filter out the
          >> > annotations.
          >> >
          >> > Sketch:
          >> >
          >> > +==============+ +==============+
          >> > | | | |
          >> > | gdb window | | VIM window |
          >> > | | | |
          >> > +==============+ +==============+
          >> > | (1) | (2)
          >> > | |
          >> > +--------------+ +--------------+
          >> > | | | |
          >> > | VimGDB' |---------| VIM |
          >> > | | (3) | |
          >> > +--------------+ +--------------+
          >> > | (4)
          >> > |
          >> > +--------------+
          >> > | |
          >> > | gdb |
          >> > | |
          >> > +--------------+
          >> >
          >> >
          >> > And then have "gdb window" and "VIM window" run in a split xterm. Or
          >> > two xterms, or an xterm and gvim, that doesn't really matter.
          >> >
          >> > (1) gdb terminal I/O (with annotations filtered out)
          >> > (2) Vim terminal I/O
          >> > (3) client-server or NetBeans interface
          >> > (4) gdb terminal I/O (including annotations)
          >> >
          >> > Of these only (3) may need to be improved.
          >>
          >> In your sketch:
          >>
          >> The "gdb window" needs features such as scrolling and
          >> searching.
          >
          >You should be able to use the scrolling features of the terminal. I
          >never really missed being able to search in gdb output, but I can see it
          >could be useful.
          >
          >> It needs also displaying the current state of GDB.
          >
          >Normally there is a prompt when gdb is ready for input. Anything else?
          >
          >> When VimGDB supports management of GDB variables, the
          >> "gdb window" needs some kind of windowing capabilities, and
          >> maybe highlighting to indicate a changed or out of scope
          >> variable.
          >
          >Do you mean that variables can be watched? Yes, that would require
          >another window or a split window. If you ever used the "ddd" debugger,
          >it has a nice solution for this, also showing what pointers point to.
          >That does require a GUI though.
          >


          Yes, variables can be watched with VimGDB.


          >> When VimGDB supports setting breakpoints in assembly code and
          >> stepi(ing) through this code, the "gdb window" needs also windows and
          >> maybe something like Vim signs.
          >
          >I would think anything related to text and moving through it is done in
          >a Vim window.
          >
          >> It is important to have the "gdb window" preserve Vim look-and-feel.
          >
          >Or keep the "gdb look-and-feel". Depends on what you are trying to do.
          >
          >> A solution is to have all those windows (gdb console, asm
          >> windows, variables window) displayed in "VIM window" instead
          >> of in the "gdb window". Those windows are controlled
          >> (created, updated) by VimGDB through (3). This does follow
          >> your sketch. The "gdb window" user interface is mainly
          >> reduced to just one command line, the one used to type GDB
          >> commands.
          >
          >You are jumping to conslusions here. I know having it all done inside
          >Vim is a solution, but it conflicts with the principle that Vim is an
          >editor, and not much more. We should at least try to come up with a
          >modular solution and avoid that gdb-specific code is included in Vim.


          As stated above, those windows are controlled (created, updated) by VimGDB
          through (3). This means that it does avoid that gdb-specific code is
          included in Vim. VimGDB and Vim are two different processes.

          I am trying here to describe a solution that is conform to the requirement
          that Vim is an editor, not an IDE.


          >
          >> From a functional point of view, the drawbacks of this
          >> solution as compared to the features currently supported
          >> by VimGDB patch 6 (the Vim feature included into Vim, see
          >> http://skawina.eu.org/mikolaj/vimgdb/gdb.html) are:
          >>
          >> . a requirement for two terminals or a tool such as
          >> "screen"
          >
          >True, instead of having Vim do window management you need something
          >else.
          >
          >> . when using "screen" with a split screen, 3/4 lines are
          >> lost (2 are screen window status lines, 1/2 is the
          >> "gdb window" command line); however, "screen" can
          >> also be unsplit in two screens from a split
          >> screen when GDB is not used for a while, no lines
          >> are lost then
          >
          >I think that's only a detail.
          >
          >> . there is no syntax highlighting when typing GDB
          >> commands in the "gdb window" (there could be, but
          >> the effort to implement that seems disproportionate)
          >
          >Since the GDB commands are genrally short, it's not a script you are
          >editing, I don't think highlighting them is important. I never missed
          >it. Command completion is much more important for me.
          >
          >> . it may be felt that using a command line where all
          >> standard output goes to another application is unusual
          >
          >I don't understand this one. I would think having gdb run in a terminal
          >is what most people are used to.
          >
          >--
          >hundred-and-one symptoms of being an internet addict:
          >242. You turn down a better-paying job because it doesn't come with
          > a free e-mail account.
          >
          > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          >/// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          >\\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          > \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
          >



          The solution described above can be improved by removing VimGDB
          controlling terminal altogether. Then, there is no need of "screen"
          or two terminals, no lines are lost and we keep syntax highlighting
          when typing GDB commands.

          Keeping VimGDB and Vim as *two separate processes* and removing VimGDB
          controlling terminal, your sketch becomes:



          +==============+
          | |
          | VIM window |
          | |
          +==============+
          | (c)
          |
          +--------------+ +--------------+
          | | | |
          | VimGDB' |---------| VIM |
          | | (b) | |
          +--------------+ +--------------+
          | (a)
          |
          +--------------+
          | |
          | gdb |
          | |
          +--------------+

          (a) gdb terminal I/O
          (b) NetBeans interface
          (c) Vim terminal I/O

          The NetBeans interface (b) would need to be improved so that:

          . a Vim |+eval| function named f_nbinput() sends all its user
          input to the NetBeans interface. The NetBeans interface sends
          these user input as NetBeans events to the external application
          (VimGDB in the sketch).

          . a NetBeans command allows the external application to send
          error and warning messages that are displayed by the NetBeans
          interface as Vim error and warning messages

          . the scheme that is used by the current VimGDB implementation to
          pop up an input-line window can be used by the NetBeans interface.
          (see http://skawina.eu.org/mikolaj/vimgdb/gdb_design.html,
          search for input-line in this text)
          A NetBeans command allows the external application to trigger
          the pop up of this window with text added to the current last
          line (same behavior as current VimGDB when GDB sends a query
          yes/no for example or sends a completion result, or waits for
          user input while entering a GDB "commands" with the ">" prompt,
          etc...)

          Xavier...



          __________________________________________________________________
          Introducing the New Netscape Internet Service.
          Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

          Netscape. Just the Net You Need.

          New! Netscape Toolbar for Internet Explorer
          Search from anywhere on the Web and block those annoying pop-ups.
          Download now at http://channels.netscape.com/ns/search/install.jsp
        • Bram Moolenaar
          ... I suppose this is a Vim window then, that behaves like a terminal: typed keys are passed to gdb and the gdb response (e.g., completion) is displayed. But
          Message 4 of 29 , Apr 5, 2004
          • 0 Attachment
            Xavier de Gaye wrote:

            > The input-line window pops up just below the gdb console window.
            > You type GDB commands in this window.
            > You have completion in this window.
            > I do not think this is very much different from typing commands
            > in a terminal. It's just few lines below and you benefit from the
            > history provided by the input-line window, so it's even a little
            > bit better.

            I suppose this is a Vim window then, that behaves like a terminal: typed
            keys are passed to gdb and the gdb response (e.g., completion) is
            displayed. But gdb output it not displayed here but in a separate gdb
            output window.

            Takes a little bit getting used to. But at least avoids the problem
            that gdb output and commands from buttons and the like cause the current
            input line to be lost.

            > As stated above, those windows are controlled (created, updated) by VimGDB
            > through (3). This means that it does avoid that gdb-specific code is
            > included in Vim. VimGDB and Vim are two different processes.

            OK, but you do use a Vim window as if it was a terminal. That means Vim
            does the scrolling, window resizing, highlighting and the like.


            > The solution described above can be improved by removing VimGDB
            > controlling terminal altogether. Then, there is no need of "screen"
            > or two terminals, no lines are lost and we keep syntax highlighting
            > when typing GDB commands.

            I still wonder what is so important about avoiding the need to use
            something like "screen" and use a Vim window like a terminal.


            > Keeping VimGDB and Vim as *two separate processes* and removing VimGDB
            > controlling terminal, your sketch becomes:
            >
            >
            >
            > +==============+
            > | |
            > | VIM window |
            > | |
            > +==============+
            > | (c)
            > |
            > +--------------+ +--------------+
            > | | | |
            > | VimGDB' |---------| VIM |
            > | | (b) | |
            > +--------------+ +--------------+
            > | (a)
            > |
            > +--------------+
            > | |
            > | gdb |
            > | |
            > +--------------+
            >
            > (a) gdb terminal I/O
            > (b) NetBeans interface
            > (c) Vim terminal I/O
            >
            > The NetBeans interface (b) would need to be improved so that:
            >
            > . a Vim |+eval| function named f_nbinput() sends all its user
            > input to the NetBeans interface. The NetBeans interface sends
            > these user input as NetBeans events to the external application
            > (VimGDB in the sketch).

            I don't quite get how this works. Is this a separate mode in which
            every typed character is send over the NetBeans interface? That sounds
            like the user-input side of a terminal. Isn't this very similar to "Vim
            provides a terminal window, where I/O of an external application is
            handled"?

            > . a NetBeans command allows the external application to send
            > error and warning messages that are displayed by the NetBeans
            > interface as Vim error and warning messages

            That is relatively simple to do.

            > . the scheme that is used by the current VimGDB implementation to
            > pop up an input-line window can be used by the NetBeans interface.
            > (see http://skawina.eu.org/mikolaj/vimgdb/gdb_design.html,
            > search for input-line in this text)
            > A NetBeans command allows the external application to trigger
            > the pop up of this window with text added to the current last
            > line (same behavior as current VimGDB when GDB sends a query
            > yes/no for example or sends a completion result, or waits for
            > user input while entering a GDB "commands" with the ">" prompt,
            > etc...)

            Handling the input-line somewhere deep down in the character input
            functions looks like a very bad architecture to me. It's like Vim is
            expecting the user to type a character (Normal command or text to be
            inserted), and instead of that suddenly a new window is created.
            I don't see the details, but inserting something in the input stream
            similar to a CTRL-W s command would be more appropriate.

            --
            ARTHUR: Right! Knights! Forward!
            ARTHUR leads a charge toward the castle. Various shots of them battling on,
            despite being hit by a variety of farm animals.
            "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
          • Xavier de Gaye
            ... No, this is used for mapping commands to key sequences. ... It is not right to say that the input-line is handled somewhere deep down in the character
            Message 5 of 29 , Apr 14, 2004
            • 0 Attachment
              On Mon, 5 Apr 2004, Bram Moolenaar wrote:

              > [...]
              >
              > > Keeping VimGDB and Vim as *two separate processes* and removing VimGDB
              > > controlling terminal, your sketch becomes:
              > >
              > >
              > >
              > > +==============+
              > > | |
              > > | VIM window |
              > > | |
              > > +==============+
              > > | (c)
              > > |
              > > +--------------+ +--------------+
              > > | | | |
              > > | VimGDB' |---------| VIM |
              > > | | (b) | |
              > > +--------------+ +--------------+
              > > | (a)
              > > |
              > > +--------------+
              > > | |
              > > | gdb |
              > > | |
              > > +--------------+
              > >
              > > (a) gdb terminal I/O
              > > (b) NetBeans interface
              > > (c) Vim terminal I/O
              > >
              > > The NetBeans interface (b) would need to be improved so that:
              > >
              > > . a Vim |+eval| function named f_nbinput() sends all its user
              > > input to the NetBeans interface. The NetBeans interface sends
              > > these user input as NetBeans events to the external application
              > > (VimGDB in the sketch).
              >
              > I don't quite get how this works. Is this a separate mode in which
              > every typed character is send over the NetBeans interface? That sounds
              > like the user-input side of a terminal. Isn't this very similar to "Vim
              > provides a terminal window, where I/O of an external application is
              > handled"?

              No, this is used for mapping commands to key sequences.


              >
              > > . a NetBeans command allows the external application to send
              > > error and warning messages that are displayed by the NetBeans
              > > interface as Vim error and warning messages
              >
              > That is relatively simple to do.
              >
              > > . the scheme that is used by the current VimGDB implementation to
              > > pop up an input-line window can be used by the NetBeans interface.
              > > (see http://skawina.eu.org/mikolaj/vimgdb/gdb_design.html,
              > > search for input-line in this text)
              > > A NetBeans command allows the external application to trigger
              > > the pop up of this window with text added to the current last
              > > line (same behavior as current VimGDB when GDB sends a query
              > > yes/no for example or sends a completion result, or waits for
              > > user input while entering a GDB "commands" with the ">" prompt,
              > > etc...)
              >
              > Handling the input-line somewhere deep down in the character input
              > functions looks like a very bad architecture to me. It's like Vim is
              > expecting the user to type a character (Normal command or text to be
              > inserted), and instead of that suddenly a new window is created.
              > I don't see the details, but inserting something in the input stream
              > similar to a CTRL-W s command would be more appropriate.

              It is not right to say that the input-line is handled somewhere
              deep down in the character input functions:

              . Vim is expecting the user to type a character and gets
              got_int TRUE, which is what happens when the user hits
              <CTRL-C>

              . Vim then returns to Normal mode and the main loop after
              flushing its internal typeahead and stuff buffers

              . up to now, it's all standard Vim behavior

              . *From main_loop* VimGDB inserts characters in the
              typeahead buffer (this is also done by the ClientServer
              code for example and in many other places in Vim code)

              . the characters inserted are "<CTRL-F>a", this is used
              to start automatically the input-line window in insert
              mode

              . VimGDB runs *from main_loop* the Vim function
              getcmdline_prompt((int)'@', NULL, 0);
              that creates the input-line window

              . the input-line window is the same kind of window
              as the command-line window, no VimGDB specific processing
              is *ever* done in this window, it is no more a "terminal
              window" than the command-line window may be called one
              of such things for example

              I don't understand the relationship between CTRL-W s command
              and the input stream.

              I am going to try adapting VimGDB to your original sketch
              where VimGDB' is a separate task, uses its own "screen" or
              xterm window and is interfaced to Vim through the
              standard NetBeans.

              Xavier...



              __________________________________________________________________
              Introducing the New Netscape Internet Service.
              Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

              Netscape. Just the Net You Need.

              New! Netscape Toolbar for Internet Explorer
              Search from anywhere on the Web and block those annoying pop-ups.
              Download now at http://channels.netscape.com/ns/search/install.jsp
            • Xavier de Gaye
              Bram, I have adapted VimGDB to follow the design you have proposed in a previous mail in this thread: +==============+ +==============+ ...
              Message 6 of 29 , May 11, 2004
              • 0 Attachment
                Bram,

                I have adapted VimGDB to follow the design you have proposed in a
                previous mail in this thread:


                +==============+ +==============+
                | | | |
                | gdb window | | VIM window |
                | | | |
                +==============+ +==============+
                | (1) | (2)
                | |
                +--------------+ +--------------+
                | | | |
                | clewn |---------| VIM |
                | (was VimGDB')| (3) | |
                +--------------+ +--------------+
                | (4)
                |
                +--------------+
                | |
                | gdb |
                | |
                +--------------+

                (1) gdb terminal I/O (with annotations filtered out)
                (2) Vim terminal I/O
                (3) NetBeans interface
                (4) gdb terminal I/O (including annotations)


                It works on any existing gvim with the |+netbeans_intg| feature
                enabled, although it's better to use a version later than 6.2.480.
                It does not work with Vim in terminal mode yet.

                [Some pending issues with Vim NetBeans in terminal mode:
                . is it possible to have 'defineAnnoType' also handle terminal colors ?
                . could 'balloonText' events be sent for the cursor position
                (using CursorHold ?) in terminal mode]

                This tool can also be used in debug mode to trace, do unit testing
                or experiment with Vim NetBeans interface: any NetBeans command
                or function can be sent to Vim from clewn command line.

                The name of this tool is 'clewn' and thanks to Mikolaj, it should
                be set up in a few days on Mikolaj web site from where it can be
                downloaded.

                Clewn's user interface, with very few exceptions, is the same as the GDB
                command line interface. Here is a summary of clewn features, they are
                mostly the same as VimGDB (they have about two third of their code in
                common):

                * any GDB command can be mapped to a Vim keystroke or key sequence
                * you can send an interrupt from Vim to GDB and the program it is
                running
                * a variable can be "dropped" and watched in a Vim window, to remove
                the variable just delete it from the window
                * assembly buffers hold the assembly code for functions that miss the
                source code and are being stepped through, or where breakpoints have
                been set
                * breakpoints are highlighted in source code and in the assembly buffers;
                disabled breakpoints are noted with a different highlighting color;
                the source file is automatically loaded when setting a breakpoint
                * each time GDB displays a stack frame, the source file or assembly buffer
                for that frame is automatically loaded and the line highlighted
                * support of the clever GDB command and file name completion
                * real-time target status display


                Xavier...



                __________________________________________________________________
                Introducing the New Netscape Internet Service.
                Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                Netscape. Just the Net You Need.

                New! Netscape Toolbar for Internet Explorer
                Search from anywhere on the Web and block those annoying pop-ups.
                Download now at http://channels.netscape.com/ns/search/install.jsp
              • Bram Moolenaar
                ... Very good. I am glad you managed to make it work this way. This means we have more generic building blocks. ... I ll add them to the todo list. In the
                Message 7 of 29 , May 11, 2004
                • 0 Attachment
                  Xavier de Gaye wrote:

                  > I have adapted VimGDB to follow the design you have proposed in a
                  > previous mail in this thread:

                  Very good. I am glad you managed to make it work this way. This means
                  we have more generic building blocks.

                  > [Some pending issues with Vim NetBeans in terminal mode:
                  > . is it possible to have 'defineAnnoType' also handle terminal colors ?
                  > . could 'balloonText' events be sent for the cursor position
                  > (using CursorHold ?) in terminal mode]

                  I'll add them to the todo list. In the terminal we currently don't use
                  mouse-moved events, adding that might be tricky.

                  > The name of this tool is 'clewn' and thanks to Mikolaj, it should
                  > be set up in a few days on Mikolaj web site from where it can be
                  > downloaded.

                  Perhaps you can explain the name "clewn"?

                  --
                  hundred-and-one symptoms of being an internet addict:
                  245. You use Real Audio to listen to a radio station from a distant
                  city rather than turn on your stereo system.

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                  \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
                • Xavier de Gaye
                  ... Maybe we could use the cursor position instead of the mouse in this case. ... Command Line Editor Worker on NetBeans Xavier...
                  Message 8 of 29 , May 13, 2004
                  • 0 Attachment
                    Bram Moolenaar <Bram@...> wrote:

                    >
                    >Xavier de Gaye wrote:
                    >
                    >> I have adapted VimGDB to follow the design you have proposed in a
                    >> previous mail in this thread:
                    >
                    >Very good.  I am glad you managed to make it work this way.  This means
                    >we have more generic building blocks.
                    >
                    >> [Some pending issues with Vim NetBeans in terminal mode:
                    >>   . is it possible to have 'defineAnnoType' also handle terminal colors ?
                    >>   . could 'balloonText' events be sent for the cursor position
                    >>     (using CursorHold ?) in terminal mode]
                    >
                    >I'll add them to the todo list.  In the terminal we currently don't use
                    >mouse-moved events, adding that might be tricky.
                    >

                    Maybe we could use the cursor position instead of the mouse
                    in this case.


                    >> The name of this tool is 'clewn' and thanks to Mikolaj, it should
                    >> be set up in a few days on Mikolaj web site from where it can be
                    >> downloaded.
                    >
                    >Perhaps you can explain the name "clewn"?

                    Command Line Editor Worker on NetBeans

                    Xavier...


                    __________________________________________________________________
                    Introducing the New Netscape Internet Service.
                    Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                    Netscape. Just the Net You Need.

                    New! Netscape Toolbar for Internet Explorer
                    Search from anywhere on the Web and block those annoying pop-ups.
                    Download now at http://channels.netscape.com/ns/search/install.jsp
                  • Xavier de Gaye
                    ... Not so funny as a clown, I am afraid Clewn: Command Line Editor Worker on NetBeans Xavier...
                    Message 9 of 29 , May 13, 2004
                    • 0 Attachment
                      "Charles E. Campbell, Jr." <drchip@...> wrote:

                      >Xavier de Gaye wrote:
                      >
                      >>Clewn's user interface, with very few exceptions, is the same as the GDB
                      >>command line interface. Here is a summary of clewn features, they are
                      >>mostly the same as VimGDB (they have about two third of their code in
                      >>common):
                      >>  
                      >>
                      >
                      >I don't know the etymology of "clewn", but I just thought I'd tell you
                      >that its very close to "clown"
                      >in English.  Sounds interesting...
                      >
                      >Regards,
                      >Chip Campbell
                      >
                      >

                      Not so funny as a clown, I am afraid
                      Clewn: Command Line Editor Worker on NetBeans

                      Xavier...


                      __________________________________________________________________
                      Introducing the New Netscape Internet Service.
                      Only $9.95 a month -- Sign up today at http://isp.netscape.com/register

                      Netscape. Just the Net You Need.

                      New! Netscape Toolbar for Internet Explorer
                      Search from anywhere on the Web and block those annoying pop-ups.
                      Download now at http://channels.netscape.com/ns/search/install.jsp
                    Your message has been successfully submitted and would be delivered to recipients shortly.