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

Re: todo.txt questions

Expand Messages
  • 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 1 of 11 , Mar 1, 2005
    • 0 Attachment
      > >
      > > 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 2 of 11 , Mar 1, 2005
      • 0 Attachment
        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 3 of 11 , Mar 1, 2005
        • 0 Attachment
          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 4 of 11 , Mar 2, 2005
          • 0 Attachment
            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.