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

Re: Vim BOF session

Expand Messages
  • Kim Schulz
    On Fri, 01 Sep 2006 18:55:07 -0400 ... I tend to agree. Some of the current features are still slow (think cursorline columnline) and others still lack some
    Message 1 of 24 , Sep 2, 2006
    • 0 Attachment
      On Fri, 01 Sep 2006 18:55:07 -0400
      Robert Hicks <sigzero@...> wrote:

      > Bram Moolenaar wrote:
      > > Greetings, Vim users.
      > >
      > > I am hosting a Vim BOF at the upcoming O'Reilly Open Source
      > > Convention:
      > >
      > > Title: Vim 8?
      > > Date: Tuesday, 19 September 2006
      > > Time: 20:30 - 21:30
      > > Location: Salon Versailles
      > >
      > > Summary: Vim 7 was released May 2006. Does it make sense to make
      > > another major release and add lots of new features? Or
      > > should priority be given to fix problems and fine tune
      > > existing features?
      > >
      > > What new features would users really profit from? Talk
      > > about the pros and cons with the main Vim author.
      > >
      > > The conference is held in Brussels, 18 - 21 September.
      > >
      > > More information:
      > > http://conferences.oreillynet.com/cs/euos2006/view/e_sess/9854
      > >
      > I can't be there but...
      >
      > "fix problems and fine tune existing features?"
      >
      > Yes
      >

      I tend to agree. Some of the current features are still slow (think
      cursorline columnline) and others still lack some userfriendlyness
      (like omnicompletion). fine tuning these things would be great.

      there is however a couple of things I would like to see added in vim8:

      Dialogs:
      ----------------------
      Gvim has confirm that can give me a dialog for selecting files etc. but
      I want this to be implemented as a more generic dialog api. It should
      be possible to have a "dialog" with the user such that vim can ask a
      question and the user can answer this. it is not userfriendly enough if
      it is just shown in the command line area of the editor - we need
      better looking modal dialog "windows". The output in the bottom of the
      window that scrolls the entire contents to be able to show multiple
      lines is simply not userfriendly and "good looking".
      I think this could be really useful in scripts and especially in
      relation to e.g., templates.

      Omnicompletion++:
      -----------------------
      Omnicompletion is a great new feature, but I would like to see it
      become even stronger. The intellisense plugin for gvim on win32 has
      some of the features I would love to see in the generic omni completion:
      quickhelp for items in list if available:
      http://insenvim.sourceforge.net/images/vis_help.jpg
      parameter help in tooltip:
      http://insenvim.sourceforge.net/images/vis_tooltip.jpg
      Some of this might be possible to make with scripts, but it often tend
      to become slow if not natively implemented. (and please kill the pink
      color - it is really ugly)

      Fonts for visualization:
      -------------------------
      Vim is fixed font which is mostly nice enough. I have hovever lately
      been working a bit in the editor/code navigator called SourceInsight.
      It used different fontsizes for marking the parts in the code - e.g.
      the function name is 2-4pt larger then the rest of the code and the
      size of the brackets are bigger for each level of them there is
      (biggest outside, normal innermost). This makes it extreamly easy to
      recognize where you are in the code while scrolling through i.

      Sessions:
      Sessions are great and I use it all the time. It does however have a
      single problem that irritates me. It does not save information about
      how the windows, tabs, buffers etc. are placed individually. This makes
      it really annoying when you, like me, has a window with a file list, a
      window with debug output, 2-3 open windows in each tab etc. All of this
      setting up is lost when I close vim and opens it again.


      Some of these things might already be possible to some extent, but I
      havent been able to find any info about it - hence it should probably
      be either better described or more easily available.




      --
      Kim Schulz | Private : http://www.schulz.dk
      Kim@... | Business: http://www.devteam.dk
      +45 5190 4262 | Sparetime: http://www.fundanemt.com
    • Mikolaj Machowski
      ... aspell ... from ... horse s ... Vim spellchecker is better than aspell or other well stablished architecture . I was testing it extensively for Polish and
      Message 2 of 24 , Sep 2, 2006
      • 0 Attachment
        Dnia sobota, 2 września 2006 04:21, Gabriel B. napisał:
        > didn't get if it was just a invitation to the brussels' talk or a
        > invite to a vim8 suggestion fest. so i'm bitting :)
        >
        > wrote that about vim7:
        > http://gabriel.barros.googlepages.com/vim7reviewrant

        Few comments:

        > - Spell checking support for about 50 languages
        >
        > I never dweled in the spellcheking, but i haven't seen any mention of
        aspell
        > or other well stabilished architeture used, so i assumed it was written
        from
        > scratch. Don't think that was clever. But i'm not going to look the
        horse's
        > teeths :) >

        Vim spellchecker is better than "aspell or other well stablished
        architecture".
        I was testing it extensively for Polish and helping (I hope ;) in
        development in non-coding way.

        > - Internal grep; works on all platforms, searches compressed files
        >
        > now, this i feel like making the same rant as the spell check. Why? oh
        why?
        > think of the children! > !grep

        Internal grep is godsend for people working on different architectures.
        No more guessing dialect of grep and supported regexp features.
        Also using all the time the same regular expressions is making life
        easier for script developers - point as above plus passing string to
        external program was always risky. All this quotes mess.

        > vim8 should be about interface and feedback.

        What about interface? Consistency and thesameness of interface on all
        platforms is what I like (and I think many people are sharing my
        sentiments). Sure, Vim could use more ncurses features like menus and
        dialogs but no serious overhaul can expected.

        > It's functional as it is today. But not easy yet.

        I don't suspect "easy" was goal for Vim ever. Effective, yes.

        m.
      • A.J.Mechelynck
        ... [...] ... I agree, and I add: on some closed-source architectures sold worldwide (I m naming no names, but you can guess ;-) ), a grep program cannot
        Message 3 of 24 , Sep 2, 2006
        • 0 Attachment
          Mikolaj Machowski wrote:
          > Dnia sobota, 2 września 2006 04:21, Gabriel B. napisał:
          [...]
          >> - Internal grep; works on all platforms, searches compressed files
          >>
          >> now, this i feel like making the same rant as the spell check. Why? oh
          > why?
          >> think of the children! > !grep
          >
          > Internal grep is godsend for people working on different architectures.
          > No more guessing dialect of grep and supported regexp features.
          > Also using all the time the same regular expressions is making life
          > easier for script developers - point as above plus passing string to
          > external program was always risky. All this quotes mess.

          I agree, and I add: on some closed-source architectures sold worldwide
          (I'm naming no names, but you can guess ;-) ), a grep program cannot
          always be expected to be present. Now historically, ":helpgrep" was
          added first, and that alone was already a godsend to users, on all
          architectures especially where no external grep was present, because the
          good quality end extensiveness of the Vim help generates a
          needle-and-haystack problem at times: we know the info is there, but how
          do we get at it? Once we had ":helpgrep", ":vimgrep" wasn't hard to
          develop, and the fact that it uses Vim regular expressions and does not
          require an external program which may or may not be present, makes it
          indeed a godsend to users with large collections of files, be they Vim
          scripts, shell scripts, source modules, HTML pages, whatever.

          >
          >> vim8 should be about interface and feedback.
          >
          > What about interface? Consistency and thesameness of interface on all
          > platforms is what I like (and I think many people are sharing my
          > sentiments). Sure, Vim could use more ncurses features like menus and
          > dialogs but no serious overhaul can expected.
          >
          >> It's functional as it is today. But not easy yet.
          >
          > I don't suspect "easy" was goal for Vim ever. Effective, yes.
          >
          > m.
          >
          >

          :-) If you want an "easy" text editor, use Notepad or kedit. But don't
          expect power from them: TANSTAAFL.


          Best regards,
          Tony.
        • Elliot Shank
          ... Since this is turning into a wish list thread... Mac version: Get the ... .swp file already exists ... dialog to be keyboard navigable. Right now, if
          Message 4 of 24 , Sep 2, 2006
          • 0 Attachment
            Robert Hicks wrote:
            > Bram Moolenaar wrote:
            >> I am hosting a Vim BOF at the upcoming O'Reilly Open Source Convention:
            >
            > I can't be there but...
            >
            > "fix problems and fine tune existing features?"
            >
            > Yes

            Since this is turning into a wish list thread...

            Mac version:

            Get the "... .swp file already exists ..." dialog to be keyboard navigable. Right now, if you want to choose anything other than the default "Open Read-Only" option, you have to reach for the trackpad (or mouse, for you desktop users).

            Change the application title for each vim instance to be what it would be for a OS-level window in other OSs so that they're differentiable. (Yeah, I'm probably repeating what a lot of other people have requested, but...)
          • A.J.Mechelynck
            ... Can t you hit the corresponding letter? [O]pen readonly, (E)dit anyway, (R)ecover, (Q)uit, (A)bort, (D)elete There is also the c flag in guioptions if
            Message 5 of 24 , Sep 2, 2006
            • 0 Attachment
              Elliot Shank wrote:
              > Robert Hicks wrote:
              >> Bram Moolenaar wrote:
              >>> I am hosting a Vim BOF at the upcoming O'Reilly Open Source Convention:
              >>
              >> I can't be there but...
              >>
              >> "fix problems and fine tune existing features?"
              >>
              >> Yes
              >
              > Since this is turning into a wish list thread...
              >
              > Mac version:
              >
              > Get the "... .swp file already exists ..." dialog to be keyboard
              > navigable. Right now, if you want to choose anything other than the
              > default "Open Read-Only" option, you have to reach for the trackpad (or
              > mouse, for you desktop users).

              Can't you hit the corresponding letter? [O]pen readonly, (E)dit anyway,
              (R)ecover, (Q)uit, (A)bort, (D)elete

              There is also the c flag in 'guioptions' if you prefer text
              (command-line) dialogs to GUI popup dialogs. But I'm not sure whether
              that flag has any effect in M$W.

              >
              > Change the application title for each vim instance to be what it would
              > be for a OS-level window in other OSs so that they're differentiable.
              > (Yeah, I'm probably repeating what a lot of other people have requested,
              > but...)
              >

              see ":help --servername". That setting defines the "program name" as
              seen on the titlebar. If you don't edit the same file in different Vim
              instances, the filename displayed on the titlebar will also help you
              differentiate them.


              Best regards,
              Tony.
            • drchip@campbellfamily.biz
              ... Try :help ssop in particular, perhaps ZoomWin s internal but temporary setting will be what you want:
              Message 6 of 24 , Sep 2, 2006
              • 0 Attachment
                Quoting Kim Schulz <kim@...>:

                > Sessions:
                > Sessions are great and I use it all the time. It does however have a
                > single problem that irritates me. It does not save information about
                > how the windows, tabs, buffers etc. are placed individually. This makes
                > it really annoying when you, like me, has a window with a file list, a
                > window with debug output, 2-3 open windows in each tab etc. All of this
                > setting up is lost when I close vim and opens it again.

                Try :help ssop

                in particular, perhaps ZoomWin's internal but temporary setting will be what
                you want: blank,buffers,curdir,folds,help,options,tabpages,winsize

                Regards,
                Chip Campbell
              • Kim Schulz
                On Sat, 2 Sep 2006 09:37:43 -0700 ... It does not seem to remember how the windows are placed inside Vim. I have tried all the sessionoptions but I still have
                Message 7 of 24 , Sep 2, 2006
                • 0 Attachment
                  On Sat, 2 Sep 2006 09:37:43 -0700
                  drchip@... wrote:
                  >
                  > Try :help ssop
                  >
                  > in particular, perhaps ZoomWin's internal but temporary setting will
                  > be what you want:
                  > blank,buffers,curdir,folds,help,options,tabpages,winsize

                  It does not seem to remember how the windows are placed inside Vim. I
                  have tried all the sessionoptions but I still have window splits that
                  are set to equal size when I reopen a session even though I saved it
                  with one of the windows being only 1/5 of the window in height.

                  --
                  Kim Schulz | Private : http://www.schulz.dk
                  Kim@... | Business: http://www.devteam.dk
                  +45 5190 4262 | Sparetime: http://www.fundanemt.com
                • A.J.Mechelynck
                  ... Best regards, Tony.
                  Message 8 of 24 , Sep 2, 2006
                  • 0 Attachment
                    Kim Schulz wrote:
                    > On Sat, 2 Sep 2006 09:37:43 -0700
                    > drchip@... wrote:
                    >> Try :help ssop
                    >>
                    >> in particular, perhaps ZoomWin's internal but temporary setting will
                    >> be what you want:
                    >> blank,buffers,curdir,folds,help,options,tabpages,winsize
                    >
                    > It does not seem to remember how the windows are placed inside Vim. I
                    > have tried all the sessionoptions but I still have window splits that
                    > are set to equal size when I reopen a session even though I saved it
                    > with one of the windows being only 1/5 of the window in height.
                    >

                    :set noequalalways


                    Best regards,
                    Tony.
                  • Groleo Marius
                    ... But can t vim be both : easy and powerful ? I don t see giving kedit as a counterexample be of a help.` Instead, look at slickedit. It has most of the
                    Message 9 of 24 , Sep 2, 2006
                    • 0 Attachment
                      On 9/2/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:
                      > Mikolaj Machowski wrote:
                      > > Dnia sobota, 2 września 2006 04:21, Gabriel B. napisał:
                      > [...]
                      > >> - Internal grep; works on all platforms, searches compressed files
                      > >>
                      > >> now, this i feel like making the same rant as the spell check. Why? oh
                      > > why?
                      > >> think of the children! > !grep
                      > >
                      > > Internal grep is godsend for people working on different architectures.
                      > > No more guessing dialect of grep and supported regexp features.
                      > > Also using all the time the same regular expressions is making life
                      > > easier for script developers - point as above plus passing string to
                      > > external program was always risky. All this quotes mess.
                      >
                      > I agree, and I add: on some closed-source architectures sold worldwide
                      > (I'm naming no names, but you can guess ;-) ), a grep program cannot
                      > always be expected to be present. Now historically, ":helpgrep" was
                      > added first, and that alone was already a godsend to users, on all
                      > architectures especially where no external grep was present, because the
                      > good quality end extensiveness of the Vim help generates a
                      > needle-and-haystack problem at times: we know the info is there, but how
                      > do we get at it? Once we had ":helpgrep", ":vimgrep" wasn't hard to
                      > develop, and the fact that it uses Vim regular expressions and does not
                      > require an external program which may or may not be present, makes it
                      > indeed a godsend to users with large collections of files, be they Vim
                      > scripts, shell scripts, source modules, HTML pages, whatever.
                      >
                      > >
                      > >> vim8 should be about interface and feedback.
                      > >
                      > > What about interface? Consistency and thesameness of interface on all
                      > > platforms is what I like (and I think many people are sharing my
                      > > sentiments). Sure, Vim could use more ncurses features like menus and
                      > > dialogs but no serious overhaul can expected.
                      > >
                      > >> It's functional as it is today. But not easy yet.
                      > >
                      > > I don't suspect "easy" was goal for Vim ever. Effective, yes.
                      > >
                      > > m.
                      > >
                      > >
                      >
                      > :-) If you want an "easy" text editor, use Notepad or kedit. But don't
                      > expect power from them: TANSTAAFL.

                      But can't vim be both : easy and powerful ? I don't see giving kedit as
                      a counterexample be of a help.`
                      Instead, look at slickedit. It has most of the desired features listed so far,
                      and still is easy, and still is powerful.
                      The most annoying thing (IMHO) in vim7 is that the newly added
                      features are sluggish (omnicomplete, cursorline).


                      >
                      >
                      > Best regards,
                      > Tony.
                      >


                      --
                      Regards, Groleo!
                    • Elliot Shank
                      ... Nope. The dialog is completely unresponsive to any key other than return/enter. ... Yes, that works, so it s what I ll go with for now. But what s the
                      Message 10 of 24 , Sep 2, 2006
                      • 0 Attachment
                        A.J.Mechelynck wrote:
                        > Elliot Shank wrote:
                        > Can't you hit the corresponding letter? [O]pen readonly, (E)dit anyway,
                        > (R)ecover, (Q)uit, (A)bort, (D)elete

                        Nope. The dialog is completely unresponsive to any key other than return/enter.

                        > There is also the c flag in 'guioptions' if you prefer text
                        > (command-line) dialogs to GUI popup dialogs. But I'm not sure whether
                        > that flag has any effect in M$W.

                        Yes, that works, so it's what I'll go with for now.

                        But what's the point of a GUI if it doesn't do things in a gooey way? :]

                        >> Change the application title for each vim instance to be what it would
                        >> be for a OS-level window in other OSs so that they're differentiable.
                        >> (Yeah, I'm probably repeating what a lot of other people have
                        >> requested, but...)
                        >
                        > see ":help --servername". That setting defines the "program name" as
                        > seen on the titlebar. If you don't edit the same file in different Vim
                        > instances, the filename displayed on the titlebar will also help you
                        > differentiate them.

                        The Mac version of Vim does not support the +clientserver build option and thus doesn't support that command-line option.

                        Anyway, that wouldn't do any good for Vim instances started by the Finder.

                        You don't understand: switching between windows and switching between applications are two different things on the Mac. Using command-tab switches between applications; command-` switches between windows within an application. When command-tabbing between applications, all you get is the application name; this isn't anything specific to Vim. It's how all Mac apps work, e.g., if you've got a word processor with multiple documents/windows open, all you'll be able to see when switching is the application's name. Yes, the Vim window title-bar reflects all the usual information you see in it on other platforms, but that does you no good when switching between Vim instances.
                      • Elliot Shank
                        ... Actually, to get multiple instances of gvim running on a Mac takes a bit of a hack. There s only supposed to be a single process running of any given
                        Message 11 of 24 , Sep 2, 2006
                        • 0 Attachment
                          Elliot Shank wrote:
                          > A.J.Mechelynck wrote:
                          >> Elliot Shank wrote:
                          >>> Change the application title for each vim instance to be what it
                          >>> would be for a OS-level window in other OSs so that they're
                          >>> differentiable. (Yeah, I'm probably repeating what a lot of other
                          >>> people have requested, but...)
                          >>
                          >> see ":help --servername". That setting defines the "program name" as
                          >> seen on the titlebar. If you don't edit the same file in different Vim
                          >> instances, the filename displayed on the titlebar will also help you
                          >> differentiate them.
                          >
                          > The Mac version of Vim does not support the +clientserver build option
                          > and thus doesn't support that command-line option.
                          >
                          > Anyway, that wouldn't do any good for Vim instances started by the Finder.
                          >
                          > You don't understand: switching between windows and switching between
                          > applications are two different things on the Mac. Using command-tab
                          > switches between applications; command-` switches between windows within
                          > an application. When command-tabbing between applications, all you get
                          > is the application name; this isn't anything specific to Vim. It's how
                          > all Mac apps work, e.g., if you've got a word processor with multiple
                          > documents/windows open, all you'll be able to see when switching is the
                          > application's name. Yes, the Vim window title-bar reflects all the
                          > usual information you see in it on other platforms, but that does you no
                          > good when switching between Vim instances.

                          Actually, to get multiple instances of gvim running on a Mac takes a bit of a hack. There's only supposed to be a single process running of any given application at a time. If you try to launch an application while its already running, no new process is created and the existing process's windows are brought forward. If that launch attempt was caused by trying to open a document that that app handles, then the existing process is told to open it. It's like a --remote command line option is forced to be there, whether you want it or not.
                        • Nicolas Weber
                          Hi, ... I m doing some work on the mac port. This will be fixed in the next two months (I hope :-P). ... I ll take a look at that as well. Bye, Nico
                          Message 12 of 24 , Sep 2, 2006
                          • 0 Attachment
                            Hi,

                            > Nope. The dialog is completely unresponsive to any key other than
                            > return/enter.

                            I'm doing some work on the mac port. This will be fixed in the next
                            two months (I hope :-P).

                            > You don't understand: switching between windows and switching
                            > between applications are two different things on the Mac. Using
                            > command-tab switches between applications; command-` switches
                            > between windows within an application. When command-tabbing
                            > between applications, all you get is the application name; this
                            > isn't anything specific to Vim. It's how all Mac apps work, e.g.,
                            > if you've got a word processor with multiple documents/windows
                            > open, all you'll be able to see when switching is the application's
                            > name. Yes, the Vim window title-bar reflects all the usual
                            > information you see in it on other platforms, but that does you no
                            > good when switching between Vim instances.

                            I'll take a look at that as well.

                            Bye,
                            Nico
                          • Max Dyckhoff
                            ... I don t really have any other comments, other than you can change the pink by adding this to your .vimrc: hi Pmenu guibg=DarkRed I agree, the pink is
                            Message 13 of 24 , Sep 2, 2006
                            • 0 Attachment
                              > Omnicompletion++:
                              > -----------------------
                              > (snip!)
                              > (and please kill the pink color - it is really ugly)

                              I don't really have any other comments, other than you can change the
                              pink by adding this to your .vimrc:

                              hi Pmenu guibg=DarkRed

                              I agree, the pink is heinous :)

                              Max
                            • A.J.Mechelynck
                              ... What s the point of a GUI if one doesn t want to use the mouse? What s the point of a Mac, for that matter, if one doesn t want to use the mouse? (Just
                              Message 14 of 24 , Sep 2, 2006
                              • 0 Attachment
                                Elliot Shank wrote:
                                > A.J.Mechelynck wrote:
                                >> Elliot Shank wrote:
                                >> Can't you hit the corresponding letter? [O]pen readonly, (E)dit
                                >> anyway, (R)ecover, (Q)uit, (A)bort, (D)elete
                                >
                                > Nope. The dialog is completely unresponsive to any key other than
                                > return/enter.
                                >
                                >> There is also the c flag in 'guioptions' if you prefer text
                                >> (command-line) dialogs to GUI popup dialogs. But I'm not sure whether
                                >> that flag has any effect in M$W.
                                >
                                > Yes, that works, so it's what I'll go with for now.
                                >
                                > But what's the point of a GUI if it doesn't do things in a gooey way? :]

                                What's the point of a GUI if one doesn't want to use the mouse? What's
                                the point of a Mac, for that matter, if one doesn't want to use the mouse?
                                (Just kidding.)

                                >
                                >>> Change the application title for each vim instance to be what it
                                >>> would be for a OS-level window in other OSs so that they're
                                >>> differentiable. (Yeah, I'm probably repeating what a lot of other
                                >>> people have requested, but...)
                                >>
                                >> see ":help --servername". That setting defines the "program name" as
                                >> seen on the titlebar. If you don't edit the same file in different Vim
                                >> instances, the filename displayed on the titlebar will also help you
                                >> differentiate them.
                                >
                                > The Mac version of Vim does not support the +clientserver build option
                                > and thus doesn't support that command-line option.

                                Not even on MacOsX with X11?

                                >
                                > Anyway, that wouldn't do any good for Vim instances started by the Finder.
                                >
                                > You don't understand: switching between windows and switching between
                                > applications are two different things on the Mac. Using command-tab
                                > switches between applications; command-` switches between windows within
                                > an application. When command-tabbing between applications, all you get
                                > is the application name; this isn't anything specific to Vim. It's how
                                > all Mac apps work, e.g., if you've got a word processor with multiple
                                > documents/windows open, all you'll be able to see when switching is the
                                > application's name. Yes, the Vim window title-bar reflects all the
                                > usual information you see in it on other platforms, but that does you no
                                > good when switching between Vim instances.
                                >

                                Unlike some programs like Firefox (where all windows are handled by a
                                single instance of the program), in the case of gvim there is a
                                one-to-one correspondence between windows (as seen by the OS, I'm not
                                talking about split windows here) and program instances. If the
                                Mac-specific mechanism for switching between program instances doesn't
                                reflect the information gvim puts on its titlebar, then it might be a
                                Mac problem rather than a Vim problem. On Windows or Linux, the OS
                                taskbar at the bottom of my screen reflects whatever Vim has placed in
                                its titlebar so I have no problem discriminating between vim instances
                                even there; similarly, Alt-Tab also shows the information on the various
                                titlebars, including gvim titlebars.


                                Best regards,
                                Tony.
                              • Kim Schulz
                                On Sat, 2 Sep 2006 13:00:32 -0700 ... sure, but it is default and what most users see and use. -- Kim Schulz | Private : http://www.schulz.dk Kim@schulz.dk
                                Message 15 of 24 , Sep 2, 2006
                                • 0 Attachment
                                  On Sat, 2 Sep 2006 13:00:32 -0700
                                  "Max Dyckhoff" <maxd@...> wrote:

                                  > > Omnicompletion++:
                                  > > -----------------------
                                  > > (snip!)
                                  > > (and please kill the pink color - it is really ugly)
                                  >
                                  > I don't really have any other comments, other than you can change the
                                  > pink by adding this to your .vimrc:
                                  >
                                  > hi Pmenu guibg=DarkRed
                                  >
                                  > I agree, the pink is heinous :)


                                  sure, but it is default and what most users see and use.
                                  --
                                  Kim Schulz | Private : http://www.schulz.dk
                                  Kim@... | Business: http://www.devteam.dk
                                  +45 5190 4262 | Sparetime: http://www.fundanemt.com
                                • Elliot Shank
                                  ... Probably does, but ughhh. The X11 implementation for the Mac treats the entire server as a single application, i.e. three different apps running under X11
                                  Message 16 of 24 , Sep 2, 2006
                                  • 0 Attachment
                                    >>>> Change the application title for each vim instance to be what
                                    >>>> it would be for a OS-level window in other OSs so that they're
                                    >>>> differentiable. (Yeah, I'm probably repeating what a lot of
                                    >>>> other people have requested, but...)
                                    >>>
                                    >>> see ":help --servername". That setting defines the "program name"
                                    >>> as seen on the titlebar. If you don't edit the same file in
                                    >>> different Vim instances, the filename displayed on the titlebar
                                    >>> will also help you differentiate them.
                                    >>
                                    >> The Mac version of Vim does not support the +clientserver build
                                    >> option and thus doesn't support that command-line option.
                                    >
                                    > Not even on MacOsX with X11?

                                    Probably does, but ughhh. The X11 implementation for the Mac treats the entire server as a single application, i.e. three different apps running under X11 are handled as three windows for the single X11 server app. This makes switching between regular Mac apps and X11 apps a royal pain because you're continually having to switch between command-tab and command-`.

                                    It's best to only run a single X11 program at a time.

                                    >> You don't understand: switching between windows and switching
                                    >> between applications are two different things on the Mac. Using
                                    >> command-tab switches between applications; command-` switches
                                    >> between windows within an application. When command-tabbing
                                    >> between applications, all you get is the application name; this
                                    >> isn't anything specific to Vim. It's how all Mac apps work, e.g.,
                                    >> if you've got a word processor with multiple documents/windows
                                    >> open, all you'll be able to see when switching is the application's
                                    >> name. Yes, the Vim window title-bar reflects all the usual
                                    >> information you see in it on other platforms, but that does you no
                                    >> good when switching between Vim instances.
                                    >
                                    > Unlike some programs like Firefox (where all windows are handled by a
                                    > single instance of the program), in the case of gvim there is a
                                    > one-to-one correspondence between windows (as seen by the OS, I'm not
                                    > talking about split windows here) and program instances.

                                    I'm well aware of that. It was a lot easier to implement tabs than multiple OS windows, so that's what happened. Only thing: I hate this whole general move to tabs for applications; we're heading back to the whole MDI insanity. SDI is the way to go.

                                    > If the Mac-specific mechanism for switching between program instances
                                    > doesn't reflect the information gvim puts on its titlebar, then it
                                    > might be a Mac problem rather than a Vim problem.

                                    "Problem"? I think that's by design. It's the way the whole Mac GUI works.

                                    > On Windows or Linux, the OS taskbar at the bottom of my screen
                                    > reflects whatever Vim has placed in its titlebar so I have no problem
                                    > discriminating between vim instances even there; similarly, Alt-Tab
                                    > also shows the information on the various titlebars, including gvim
                                    > titlebars.

                                    The task bar "equivalent" (and that requires using the term very loosely) is the Dock. The Dock has a single icon per app, not per window. It's part of the whole paradigm. (I have very little use for the Dock; however, a lot of OS functionality depends upon its services.)

                                    This whole difference in handling windows vs. programs has its pluses and minuses. It takes some getting used to.

                                    Interestingly, there's one aspect of this I've really come to like. I think it's a usability disaster for regular users, but closing the last window for an app does not close the app. It's still running, it just doesn't have anything visible in the main area of your screen. I use this with Firefox all the time. I can close all its windows, yet when another app initiates the display of a web page, there's no startup time for the browser; it's already running.



                                    Regardless of OS, generally the only way I ever simultaneously edit multiple files in Vim is in diff mode. Obviously, this means I lean on the * and + registers a lot. :]
                                  • Mikolaj Machowski
                                    ... You point can be split in two: 1. Intellisense plugin is tied to widget system. It could mean that popup system had to be written each time for each GUI.
                                    Message 17 of 24 , Sep 3, 2006
                                    • 0 Attachment
                                      Dnia sobota, 2 września 2006 12:36, Kim Schulz napisał:
                                      > Omnicompletion++:
                                      > -----------------------
                                      > Omnicompletion is a great new feature, but I would like to see it
                                      > become even stronger. The intellisense plugin for gvim on win32 has
                                      > some of the features I would love to see in the generic omni completion:
                                      > quickhelp for items in list if available:
                                      > http://insenvim.sourceforge.net/images/vis_help.jpg
                                      > parameter help in tooltip:
                                      > http://insenvim.sourceforge.net/images/vis_tooltip.jpg
                                      > Some of this might be possible to make with scripts, but it often tend
                                      > to become slow if not natively implemented. (and please kill the pink
                                      > color - it is really ugly)

                                      You point can be split in two:

                                      1. Intellisense plugin is tied to widget system. It could mean that
                                      popup system had to be written each time for each GUI. Monstrous
                                      effort for writing and maintaining.

                                      2. Info provided by intellisense can be provided by current
                                      implementation of omnicompletion. Problem is efficiency and size of
                                      data. For example inclusion of built-in functions in PHP
                                      omnicompletion caused that phpcomplete.vim has almost 300K. Adding
                                      help would easily explode that file to few M [1]. Parsing of PHPdoc is
                                      also possible but it could take time (phpcomplete is already
                                      sluggish).

                                      [1] Hmm. It could be done by external manual and dependency on `lynx
                                      -dump`. OK, done (1h), but it is unusable because scrolling
                                      of info window is practically impossible.

                                      m.
                                    • Kim Schulz
                                      On Sun, 3 Sep 2006 13:21:06 +0200 ... I dont want MS intellisense, I just want an improved omnicompletion :-) ... Well it is posssible in other editors with a
                                      Message 18 of 24 , Sep 3, 2006
                                      • 0 Attachment
                                        On Sun, 3 Sep 2006 13:21:06 +0200
                                        Mikolaj Machowski <mikmach@...> wrote:
                                        > You point can be split in two:
                                        > 1. Intellisense plugin is tied to widget system. It could mean that
                                        > popup system had to be written each time for each GUI. Monstrous
                                        > effort for writing and maintaining.

                                        I dont want MS intellisense, I just want an improved omnicompletion :-)

                                        > 2. Info provided by intellisense can be provided by current
                                        > implementation of omnicompletion. Problem is efficiency and size of
                                        > data. For example inclusion of built-in functions in PHP
                                        > omnicompletion caused that phpcomplete.vim has almost 300K. Adding
                                        > help would easily explode that file to few M [1]. Parsing of
                                        > PHPdoc is also possible but it could take time (phpcomplete is already
                                        > sluggish).

                                        Well it is posssible in other editors with a reasonable speed (even in
                                        Java based editors like IntelliJ Idea), so it must be possible to do
                                        natively in vim too. A large modification - probably, but I am sure
                                        that will be af great help for many programmers using Vim.

                                        --
                                        Kim Schulz | Private : http://www.schulz.dk
                                        Kim@... | Business: http://www.devteam.dk
                                        +45 5190 4262 | Sparetime: http://www.fundanemt.com
                                      • mzyzik@gmail.com
                                        ... But the current popup system in Vim does not require intense rewrites for each GUI. ... pythoncomplete.vim is about 20K and seems to return a wealth of
                                        Message 19 of 24 , Sep 3, 2006
                                        • 0 Attachment
                                          On Sun, Sep 03, 2006 at 01:21:06PM +0200, Mikolaj Machowski wrote:
                                          > Dnia sobota, 2 wrze?nia 2006 12:36, Kim Schulz napisa?:
                                          > > Omnicompletion++:
                                          > > -----------------------
                                          > > Omnicompletion is a great new feature, but I would like to see it
                                          > > become even stronger. The intellisense plugin for gvim on win32 has
                                          > > some of the features I would love to see in the generic omni completion:
                                          > > quickhelp for items in list if available:
                                          > > http://insenvim.sourceforge.net/images/vis_help.jpg
                                          > > parameter help in tooltip:
                                          > > http://insenvim.sourceforge.net/images/vis_tooltip.jpg
                                          > > Some of this might be possible to make with scripts, but it often tend
                                          > > to become slow if not natively implemented. (and please kill the pink
                                          > > color - it is really ugly)
                                          >
                                          > You point can be split in two:
                                          >
                                          > 1. Intellisense plugin is tied to widget system. It could mean that
                                          > popup system had to be written each time for each GUI. Monstrous
                                          > effort for writing and maintaining.

                                          But the current popup system in Vim does not require intense rewrites
                                          for each GUI.

                                          >
                                          > 2. Info provided by intellisense can be provided by current
                                          > implementation of omnicompletion. Problem is efficiency and size of
                                          > data. For example inclusion of built-in functions in PHP
                                          > omnicompletion caused that phpcomplete.vim has almost 300K. Adding
                                          > help would easily explode that file to few M [1]. Parsing of PHPdoc is
                                          > also possible but it could take time (phpcomplete is already
                                          > sluggish).

                                          pythoncomplete.vim is about 20K and seems to return a wealth of info.

                                          Also, I'm more interested in plugins that 3rd parties might make, that
                                          won't be included into Vim. Those 3rd party plugins might require people
                                          to download megs of xml data files or something of the sort; and who
                                          cares, it's not bundled with vim.

                                          --Matt

                                          >
                                          > [1] Hmm. It could be done by external manual and dependency on `lynx
                                          > -dump`. OK, done (1h), but it is unusable because scrolling
                                          > of info window is practically impossible.
                                          >
                                          > m.
                                          >
                                          >
                                        • Robert Hicks
                                          How about the ability to use our own icon sets? The default under XP looks less than spectacular while the Gnome version looks great. Robert
                                          Message 20 of 24 , Sep 5, 2006
                                          • 0 Attachment
                                            How about the ability to use our own icon sets? The default under XP
                                            looks less than spectacular while the Gnome version looks great.

                                            Robert
                                          • Charles E Campbell Jr
                                            I d still like to see Vince Negri s ideas (ownsyntax, conceal) included. Regards, Chip Campbell
                                            Message 21 of 24 , Sep 6, 2006
                                            • 0 Attachment
                                              I'd still like to see Vince Negri's ideas (ownsyntax, conceal) included.

                                              Regards,
                                              Chip Campbell
                                            Your message has been successfully submitted and would be delivered to recipients shortly.