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

RE: VimGDB future

Expand Messages
  • Xavier de Gaye
    ... VimGDB implements (2). 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
    Message 1 of 29 , Mar 30, 2004
      On Sun, 28 Mar 2004, Bram Moolenaar wrote:

      > Brian Sturk wrote:
      >
      > > > Anyway, here's the question: is it at all possible to
      > > > improve Vim's client-server feature and/or add other hooks
      > > > to Vim so as to achieve the end result of having all the
      > > > features of VimGDB while making "VimGDB" an external plugin? >
      > > I would like the same thing to get vimsh to work a little better. Being
      > > able to do idle processing would be great for starts. CursorHold works
      > > but has limitations. Right now gdb runs fine within vimsh, I just
      > > haven't taken the time to write read and write hooks which I have been
      > > hoping to get to. That would allow me to use the "signs" feature or
      > > some other way to show the current line, etc. What does VimGDB do?
      >
      > If all you want to do is run a shell in a split window, there are other
      > ways. I mostly open another xterm, but you could split an xterm with a
      > program like "screen".
      >
      > > I would have to agree w/ Bram on including this in vim proper. If it
      > > can be done by some external script/tool with maybe a few more
      > > primitives added to vim as mentioned by the original poster that seems
      > > like it would suffice.
      >
      > Since it is already possible to use Vim with NetBeans and Agide, the
      > most important primitives for a debugger interface already exist. The
      > main issue is what the debugger uses for its window. The GUI solutions
      > use a separate toplevel window. That is very flexible for window
      > placement, although you often have to deal with overlaps.
      >
      > For a terminal some method is required to split the screen into a part
      > that Vim uses and a part used for the debugger. There are two basic ways:
      >
      > 1. Use a separate split-window program such as "screen" or "splitvt".
      > Run Vim in one window and the debugger in another. Somehow the
      > connection between the two has to be made. A possible solution is
      > using a wrapper around the debugger that communicates with the Vim in
      > the other window.
      >
      > 2. Use a Vim window to run the debugger in. This means Vim has to
      > update the window contents and take care of passing on typed text to
      > the debugger. It functions as a terminal emulator.
      >
      > A disadvantage of (2) is that when Vim is busy with something the
      > debugger window won't be updated. Also, behaving like a terminal
      > emulator is quite complicated, especially if we also want to do colors,
      > mouse pointer, resizing, etc. And we will want that sooner or later.
      >

      VimGDB implements (2).

      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.

      > (1) appears to be the obvious solution. But it still didn't get
      > implemented yet. I wonder why...

      I agree with you, (1) has got modularity, extensibility and
      maintainability over (2). Also, using "screen" is a good
      setup as "screen" is so easy to use.

      If it's still not yet implemented, it might be because:

      a NetBeans is fairly new and not very well known.
      I have just started looking at it, I am impressed.

      b The NetBeans protocol needs to be mastered by the
      implementor(s).

      c The wrapper around the debugger must be dressed up
      with an MMI, curses, commands, menus, help (maybe
      using another language that C).

      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
    • Ritesh Banerjee
      Hi Bram ... a vanilla install of gvim (with my scripts) and gdb suffices. I can use them even on embedded environment on Linux where memory is a concern.
      Message 2 of 29 , Mar 30, 2004
        Hi Bram
        --- Bram Moolenaar <Bram@...> wrote:
        >
        > Ritesh Banerjee wrote:
        > [snipped]---
        > I wasn't saying that you should use NetBeans or
        > Agide. They are just
        > two examples of alternatives. NetBeans indeed is
        > huge, just like
        > Eclipse (which still doesn't have a Vim plugin).
        > Agide is tiny, but
        > at the same time very low on features. I do use it
        > to debug Vim though,
        > a simple "agide vim" does that.
        >
        > When using Vim for debugging you still need to
        > install the version of
        > Vim that supports it. I don't think the requirement
        > to install
        > something is a good reason not to go that way.
        > Especially since
        > installing Python is quite simple. Java can be a
        > bit more complicated
        > (it's not open source and Sun said it won't be).
        > Nevertheless, avoiding
        > dependencies is a good thing.
        --- Well, I usually use vim to develop other s/w, so
        a vanilla install of gvim (with my scripts) and gdb
        suffices. I can use them even on embedded environment
        on Linux where memory is a concern. Problem with
        scripting languages is that one has several useful
        programs each requiring different scripting languages
        - at some point, I had tcl, perl and python installed
        in my machine and such an environment is not easy to
        replicate on a 'random' lab m/c or embedded target.
        So, as you say, avoiding dependencies is a good thing.
        >
        > > I tried looking at agide in the past but it
        > didn't
        > > seem like an easy and quick way to understand and
        > use
        > > it for my requirements ... - I am sure its very
        > useful
        > > to many. It requires python for one. "Recipe"
        > maybe
        > > better than makefiles but that does not
        > necessarily
        > > appeal to me - Here's a partial list of issues
        > which
        > > may require someone to use makefiles instead :
        > > * gnu make is a very powerful mechanism -
        > someone
        > > with make expertise can do things which most IDE's
        > > will never achieve through a 'GUI' interface.
        > > * Working on big projects with extensive
        > makefiles
        > > like the Linux kernel - don't want to think about
        > > another mechanism to build it.
        >
        > It always takes some effort to learn something new.
        > I have been bitten
        > by "make" disadvantages too many times. GNU make
        > offers more features,
        > but also makes it easier to do things wrong. And
        > you still have to mix
        > in snippets of shell scripts, causing portability
        > problems.
        --- I agree that makefiles can get complicated ... In
        most cases, projects already have makefiles defined,
        so its much easier to use/fix them than define things
        from scratch. From makefiles, you can use perl or
        python also, so it depends how you write your makefile
        - besides bash, ksh etc are available on most
        platforms with the same functionality - esp if perl or
        python are available for that platform ?
        >
        > Anyway, including a gdb interface inside Vim will
        > also require learning
        > to use it. It's a smaller step, but not much
        > smaller than using Agide.
        > It also uses Vim and gdb, you only need to know how
        > to install and start
        > it.
        --- Yes, but learning a totally new way of defining
        build rules and all is definitely more complex.
        Besides, one can define interface commands so that
        they are exactly similar to gdb commands (:Gdbxxx for
        xxx command in GDB) in which case I can argue there is
        no overhead at all. This is what cvsmenu.vim script
        does for CVS commands, and its cool! And I can always
        use vim's nice map capabilities to map shortcuts to my
        liking - all requiring a few hours at the max) I'll
        give agide a try, but usually I don't like IDEs and
        don't use IDE like MSVisual Studio even though they
        have vim plugin - i prefer my own layout of the
        screen, and little wastage of screen space. So as
        personal preference/habit whatever, I use gvim as the
        main program for development :-)
        >
        > > vim is trim and fast and a compiled binary and
        > so
        > [snipped]

        > I have been thinking of making a console version of
        > Agide. That would
        > at least avoid the GUI. I don't know yet how that
        > would work though.
        > It would require Python, but not wxPython, thus on
        > many systems you
        > don't need to install something.
        --- Well, from the website tutorial, it seems like one
        has to use menus and dialogs for operations such as
        find, which vim supports efficiently through
        keystrokes (of course, vim does not have a concept of
        projects, but subdirs usually work, and simple scripts
        can easily extend this to project like handling).
        >
        > > But, I feel strongly that a gdb interface is
        > required
        > > which does not require a separate IDE ...
        >
        > Anything with an editor, a way to invoke "make" and
        > a debugger window
        > can be called an IDE.
        --- Well said :-) So, i use vim/gvim as my IDE (using
        my config and script collection) :-) Hence, I guess,
        using an external IDE with vim is to me akin to using
        IDE A with IDE B - now that I think this way, I can
        see why I don't like to use an external IDE at all -
        can't see people ever wanting to use Borland IDE with
        MS IDE just to have additional powerful capabilities.

        Regards
        Ritesh

        __________________________________
        Do you Yahoo!?
        Yahoo! Finance Tax Center - File online. File on time.
        http://taxes.yahoo.com/filing.html
      • Bram Moolenaar
        ... 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
        Message 3 of 29 , Mar 30, 2004
          Xavier de Gaye wrote:

          > > For a terminal some method is required to split the screen into a part
          > > that Vim uses and a part used for the debugger. There are two basic ways:
          > >
          > > 1. Use a separate split-window program such as "screen" or "splitvt".
          > > Run Vim in one window and the debugger in another. Somehow the
          > > connection between the two has to be made. A possible solution is
          > > using a wrapper around the debugger that communicates with the Vim in
          > > the other window.
          > >
          > > 2. Use a Vim window to run the debugger in. This means Vim has to
          > > update the window contents and take care of passing on typed text to
          > > the debugger. It functions as a terminal emulator.
          > >
          > > A disadvantage of (2) is that when Vim is busy with something the
          > > debugger window won't be updated. Also, behaving like a terminal
          > > emulator is quite complicated, especially if we also want to do colors,
          > > mouse pointer, resizing, etc. And we will want that sooner or later.
          > >
          >
          > VimGDB implements (2).
          >
          > 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.

          Another method would be to offer a window as a terminal. Typed keys go
          to the application, application output (and escape sequences) cause text
          to appear in the window. For gdb you then need a layer in between that
          filters out the annotations. Vim would need to privide a kind of
          terminal emulator.

          > > (1) appears to be the obvious solution. But it still didn't get
          > > implemented yet. I wonder why...
          >
          > I agree with you, (1) has got modularity, extensibility and
          > maintainability over (2). Also, using "screen" is a good
          > setup as "screen" is so easy to use.
          >
          > If it's still not yet implemented, it might be because:
          >
          > a NetBeans is fairly new and not very well known.
          > I have just started looking at it, I am impressed.

          NetBeans is not new, but it's quite a different thing from a split
          xterm. It is a GUI IDE where you can use Vim for the editor. Not very
          different from Eclipse, except that no Vim plugin is available for it.

          > b The NetBeans protocol needs to be mastered by the
          > implementor(s).

          True, but I don't think this would be more work than what you have down
          now with VimGDB. Just a different approach, perhaps less obvious.

          > c The wrapper around the debugger must be dressed up
          > with an MMI, curses, commands, menus, help (maybe
          > using another language that C).

          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.

          --
          A computer program does what you tell it to do, not what you want it to do.

          /// 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 ///
        • Benji Fisher
          ... Using Agide to help vim and gdb communicate should not force you to use AAP instead of make. HTH --Benji Fisher
          Message 4 of 29 , Mar 30, 2004
            On Tue, Mar 30, 2004 at 05:23:00AM -0800, Ritesh Banerjee wrote:
            > Hi Bram
            > --- Bram Moolenaar <Bram@...> wrote:
            > >
            > > Anyway, including a gdb interface inside Vim will also require
            > > learning to use it. It's a smaller step, but not much smaller than
            > > using Agide. It also uses Vim and gdb, you only need to know how to
            > > install and start it.
            > --- Yes, but learning a totally new way of defining
            > build rules and all is definitely more complex.

            Using Agide to help vim and gdb communicate should not force you to
            use AAP instead of make.

            HTH --Benji Fisher
          • Bram Moolenaar
            ... Yes, it s often simpler to make Makefiles more complex than switching to something simpler. (read that twice :-) ... That is not at all necessary. Agide
            Message 5 of 29 , Mar 30, 2004
              Ritesh Banerjee wrote:

              > --- I agree that makefiles can get complicated ... In
              > most cases, projects already have makefiles defined,
              > so its much easier to use/fix them than define things
              > from scratch. From makefiles, you can use perl or
              > python also, so it depends how you write your makefile
              > - besides bash, ksh etc are available on most
              > platforms with the same functionality - esp if perl or
              > python are available for that platform ?

              Yes, it's often simpler to make Makefiles more complex than switching to
              something simpler. (read that twice :-)

              > > Anyway, including a gdb interface inside Vim will also require
              > > learning to use it. It's a smaller step, but not much smaller than
              > > using Agide. It also uses Vim and gdb, you only need to know how to
              > > install and start it.
              > --- Yes, but learning a totally new way of defining
              > build rules and all is definitely more complex.

              That is not at all necessary. Agide offers a way to define projects,
              but you can ignore that and do ":make" from within Vim.

              > > I have been thinking of making a console version of Agide. That
              > > would at least avoid the GUI. I don't know yet how that would work
              > > though. It would require Python, but not wxPython, thus on many
              > > systems you don't need to install something.
              > --- Well, from the website tutorial, it seems like one
              > has to use menus and dialogs for operations such as
              > find, which vim supports efficiently through
              > keystrokes (of course, vim does not have a concept of
              > projects, but subdirs usually work, and simple scripts
              > can easily extend this to project like handling).

              In Agide you can use Vim just like you would otherwise. The extra items
              are just extra, you don't have to use them.

              --
              hundred-and-one symptoms of being an internet addict:
              191. You rate eating establishments not by the quality of the food,
              but by the availability of electrical outlets for your PowerBook.

              /// 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
              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 6 of 29 , Apr 2, 2004
                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 7 of 29 , Apr 2, 2004
                  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 8 of 29 , Apr 5, 2004
                    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 9 of 29 , Apr 5, 2004
                      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 10 of 29 , Apr 14, 2004
                        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 11 of 29 , May 11, 2004
                          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 12 of 29 , May 11, 2004
                            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 13 of 29 , May 13, 2004
                              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 14 of 29 , May 13, 2004
                                "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.