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

1431Re: Mac-VIM doesn't cooperate with Finder

Expand Messages
  • Bram Moolenaar
    Feb 6, 2004
      Eckehard Berns wrote:

      > > The .vimrc is sourced before the GUI window is opened (because it may
      > > specify how it is to be opened). Errors that occur here should be
      > > reported in a separate popup window, unless there is a terminal where
      > > they can be seen. There already is code to collect the messages and
      > > show them in a popup window (for Win32).
      > I will have a look at that and see if I can adopt this for Mac OS X also.

      That would be good. It's very annoying if there is a problem in your
      vimrc but you never get a hint about it.

      > > This delay was added long ago, I think for the X11 GUI. It avoids that
      > > the GUI window appears and is then redrawn, that causes a bit of
      > > flashing and looks ugly. I can't say I understand why a short delay
      > > would cause trouble for the Mac GUI, thus if this helps there should be
      > > an explanation why it needs to be different for the Mac.
      > The problem here is, that Mac OS X behaves completely different from X11
      > and Windows based systems when starting an GUI Application with some
      > files which have been dropped on the application icon (or that have been
      > double clicked). Instead of adding arguments to the command line the app
      > will be started and send AppleEvent messages to open these files. So
      > when you drag a file onto the Vim app, it starts without any arguments.
      > As soon as you call gui_wait_for_chars(), gui_mac.c will call
      > WaitNextEvent(), which will receive the AppleEvent that tells Vim to
      > open the dropped file(s). The callback will collect the files and send
      > them to Vim via handle_drop(). This again results in output of the
      > fileinfo, which sets msg_didany. msg_didany is resposible for the "hit
      > ENTER" prompt further down in main.c (I can't lookup actual line numbers
      > and the correct function names at the moment). If you skip the GUI
      > delay, this event will not be received before the wait_enter() call and
      > thus will not force a "hit ENTER" prompt. The AppleEvent will be handled
      > like an ordinary file drop, which is ok.
      > Maybe a comment stating that the Mac GUI would receive a file drop which
      > disturbs the output slightly would be sufficient?

      I think I understand the issue. I have three suggestions:

      1. Remove the delay in main(), since it is not needed.

      2. Add a mechanism to avoid accepting events before Vim has finished
      starting up. The current issue with the explicit delay is just one
      situation where events might be waited for. If someone adds a
      strange thing in his vimrc then the same problem might popup again.
      The "starting" variable can be used for this.
      One catch: If something interactive is to be done (e.g., from a
      plugin that runs an external command) you are stuck, since you
      probably can't handle user input before accepting the apple events
      for the drop. A solution would be to store the drop request and
      handle it after startup has finished. That's a bit complicated,
      hopefully we don't really need this.

      3. If you don't want the hit-enter prompt for the dropped files, check
      what happens in gui_handle_drop(). I don't get a prompt on Win32,
      thus I wonder why Mac would be different.

      "I simultaneously try to keep my head in the clouds and my feet on the
      ground. Sometimes it's a stretch, though." -- Larry Wall

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
      \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
    • Show all 22 messages in this topic