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

Re: todo.txt questions

Expand Messages
  • 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 1 of 11 , Mar 1 1:56 PM
    • 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 2 of 11 , Mar 1 3:18 PM
      • 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 3 of 11 , Mar 2 12:59 AM
        • 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.