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

"window tabs" and "frames/pages"

Expand Messages
  • mzyzik@gmail.com
    All, Looking through the todo list, I noticed a mention of Window Tabs and pages . Also I see that it s planned for the vim7 release. I personally think
    Message 1 of 26 , Feb 2 7:18 PM
    • 0 Attachment
      All,

      Looking through the todo list, I noticed a mention of "Window Tabs" and
      "pages". Also I see that it's planned for the vim7 release. I personally
      think this is a very useful feature; and it's sad to me that only emacs
      has it. I want to propose some ideas about it.

      For mostly consistency reasons, I thought up these:
      1. Call them "frames" instead of "pages"; just like emacs.
      2. Call the tabs "frame tabs".
      3. Have something similar to 'laststatus', but call it 'framestatus',
      accepting these values: 0 (never), 1 (>2 frames), and 2 (always). 0
      means the tabs are hidden. 1 means they appear like the "status line" if
      there are two or more frames; and the line can be at the top of vim. 2
      means these tabs are always visible.
      4. Instead of "1gt" - "99gt" as mentioned in the todo file, have ex stuff
      like this: fadd, fclose, fp, fn, frame, etc. to be consistent with badd,
      bn, buffer, etc.
      5. Figure out how :windo should behave (all windows or all windows in
      current frame) and how to have both functionalities.

      I would appreciate any input on this. Thanks.

      --Matt Zyzik
    • Bram Moolenaar
      ... The name page or frame will mostly be used in the docs, thus it s not very important. For the source code it matters: frame is already used for a
      Message 2 of 26 , Feb 3 3:33 AM
      • 0 Attachment
        Mat Zyzik wrote:

        > Looking through the todo list, I noticed a mention of "Window Tabs" and
        > "pages". Also I see that it's planned for the vim7 release. I personally
        > think this is a very useful feature; and it's sad to me that only emacs
        > has it. I want to propose some ideas about it.
        >
        > For mostly consistency reasons, I thought up these:
        > 1. Call them "frames" instead of "pages"; just like emacs.
        > 2. Call the tabs "frame tabs".

        The name "page" or "frame" will mostly be used in the docs, thus it's
        not very important. For the source code it matters: "frame" is already
        used for a collection of split windows. Using "page" avoids confusion
        there.

        I don't think using the same name as Emacs is an advantage...

        > 3. Have something similar to 'laststatus', but call it 'framestatus',
        > accepting these values: 0 (never), 1 (>2 frames), and 2 (always). 0
        > means the tabs are hidden. 1 means they appear like the "status line" if
        > there are two or more frames; and the line can be at the top of vim. 2
        > means these tabs are always visible.

        Is there a reason to always show tabs? Firefox uses tabs quite nicely,
        and it doesn't show tabs until there is more than one page. Appears to
        work just fine.

        I don't want to hide the tabs, because you can't see what you are doing.
        It's too easy to forget that you have windows that you are currently not
        seeing.

        > 4. Instead of "1gt" - "99gt" as mentioned in the todo file, have ex stuff
        > like this: fadd, fclose, fp, fn, frame, etc. to be consistent with badd,
        > bn, buffer, etc.

        We do need a bunch of commands for this, yes. That will be easy. The
        hard part is the redrawing.

        > 5. Figure out how :windo should behave (all windows or all windows in
        > current frame) and how to have both functionalities.

        I think we need both. The default would be to go over all windows and
        with a modifier you could restrict it to the current page/frame.

        Note that I will have to cut down the list of "planned for Vim 7"
        features. Vim 7 currently has sufficient new features to release it.
        The more things are added the longer it will take. I'll probably only
        do a few more things that will not take much time and are still useful.
        Adding tabs does sound like something that could still be included.

        --
        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/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://www.ICCF.nl ///
      • A. J. Mechelynck
        ... [...] ... [...] That s an option (a preference, if you will: the corresponding menu is named Tools - Options on Windows and, I ve been told, Edit -
        Message 3 of 26 , Feb 3 4:01 AM
        • 0 Attachment
          Bram Moolenaar wrote:
          > Mat Zyzik wrote:
          [...]
          >> 3. Have something similar to 'laststatus', but call it 'framestatus',
          >> accepting these values: 0 (never), 1 (>2 frames), and 2 (always). 0
          >> means the tabs are hidden. 1 means they appear like the "status line" if
          >> there are two or more frames; and the line can be at the top of vim. 2
          >> means these tabs are always visible.
          >
          > Is there a reason to always show tabs? Firefox uses tabs quite nicely,
          > and it doesn't show tabs until there is more than one page. Appears to
          > work just fine.
          [...]

          That's an option (a preference, if you will: the corresponding menu is
          named "Tools -> Options" on Windows and, I've been told, "Edit ->
          Preferences" on Unix). Personally I prefer to always show tabs in
          Firefox, even in the (rare for me) case that there's only one of them.
          Of course, Vim is not Firefox, and Vim has status lines (there too, I
          use ":set laststatus=2", i.e., always). I wonder how tabs will appear if
          the idea is to make one tab correspond to a set of several windows: for
          instance, will some options such as 'equalalways' or 'winheight' get a
          different value in each tab (or frame or page, the name isn't that
          important)? And what about 'encoding'? Will some options get three
          values (local-to-window, global-to-tab, global-to-Vim)?


          Best regards,
          Tony.
        • Martin Stubenschrott
          ... And I would like to never show tabs in firefox, but there is no option there yet :) A little off topic - if you dislike this, I am sorry, and will stop
          Message 4 of 26 , Feb 3 4:23 AM
          • 0 Attachment
            On Friday 03 February 2006 13:01, A. J. Mechelynck wrote:
            > Personally I prefer to always show tabs in
            > Firefox

            And I would like to never show tabs in firefox, but there is no option there
            yet :)


            A little off topic - if you dislike this, I am sorry, and will stop posting
            things like this:

            However, I am currently developing a firefox extension which will make firefox
            very vim-like (with ex-mode, most the usual vim-keybindings, a GUI which
            resembles vim by showing only content (no menubar/toolbar/tab bar), a
            statusline and the line for the :command inputs..., and lots more vim-like
            features like :map, but it's still a long way to go).

            But I have a question right now to you heavy vim-users:

            What's more intuitive to use for GoBack and GoForward commands?
            I'm thinking between:
            u/ctrl-r
            and
            ctrl-o/ctrl-i

            Ctrl-o/ctrl-i are probably better, since a browser history is like a
            changelist, but back is often needed, and 'u' would be shorter for this, and
            in some way it also 'undoes' chainging the website.

            Also I have not decided if it's better to say:

            :e[dit] www.google.com

            or

            :o[pen] www.google.com

            or just:

            :go www.google.com

            :edit is more vim like, but is it intuitive to edit a webpage?


            Quickly changing between buffers would be done with Ctrl-n/Ctrl-p or better
            ideas? :bnext/:bprevious are quite long for this often used feature in a
            browser.
            --
            Martin Stubenschrott
          • Bram Moolenaar
            ... I see, you can change that in Firefox. Well, it s just that I like the default and I don t see a very good reason to do otherwise. Especially because we
            Message 5 of 26 , Feb 3 5:44 AM
            • 0 Attachment
              Tony Mechelynck wrote:

              > Bram Moolenaar wrote:
              > > Mat Zyzik wrote:
              > [...]
              > >> 3. Have something similar to 'laststatus', but call it 'framestatus',
              > >> accepting these values: 0 (never), 1 (>2 frames), and 2 (always). 0
              > >> means the tabs are hidden. 1 means they appear like the "status line" if
              > >> there are two or more frames; and the line can be at the top of vim. 2
              > >> means these tabs are always visible.
              > >
              > > Is there a reason to always show tabs? Firefox uses tabs quite nicely,
              > > and it doesn't show tabs until there is more than one page. Appears to
              > > work just fine.
              > [...]
              >
              > That's an option (a preference, if you will: the corresponding menu is
              > named "Tools -> Options" on Windows and, I've been told, "Edit ->
              > Preferences" on Unix). Personally I prefer to always show tabs in
              > Firefox, even in the (rare for me) case that there's only one of them.
              > Of course, Vim is not Firefox, and Vim has status lines (there too, I
              > use ":set laststatus=2", i.e., always).

              I see, you can change that in Firefox. Well, it's just that I like the
              default and I don't see a very good reason to do otherwise. Especially
              because we have never had tabs until now.

              > I wonder how tabs will appear if
              > the idea is to make one tab correspond to a set of several windows: for
              > instance, will some options such as 'equalalways' or 'winheight' get a
              > different value in each tab (or frame or page, the name isn't that
              > important)? And what about 'encoding'? Will some options get three
              > values (local-to-window, global-to-tab, global-to-Vim)?

              At first there will be no local-to-tab options. It will make things
              quite complicated, thus hopefully we can avoid them.

              Note that it's very easy to come up with all kinds of extra things once
              you have tabs. But I really want to keep the number of options and
              commands to a minimum. We have more than enough of them already!

              --
              Vi is clearly superior to emacs, since "vi" has only two characters
              (and two keystrokes), while "emacs" has five. (Randy C. Ford)

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://www.ICCF.nl ///
            • Benji Fisher
              ... While discussing design issues for tabs, I think we should also think about multiple gwindows (that is, windows in the GUI sense) for gvim. From the
              Message 6 of 26 , Feb 3 6:31 AM
              • 0 Attachment
                On Fri, Feb 03, 2006 at 02:44:26PM +0100, Bram Moolenaar wrote:
                >
                > At first there will be no local-to-tab options. It will make things
                > quite complicated, thus hopefully we can avoid them.
                >
                > Note that it's very easy to come up with all kinds of extra things once
                > you have tabs. But I really want to keep the number of options and
                > commands to a minimum. We have more than enough of them already!

                While discussing design issues for tabs, I think we should also
                think about multiple gwindows (that is, windows in the GUI sense) for
                gvim. From the user's point of view, a separate gwindow is a lot like a
                separate tab that is displayed differently. A lot of the same issues
                come up: should :windo and :bufdo act on the current tab/gwindow or on
                all of them; which options should, by default, stick with a single
                tab/gwindow; is there a separate command history for each tab/gwindow;
                etc.

                If you add up the votes for tabs and multiple gwindows on
                http://www.vim.org/sponsor/vote_results.php
                (which is not to say that this is actually justified) you get the second
                most popular RFE. I am not suggesting that we tackle both right now,
                just that we pay attention to common issues.

                --Benji Fisher
              • A. J. Mechelynck
                ... At the moment, multiple gwindows exist in the form of multiple instances of gvim (or didn t I understand what you meant by gwindows?). (Some programs, like
                Message 7 of 26 , Feb 3 7:08 AM
                • 0 Attachment
                  Benji Fisher wrote:
                  > On Fri, Feb 03, 2006 at 02:44:26PM +0100, Bram Moolenaar wrote:
                  >> At first there will be no local-to-tab options. It will make things
                  >> quite complicated, thus hopefully we can avoid them.
                  >>
                  >> Note that it's very easy to come up with all kinds of extra things once
                  >> you have tabs. But I really want to keep the number of options and
                  >> commands to a minimum. We have more than enough of them already!
                  >
                  > While discussing design issues for tabs, I think we should also
                  > think about multiple gwindows (that is, windows in the GUI sense) for
                  > gvim. From the user's point of view, a separate gwindow is a lot like a
                  > separate tab that is displayed differently. A lot of the same issues
                  > come up: should :windo and :bufdo act on the current tab/gwindow or on
                  > all of them; which options should, by default, stick with a single
                  > tab/gwindow; is there a separate command history for each tab/gwindow;
                  > etc.
                  >
                  > If you add up the votes for tabs and multiple gwindows on
                  > http://www.vim.org/sponsor/vote_results.php
                  > (which is not to say that this is actually justified) you get the second
                  > most popular RFE. I am not suggesting that we tackle both right now,
                  > just that we pay attention to common issues.
                  >
                  > --Benji Fisher
                  >
                  >
                  >

                  At the moment, multiple gwindows exist in the form of multiple instances
                  of gvim (or didn't I understand what you meant by gwindows?). (Some
                  programs, like Firefox, will open a different window or tab but not a
                  different instance of the executable each time they are invoked).

                  Settings common to all gwindows exist in the form of a common vimrc.
                  However, changing settings (even global settings like 'encoding' and
                  'guifont') in one gwindow doesn't carry over to the other ones. This is
                  very important to me: I need to be able to edit several files with ":set
                  enc=latin1 gfn=Lucida_Console:h8:cDEFAULT" (in Latin-only text, but
                  possibly in languages like French or German, which use many diacritics
                  which English sees only in foreign words) in one gvim, a couple more
                  with ":set enc=utf8 gfn=Courier_New:h12:cDEFAULT" in another (with Latin
                  and Arabic text), and maybe still one or two additional files with ":set
                  enc=utf8 gfn=MingLiU:h16:cDEFAULT" in a third one (with Latin and
                  Chinese text). I wouldn't want gvim to force such settings to carry over
                  from one GUI to the next (as might happen if all invocations were
                  referred to a single instance of the executable).


                  Best regards,
                  Tony.
                • Milan Vancura
                  ... As I think about tabs in Firefox or Opera, especialy after I have installed the nice extension Duplicate Tab which can also merge more windows to one, I
                  Message 8 of 26 , Feb 3 7:22 AM
                  • 0 Attachment
                    > Note that it's very easy to come up with all kinds of extra things once
                    > you have tabs. But I really want to keep the number of options and
                    > commands to a minimum. We have more than enough of them already!

                    As I think about tabs in Firefox or Opera, especialy after I have installed the
                    nice extension Duplicate Tab which can also merge more windows to one, I feel
                    the differencies between windows and tabs are only these:

                    1. all tabs have the same window size
                    2. they are displayed at the same area on the screen, only one is visible at
                    every time
                    3. you have only one record in a system window list for the whole set of tabs,
                    all manipulations with an order of tabs etc. is done in the "parent window",
                    not in the system itself

                    And that's all. If you change window-local property, it will be usualy changed
                    in one tab only - there are specialy mentioned exceptions when not (for example
                    window size :-) ).

                    If I look at these three points, I think normal window splitting with some
                    setting to show only of them at each time is very near to "tabs" - all you need
                    to full feeling of (Firefox) tabs is to write names of all windows/tabs to
                    status line. That's all.

                    Am I missed something? Or do you plan vim tabs will do something more than tabs
                    in Opera, Firefox, KDE shell Konsole etc. ?

                    Milan Vancura
                  • mzyzik@gmail.com
                    ... The reason to always show tabs is the same as the reason to always show the status line. I personally set laststatus = 2. It s just a preference. I was
                    Message 9 of 26 , Feb 3 7:58 AM
                    • 0 Attachment
                      > > 3. Have something similar to 'laststatus', but call it 'framestatus',
                      > > accepting these values: 0 (never), 1 (>2 frames), and 2 (always). 0
                      > > means the tabs are hidden. 1 means they appear like the "status line" if
                      > > there are two or more frames; and the line can be at the top of vim. 2
                      > > means these tabs are always visible.
                      >
                      > Is there a reason to always show tabs? Firefox uses tabs quite nicely,
                      > and it doesn't show tabs until there is more than one page. Appears to
                      > work just fine.
                      >

                      The reason to always show tabs is the same as the reason to always show the status
                      line. I personally set laststatus = 2. It's just a preference. I was
                      under the impression that it would be quite easy to implement; and
                      consistency-wise, it's a plus. In firefox and vim, I would probably show
                      tabs when there's more than one page; yet still I think something like
                      framestatus is important. Firefox does have the option to change the
                      behavior. Maybe it "works fine" because everyone is configuring it :) ??

                      > I don't want to hide the tabs, because you can't see what you are doing.
                      > It's too easy to forget that you have windows that you are currently not
                      > seeing.

                      When hiding the laststatus, I can't see the filename I'm working with
                      unless I edit 'rulerformat', yet I don't. Who cares if you forget what
                      windows you have. At least you won't forget which buffers you have open.
                      Since :buffers acts like :ls; you could have :frames act like an :ls for
                      frames. What I don't like about "pages" is that :pclose is already for
                      the preview window. You could do :pgclose, but it's ugly.

                      --Matt Zyzik
                    • mzyzik@gmail.com
                      ... I actually never thought of this. It s the behavior that emacs has. When in gui mode, new windows are created for frames; and they re not when in console
                      Message 10 of 26 , Feb 3 8:09 AM
                      • 0 Attachment
                        > While discussing design issues for tabs, I think we should also
                        > think about multiple gwindows (that is, windows in the GUI sense) for
                        > gvim. From the user's point of view, a separate gwindow is a lot like a
                        > separate tab that is displayed differently. A lot of the same issues
                        > come up: should :windo and :bufdo act on the current tab/gwindow or on
                        > all of them; which options should, by default, stick with a single
                        > tab/gwindow; is there a separate command history for each tab/gwindow;
                        > etc.
                        >
                        > If you add up the votes for tabs and multiple gwindows on
                        > http://www.vim.org/sponsor/vote_results.php
                        > (which is not to say that this is actually justified) you get the second
                        > most popular RFE. I am not suggesting that we tackle both right now,
                        > just that we pay attention to common issues.
                        >
                        > --Benji Fisher

                        I actually never thought of this. It's the behavior that emacs has. When
                        in gui mode, new windows are created for frames; and they're not when in
                        console mode.
                        I personally don't need the "multiple gwindows" because if I have enough
                        room on my screen for another window, I would rather just maximize vim
                        and split vertically. But this is a good thought; maybe others would
                        want it.
                      • mzyzik@gmail.com
                        You are missing something. File editing is different than browsing. You might need to see two files at the same time when editing a third. You might want to
                        Message 11 of 26 , Feb 3 8:15 AM
                        • 0 Attachment
                          You are missing something. File editing is different than browsing. You
                          might need to see two files at the same time when editing a third. You
                          might want to then create a new frame temporarily to browse through one
                          file, then switch back to the previous window layout. And if you are
                          working on a complicated project, you might want to have multiple window
                          layouts, and switch back and forth between them.

                          --Matt

                          On Fri, Feb 03, 2006 at 04:22:50PM +0100, Milan Vancura wrote:
                          > > Note that it's very easy to come up with all kinds of extra things once
                          > > you have tabs. But I really want to keep the number of options and
                          > > commands to a minimum. We have more than enough of them already!
                          >
                          > As I think about tabs in Firefox or Opera, especialy after I have installed the
                          > nice extension Duplicate Tab which can also merge more windows to one, I feel
                          > the differencies between windows and tabs are only these:
                          >
                          > 1. all tabs have the same window size
                          > 2. they are displayed at the same area on the screen, only one is visible at
                          > every time
                          > 3. you have only one record in a system window list for the whole set of tabs,
                          > all manipulations with an order of tabs etc. is done in the "parent window",
                          > not in the system itself
                          >
                          > And that's all. If you change window-local property, it will be usualy changed
                          > in one tab only - there are specialy mentioned exceptions when not (for example
                          > window size :-) ).
                          >
                          > If I look at these three points, I think normal window splitting with some
                          > setting to show only of them at each time is very near to "tabs" - all you need
                          > to full feeling of (Firefox) tabs is to write names of all windows/tabs to
                          > status line. That's all.
                          >
                          > Am I missed something? Or do you plan vim tabs will do something more than tabs
                          > in Opera, Firefox, KDE shell Konsole etc. ?
                          >
                          > Milan Vancura
                        • Bram Moolenaar
                          ... There is one important difference: with multiple tabs you still have only one command line. With multiple toplevel windows you will have multiple command
                          Message 12 of 26 , Feb 3 10:54 AM
                          • 0 Attachment
                            Benji Fisher wrote:

                            > On Fri, Feb 03, 2006 at 02:44:26PM +0100, Bram Moolenaar wrote:
                            > >
                            > > At first there will be no local-to-tab options. It will make things
                            > > quite complicated, thus hopefully we can avoid them.
                            > >
                            > > Note that it's very easy to come up with all kinds of extra things once
                            > > you have tabs. But I really want to keep the number of options and
                            > > commands to a minimum. We have more than enough of them already!
                            >
                            > While discussing design issues for tabs, I think we should also
                            > think about multiple gwindows (that is, windows in the GUI sense) for
                            > gvim. From the user's point of view, a separate gwindow is a lot like a
                            > separate tab that is displayed differently. A lot of the same issues
                            > come up: should :windo and :bufdo act on the current tab/gwindow or on
                            > all of them; which options should, by default, stick with a single
                            > tab/gwindow; is there a separate command history for each tab/gwindow;
                            > etc.
                            >
                            > If you add up the votes for tabs and multiple gwindows on
                            > http://www.vim.org/sponsor/vote_results.php
                            > (which is not to say that this is actually justified) you get the second
                            > most popular RFE. I am not suggesting that we tackle both right now,
                            > just that we pay attention to common issues.

                            There is one important difference: with multiple tabs you still have
                            only one command line. With multiple toplevel windows you will have
                            multiple command lines. That creates a lot of issues that aren't easy
                            to tackle... Also, having multiple Visual areas, multiple states, etc.
                            It's probably easier to run gvim twice and have them communicate.

                            --
                            hundred-and-one symptoms of being an internet addict:
                            252. You vote for foreign officials.

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ download, build and distribute -- http://www.A-A-P.org ///
                            \\\ help me help AIDS victims -- http://www.ICCF.nl ///
                          • Mikolaj Machowski
                            Dnia pi±tek, 3 lutego 2006 15:31, Benji Fisher napisa³: Personally I think it would be nice if there could be possibility to treat all separate windows (or
                            Message 13 of 26 , Feb 3 11:48 AM
                            • 0 Attachment
                              Dnia piątek, 3 lutego 2006 15:31, Benji Fisher napisał:

                              Personally I think it would be nice if there could be possibility to
                              treat all separate windows (or chosen subset of them) as one session.
                              Especially to have one common list of buffers and auto switching
                              between windows with :buffer command.

                              > If you add up the votes for tabs and multiple gwindows on
                              > http://www.vim.org/sponsor/vote_results.php

                              Yep. Time to renew my votes :)

                              m.
                            • Stefano Zacchiroli
                              ... Agreed, I often work with multiple gvim windows for instance. But an easy way to start up another gvim from one in execution would be a real plus. Also, in
                              Message 14 of 26 , Feb 4 1:38 AM
                              • 0 Attachment
                                On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                > to tackle... Also, having multiple Visual areas, multiple states, etc.
                                > It's probably easier to run gvim twice and have them communicate.

                                Agreed, I often work with multiple gvim windows for instance.
                                But an easy way to start up another gvim from one in execution would be
                                a real plus.

                                Also, in such a way of working, a (optional) feature like: start a new
                                gvim with the current set of windows/tabs/buffer would be valuable.

                                Just my 0.02 EUR.
                                Cheers.

                                --
                                Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
                                zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
                                If there's any real truth it's that the entire multidimensional infinity
                                of the Universe is almost certainly being run by a bunch of maniacs. -!-
                              • Benji Fisher
                                ... Both of these can be implemented as user-defined commands/maps/menus. Assuming that gvim is in your path, ... will start up a new instance. If you want
                                Message 15 of 26 , Feb 4 5:13 AM
                                • 0 Attachment
                                  On Sat, Feb 04, 2006 at 10:38:15AM +0100, Stefano Zacchiroli wrote:
                                  > On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                  > > to tackle... Also, having multiple Visual areas, multiple states, etc.
                                  > > It's probably easier to run gvim twice and have them communicate.
                                  >
                                  > Agreed, I often work with multiple gvim windows for instance.
                                  > But an easy way to start up another gvim from one in execution would be
                                  > a real plus.
                                  >
                                  > Also, in such a way of working, a (optional) feature like: start a new
                                  > gvim with the current set of windows/tabs/buffer would be valuable.
                                  >
                                  > Just my 0.02 EUR.
                                  > Cheers.

                                  Both of these can be implemented as user-defined
                                  commands/maps/menus. Assuming that gvim is in your path,

                                  :!gvim

                                  will start up a new instance. If you want the current windows and
                                  buffers, then

                                  :mksession <tempfile>
                                  :gvim -S <tempfile>

                                  will do.

                                  The problem is that you will then get a bunch of warning messages,
                                  telling you that the buffers are all being edited already: edit
                                  read-only, edit anyway, recover, or quit? With multiple tabs or with
                                  multiple gwindows, you would not want this to happen: there is only one
                                  running gvim, and it has one copy of each buffer no matter how many
                                  windows/tabs/gwindows are viewing it.

                                  BTW, others have asked why you would ever want to hide the tabs if
                                  there are multiple tabs open. Here is one scenario: I am writing a
                                  script, and I prefer to use :s rather than substitute(). I would like
                                  to open a temporary buffer. If I can do this in a hidden tab, then I do
                                  not have to worry about messing up the current view. This also argues
                                  for the option of having separate command and search histories for each
                                  tab.

                                  --Benji Fisher
                                • Johnny Blaze
                                  ... Why not make tabs a display option for split windows? Something like: set tabs then when you do a :sball or :new, you get tabs instead of windows... set
                                  Message 16 of 26 , Feb 5 9:19 AM
                                  • 0 Attachment
                                    On 2/4/06, Benji Fisher <benji@...> wrote:
                                    > On Sat, Feb 04, 2006 at 10:38:15AM +0100, Stefano Zacchiroli wrote:
                                    > > On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                    > > > to tackle... Also, having multiple Visual areas, multiple states, etc.
                                    > > > It's probably easier to run gvim twice and have them communicate.
                                    > >
                                    > > Agreed, I often work with multiple gvim windows for instance.
                                    > > But an easy way to start up another gvim from one in execution would be
                                    > > a real plus.
                                    > >
                                    > > Also, in such a way of working, a (optional) feature like: start a new
                                    > > gvim with the current set of windows/tabs/buffer would be valuable.
                                    > >
                                    > > Just my 0.02 EUR.
                                    > > Cheers.
                                    >
                                    > Both of these can be implemented as user-defined
                                    > commands/maps/menus. Assuming that gvim is in your path,
                                    >
                                    > :!gvim
                                    >
                                    > will start up a new instance. If you want the current windows and
                                    > buffers, then
                                    >
                                    > :mksession <tempfile>
                                    > :gvim -S <tempfile>
                                    >
                                    > will do.
                                    >
                                    > The problem is that you will then get a bunch of warning messages,
                                    > telling you that the buffers are all being edited already: edit
                                    > read-only, edit anyway, recover, or quit? With multiple tabs or with
                                    > multiple gwindows, you would not want this to happen: there is only one
                                    > running gvim, and it has one copy of each buffer no matter how many
                                    > windows/tabs/gwindows are viewing it.
                                    >
                                    > BTW, others have asked why you would ever want to hide the tabs if
                                    > there are multiple tabs open. Here is one scenario: I am writing a
                                    > script, and I prefer to use :s rather than substitute(). I would like
                                    > to open a temporary buffer. If I can do this in a hidden tab, then I do
                                    > not have to worry about messing up the current view. This also argues
                                    > for the option of having separate command and search histories for each
                                    > tab.
                                    >
                                    > --Benji Fisher
                                    >

                                    Why not make tabs a display option for split windows? Something like:

                                    set tabs

                                    then when you do a :sball or :new, you get tabs instead of windows...

                                    set notabs

                                    then when you do a :sball or :new, you get the current behavior with
                                    out any kind of tab-line.


                                    --

                                    . o O pyromancer O o .
                                  • A. J. Mechelynck
                                    ... Hello Johnny. Without changing anything in the current versions of ... Only the current buffer s contents (the current tab s, if you will) will be visible,
                                    Message 17 of 26 , Feb 5 9:58 AM
                                    • 0 Attachment
                                      Johnny Blaze wrote:
                                      > On 2/4/06, Benji Fisher <benji@...> wrote:
                                      >> On Sat, Feb 04, 2006 at 10:38:15AM +0100, Stefano Zacchiroli wrote:
                                      >>> On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                      >>>> to tackle... Also, having multiple Visual areas, multiple states, etc.
                                      >>>> It's probably easier to run gvim twice and have them communicate.
                                      >>> Agreed, I often work with multiple gvim windows for instance.
                                      >>> But an easy way to start up another gvim from one in execution would be
                                      >>> a real plus.
                                      >>>
                                      >>> Also, in such a way of working, a (optional) feature like: start a new
                                      >>> gvim with the current set of windows/tabs/buffer would be valuable.
                                      >>>
                                      >>> Just my 0.02 EUR.
                                      >>> Cheers.
                                      >> Both of these can be implemented as user-defined
                                      >> commands/maps/menus. Assuming that gvim is in your path,
                                      >>
                                      >> :!gvim
                                      >>
                                      >> will start up a new instance. If you want the current windows and
                                      >> buffers, then
                                      >>
                                      >> :mksession <tempfile>
                                      >> :gvim -S <tempfile>
                                      >>
                                      >> will do.
                                      >>
                                      >> The problem is that you will then get a bunch of warning messages,
                                      >> telling you that the buffers are all being edited already: edit
                                      >> read-only, edit anyway, recover, or quit? With multiple tabs or with
                                      >> multiple gwindows, you would not want this to happen: there is only one
                                      >> running gvim, and it has one copy of each buffer no matter how many
                                      >> windows/tabs/gwindows are viewing it.
                                      >>
                                      >> BTW, others have asked why you would ever want to hide the tabs if
                                      >> there are multiple tabs open. Here is one scenario: I am writing a
                                      >> script, and I prefer to use :s rather than substitute(). I would like
                                      >> to open a temporary buffer. If I can do this in a hidden tab, then I do
                                      >> not have to worry about messing up the current view. This also argues
                                      >> for the option of having separate command and search histories for each
                                      >> tab.
                                      >>
                                      >> --Benji Fisher
                                      >>
                                      >
                                      > Why not make tabs a display option for split windows? Something like:
                                      >
                                      > set tabs
                                      >
                                      > then when you do a :sball or :new, you get tabs instead of windows...
                                      >
                                      > set notabs
                                      >
                                      > then when you do a :sball or :new, you get the current behavior with
                                      > out any kind of tab-line.
                                      >
                                      >
                                      > --
                                      >
                                      > . o O pyromancer O o .

                                      Hello Johnny. Without changing anything in the current versions of
                                      (g)vim, you can use "Rolodex Vim", as follows:

                                      :set noequalalways winminheight=0 winheight=99999

                                      or if you're lazy ;-) :

                                      :set noea wmh=0 wh=999

                                      Only the current buffer's contents (the current tab's, if you will) will
                                      be visible, and all other "horizontally split windows" will be reduced
                                      to a status line each and nothing else (displaying the corresponding
                                      filename). Think of these status lines (above and below the active tab
                                      contents) as colored tabs (or black with white print) on the edges of
                                      the pages of a Rolodex before and after the current one. Click on a
                                      "tab" to open it, or use {number}^Ww to open the nth one, ^Ww with no
                                      number for the next one, ^WW for the previous one (in the two latter
                                      cases, in round-robin fashion).


                                      Best regards,
                                      Tony.
                                    • mzyzik@gmail.com
                                      ... It s easier and better and more logical just to create new commands for creating new frames. Why would someone want to change tabs/notabs on the fly when
                                      Message 18 of 26 , Feb 5 10:00 AM
                                      • 0 Attachment
                                        > Why not make tabs a display option for split windows? Something like:
                                        >
                                        > set tabs
                                        >
                                        > then when you do a :sball or :new, you get tabs instead of windows...
                                        >
                                        > set notabs
                                        >
                                        > then when you do a :sball or :new, you get the current behavior with
                                        > out any kind of tab-line.
                                        >
                                        >
                                        > --
                                        >
                                        > . o O pyromancer O o .

                                        It's easier and better and more logical just to create new commands
                                        for creating new frames.
                                        Why would someone want to change tabs/notabs on the fly when they can
                                        just have a command like :frall or :fnew?

                                        --Matt
                                      • Gautam Iyer
                                        ... Well for me the real plus of having multiple windows is to detach tabs! Would that be easy to implement if you have multiple gvim instances
                                        Message 19 of 26 , Feb 5 1:30 PM
                                        • 0 Attachment
                                          On Sat, Feb 04, 2006 at 10:38:15AM +0100, Stefano Zacchiroli wrote:

                                          > On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                          >
                                          > > to tackle... Also, having multiple Visual areas, multiple states, etc.
                                          > > It's probably easier to run gvim twice and have them communicate.
                                          >
                                          > Agreed, I often work with multiple gvim windows for instance.
                                          > But an easy way to start up another gvim from one in execution would be
                                          > a real plus.

                                          Well for me the real plus of having multiple windows is to "detach"
                                          tabs! Would that be easy to implement if you have multiple gvim
                                          instances communicating?

                                          If you do manage to do this with multiple gvim instances communicating,
                                          then I'm hoping that tabs (and buffers) can be somehow magically moved
                                          between console vim instances (which is all I use anyway!).

                                          But yes, I'm all for multiple windows and (detachable) tabs!

                                          :)

                                          GI

                                          --
                                          Microsoft broke Volkswagen's world record: Volkswagen only made 22
                                          million bugs!
                                        • Zdenek Sekera
                                          ... And mine too!
                                          Message 20 of 26 , Feb 6 1:21 AM
                                          • 0 Attachment
                                            > -----Original Message-----
                                            > From: Mikolaj Machowski [mailto:mikmach@...]
                                            > Sent: 03 February 2006 20:48
                                            > To: vim-dev@...
                                            > Subject: Re: "window tabs" and "frames/pages"
                                            >
                                            > Dnia piątek, 3 lutego 2006 15:31, Benji Fisher napisał:
                                            >
                                            > Personally I think it would be nice if there could be possibility to
                                            > treat all separate windows (or chosen subset of them) as one session.
                                            > Especially to have one common list of buffers and auto switching
                                            > between windows with :buffer command.
                                            >
                                            > > If you add up the votes for tabs and multiple gwindows on
                                            > > http://www.vim.org/sponsor/vote_results.php
                                            >
                                            > Yep. Time to renew my votes :)

                                            And mine too!

                                            ---Zdenek
                                          • Benji Fisher
                                            ... Good point: if multiple windows are implemented by having more communication between different instances of vim, there is no need to insist on gvim.
                                            Message 21 of 26 , Feb 6 5:36 AM
                                            • 0 Attachment
                                              On Sun, Feb 05, 2006 at 03:30:30PM -0600, Gautam Iyer wrote:
                                              > On Sat, Feb 04, 2006 at 10:38:15AM +0100, Stefano Zacchiroli wrote:
                                              >
                                              > > On Fri, Feb 03, 2006 at 07:54:18PM +0100, Bram Moolenaar wrote:
                                              > >
                                              > > > to tackle... Also, having multiple Visual areas, multiple states, etc.
                                              > > > It's probably easier to run gvim twice and have them communicate.
                                              > >
                                              > > Agreed, I often work with multiple gvim windows for instance.
                                              > > But an easy way to start up another gvim from one in execution would be
                                              > > a real plus.
                                              >
                                              > Well for me the real plus of having multiple windows is to "detach"
                                              > tabs! Would that be easy to implement if you have multiple gvim
                                              > instances communicating?
                                              >
                                              > If you do manage to do this with multiple gvim instances communicating,
                                              > then I'm hoping that tabs (and buffers) can be somehow magically moved
                                              > between console vim instances (which is all I use anyway!).
                                              >
                                              > But yes, I'm all for multiple windows and (detachable) tabs!

                                              Good point: if multiple windows are implemented by having more
                                              communication between different instances of vim, there is no need to
                                              insist on gvim.

                                              Design issues: this would force a lot of decisions on us. The two
                                              instances of vim would have separate histories (search, command-line,
                                              jumps, etc.); global options changed in one would not affect the other;
                                              new mappings, commands, etc. defined in one would not affect the other.
                                              Is this what we want? It should be possible to do the equivalent of
                                              making a session file and loading it, so that the two instances start
                                              off in the same state.

                                              Implementation issues: I am not really competent to discuss this,
                                              but I suspect that the main difficulty would be allowing two instances
                                              of vim to share a buffer.

                                              OT: is it possible in Mozilla to detach a tab, so that the web page in
                                              the tab gets its own window?

                                              --Benji Fisher
                                            • mzyzik@gmail.com
                                              ... Undoubtedly implementing the multiple windows to represent frames/pages will be difficult to implement. I think Bram would be reluctant to introduce
                                              Message 22 of 26 , Feb 6 7:27 AM
                                              • 0 Attachment
                                                > Good point: if multiple windows are implemented by having more
                                                > communication between different instances of vim, there is no need to
                                                > insist on gvim.
                                                >
                                                > Design issues: this would force a lot of decisions on us. The two
                                                > instances of vim would have separate histories (search, command-line,
                                                > jumps, etc.); global options changed in one would not affect the other;
                                                > new mappings, commands, etc. defined in one would not affect the other.
                                                > Is this what we want? It should be possible to do the equivalent of
                                                > making a session file and loading it, so that the two instances start
                                                > off in the same state.
                                                >
                                                > Implementation issues: I am not really competent to discuss this,
                                                > but I suspect that the main difficulty would be allowing two instances
                                                > of vim to share a buffer.
                                                >
                                                > OT: is it possible in Mozilla to detach a tab, so that the web page in
                                                > the tab gets its own window?
                                                >
                                                > --Benji Fisher

                                                Undoubtedly implementing the multiple windows to represent
                                                "frames/pages" will be difficult to implement. I think Bram would be
                                                reluctant to introduce frames in Vim7 if this was a requirement. We
                                                should consider this once the tabs and frames are working well within
                                                one window.
                                                Basically what I'm saying is, we should just get the frames working
                                                first, hopefully in Vim7, and then consider the multiple windows per
                                                frames later. Besides, the two votes in the top 10 are for frames, and
                                                tabs for those frames; with no mention of multiple windows.

                                                --Matt
                                              • Benji Fisher
                                                ... In my first post on this thread, I advocated considering the design issues of multiple windows at the same time that we discuss tabs, and I still think
                                                Message 23 of 26 , Feb 6 3:56 PM
                                                • 0 Attachment
                                                  On Mon, Feb 06, 2006 at 10:27:11AM -0500, mzyzik@... wrote:
                                                  > > Good point: if multiple windows are implemented by having more
                                                  > > communication between different instances of vim, there is no need to
                                                  > > insist on gvim.
                                                  > >
                                                  > > Design issues: this would force a lot of decisions on us. The two
                                                  > > instances of vim would have separate histories (search, command-line,
                                                  > > jumps, etc.); global options changed in one would not affect the other;
                                                  > > new mappings, commands, etc. defined in one would not affect the other.
                                                  > > Is this what we want? It should be possible to do the equivalent of
                                                  > > making a session file and loading it, so that the two instances start
                                                  > > off in the same state.
                                                  > >
                                                  > > Implementation issues: I am not really competent to discuss this,
                                                  > > but I suspect that the main difficulty would be allowing two instances
                                                  > > of vim to share a buffer.
                                                  > >
                                                  > > OT: is it possible in Mozilla to detach a tab, so that the web page in
                                                  > > the tab gets its own window?
                                                  > >
                                                  > > --Benji Fisher
                                                  >
                                                  > Undoubtedly implementing the multiple windows to represent
                                                  > "frames/pages" will be difficult to implement. I think Bram would be
                                                  > reluctant to introduce frames in Vim7 if this was a requirement. We
                                                  > should consider this once the tabs and frames are working well within
                                                  > one window.

                                                  In my first post on this thread, I advocated considering the design
                                                  issues of multiple windows at the same time that we discuss tabs, and I
                                                  still think that is a good idea. Since I am not volunteering to do any
                                                  development, I do not have much to say about when to implement these
                                                  features. Maybe it is right to have tabs in vim 7.0 and put off windows
                                                  until 7.2 or 8.0.

                                                  > Basically what I'm saying is, we should just get the frames working
                                                  > first, hopefully in Vim7, and then consider the multiple windows per
                                                  > frames later. Besides, the two votes in the top 10 are for frames, and
                                                  > tabs for those frames; with no mention of multiple windows.

                                                  I am not sure what you mean by that last sentence. Are we looking
                                                  at the same list? From http://www.vim.org/sponsor/vote_results.php :

                                                  9 146 (-12) 32 -8 support multiple top-level windows for one running Vim

                                                  --Benji Fisher
                                                • A. J. Mechelynck
                                                  ... [...] ... [...] ... [...] ... Didn t realize you knew about it (and didn t like it). Sorry. Best regards, Tony.
                                                  Message 24 of 26 , Feb 6 5:18 PM
                                                  • 0 Attachment
                                                    Johnny Blaze wrote:
                                                    > On 2/5/06, *A. J. Mechelynck* < antoine.mechelynck@...
                                                    > <mailto:antoine.mechelynck@...>> wrote:
                                                    >
                                                    > Johnny Blaze wrote:
                                                    [...]
                                                    > > Why not make tabs a display option for split windows? Something like:
                                                    > >
                                                    > > set tabs
                                                    > >
                                                    > > then when you do a :sball or :new, you get tabs instead of windows...
                                                    > >
                                                    > > set notabs
                                                    [...]
                                                    > Hello Johnny. Without changing anything in the current versions of
                                                    > (g)vim, you can use "Rolodex Vim", as follows:
                                                    >
                                                    > :set noequalalways winminheight=0 winheight=99999
                                                    [...]
                                                    > oh I know... anytime anyone asks this question, you paste the above
                                                    > text, and I point them to my script (multiwin.vim ).
                                                    >
                                                    >
                                                    >
                                                    > --
                                                    >
                                                    > . o O pyromancer O o .

                                                    Didn't realize you knew about it (and didn't like it). Sorry.


                                                    Best regards,
                                                    Tony.
                                                  • mzyzik@gmail.com
                                                    ... Yeah but I think that means frames/pages, doesn t it? I very possibly could be wrong. --Matt
                                                    Message 25 of 26 , Feb 6 5:35 PM
                                                    • 0 Attachment
                                                      > > Basically what I'm saying is, we should just get the frames working
                                                      > > first, hopefully in Vim7, and then consider the multiple windows per
                                                      > > frames later. Besides, the two votes in the top 10 are for frames, and
                                                      > > tabs for those frames; with no mention of multiple windows.
                                                      >
                                                      > I am not sure what you mean by that last sentence. Are we looking
                                                      > at the same list? From http://www.vim.org/sponsor/vote_results.php :
                                                      >
                                                      > 9 146 (-12) 32 -8 support multiple top-level windows for one running Vim
                                                      >
                                                      > --Benji Fisher

                                                      Yeah but I think that means frames/pages, doesn't it?
                                                      I very possibly could be wrong.

                                                      --Matt
                                                    • Johnny Blaze
                                                      ... Its not that I don t like it... you gave me the orignal idea that started the script :-) -- you re actually credited in the script s description on
                                                      Message 26 of 26 , Feb 8 3:02 PM
                                                      • 0 Attachment
                                                        On 2/7/06, A. J. Mechelynck <antoine.mechelynck@...> wrote:
                                                        > Johnny Blaze wrote:
                                                        > > On 2/5/06, *A. J. Mechelynck* < antoine.mechelynck@...
                                                        > > <mailto:antoine.mechelynck@...>> wrote:
                                                        > >
                                                        > > Johnny Blaze wrote:
                                                        > [...]
                                                        > > > Why not make tabs a display option for split windows? Something like:
                                                        > > >
                                                        > > > set tabs
                                                        > > >
                                                        > > > then when you do a :sball or :new, you get tabs instead of windows...
                                                        > > >
                                                        > > > set notabs
                                                        > [...]
                                                        > > Hello Johnny. Without changing anything in the current versions of
                                                        > > (g)vim, you can use "Rolodex Vim", as follows:
                                                        > >
                                                        > > :set noequalalways winminheight=0 winheight=99999
                                                        > [...]
                                                        > > oh I know... anytime anyone asks this question, you paste the above
                                                        > > text, and I point them to my script (multiwin.vim ).

                                                        > Didn't realize you knew about it (and didn't like it). Sorry.

                                                        Its not that I don't like it... you gave me the orignal idea that
                                                        started the script :-) -- you're actually credited in the script's
                                                        description on vim.org... :-)

                                                        --

                                                        . o O pyromancer O o .
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.