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

VimGDB future

Expand Messages
  • Mikolaj Machowski
    Hello, Works on VimGDB are progressing nicely. Patch 6 will arrive soon. But this is still to early to include VimGDB into main tree. (Xavier especially looks
    Message 1 of 29 , Mar 25, 2004
      Hello,

      Works on VimGDB are progressing nicely. Patch 6 will arrive soon.

      But this is still to early to include VimGDB into main tree.
      (Xavier especially looks for testers on non-Linux systems: Sun.)

      On the other hand waiting next year for 7.0 to arrive seems to long.

      This is a big patch and highly demanded feature.
      What about fast 6.4 with VimGDB as the only big feature?

      m.

      --
      LaTeX + Vim = http://vim-latex.sourceforge.net/
      Vim-list(s) Users Map: (last change 10 Mar)
      http://skawina.eu.org/mikolaj/vimlist
      Are You There?
    • Ritesh Banerjee
      Hi would be definitely welcome feature - 6.4 seems like a good idea... my 2 cents. Regards Ritesh ... __________________________________ Do you Yahoo!? Yahoo!
      Message 2 of 29 , Mar 26, 2004
        Hi
        would be definitely welcome feature - 6.4 seems like
        a good idea... my 2 cents.

        Regards
        Ritesh
        --- Mikolaj Machowski <mikmach@...> wrote:
        >
        > Hello,
        >
        > Works on VimGDB are progressing nicely. Patch 6
        > will arrive soon.
        >
        > But this is still to early to include VimGDB into
        > main tree.
        > (Xavier especially looks for testers on non-Linux
        > systems: Sun.)
        >
        > On the other hand waiting next year for 7.0 to
        > arrive seems to long.
        >
        > This is a big patch and highly demanded feature.
        > What about fast 6.4 with VimGDB as the only big
        > feature?
        >
        > m.
        >
        > --
        > LaTeX + Vim = http://vim-latex.sourceforge.net/
        > Vim-list(s) Users Map: (last change 10 Mar)
        > http://skawina.eu.org/mikolaj/vimlist
        > Are You There?
        >
        >


        __________________________________
        Do you Yahoo!?
        Yahoo! Finance Tax Center - File online. File on time.
        http://taxes.yahoo.com/filing.html
      • Bram Moolenaar
        ... I intend the 6.x series to be mostly bug fixes. Adding something big as a gdb interface is inappropriate. It s even the question whether this belongs
        Message 3 of 29 , Mar 26, 2004
          Mikolaj Machowski wrote:

          > Works on VimGDB are progressing nicely. Patch 6 will arrive soon.
          >
          > But this is still to early to include VimGDB into main tree.
          > (Xavier especially looks for testers on non-Linux systems: Sun.)
          >
          > On the other hand waiting next year for 7.0 to arrive seems to long.
          >
          > This is a big patch and highly demanded feature.
          > What about fast 6.4 with VimGDB as the only big feature?

          I intend the 6.x series to be mostly bug fixes. Adding something big as
          a gdb interface is inappropriate.

          It's even the question whether this belongs inside Vim. Looking at it
          from the viewpoint that Vim is an editor and not a complete IDE, it
          should not be included. On the other hand, it is a very useful setup,
          and attempts to implement it in other ways (e.g., Agide) have not been
          very popular...

          --
          We are the Borg of GNU GPL. We will assimilate your source code.
          Resistance is futile.

          /// 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 ///
        • Suresh Govindachar
          ... [... VimGDB] ... In regard to other external ways of supporting a debugger: in addition to Agide, there has been scripts #84 and #663. But I suspect that
          Message 4 of 29 , Mar 26, 2004
            Bram Moolenaar wrote:
            >Mikolaj Machowski wrote:
            [... VimGDB]
            >> is a big patch and highly demanded feature. What
            >> about fast 6.4 with VimGDB as the only big feature?

            > I intend the 6.x series to be mostly bug fixes. Adding
            > something big as a gdb interface is inappropriate.
            >
            > It's even the question whether this belongs inside Vim.
            > Looking at it from the viewpoint that Vim is an editor and
            > not a complete IDE, it should not be included. On the
            > other hand, it is a very useful setup, and attempts to
            > implement it in other ways (e.g., Agide) have not been
            > very popular...

            In regard to other "external" ways of supporting a debugger:
            in addition to Agide, there has been scripts #84 and #663.
            But I suspect that VimGDB (and Agide) have more features than
            these two scripts.

            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?

            --Suresh
          • Bram Moolenaar
            ... The debugger with probably the largest functionality is NetBeans from Sun. ... The NetBeans interface can also be used. This is what Agide and NetBeans
            Message 5 of 29 , Mar 26, 2004
              Suresh Govindachar wrote:

              > In regard to other "external" ways of supporting a debugger:
              > in addition to Agide, there has been scripts #84 and #663.
              > But I suspect that VimGDB (and Agide) have more features than
              > these two scripts.

              The debugger with probably the largest functionality is NetBeans from
              Sun.

              > 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?

              The NetBeans interface can also be used. This is what Agide and
              NetBeans are using.

              It's certainly possible to extend the client-server interface, but since
              the commands are quite generic, I wonder if this is really necessary.

              --
              hundred-and-one symptoms of being an internet addict:
              153. You find yourself staring at your "inbox" waiting for new e-mail
              to arrive.

              /// 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
              ... Vim provides many tools to assist the C or C++ developer in her tasks: quickfix, the preview window and key K for documentation, gf to jump to any file
              Message 6 of 29 , Mar 27, 2004
                Bram Moolenaar <Bram@...> wrote:

                >
                >Mikolaj Machowski wrote:
                >
                >> Works on VimGDB are progressing nicely.  Patch 6 will arrive soon.
                >>
                >> But this is still to early to include VimGDB into main tree.
                >> (Xavier especially looks for testers on non-Linux systems: Sun.)
                >>
                >> On the other hand waiting next year for 7.0 to arrive seems to long.
                >>
                >> This is a big patch and highly demanded feature.
                >> What about fast 6.4 with VimGDB as the only big feature?
                >
                >I intend the 6.x series to be mostly bug fixes.  Adding something big as
                >a gdb interface is inappropriate.
                >
                >It's even the question whether this belongs inside Vim.  Looking at it
                >from the viewpoint that Vim is an editor and not a complete IDE, it
                >should not be included.  On the other hand, it is a very useful setup,
                >and attempts to implement it in other ways (e.g., Agide) have not been
                >very popular...
                >
                >--
                >We are the Borg of GNU GPL.  We will assimilate your source code.
                >Resistance is futile.
                >
                > /// 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 ///
                >

                Vim provides many tools to assist the C or C++ developer in her tasks:
                quickfix, the preview window and key "K" for documentation, "gf" to
                jump to any file in the 'path', an interafce to tags and to cscope for
                browsing source code. I may miss some. GDB is another tool used by
                developers.

                Why can't we add an interface to GDB to the list of Vim supported
                development tools ?

                A reason might be it does not fulfill clause (1) of:
                - There is no limit to the features that can be added. Selecting new features
                is one based on (1) what users ask for, (2) how much effort it takes to
                implement and (3) someone actually implementing it.
                in the runtime/doc/develop.txt section titled "VIM IS... IMPROVED".

                Another reason might be the interface is too complex. There is no
                instrument to measure software complexity. The current size of VimGDB
                (patch 6, to be released soon) including support for both annotations
                level 2 and GDB/MI with annotations level 3 is about 165 Kb (was about
                120 Kb with patch 5). The size of if_cscope is 54 Kb. The size of
                tags.c is 77 Kb. These are very poor indicators.

                Of course, being the one who develops VimGDB, I wish those reasons
                should not prevent VimGDB to be included in Vim as a regular feature.
                As a user, I try my hardest to avoid using any graphical application
                (the only one I found I would be a fool not to use in its graphical
                version is ethereal). I did not try to install Agide for this reason.
                I want to use GDB. You cannot use GDB with its CLI alone, you need an
                interface to GDB. I don't want to use Emacs.

                A debuger is not always the last tool used in the development process
                and not always used to find bugs. In many cases it is a very useful
                source code browser that may be used in the early stages or all along
                the development process. A debuger can walk you along the first steps
                you make in a huge sofware with literally thousands of files and new
                concepts that was just suddenly dropped in your lap (or walk you along
                Vim source code). With cscope you might just drown in this case.
                While writing VimGDB, my use of GDB was at the beginning maybe 20% of
                the time dedicated to finding bugs, and 80% of the time dedicated to
                understanding Vim source code.
                My point here, is that adding a GDB interface to Vim does not change
                Vim's nature as an editor in this case since an editor is also a
                browser: Vim can browse source code better with VimGDB.

                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 in my view, GDB interface would be a _key_ improvement to the experience of programming using vim. I agree with Xavier - fo eg., make error lists are also
                Message 7 of 29 , Mar 27, 2004
                  Hi
                  in my view, GDB interface would be a _key_
                  improvement to the experience of programming using
                  vim. I agree with Xavier - fo eg., make error lists
                  are also not _strictly_ an editor domain, but its
                  really useful! I have been looking for such an
                  debugger option for long (and even tried to hack an
                  interface myself studying xxgdb code but ran out of
                  time).
                  I feel the question 'what should an editor do', is a
                  bit subjective. But if this gdb feature can be
                  compiled out, then we have not violated the general
                  make up of vim. People can compile it in or out based
                  on their requirements of an "editor". In my case, it
                  would, of course, be compiled _in_.

                  Regards
                  Ritesh


                  --- Xavier de Gaye <XavierDeGaye@...> wrote:
                  > Bram Moolenaar <Bram@...> wrote:
                  >
                  > >
                  > >Mikolaj Machowski wrote:
                  > >
                  > >> Works on VimGDB are progressing nicely. Patch 6
                  > will arrive soon.
                  > >>
                  > >> But this is still to early to include VimGDB into
                  > main tree.
                  > >> (Xavier especially looks for testers on non-Linux
                  > systems: Sun.)
                  > >>
                  > >> On the other hand waiting next year for 7.0 to
                  > arrive seems to long.
                  > >>
                  > >> This is a big patch and highly demanded feature.
                  > >> What about fast 6.4 with VimGDB as the only big
                  > feature?
                  > >
                  > >I intend the 6.x series to be mostly bug fixes.
                  > Adding something big as
                  > >a gdb interface is inappropriate.
                  > >
                  > >It's even the question whether this belongs inside
                  > Vim. Looking at it
                  > >from the viewpoint that Vim is an editor and not a
                  > complete IDE, it
                  > >should not be included. On the other hand, it is a
                  > very useful setup,
                  > >and attempts to implement it in other ways (e.g.,
                  > Agide) have not been
                  > >very popular...
                  > >
                  > >--
                  > >We are the Borg of GNU GPL. We will assimilate
                  > your source code.
                  > >Resistance is futile.
                  > >
                  > > /// 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 ///
                  > >
                  >
                  > Vim provides many tools to assist the C or C++
                  > developer in her tasks:
                  > quickfix, the preview window and key "K" for
                  > documentation, "gf" to
                  > jump to any file in the 'path', an interafce to tags
                  > and to cscope for
                  > browsing source code. I may miss some. GDB is
                  > another tool used by
                  > developers.
                  >
                  > Why can't we add an interface to GDB to the list of
                  > Vim supported
                  > development tools ?
                  >
                  > A reason might be it does not fulfill clause (1) of:
                  > - There is no limit to the features that can be
                  > added. Selecting new features
                  > is one based on (1) what users ask for, (2) how
                  > much effort it takes to
                  > implement and (3) someone actually implementing
                  > it.
                  > in the runtime/doc/develop.txt section titled "VIM
                  > IS... IMPROVED".
                  >
                  > Another reason might be the interface is too
                  > complex. There is no
                  > instrument to measure software complexity. The
                  > current size of VimGDB
                  > (patch 6, to be released soon) including support for
                  > both annotations
                  > level 2 and GDB/MI with annotations level 3 is about
                  > 165 Kb (was about
                  > 120 Kb with patch 5). The size of if_cscope is 54
                  > Kb. The size of
                  > tags.c is 77 Kb. These are very poor indicators.
                  >
                  > Of course, being the one who develops VimGDB, I wish
                  > those reasons
                  > should not prevent VimGDB to be included in Vim as a
                  > regular feature.
                  > As a user, I try my hardest to avoid using any
                  > graphical application
                  > (the only one I found I would be a fool not to use
                  > in its graphical
                  > version is ethereal). I did not try to install Agide
                  > for this reason.
                  > I want to use GDB. You cannot use GDB with its CLI
                  > alone, you need an
                  > interface to GDB. I don't want to use Emacs.
                  >
                  > A debuger is not always the last tool used in the
                  > development process
                  > and not always used to find bugs. In many cases it
                  > is a very useful
                  > source code browser that may be used in the early
                  > stages or all along
                  > the development process. A debuger can walk you
                  > along the first steps
                  > you make in a huge sofware with literally thousands
                  > of files and new
                  > concepts that was just suddenly dropped in your lap
                  > (or walk you along
                  > Vim source code). With cscope you might just drown
                  > in this case.
                  > While writing VimGDB, my use of GDB was at the
                  > beginning maybe 20% of
                  > the time dedicated to finding bugs, and 80% of the
                  > time dedicated to
                  > understanding Vim source code.
                  > My point here, is that adding a GDB interface to Vim
                  > does not change
                  > Vim's nature as an editor in this case since an
                  > editor is also a
                  > browser: Vim can browse source code better with
                  > VimGDB.
                  >
                  > 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


                  __________________________________
                  Do you Yahoo!?
                  Yahoo! Finance Tax Center - File online. File on time.
                  http://taxes.yahoo.com/filing.html
                • Brian Sturk
                  ... 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
                  Message 8 of 29 , Mar 27, 2004
                    > Bram Moolenaar wrote:
                    > >Mikolaj Machowski wrote:
                    > [... VimGDB]
                    > >> is a big patch and highly demanded feature. What
                    > >> about fast 6.4 with VimGDB as the only big feature?
                    >
                    > > I intend the 6.x series to be mostly bug fixes. Adding
                    > > something big as a gdb interface is inappropriate.
                    > >
                    > > It's even the question whether this belongs inside Vim.
                    > > Looking at it from the viewpoint that Vim is an editor and
                    > > not a complete IDE, it should not be included. On the
                    > > other hand, it is a very useful setup, and attempts to
                    > > implement it in other ways (e.g., Agide) have not been
                    > > very popular...
                    >
                    > In regard to other "external" ways of supporting a debugger:
                    > in addition to Agide, there has been scripts #84 and #663.
                    > But I suspect that VimGDB (and Agide) have more features than
                    > these two scripts.
                    >
                    > 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?

                    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.

                    ~brian

                    --
                    .--------------------------------------------------,--------.
                    | Brian Sturk - http://users.adelphia.net/~bsturk \ C/C++ |
                    |-------------------------. bsturk<AT>adelphia.net | Python |
                    | http://www.telengard.com `------------------------`-------|
                    | Telengard Technologies Inc. - NT/*nix UI & device drivers |
                    `-----------------------------------------------------------'
                  • Zdenek Sekera
                    I am sure (and as we can observe from follow-ups so far) this will create a controversal thread. To add to it, let me have *my opinion*: If it is well done,
                    Message 9 of 29 , Mar 28, 2004
                      I am sure (and as we can observe from follow-ups so far)
                      this will create a controversal thread.

                      To add to it, let me have *my opinion*:

                      If it is well done, well thought out (I haven't
                      tried), it should be included in VIM as soon as
                      possible and reasonable. Probably in the *6* series
                      still.

                      Why?

                      Vim (as an improved *vi*) was originally a developers editor
                      (I am very happy it's usage scope has broaden vastly, don't
                      get me wrong here), and I want to touch here just one particular
                      usage field, so important to lots of us. Many features have been
                      added to support dev environment (ctags, cscope, quickfix, one
                      can argue that client-server is one of those, too, it is for me,
                      and others). Debugging is just another dev problem one has to
                      deal with.

                      There were various (clever) attempts to do it via various vim
                      scripts (=outside of vim), I think they showed limits of what
                      one can do this way. Nothing can beat a proper implementation
                      "inside" vim, there is just now way to get those two (vim & gdb)
                      play the same game well if separated.

                      Why not to use an IDE?
                      Well I did and do use some on occassions, when they are installed
                      and easily available. All are usable (some more some less), all
                      have their quirks, none is perfect. To install them just for my
                      purpose, maybe a one time shot, seems often an overkill (and
                      sometimes a real hassle), but pure gdb is almost always available.
                      So I dream of a simple way to use my vim with gdb, easily and
                      efficiently.

                      I don't share the argument "vim is an editor only". It just isn't,
                      at least not in its 'noncompatible' mode. And who would ever set
                      the 'compatible' mode and loose all its beautiful features to get
                      the pure "vi" ?? I do share the worry vim shouldn't grow up to
                      an unmanageable beast (I don't remember who said "every program
                      always grows until it include email handling", no I don't want
                      that). So vim includes number of features that have little to do
                      with "pure" editing, but they are there because they get "the job
                      done" in the (pick your choice) fastest/simplest/hassle-free/...
                      way. Thanks, Bram, for all this, vim *is* a beauty.

                      However, there is a value to implement gdb support in vim with
                      some precations in mind:

                      - it should be "include-if-wanted" feature, just like e.g. cscope
                      and others. Lots of people may not want it because they never
                      do program development/debugging work.
                      - it should be implemented in "nice" fashion: if it has been
                      "compiled in" but the gdb cannot be found durin execution,
                      I should get perhaps some message (and only once in the vim
                      session, maybe I should be able to set a flag "no message if
                      gdb is not available"). This is because I may need to take
                      *my* vim to another environment *as-is* and don't want to
                      be bothered that gdb is not available there (I surely know
                      it). This also means I may want to compile vim on a system
                      where gdb is *not* available, just to compile gdb support in
                      but later execute on a machine where gdb is available, relying
                      perhaps on the PATH to find it.

                      Etc...

                      You were looking for testers on non-Linux systems, I can't do
                      Solaris (perhaps could but with difficulty) but I can do Irix,
                      (I believe gdb is now available for Irix, haven't checked
                      lately, but I think it is), so if that can help, feel free
                      to contact me on any of

                      'z.sekera@...' or 'zdenek.sekera@...'

                      I will dust off my machine :-).

                      Cheers,

                      ---Zdenek


                      > -----Original Message-----
                      > From: Mikolaj Machowski [mailto:mikmach@...]
                      > Sent: jeudi, 25. mars 2004 19:24
                      > To: vim-dev@...
                      > Subject: VimGDB future
                      >
                      >
                      >
                      > Hello,
                      >
                      > Works on VimGDB are progressing nicely. Patch 6 will arrive soon.
                      >
                      > But this is still to early to include VimGDB into main tree.
                      > (Xavier especially looks for testers on non-Linux systems: Sun.)
                      >
                      > On the other hand waiting next year for 7.0 to arrive seems to long.
                      >
                      > This is a big patch and highly demanded feature.
                      > What about fast 6.4 with VimGDB as the only big feature?
                      >
                      > m.
                      >
                      > --
                      > LaTeX + Vim = http://vim-latex.sourceforge.net/
                      > Vim-list(s) Users Map: (last change 10 Mar)
                      > http://skawina.eu.org/mikolaj/vimlist
                      > Are You There?
                      >
                      >
                    • Bram Moolenaar
                      ... 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
                      Message 10 of 29 , Mar 28, 2004
                        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.

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

                        --
                        hundred-and-one symptoms of being an internet addict:
                        167. You have more than 200 websites bookmarked.

                        /// 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 ///
                      • Mikolaj Machowski
                        ... Full description is at: http://skawina.eu.org/mikolaj/vimgdb m. -- LaTeX + Vim = http://vim-latex.sourceforge.net/ Vim-list(s) Users Map: (last change 10
                        Message 11 of 29 , Mar 28, 2004
                          Dnia nie 28. marca 2004 08:26, Brian Sturk napisał:

                          > What does VimGDB do?
                          >
                          Full description is at:
                          http://skawina.eu.org/mikolaj/vimgdb

                          m.


                          --
                          LaTeX + Vim = http://vim-latex.sourceforge.net/
                          Vim-list(s) Users Map: (last change 10 Mar)
                          http://skawina.eu.org/mikolaj/vimlist
                          Are You There?
                        • Suresh Govindachar
                          ... [ Suresh Govindachar wrote:] ... In an integration of anything with Vim (console with Vim, ide with Vim etc.) an essential feature for me is the ability
                          Message 12 of 29 , Mar 28, 2004
                            Bram Moolenaar worte:
                            > Brian Sturk wrote:
                            [> >Suresh Govindachar 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.
                            >
                            > (1) appears to be the obvious solution. But it still didn't get
                            > implemented yet. I wonder why...
                            >

                            In an integration of anything with Vim (console with Vim,
                            ide with Vim etc.) an essential feature for me is the
                            ability to use Vim-commands to interact with the entire
                            solution: for example, to manipulate the windows (not only
                            the windows of Vim but also the windows of the other thing
                            being integrated to Vim) using keystrokes such as: CTRL-W h
                            and CTRL-W CTRL-R; and to be able to use Vim-commands like
                            hjkl keys, /<search-pattern>, :<line-number> within all the
                            windows. Vim's file-explorer is a simple but good example
                            of something else being integrated with Vim.

                            In regard to the second basic way mentioned by Bram, can't
                            the color, mouse etc problem be made moot by having the
                            external thing connect to Vim via client-server feature;
                            and can't the "update window contents" problem be addressed
                            by having:

                            a) FIFOs dedicated to each source of input: the human
                            user, the external thing etc.
                            b) the inputs from each source gets collected in its FIFO
                            (each source of input gets a thread to collect the
                            input into its FIFO, while relying on the OS to manage
                            the threads)
                            c) the Vim core processes these FIFOs using a schedule
                            such as round-robin with at most N inputs processed
                            at each FIFO?

                            (I wrote more on the above steps in a post around Feb 18.)

                            My reasoning for opting to delay the introduction of VimGDB
                            is to make sure that Option 2 is explored thoroughly. If
                            Option 2 can be implemented then Vim becomes useful as a
                            user interface in many more contexts than just gdb.

                            --Suresh
                          • Ritesh Banerjee
                            Hi Bram here is 2 more cents from my side on vim and gdb interaction. As you say its possible to use vim and gdb thru agide or netbeans ide. While this is
                            Message 13 of 29 , Mar 28, 2004
                              Hi Bram
                              here is 2 more cents from my side on vim and gdb
                              interaction.
                              As you say its possible to use vim and gdb thru
                              agide or netbeans ide. While this is great and surely
                              works for many, I don't think it works for everyone -
                              atleast not for me. Netbeans requires Java VM and
                              whole lot of stuff to work - lot of bloat, not easily
                              replicated and moveable environment (what i mean is
                              lot of installation work etc) - the beauty of vim and
                              gdb is that they are almost always installed in varied
                              environments (and/or pretty easy to do so) and don't
                              require secondary environments and languages. I
                              develop in C (and sometimes in C++) - why should I
                              care for Java or python for that matter which agide
                              requires.

                              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.

                              vim is trim and fast and a compiled binary and so
                              is gdb - both depend highly on keystrokes and commands
                              which is my preferred way of development (don't get me
                              wrong, GUI visualization is a very helpful tool, but
                              you won't find my gvim having a toolbar - that's
                              useless for me). So, to conclude, I feel there are
                              many vim users (and I use gvim daily) that want a vim
                              - gdb interaction without a separate IDE or elaborate
                              framework - I am not saying that putting the interface
                              inside vim is the only option, maybe your
                              "client-server" mechanism (option 2) is a good way.
                              But, I feel strongly that a gdb interface is required
                              which does not require a separate IDE ...

                              Regards
                              Ritesh
                              --- Bram Moolenaar <Bram@...> 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.
                              >
                              > (1) appears to be the obvious solution. But it
                              > still didn't get
                              > implemented yet. I wonder why...
                              >
                              > --
                              > hundred-and-one symptoms of being an internet
                              > addict:
                              > 167. You have more than 200 websites bookmarked.
                              >
                              > /// 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 ///


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

                                > here is 2 more cents from my side on vim and gdb
                                > interaction.
                                > As you say its possible to use vim and gdb thru
                                > agide or netbeans ide. While this is great and surely
                                > works for many, I don't think it works for everyone -
                                > atleast not for me. Netbeans requires Java VM and
                                > whole lot of stuff to work - lot of bloat, not easily
                                > replicated and moveable environment (what i mean is
                                > lot of installation work etc) - the beauty of vim and
                                > gdb is that they are almost always installed in varied
                                > environments (and/or pretty easy to do so) and don't
                                > require secondary environments and languages. I
                                > develop in C (and sometimes in C++) - why should I
                                > care for Java or python for that matter which agide
                                > requires.

                                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.

                                > 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.

                                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.

                                > vim is trim and fast and a compiled binary and so
                                > is gdb - both depend highly on keystrokes and commands
                                > which is my preferred way of development (don't get me
                                > wrong, GUI visualization is a very helpful tool, but
                                > you won't find my gvim having a toolbar - that's
                                > useless for me). So, to conclude, I feel there are
                                > many vim users (and I use gvim daily) that want a vim
                                > - gdb interaction without a separate IDE or elaborate
                                > framework - I am not saying that putting the interface
                                > inside vim is the only option, maybe your
                                > "client-server" mechanism (option 2) is a good way.

                                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.

                                > 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.

                                --
                                "Hit any key to continue" it said, but nothing happened after F sharp.

                                /// 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 ///
                              • Charles E. Campbell, Jr.
                                ... For running gdb on gvim I ve found gdb gvim run -gf (whatever else) helpful. Regards, Chip Campbell
                                Message 15 of 29 , Mar 29, 2004
                                  Bram Moolenaar wrote:

                                  > 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.
                                  >
                                  >
                                  >

                                  For running gdb on gvim I've found

                                  gdb gvim
                                  run -gf (whatever else)

                                  helpful.

                                  Regards,
                                  Chip Campbell
                                • 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 16 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 17 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 18 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 19 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 20 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 21 of 29 , Apr 2 5:46 AM
                                              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 22 of 29 , Apr 2 7:10 AM
                                                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 23 of 29 , Apr 5 6:38 AM
                                                  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 24 of 29 , Apr 5 8:23 AM
                                                    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 25 of 29 , Apr 14 5:14 AM
                                                      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 26 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 27 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 28 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 29 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.