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

Re: Tab dragging prototype

Expand Messages
  • björn
    Matt, (CC:ing my reply to vim_mac because I think this is of general interest.) ... It s good that you are looking into this yourself...I simply haven t found
    Message 1 of 4 , Jul 2, 2008
    • 0 Attachment
      Matt,

      (CC:ing my reply to vim_mac because I think this is of general interest.)

      2008/7/2 Matt Tolton <matt@...>:
      >
      > I started implementing dragging tabs between vim instances awhile ago,
      > and I thought I'd finish it up. I have a very rough working prototype
      > of this in the attached patch. I wanted you to look over it before I
      > go to the trouble of refining it. I've changed the way that dragging
      > tabs works, even in the normal case where it's not between instances.
      > I did this because it simplifies the code, and IMHO makes it a bit
      > cleaner. The downside is that I think it is ever so slightly slower
      > for that normal case, although I don't notice any visible difference
      > on my computer.
      >
      > Anyway, please look at it and let me know what you think. The code is
      > messy...there are remnants of my attempts at doing this different ways
      > still left in there, etc, and that stuff will be cleaned up/fixed. I
      > just want you to look at the general idea and let me know whether
      > you're ok with it.
      >
      > Thanks!
      >
      > Matt
      >

      It's good that you are looking into this yourself...I simply haven't
      found the time to do so yet. I am still a bit dubious as to how well
      this feature will be work so first of all I want a way to disable it
      and use the old code. Preferably this should be controlled with a
      user default so it can be changed via the preference panel.

      Some random things I noticed while using this patch (you might already
      know about them, but I'll point them out anyway):

      1. I get a warning on line 233 in PSMTabDragAssistant.m
      2. You can only drag if the tabline is visible in the destination window
      3. The tab is always inserted at the end of the tabline when dragging
      between window even though the "visual drag feedback" indicates that
      it should be inserted somewhere else
      4. ":tabmove #" is displayed in the command line when I drag tabs
      inside a window

      Otherwise I think this looks like a nice patch. If you clean it up
      and add a user default to enable/disable inter-window drags I don't
      have any objections to merging it. You should know that I will have
      this disabled by default for now. It is just a bit weird that you
      loose undo-history for a buffer when you drag it to another window.
      Later on we can add a switch button to the preferences with a big
      warning so that users who enable it know what they're getting
      themselves into.

      At this point I'm not sure if I prefer sending ":tabmove" instead of
      the way I'm doing it now to move tabs inside a window. Mostly because
      I don't like this "<C-\><C-N>" dance we have to perform every time we
      send input to Vim. I have been thinking about adding a method much
      like addVimInput: but which calls do_cmdline_cmd() instead of
      add_server_input(). I'm not sure what consequences this will have.
      Does anybody have a clue? Maybe it would be safer to just have a
      method which automatically inserts "<C-\><C-N>". (By "safer" I mean
      that adding input just puts thing on a buffer and returns, whereas I
      think do_cmdline_cmd() executes its command immediately. At the
      moment the backend delays anything but keyboard/mouse input coming
      from MacVim until it deems it safe to act on the input since DO calls
      can arrive at inopportune moments. Anyway, this means that with
      do_cmdline_cmd() the input may be delayed a while, whereas with
      add_server_input() the input is put on the buffer straight away. Ok,
      that may not have made much sense...)

      Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Matt Tolton
      ... Ok. ... Yes, I know about all these...I -did- say it was rough! :) ... Ok, sounds good. ... To me, the stuff isn t -that- bad. However, just
      Message 2 of 4 , Jul 2, 2008
      • 0 Attachment
        > It's good that you are looking into this yourself...I simply haven't
        > found the time to do so yet. I am still a bit dubious as to how well
        > this feature will be work so first of all I want a way to disable it
        > and use the old code. Preferably this should be controlled with a
        > user default so it can be changed via the preference panel.

        Ok.

        >
        > Some random things I noticed while using this patch (you might already
        > know about them, but I'll point them out anyway):
        >
        > 1. I get a warning on line 233 in PSMTabDragAssistant.m
        > 2. You can only drag if the tabline is visible in the destination window
        > 3. The tab is always inserted at the end of the tabline when dragging
        > between window even though the "visual drag feedback" indicates that
        > it should be inserted somewhere else
        > 4. ":tabmove #" is displayed in the command line when I drag tabs
        > inside a window

        Yes, I know about all these...I -did- say it was rough! :)

        > Otherwise I think this looks like a nice patch. If you clean it up
        > and add a user default to enable/disable inter-window drags I don't
        > have any objections to merging it. You should know that I will have
        > this disabled by default for now. It is just a bit weird that you
        > loose undo-history for a buffer when you drag it to another window.
        > Later on we can add a switch button to the preferences with a big
        > warning so that users who enable it know what they're getting
        > themselves into.

        Ok, sounds good.

        >
        > At this point I'm not sure if I prefer sending ":tabmove" instead of
        > the way I'm doing it now to move tabs inside a window. Mostly because
        > I don't like this "<C-\><C-N>" dance we have to perform every time we
        > send input to Vim. I have been thinking about adding a method much
        > like addVimInput: but which calls do_cmdline_cmd() instead of
        > add_server_input(). I'm not sure what consequences this will have.
        > Does anybody have a clue? Maybe it would be safer to just have a
        > method which automatically inserts "<C-\><C-N>". (By "safer" I mean
        > that adding input just puts thing on a buffer and returns, whereas I
        > think do_cmdline_cmd() executes its command immediately. At the

        To me, the <C-\><C-N> stuff isn't -that- bad. However, just from
        grepping through the vim source, it looks like do_cmdline_cmd would be
        safe to use.

        Matt

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Nikola Knežević
        ... Lame stupid question :) Can vim-core be modified to serialize/ deserialize the undo-history, so when MacVim does the tab move, it serializes the
        Message 3 of 4 , Jul 2, 2008
        • 0 Attachment
          On 2 Jul 2008, at 23:34 , Matt Tolton wrote:
          >> Otherwise I think this looks like a nice patch. If you clean it up
          >> and add a user default to enable/disable inter-window drags I don't
          >> have any objections to merging it. You should know that I will have
          >> this disabled by default for now. It is just a bit weird that you
          >> loose undo-history for a buffer when you drag it to another window.
          >> Later on we can add a switch button to the preferences with a big
          >> warning so that users who enable it know what they're getting
          >> themselves into.
          >
          > Ok, sounds good.

          Lame stupid question :) Can vim-core be modified to "serialize/
          deserialize" the undo-history, so when MacVim does the tab move, it
          serializes the undo-history somewhere. When attaching it to another
          window, the undo history gets deserialized...

          Cheers,
          Nikola

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Matt Tolton
          http://www.vim.org/sponsor/vote_results.phpSee #1 on that list. :)On Wed, Jul 2, 2008 at 2:51 PM, Nikola Kne¾eviæ wrote:
          Message 4 of 4 , Jul 2, 2008
          • 0 Attachment
            http://www.vim.org/sponsor/vote_results.php

            See #1 on that list. :)

            On Wed, Jul 2, 2008 at 2:51 PM, Nikola Knežević
            <laladelausanne@...> wrote:
            >
            > On 2 Jul 2008, at 23:34 , Matt Tolton wrote:
            >>> Otherwise I think this looks like a nice patch. If you clean it up
            >>> and add a user default to enable/disable inter-window drags I don't
            >>> have any objections to merging it. You should know that I will have
            >>> this disabled by default for now. It is just a bit weird that you
            >>> loose undo-history for a buffer when you drag it to another window.
            >>> Later on we can add a switch button to the preferences with a big
            >>> warning so that users who enable it know what they're getting
            >>> themselves into.
            >>
            >> Ok, sounds good.
            >
            > Lame stupid question :) Can vim-core be modified to "serialize/
            > deserialize" the undo-history, so when MacVim does the tab move, it
            > serializes the undo-history somewhere. When attaching it to another
            > window, the undo history gets deserialized...
            >
            > Cheers,
            > Nikola
            >
            > >
            >

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          Your message has been successfully submitted and would be delivered to recipients shortly.