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

todo.txt questions

Expand Messages
  • Edward Peschko
    hey all (and bram in particular), I took a look at the todo.txt inside vim7, and noticed the DEBUGGER SUPPORT ADDED item, that it was to be done in a way
    Message 1 of 11 , Feb 25, 2005
      hey all (and bram in particular),

      I took a look at the todo.txt inside vim7, and noticed the 'DEBUGGER
      SUPPORT ADDED' item, that it was to be done in a 'way that is generic
      that works as an IDE'.

      I was wondering if any choices were made as to how this would be
      implemented. I have some generic ideas - either through screen
      scraping an embedded shell (ie: vimshell), or through communication
      with a server (idevim) - but would like to know which way vim7
      was planning on doing it.

      Personally, I prefer the screen scraping because imo you could use it
      for other things besides debugging environments (as a 'screen'
      replacement for example) and because the technical requirements are
      less (no server mode required) but I could see why you could do
      fancier things with a server..

      Ed

      (
      ps - any reason why vimshell hasn't been incorporated into vim
      already? Its only 3000 lines long, seems to fit with vim7's goals,
      and seems well tested..
      )
    • Bram Moolenaar
      ... Deciding how to do it will be most of the work that is still to be done. There are a few examples already. I do want to avoid that we run a shell or other
      Message 2 of 11 , Feb 26, 2005
        Edward Peschko wrote:

        > hey all (and bram in particular),
        >
        > I took a look at the todo.txt inside vim7, and noticed the 'DEBUGGER
        > SUPPORT ADDED' item, that it was to be done in a 'way that is generic
        > that works as an IDE'.
        >
        > I was wondering if any choices were made as to how this would be
        > implemented. I have some generic ideas - either through screen
        > scraping an embedded shell (ie: vimshell), or through communication
        > with a server (idevim) - but would like to know which way vim7
        > was planning on doing it.

        Deciding how to do it will be most of the work that is still to be done.
        There are a few examples already.

        I do want to avoid that we run a shell or other program in a Vim
        window. Because this is the start of a whole range of new problems.
        Such as that we would need to emulate a console window on MS-Windows.
        Even MS had trouble doing that. This always starts with a minimal
        implementation and grows out of proportians over time.

        There are other solutions, such as using another application that splits
        the screen. Or using two separate toplevel windows.

        > Personally, I prefer the screen scraping because imo you could use it
        > for other things besides debugging environments (as a 'screen'
        > replacement for example) and because the technical requirements are
        > less (no server mode required) but I could see why you could do
        > fancier things with a server..

        What is screen scraping?

        > (
        > ps - any reason why vimshell hasn't been incorporated into vim
        > already? Its only 3000 lines long, seems to fit with vim7's goals,
        > and seems well tested..
        > )

        I think it's exactly the kind of thing I want to avoid. As far as I
        know it doesn't work on Win32. That is a good hint that this is a
        handicapped solution.

        --
        hundred-and-one symptoms of being an internet addict:
        230. You spend your Friday nights typing away at your keyboard

        /// 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 LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
      • Edward Peschko
        ... As far as I know, cygwin and xemacs have solved almost all of the problems of running a shell under win32. At least when I was running a cygwin rxvt, I
        Message 3 of 11 , Feb 27, 2005
          On Sat, Feb 26, 2005 at 01:31:36PM +0100, Bram Moolenaar wrote:
          >
          > Edward Peschko wrote:
          >
          > > hey all (and bram in particular),
          > >
          > > I took a look at the todo.txt inside vim7, and noticed the 'DEBUGGER
          > > SUPPORT ADDED' item, that it was to be done in a 'way that is generic
          > > that works as an IDE'.
          > >
          > > I was wondering if any choices were made as to how this would be
          > > implemented. I have some generic ideas - either through screen
          > > scraping an embedded shell (ie: vimshell), or through communication
          > > with a server (idevim) - but would like to know which way vim7
          > > was planning on doing it.
          >
          > Deciding how to do it will be most of the work that is still to be done.
          > There are a few examples already.
          >
          > I do want to avoid that we run a shell or other program in a Vim
          > window. Because this is the start of a whole range of new problems.
          > Such as that we would need to emulate a console window on MS-Windows.
          > Even MS had trouble doing that. This always starts with a minimal
          > implementation and grows out of proportians over time.


          As far as I know, cygwin and xemacs have solved almost all of the
          problems of running a shell under win32. At least when I was running
          a cygwin rxvt, I could:

          1) run screen,
          2) open up a cmd window under screen
          3) cut and paste the text in the cmd window under screen into a buffer

          so I'd say that the work is 95% there. Whether or not it is in a form
          that you could use in the GUI version of vim, I don't know. I do know that
          the vimshell group is planning on adding GUI support pretty soon, though.

          > There are other solutions, such as using another application that splits
          > the screen. Or using two separate toplevel windows.
          >
          > > Personally, I prefer the screen scraping because imo you could use it
          > > for other things besides debugging environments (as a 'screen'
          > > replacement for example) and because the technical requirements are
          > > less (no server mode required) but I could see why you could do
          > > fancier things with a server..
          >
          > What is screen scraping?

          'screen scraping' is the practice of taking text from a window/screen/whatever,
          and using it to drive a process - example - using the interface to already
          existing mainframe programs by automating data entry in the windows, or
          testing out an app by simulating data entry by a bot.

          >
          > > (
          > > ps - any reason why vimshell hasn't been incorporated into vim
          > > already? Its only 3000 lines long, seems to fit with vim7's goals,
          > > and seems well tested..
          > > )
          >
          > I think it's exactly the kind of thing I want to avoid. As far as I
          > know it doesn't work on Win32. That is a good hint that this is a
          > handicapped solution.

          well, there goes my preferred solution. The nice thing about 'screen
          scraping' as stated up above is that the command line - and hence
          your macro *controlling* the command line - does all the work;
          you don't need to make any changes to the host program that does the
          ultimate function.

          All you need to do is be able to look at the output of the host program,
          provide that program with input, and you're done. And hence
          even small out of the way programs can have addons made for them
          (like my dbg-cli for php)

          hmm.

          Perhaps shell support could be made an addon, the same way that perl
          interpreters,etc are made addons? Or take the current effort from
          vimshell and make a configure option to enable it?

          I highly doubt that this will sacrifice much in the way of portability,
          as most of the programs that would have plugins made for them would not
          be able to be controlled any other way.

          Ed
        • Bram Moolenaar
          ... Very good. That means we can use screen and not need to include anything inside Vim. It s always good to separate functionality in different modules,
          Message 4 of 11 , Feb 28, 2005
            Edward Peschko wrote:

            > As far as I know, cygwin and xemacs have solved almost all of the
            > problems of running a shell under win32. At least when I was running
            > a cygwin rxvt, I could:
            >
            > 1) run screen,
            > 2) open up a cmd window under screen
            > 3) cut and paste the text in the cmd window under screen into a buffer
            >
            > so I'd say that the work is 95% there. Whether or not it is in a form
            > that you could use in the GUI version of vim, I don't know. I do know that
            > the vimshell group is planning on adding GUI support pretty soon, though.

            Very good. That means we can use "screen" and not need to include
            anything inside Vim. It's always good to separate functionality in
            different modules, instead of trying to cram everything into one program.

            > 'screen scraping' is the practice of taking text from a
            > window/screen/whatever, and using it to drive a process - example -
            > using the interface to already existing mainframe programs by
            > automating data entry in the windows, or testing out an app by
            > simulating data entry by a bot.

            Oh, that kind of hack. We defenitely want to avoid that. Any change in
            a program being 'scraped' may break the mechanism. And wrapping lines
            will cause trouble (think vertically split windows). Not to mention
            that the text may scroll off-screen. It may work for something that
            uses fixed forms, but not for something generic as a shell or debugger.

            --
            hundred-and-one symptoms of being an internet addict:
            248. You sign your letters with your e-mail address instead of your name.

            /// 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 LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
          • Edward Peschko
            ... well, no, not exactly. Screen doesn t have: 1) macros 2) mapping 3) scripting 4) multiple undos, etc. 5) normal and insert modes etc. etc. etc. You simply
            Message 5 of 11 , Feb 28, 2005
              On Mon, Feb 28, 2005 at 10:47:19AM +0100, Bram Moolenaar wrote:
              >
              > Edward Peschko wrote:
              >
              > > As far as I know, cygwin and xemacs have solved almost all of the
              > > problems of running a shell under win32. At least when I was running
              > > a cygwin rxvt, I could:
              > >
              > > 1) run screen,
              > > 2) open up a cmd window under screen
              > > 3) cut and paste the text in the cmd window under screen into a buffer
              > >
              > > so I'd say that the work is 95% there. Whether or not it is in a form
              > > that you could use in the GUI version of vim, I don't know. I do know that
              > > the vimshell group is planning on adding GUI support pretty soon, though.
              >
              > Very good. That means we can use "screen" and not need to include
              > anything inside Vim. It's always good to separate functionality in
              > different modules, instead of trying to cram everything into one program.

              well, no, not exactly.

              Screen doesn't have:

              1) macros
              2) mapping
              3) scripting
              4) multiple undos, etc.
              5) normal and insert modes

              etc.
              etc.
              etc.

              You simply cannot make a debug mode with screen as it stands. I'd imagine
              if you made a 'screen mode' for vim, you could.

              And I don't see 'cramming it into one program' - what I would envision is
              taking screen (or somesuch package) - turning it into a library, and then enabling
              that support inside of vim with a config option.

              Either that, or using screen (or vimshell, or both) as a startpoint to make
              a package distributed with vim that you configure on or off.

              > > 'screen scraping' is the practice of taking text from a
              > > window/screen/whatever, and using it to drive a process - example -
              > > using the interface to already existing mainframe programs by
              > > automating data entry in the windows, or testing out an app by
              > > simulating data entry by a bot.
              >
              > Oh, that kind of hack. We defenitely want to avoid that. Any change in
              > a program being 'scraped' may break the mechanism. And wrapping lines
              > will cause trouble (think vertically split windows). Not to mention
              > that the text may scroll off-screen. It may work for something that
              > uses fixed forms, but not for something generic as a shell or debugger.

              well, emacs has used - as far as I know, and without problems - a form of
              gdb interaction like this for the last 6 versions of gdb, so its not as fragile
              as all that. Its the least common denominator, but it works, for a pragmatic
              version of 'works'.

              As for the 'scrolling off screen' and vertically split windows problems,
              they can be solved if the text for the shell is treated as a wrap-around
              buffer - so that you could do the same thing with the text that you
              would do in any other buffer. Screen does this too, to great effect.


              DDD - by the way, does screen scraping, as does tgdb and code-medic, so
              its not that uncommon.


              Its really a cultural thing - IMO there is no one single way to
              solve this problem. On windows, you go the server way. On unix,
              its much more common to see the screen scraping way.

              For if you go the server route, you force every single third party to
              write a 'vim mode' for their products. Screen scraping gets around this.


              So I'd really make it a configure switch if I was you, and
              enable/disable it just as you would perl integration. Otherwise, you
              really are favoring the windows mindset over unix.


              Ed

              (ps -

              Because DDD and company support screen scraping, they can support other, out
              of the way debuggers like those for ruby, perl, and even php, without the
              need to even consult the projects in question.
              )

              (
              pps - I just did a word count on screen. Its a total of 35000 lines vs.
              vim's 250,000 - and I bet that 90% of that is overlap with vim. You probably
              could get away with a decent crossplatform screen scraping mode in about 4500
              lines - and you could use vimshell as a guide, so of that 90% of the work is
              done already.
              )
            • Ryan Paul
              I just realized that the first time I sent this, I sent it as a reply to Ed, and neglected to cc the list... so here it is. ... Yeah, but if a change in the
              Message 6 of 11 , Feb 28, 2005
                I just realized that the first time I sent this, I sent it as a reply to
                Ed, and neglected to cc the list... so here it is.

                On Sun, 2005-02-27 at 20:01 -0800, Edward Peschko wrote:

                > well, there goes my preferred solution. The nice thing about 'screen
                > scraping' as stated up above is that the command line - and hence
                > your macro *controlling* the command line - does all the work;
                > you don't need to make any changes to the host program that does the
                > ultimate function.

                Yeah, but if a change in the host program changes the form of the
                output, your client script suddenly wont be able to parse the data. I
                generally avoid screen scraping where possible because such solutions
                are kludgy and prone to failure resulting from subtle discrepencies and
                inconsistencies in output. In the GNU/Linux world, the problem is
                particularly bad, because different distributions may include
                specializations that introduce further divergences in the exact nature
                of the output.

                I think that a server communication option is much more sensible, and if
                D-Bus was more mature than it currently is, it would be a good way to
                interface an external program with Vim. I think Vim would benefit quite
                a bit from general support for a D-Bus interface some day. I have done
                some preliminary experiments in which I have used Python scripting and
                Python D-Bus bindings to implement a Vim D-Bus interface, and it's been
                able to facilitate some very intersting things. If anybody is interested
                in seeing it, i'll post links to the list.

                As far as Vimshell is concerned.... I never knew about it until your
                initial message on the subject. When I figured out what it is, I got
                really excited. Now that I have tried it, i'm really impressed, and I
                would like to see it included in Vim via a compilation option at some
                point in the future when it can support GUI mode. I can understand why
                Bram is hesitant to include it, but it really is a great patch, and it
                would be a shame not to include it. I wouldnt build any other really
                important features on top of it because of it's lack of portability, but
                I really think that in and of itself, it's a valuable addition that many
                GNU/Linux users would benefit from having.

                --
                Ryan Paul <segphault@...>
              • Bram Moolenaar
                ... It doesn t need to. Just use screen for split windows, run gdb (or any other debugger) in one window and Vim in another. Then you only need some way to
                Message 7 of 11 , Feb 28, 2005
                  Edward Peschko wrote:

                  > > > As far as I know, cygwin and xemacs have solved almost all of the
                  > > > problems of running a shell under win32. At least when I was running
                  > > > a cygwin rxvt, I could:
                  > > >
                  > > > 1) run screen,
                  > > > 2) open up a cmd window under screen
                  > > > 3) cut and paste the text in the cmd window under screen into
                  > > > a buffer
                  > > >
                  > > > so I'd say that the work is 95% there. Whether or not it is in a
                  > > > form that you could use in the GUI version of vim, I don't know. I
                  > > > do know that the vimshell group is planning on adding GUI support
                  > > > pretty soon, though.
                  > >
                  > > Very good. That means we can use "screen" and not need to include
                  > > anything inside Vim. It's always good to separate functionality in
                  > > different modules, instead of trying to cram everything into one
                  > > program.
                  >
                  > well, no, not exactly.
                  >
                  > Screen doesn't have:
                  >
                  > 1) macros
                  > 2) mapping
                  > 3) scripting
                  > 4) multiple undos, etc.
                  > 5) normal and insert modes

                  It doesn't need to. Just use screen for split windows, run gdb (or any
                  other debugger) in one window and Vim in another. Then you only need
                  some way to tell Vim what code to display, and some commands back to the
                  debugger. The NetBeans interface already does this. Thusly you reduce
                  the problem to only implementing the interface.

                  Agide works this way, for example. It's a bit primitive and requires
                  wxPython, but good enough for me to debug Vim. www.agide.org


                  > You simply cannot make a debug mode with screen as it stands. I'd imagine
                  > if you made a 'screen mode' for vim, you could.
                  >
                  > And I don't see 'cramming it into one program' - what I would envision is
                  > taking screen (or somesuch package) - turning it into a library, and
                  > then enabling that support inside of vim with a config option.

                  It's very easy to underestimate the effort involved and the maintenance
                  required.

                  > well, emacs has used - as far as I know, and without problems - a form
                  > of gdb interaction like this for the last 6 versions of gdb, so its
                  > not as fragile as all that. Its the least common denominator, but it
                  > works, for a pragmatic version of 'works'.

                  GDB has been specially adjusted to be used within emacs. Check where
                  both come from :-). And there have been plenty of problems. Look
                  around for the definition of the interface between gdb and Emacs. Or
                  rather, the lack of it...

                  > As for the 'scrolling off screen' and vertically split windows problems,
                  > they can be solved if the text for the shell is treated as a wrap-around
                  > buffer - so that you could do the same thing with the text that you
                  > would do in any other buffer. Screen does this too, to great effect.

                  You can't call that screen scraping anymore. Anyway, if you have used
                  the explorer plugin you know what can be done in a window without making
                  any changes inside Vim.

                  > DDD - by the way, does screen scraping, as does tgdb and code-medic, so
                  > its not that uncommon.

                  No, ddd uses the interface that gdb supports. It filters the terminal
                  I/O only for older gdb versions. I have done this for Agide, I know
                  what I'm talking about. This is not screen scraping, this is using
                  pipes to get work done. Guessing the response from gdb is the tricky
                  part. It's trial and error, since different gdb versions give different
                  responses.

                  > Its really a cultural thing - IMO there is no one single way to
                  > solve this problem. On windows, you go the server way. On unix,
                  > its much more common to see the screen scraping way.
                  >
                  > For if you go the server route, you force every single third party to
                  > write a 'vim mode' for their products. Screen scraping gets around this.

                  Either way it's work to make the interface work. Doesn't make much
                  difference. Ideally, you separate the interface both from the debugger
                  and the editor. That way you can interface N debuggers with M editors
                  with N + M implementations, instead of N * M.

                  > So I'd really make it a configure switch if I was you, and
                  > enable/disable it just as you would perl integration. Otherwise, you
                  > really are favoring the windows mindset over unix.

                  I have no idea what that configure switch would do.

                  > Because DDD and company support screen scraping, they can support
                  > other, out of the way debuggers like those for ruby, perl, and even
                  > php, without the need to even consult the projects in question.

                  Did you ever look into the code of ddd that does this? It's very, very
                  complex and tricky. I was unable to figure out how it actually works
                  and decided it was quicker to re-implement it for Agide.

                  > pps - I just did a word count on screen. Its a total of 35000 lines
                  > vs. vim's 250,000 - and I bet that 90% of that is overlap with vim.
                  > You probably could get away with a decent crossplatform screen
                  > scraping mode in about 4500 lines - and you could use vimshell as a
                  > guide, so of that 90% of the work is done already.)

                  And there might be one line that takes several weeks to figure out.
                  Sorry, these computations don't mean anything.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  258. When you want to see your girlfriend, you surf to her homepage.

                  /// 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 LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                • Edward Peschko
                  ... Of course. But there are projects that will *never* have interfaces like this. Try getting Sun to write a interface for dbx, or HPUX to write one for xdb.
                  Message 8 of 11 , Mar 1, 2005
                    > >
                    > > well, no, not exactly.
                    > >
                    > > Screen doesn't have:
                    > >
                    > > 1) macros
                    > > 2) mapping
                    > > 3) scripting
                    > > 4) multiple undos, etc.
                    > > 5) normal and insert modes
                    >

                    > It doesn't need to. Just use screen for split windows, run gdb (or any
                    > other debugger) in one window and Vim in another. Then you only need
                    > some way to tell Vim what code to display, and some commands back to the
                    > debugger. The NetBeans interface already does this. Thusly you reduce
                    > the problem to only implementing the interface.

                    Of course. But there are projects that will *never* have interfaces like this.
                    Try getting Sun to write a interface for dbx, or HPUX to write one for xdb.
                    Or os/390's debugger. Or icon's. Or scheme's.

                    By going down just the server route, you basically limit vim's usefulness to
                    'supported' debuggers.

                    > It's very easy to underestimate the effort involved and the maintenance
                    > required.

                    I guess I'd say I have two objections to this:

                    1) much of the work is already being done, and already being integrated into
                    vim.

                    2) I've taken a look at the vimshell code, and there really isn't anything
                    there that nasty.

                    Furthermore, the vimshell code is well commented, clean, maintainable,
                    and expandable. Personally, I'm going to modify it to work on solaris
                    (it uses forkpty, which isn't available on solaris).


                    > You can't call that screen scraping anymore. Anyway, if you have used
                    > the explorer plugin you know what can be done in a window without making
                    > any changes inside Vim.
                    >
                    > > DDD - by the way, does screen scraping, as does tgdb and code-medic, so
                    > > its not that uncommon.
                    >
                    > No, ddd uses the interface that gdb supports. It filters the terminal
                    > I/O only for older gdb versions. I have done this for Agide, I know
                    > what I'm talking about. This is not screen scraping, this is using
                    > pipes to get work done. Guessing the response from gdb is the tricky
                    > part. It's trial and error, since different gdb versions give different
                    > responses.


                    > > Its really a cultural thing - IMO there is no one single way to
                    > > solve this problem. On windows, you go the server way. On unix,
                    > > its much more common to see the screen scraping way.
                    > >
                    > > For if you go the server route, you force every single third party to
                    > > write a 'vim mode' for their products. Screen scraping gets around this.
                    >
                    > Either way it's work to make the interface work. Doesn't make much
                    > difference. Ideally, you separate the interface both from the debugger
                    > and the editor. That way you can interface N debuggers with M editors
                    > with N + M implementations, instead of N * M.

                    And as I said, that's fine for supported debuggers, ones who support
                    that 'implementation'. But that's something OUTSIDE VIM'S CONTROL, and
                    you are darned lucky if you are in an environment that supports one of
                    these debuggers. Not everyone can chose their programming environment.

                    > I have no idea what that configure switch would do.

                    It would be analagous to the perl support providing ':perl'. In fact
                    it would do what vimshell does already - allow for a

                    :vimshell

                    command to fork a shell and display it inside a vim buffer.
                    You then could navigate the shell, hit 'Esc' (or maybe Ctrl-Esc)
                    when you wanted to go back and view the buffer. This could probably
                    be all implemented in terms of a 'define' inside the actual code, and
                    a switch inside the Makefiles which determined which source files to
                    include in the compilation..


                    > > Because DDD and company support screen scraping, they can support
                    > > other, out of the way debuggers like those for ruby, perl, and even
                    > > php, without the need to even consult the projects in question.
                    >
                    > Did you ever look into the code of ddd that does this? It's very, very
                    > complex and tricky. I was unable to figure out how it actually works
                    > and decided it was quicker to re-implement it for Agide.

                    But that's the point - it's tricky *user* code. And ddd doesn't have what
                    vim has - namely vimscript. Its forced to do everything in C++, wheras I
                    could probably write a gdb mode in a couple of lines of vimscript.


                    What vim needs to do this right is two *generic* things -
                    good shell emulation, and the ability to view a shell as a
                    buffer.

                    After that its fairly trivial to write a mode, just like its
                    fairly trivial to write syntax coloring code. Hell, I just wrote
                    a mode for my file based debugging system, and I'm just a beginner
                    at vimscript.

                    > And there might be one line that takes several weeks to figure out.
                    > Sorry, these computations don't mean anything.

                    well, that's alleviated some by the fact that someone is already working
                    on the extension. And - based on a cursory examination of vimshell, I think
                    you might be *overestimating* the complexity. I'd say the best way to
                    determine who is right is to keep an open mind, and if the code is right,
                    not have qualms about taking it and merging it with the mainline.

                    Ed

                    (
                    ps - IMO a good indication on why a vim-shell marriage would work well
                    is the NON debugging things that you could do with it.

                    Need a list of subject lines inside your mailbox? Write a
                    macro that goes line by line through mutt, yanks the subject
                    line and then pastes it into another buffer.

                    Need to test a curses based program with a series of test cases?
                    (like vim.. ;-) Program a bunch of macros/test cases and
                    pass that input to the program.

                    Need to go back in the buffer to get some history about what
                    you did? Hit Ctrl-U and go back.

                    I maintain that there are hundreds of uses for this apart from
                    debugginb.
                    )
                  • Bram Moolenaar
                    ... You can use a pipe in between the command and the display. It s not simple, since you need a pseudo-tty (pty) to do it properly. Might not work on
                    Message 9 of 11 , Mar 1, 2005
                      Edward Peschko wrote:

                      > > It doesn't need to. Just use screen for split windows, run gdb (or any
                      > > other debugger) in one window and Vim in another. Then you only need
                      > > some way to tell Vim what code to display, and some commands back to the
                      > > debugger. The NetBeans interface already does this. Thusly you reduce
                      > > the problem to only implementing the interface.
                      >
                      > Of course. But there are projects that will *never* have interfaces
                      > like this. Try getting Sun to write a interface for dbx, or HPUX to
                      > write one for xdb. Or os/390's debugger. Or icon's. Or scheme's.
                      >
                      > By going down just the server route, you basically limit vim's usefulness to
                      > 'supported' debuggers.

                      You can use a pipe in between the command and the display. It's not
                      simple, since you need a pseudo-tty (pty) to do it properly. Might not
                      work on MS-Windows. But this problem exists no matter if you do this
                      inside Vim or outside.

                      > > It's very easy to underestimate the effort involved and the maintenance
                      > > required.
                      >
                      > I guess I'd say I have two objections to this:
                      >
                      > 1) much of the work is already being done, and already being
                      > integrated into vim.
                      >
                      > 2) I've taken a look at the vimshell code, and there really isn't
                      > anything there that nasty.
                      >
                      > Furthermore, the vimshell code is well commented, clean, maintainable,
                      > and expandable. Personally, I'm going to modify it to work on solaris
                      > (it uses forkpty, which isn't available on solaris).

                      You just hit the first problem. There will be others...

                      > > I have no idea what that configure switch would do.
                      >
                      > It would be analagous to the perl support providing ':perl'. In fact
                      > it would do what vimshell does already - allow for a
                      >
                      > :vimshell
                      >
                      > command to fork a shell and display it inside a vim buffer.
                      > You then could navigate the shell, hit 'Esc' (or maybe Ctrl-Esc)
                      > when you wanted to go back and view the buffer. This could probably
                      > be all implemented in terms of a 'define' inside the actual code, and
                      > a switch inside the Makefiles which determined which source files to
                      > include in the compilation..

                      Oh, just a way to enable/disable the code. Well, then the code is still
                      there and needs to be maintained. That you can disable the code if the
                      compiler chokes on it is not a solution, it's working around the
                      problem that something doesn't work. It won't stop people from
                      expecting that it will work.

                      > But that's the point - it's tricky *user* code. And ddd doesn't have what
                      > vim has - namely vimscript. Its forced to do everything in C++, wheras I
                      > could probably write a gdb mode in a couple of lines of vimscript.

                      Well, I did it in Python and you need lots and lots of code to get it to
                      a usable level. And it might break with the next gdb version...

                      > What vim needs to do this right is two *generic* things -
                      > good shell emulation, and the ability to view a shell as a
                      > buffer.
                      >
                      > After that its fairly trivial to write a mode, just like its
                      > fairly trivial to write syntax coloring code. Hell, I just wrote
                      > a mode for my file based debugging system, and I'm just a beginner
                      > at vimscript.

                      I have come to the conclusion that you underestimate how much work is
                      involved. Do you know the 10/90 rule? Even that is an underestimation.

                      > > And there might be one line that takes several weeks to figure out.
                      > > Sorry, these computations don't mean anything.
                      >
                      > well, that's alleviated some by the fact that someone is already working
                      > on the extension. And - based on a cursory examination of vimshell, I think
                      > you might be *overestimating* the complexity. I'd say the best way to
                      > determine who is right is to keep an open mind, and if the code is right,
                      > not have qualms about taking it and merging it with the mainline.

                      I have been spending a day to try to avoid a crash in the regex code for
                      the MingW compiler. And it still doesn't work. That's the kind of
                      things you will run into when you try to make a shell mode work on
                      multiple OSes with multiple compilers.

                      --
                      This sentence is not sure that it exists, but if it does, it will
                      certainly consider the possibility that other sentences exist.

                      /// 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 LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html ///
                    • Edward Peschko
                      ... well, that s the way that vimshell does it, through pipes via a pty. It just so happens that its integrated with vim in a very nice, compact fashion. ...
                      Message 10 of 11 , Mar 1, 2005
                        On Tue, Mar 01, 2005 at 10:56:32PM +0100, Bram Moolenaar wrote:
                        >
                        > Edward Peschko wrote:
                        >
                        > > > It doesn't need to. Just use screen for split windows, run gdb (or any
                        > > > other debugger) in one window and Vim in another. Then you only need
                        > > > some way to tell Vim what code to display, and some commands back to the
                        > > > debugger. The NetBeans interface already does this. Thusly you reduce
                        > > > the problem to only implementing the interface.
                        > >
                        > > Of course. But there are projects that will *never* have interfaces
                        > > like this. Try getting Sun to write a interface for dbx, or HPUX to
                        > > write one for xdb. Or os/390's debugger. Or icon's. Or scheme's.
                        > >
                        > > By going down just the server route, you basically limit vim's usefulness to
                        > > 'supported' debuggers.
                        >
                        > You can use a pipe in between the command and the display. It's not
                        > simple, since you need a pseudo-tty (pty) to do it properly. Might not
                        > work on MS-Windows. But this problem exists no matter if you do this
                        > inside Vim or outside.


                        well, that's the way that vimshell does it, through pipes via a pty.
                        It just so happens that its integrated with vim in a very nice, compact
                        fashion.


                        > > > It's very easy to underestimate the effort involved and the maintenance
                        > > > required.
                        > >
                        > > I guess I'd say I have two objections to this:
                        > >
                        > > 1) much of the work is already being done, and already being
                        > > integrated into vim.
                        > >
                        > > 2) I've taken a look at the vimshell code, and there really isn't
                        > > anything there that nasty.
                        > >
                        > > Furthermore, the vimshell code is well commented, clean, maintainable,
                        > > and expandable. Personally, I'm going to modify it to work on solaris
                        > > (it uses forkpty, which isn't available on solaris).
                        >
                        > You just hit the first problem. There will be others...

                        ...and I'm sure that we can fall back on screen - and the screen
                        group, and programmers - to look for solutions. The openpty one is
                        just one example - screen is full of openpty solutions for
                        different platforms.

                        > > > I have no idea what that configure switch would do.
                        > >
                        > > It would be analagous to the perl support providing ':perl'. In fact
                        > > it would do what vimshell does already - allow for a
                        > >
                        > > :vimshell
                        > >
                        > > command to fork a shell and display it inside a vim buffer.
                        > > You then could navigate the shell, hit 'Esc' (or maybe Ctrl-Esc)
                        > > when you wanted to go back and view the buffer. This could probably
                        > > be all implemented in terms of a 'define' inside the actual code, and
                        > > a switch inside the Makefiles which determined which source files to
                        > > include in the compilation..
                        >
                        > Oh, just a way to enable/disable the code. Well, then the code is still
                        > there and needs to be maintained. That you can disable the code if the
                        > compiler chokes on it is not a solution, it's working around the
                        > problem that something doesn't work. It won't stop people from
                        > expecting that it will work.

                        why? I've seen lots of configure options that have phased in support
                        for different platforms. That's why I'm saying its like perl support.
                        Perl isn't available everywhere, but that doesn't stop vim from
                        providing it...


                        > Well, I did it in Python and you need lots and lots of code to get it to
                        > a usable level. And it might break with the next gdb version...

                        .. and it might not. In any case, this gives users a lot more functionality
                        to roll their own solutions when a 'proper' solution doesn't exist.

                        > I have come to the conclusion that you underestimate how much work is
                        > involved. Do you know the 10/90 rule? Even that is an underestimation.

                        Well, that's fair if I was starting from scratch, but I don't think
                        this is the case here. Its a solved problem, its just the packaging
                        that's different.


                        > > > And there might be one line that takes several weeks to figure out.
                        > > > Sorry, these computations don't mean anything.
                        > >
                        > > well, that's alleviated some by the fact that someone is already working
                        > > on the extension. And - based on a cursory examination of vimshell, I think
                        > > you might be *overestimating* the complexity. I'd say the best way to
                        > > determine who is right is to keep an open mind, and if the code is right,
                        > > not have qualms about taking it and merging it with the mainline.
                        >
                        > I have been spending a day to try to avoid a crash in the regex code for
                        > the MingW compiler. And it still doesn't work. That's the kind of
                        > things you will run into when you try to make a shell mode work on
                        > multiple OSes with multiple compilers.


                        ... and I don't doubt you, if you tried to do everything all at once.
                        What I'm proposing is phased in support - isolate the shell functionality
                        (maybe to a separate code directory inside of vim), and get it working
                        solidly on a couple of the more popular platforms. Make the code so that it
                        is easily portable, based on suggestions from the screen folks and the
                        screen codebase.

                        Add a check to see if the platform is supported for vimshell inside configure.

                        If it is not, then give a warning, saying 'PACKAGE VIMSHELL NOT SUPPORTED'
                        and then continue on with the build. If someone needs to have a certain
                        platform added for support, they can port it.

                        I think you agree with me that it would be a useful option, but that you
                        think the cost is prohibitive.. Is that a fair assessment?
                        If so, then if a good solution presented itself, you wouldn't have problems
                        adding it? Or would you need it to work everywhere and everywhen in order
                        to have it added?

                        Ed
                      • Nazri Ramliy
                        ... I second this. I remember a post to this list not too long ago from Vince Negri saying something about Bram being hesitant to accept patches that extend
                        Message 11 of 11 , Mar 2, 2005
                          On Mon, Feb 28, 2005 at 01:06:16PM -0800, Ryan Paul wrote:
                          > As far as Vimshell is concerned.... I never knew about it until your
                          > initial message on the subject. When I figured out what it is, I got
                          > really excited. Now that I have tried it, i'm really impressed, and I
                          > would like to see it included in Vim via a compilation option at some
                          > point in the future when it can support GUI mode. I can understand why
                          > Bram is hesitant to include it, but it really is a great patch, and it
                          > would be a shame not to include it. I wouldnt build any other really
                          > important features on top of it because of it's lack of portability, but
                          > I really think that in and of itself, it's a valuable addition that many
                          > GNU/Linux users would benefit from having.

                          I second this.

                          I remember a post to this list not too long ago from Vince Negri
                          saying something about Bram being hesitant to accept patches that
                          extend vim funtionality beyond what a text editor should do, and that
                          if provided with enough reasons he would finally accept it.

                          I understand Bram's rationale for being so, but...

                          IMHO vimshell is the best patch that has came up lately and that to
                          see it works effortlessly, one command away (:vimshell), just makes
                          vim much more impressive and makes me able to do my work more
                          efficiently. I tested vimshell by creating a new shell buffer in vim,
                          then start a new vim inside that shell, and then run vimshell, and
                          then start vim inside and then start a new vimshell buffer and then
                          start vim... deeply nested and it didn't hitch at all.

                          (This is not meant to show that vimshell doesn't have any bugs, but
                          rather to show that vimshell integrate with vim very, very well).

                          I'm using ratpoison as my window manager and if I were to use screen
                          to achieve what vimshell does then it would make it as if I was using
                          emacs as there are more keystrokes that I'd have to press in order to
                          get a shell window with a vim session beside/below it (C-t for
                          ratpoison, C-a for screen, C-w for vim window buffers). Heh.. maybe
                          it's my choice of window manager that burden my fingers with
                          keypresses.

                          Here's hoping more people would give a good reason why vimshell should
                          be included in mainstream vim :)

                          Kind regards,

                          Nazri
                        Your message has been successfully submitted and would be delivered to recipients shortly.