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

Re: yet another gtk2 vim update

Expand Messages
  • Daniel Elstner
    ... I m glad you realized that your previous patch _did_ break things, with the default setup even :) However, I already implemented a different solution and
    Message 1 of 13 , Feb 25 7:15 PM
    • 0 Attachment
      On Mit, 2003-02-26 at 03:54, Nam SungHyun wrote:
      > On 26 Feb 2003 02:41:32 +0100, Daniel Elstner wrote:
      > >
      > > OK, looks like the GTK+ 1 code assumed IM always needs an activation key
      > > to work. But since all of the IM modules included in GTK+ 2 don't have
      > > an activation key it's not a good idea to continue using that approach.
      > > You don't need the imactivatekey anyway since Vim has CTRL-^.
      >
      > How about patch below? Just check the 'p_imdisable' for 'imactivatekey'.

      I'm glad you realized that your previous patch _did_ break things, with
      the default setup even :)

      However, I already implemented a different solution and hope you'll like
      it. It's so damn simple -- I wonder why it didn't occur to me before...

      Get the new patch here:

      http://regexxer.sourceforge.net/vim/vim-gtk2-20030226.patch.gz

      I also merged Jungshik's patch; thus everything should now work fine.

      --Daniel
    • Daniel Elstner
      ... Tiny update: don t check for imactivatekey if not in insert or command line mode, or imdisable is set.
      Message 2 of 13 , Feb 25 8:11 PM
      • 0 Attachment
        On Mit, 2003-02-26 at 04:15, Daniel Elstner wrote:

        > However, I already implemented a different solution and hope you'll like
        > it. It's so damn simple -- I wonder why it didn't occur to me before...
        >
        > Get the new patch here:
        >
        > http://regexxer.sourceforge.net/vim/vim-gtk2-20030226.patch.gz
        >
        > I also merged Jungshik's patch; thus everything should now work fine.

        Tiny update: don't check for 'imactivatekey' if not in insert or command
        line mode, or 'imdisable' is set.

        http://regexxer.sourceforge.net/vim/vim-gtk2-20030226-2.patch.gz

        --Daniel
      • Nam SungHyun
        ... Great. Now I don t need any personal patch. Thanks. namsh
        Message 3 of 13 , Feb 25 8:15 PM
        • 0 Attachment
          On 26 Feb 2003 04:15:11 +0100, Daniel Elstner wrote:
          >
          > I'm glad you realized that your previous patch _did_ break things, with
          > the default setup even :)
          >
          > However, I already implemented a different solution and hope you'll like
          > it. It's so damn simple -- I wonder why it didn't occur to me before...
          >
          > Get the new patch here:
          >
          > http://regexxer.sourceforge.net/vim/vim-gtk2-20030226.patch.gz
          >
          > I also merged Jungshik's patch; thus everything should now work fine.

          Great. Now I don't need any personal patch. Thanks.

          namsh
        • Bram Moolenaar
          ... Actually, the behavior that the server comes to the foreground (raised, not minimized) is correct. This is required for most situations, where you have
          Message 4 of 13 , Feb 26 1:39 AM
          • 0 Attachment
            Namsh wrote:

            > > On Mit, 2003-02-26 at 01:18, Nam SungHyun wrote:
            > > >
            > > > Now, I'm very happy with vim-GTK2. It works great like vim-GTK1
            > > > with a very clean/cool screen/font. Thanks a lot.
            >
            > I forgot one thing.
            > With vim-GTK1:
            > 1. gvim --servername AAA fileA
            > 2. iconify gvim.
            > 3. gvim --servername AAA --remote fileB
            >
            > vim-GTK1 stays iconified after step 3. but vim-GTK2 de-iconified.
            > And personally I like vim-GTK1's operation.
            > At lease I hope vim-GTK2 do not raise the window. I mean,
            > in step 2, if I do lower the vim-GTK2, it is raised after
            > step 3.

            Actually, the behavior that the server comes to the foreground (raised,
            not minimized) is correct. This is required for most situations, where
            you have some program that tells the gvim server to edit a file.

            Perhaps there are situations where you don't want the server to be
            raised, but I see that as an exception.

            --
            Why isn't there mouse-flavored cat food?

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
            \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
            \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
          • Daniel Elstner
            ... Yep. It looks like the Vim client/server code calls gui_mch_set_foreground() which happens to actually work in the GTK+ 2 GUI, thanks to
            Message 5 of 13 , Feb 26 9:03 AM
            • 0 Attachment
              On Mit, 2003-02-26 at 10:39, Bram Moolenaar wrote:
              > Namsh wrote:
              >
              > > > On Mit, 2003-02-26 at 01:18, Nam SungHyun wrote:
              > > > >
              > > > > Now, I'm very happy with vim-GTK2. It works great like vim-GTK1
              > > > > with a very clean/cool screen/font. Thanks a lot.
              > >
              > > I forgot one thing.
              > > With vim-GTK1:
              > > 1. gvim --servername AAA fileA
              > > 2. iconify gvim.
              > > 3. gvim --servername AAA --remote fileB
              > >
              > > vim-GTK1 stays iconified after step 3. but vim-GTK2 de-iconified.
              > > And personally I like vim-GTK1's operation.
              > > At lease I hope vim-GTK2 do not raise the window. I mean,
              > > in step 2, if I do lower the vim-GTK2, it is raised after
              > > step 3.
              >
              > Actually, the behavior that the server comes to the foreground (raised,
              > not minimized) is correct. This is required for most situations, where
              > you have some program that tells the gvim server to edit a file.
              >
              > Perhaps there are situations where you don't want the server to be
              > raised, but I see that as an exception.

              Yep. It looks like the Vim client/server code calls
              gui_mch_set_foreground() which happens to actually work in the GTK+ 2
              GUI, thanks to gtk_window_present().

              --Daniel
            Your message has been successfully submitted and would be delivered to recipients shortly.