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

Re: Patches over 6.0.093 for MacOS (9 and X)

Expand Messages
  • Benji Fisher
    ... Check. ... Check. ... Check. Does edit mode mean Normal mode ? It was also a problem in Command mode. ... Check. I can invoke %
    Message 1 of 6 , Nov 27, 2001
    • 0 Attachment
      On Sunday, November 25, 2001, at 03:22 PM, Dany St-Amant wrote:

      > Hi,
      >
      > Here's a patch which should make it to the main source. Some of the
      > code
      > have been previously ship as unofficials patches.
      >
      > [MacOS] -> for any MacOS version
      > [MacOS 9] -> for MacOS 8 (or earlier) only
      > [MacOS X] -> for MacOS X only
      > [all] -> bug which may show up on other platform.
      >
      > Fixes:
      > ====
      > Improved support for command key (and other modifiers). [MacOS]

      Check.

      > Support for Quit AppleEvent (performs a :confirm qa) [MacOS]

      Check.

      > Focus gain now properly trigger :checktimes. [MacOS]
      > Improved Dialog Boxes [MacOS]
      > Proper DFLT_RUNTIME_PATH [MacOS X]
      > Explorer.vim is not auto-launch by error anymore [MacOS 9]
      > Fix crash when $TERM not found [all]
      > Fix non-handling of <C-special_keys> in insert and edit mode [MacOS]
      > ( bug example: <C-Right> was just doing <Right>)

      Check. Does "edit mode" mean "Normal mode"? It was also a problem
      in Command mode.

      >
      > Features:
      > =======
      > Console/Carbon GUI combo (small issue see below) [MacOS X]

      Check. I can invoke

      % Vim.app/Contents/MacOS/Vim

      in a Terminal window, and it seems to work.

      > Use of -DUNIX for -DMACOS_X_UNIX (better unix compatibility) [MacOS X]
      > Supports for Input Boxes [MacOS]
      >
      > Known Issue (on the fixes/features)
      > ==========
      >
      > Launching gvim from Terminal.app
      > for some reason the GUI cannot properly launch if the invocation
      > is not an absolute or relative path to the executable or a link to the
      > executable (i.e: the problem show when you rely on your $PATH).
      > To avoid this bug (which I consider a MacOS X bug), a quick guess
      > is made to disallow the gui.]
      > By using an alias such as 'alias gvim ~/bin/gvim' you can work around
      > this.

      Another work-around is

      % open -a Vim.app [file]

      > Launching Vim from ProjectBuilder
      > When using Project Builder to launch/debug Vim, you'll need to add
      > a -g to Targets.Vim.Executables.Arguments -g or type :gui in the STDIO
      > pane (only available under debug)
      >
      > Dialog boxes under MacOS 9 (or earlier) shows a weird character instead
      > of an eol.
      >
      > Mapping including the option key (unless control also used) are not
      > working
      > properly.
      >
      > Default shortcut supplied by MacOS X such as Command-Q, Command-H,
      > Command-Option-D cannot be override through mapping. The Operating
      > System is intercepting those key before they can reach Vim.
      >
      > Last Comment
      > ===========
      >
      > In case Mail.App try to laugh at me by not including my attachment, I
      > can pick it up at:
      > http://www3.sympatico.ca/dany.stamant/vim/patch/6.0/vim60_93_mac.diff.gz

      This time Mail.app worked. I wish I knew what was going on.

      > Enjoy, the patch
      >
      > Dany

      Thanks. I still have the problem that a <C-M> in the viminfo file
      causes confusion. I guess I will have to undefine USE_CR again.

      Now that I can map <D-x> again, I will borrow the mac.vim file that
      Axel Kielhorn distributed. It enables several of the standard Mac
      keyboard shortcuts.

      BTW, I see keyboard shortcuts right-justified in several menus.
      (For example, the Mail and File menus of Mail.app list a few
      shortcuts.) The Apple developers didn't manually insert the right
      number of spaces, did they?

      --Benji Fisher
    • Dany St-Amant
      ... Yup, the proper fix for require the split of USE_CR into approximately three different EOL definitions. EOL for output to the screen, EOL for files and EOL
      Message 2 of 6 , Nov 27, 2001
      • 0 Attachment
        Le Mardi 27 novembre 2001, à 02:37 , Benji Fisher a écrit :
        >
        > Thanks. I still have the problem that a <C-M> in the viminfo file
        > causes confusion. I guess I will have to undefine USE_CR again.

        Yup, the proper fix for require the split of USE_CR into approximately
        three
        different EOL definitions. EOL for output to the screen, EOL for files
        and EOL
        for system (i.e.:shell) invocation. Before I release a patch for this,
        I prefer to have
        Bram's blessing (in the mean time I'll work on it anyway.)

        > Now that I can map <D-x> again, I will borrow the mac.vim file
        > that Axel Kielhorn distributed. It enables several of the standard Mac
        > keyboard shortcuts.
        >
        > BTW, I see keyboard shortcuts right-justified in several menus.
        > (For example, the Mail and File menus of Mail.app list a few
        > shortcuts.) The Apple developers didn't manually insert the right
        > number of spaces, did they?

        I thought last time with your example like:

        :menu File.Open...t<TAB>:e

        You meant to have the :e right aligned. Now, it seem that you mean to get
        <D-O> to be right aligned. This last one is on my todo list.

        I originally thought of creating a new command similar to :tmenu,
        but with the way the toolbar specify the icon, I think I should add a
        shortcut= or map= to the menu definition. Unfortunately, only providing
        this will make the distribution menu.vim unreadable, if the shortcut/map
        need to be defined at the tim eof the menu creation.

        It should fit within the definition of :menu xyz=x Menu.Sub to instead
        of displaying data, to change the icon (what about icon in normal
        menu ;),
        the tip, the shortcut/map even the command.

        Dany
      • Benji Fisher
        ... Well, if I define ... then I want to see the :e right aligned, and if I define ... then I want the to be right aligned. Of course, it would be
        Message 3 of 6 , Nov 28, 2001
        • 0 Attachment
          On Tuesday, November 27, 2001, at 08:16 PM, Dany St-Amant wrote:

          >
          > Le Mardi 27 novembre 2001, à 02:37 , Benji Fisher a écrit :
          >>
          >> Thanks. I still have the problem that a <C-M> in the viminfo
          >> file causes confusion. I guess I will have to undefine USE_CR again.
          >
          > Yup, the proper fix for require the split of USE_CR into approximately
          > three
          > different EOL definitions. EOL for output to the screen, EOL for files
          > and EOL
          > for system (i.e.:shell) invocation. Before I release a patch for this,
          > I prefer to have
          > Bram's blessing (in the mean time I'll work on it anyway.)
          >
          >> Now that I can map <D-x> again, I will borrow the mac.vim file
          >> that Axel Kielhorn distributed. It enables several of the standard
          >> Mac keyboard shortcuts.
          >>
          >> BTW, I see keyboard shortcuts right-justified in several menus.
          >> (For example, the Mail and File menus of Mail.app list a few
          >> shortcuts.) The Apple developers didn't manually insert the right
          >> number of spaces, did they?
          >
          > I thought last time with your example like:
          >
          > :menu File.Open...t<TAB>:e
          >
          > You meant to have the :e right aligned. Now, it seem that you mean to
          > get
          > <D-O> to be right aligned. This last one is on my todo list.
          >
          > I originally thought of creating a new command similar to :tmenu,
          > but with the way the toolbar specify the icon, I think I should add a
          > shortcut= or map= to the menu definition. Unfortunately, only providing
          > this will make the distribution menu.vim unreadable, if the shortcut/map
          > need to be defined at the tim eof the menu creation.
          >
          > It should fit within the definition of :menu xyz=x Menu.Sub to instead
          > of displaying data, to change the icon (what about icon in normal
          > menu ;),
          > the tip, the shortcut/map even the command.

          Well, if I define

          :menu File.Open<TAB>:e :browse e<CR>

          then I want to see the ":e" right aligned, and if I define

          :menu File.Open<TAB><D-O> :browse e<CR>

          then I want the "<D-O>" to be right aligned. Of course, it would be
          more Mac-like if you can get the little flower symbol.

          If you make some alternative to the :menu command that allows
          icons, I should be able to supply a macmenu.vim file that uses it, and
          :source it from the gvimrc file.

          Minor complaint: your patch did not fix the version string. It
          still says "Vim 6.0ae".

          --Benji Fisher
        • Bram Moolenaar
          ... Are you sure this is required? Let s not make it more complicated than what is really necessary. Output to the screen can always be CR-LF, files are set
          Message 4 of 6 , Dec 14, 2001
          • 0 Attachment
            Dany St-Amant wrote:

            > Le Mardi 27 novembre 2001, =E0 02:37 , Benji Fisher a =E9crit :
            > >
            > > Thanks. I still have the problem that a <C-M> in the viminfo file
            > > causes confusion. I guess I will have to undefine USE_CR again.
            >
            > Yup, the proper fix for require the split of USE_CR into approximately
            > three different EOL definitions. EOL for output to the screen, EOL for
            > files and EOL for system (i.e.:shell) invocation. Before I release a
            > patch for this, I prefer to have Bram's blessing (in the mean time
            > I'll work on it anyway.)

            Are you sure this is required? Let's not make it more complicated than
            what is really necessary. Output to the screen can always be CR-LF,
            files are set by 'fileformats'. For shell invocation I don't see where
            USE_CR is used. I think the viminfo file always uses NL for
            end-of-line, don't know why it would be CR.

            --
            hundred-and-one symptoms of being an internet addict:
            99. The hum of a cooling fan and the click of keys is comforting to you.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          Your message has been successfully submitted and would be delivered to recipients shortly.