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

RE: VimGDB future

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.