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

41624Re: "window tabs" and "frames/pages"

Expand Messages
  • Benji Fisher
    Feb 4, 2006
      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,


      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

      --Benji Fisher
    • Show all 26 messages in this topic