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

Re: Mac-VIM doesn't cooperate with Finder

Expand Messages
  • Eckehard Berns
    ... I will have a look at that and see if I can adopt this for Mac OS X also. ... The problem here is, that Mac OS X behaves completely different from X11 and
    Message 1 of 22 , Feb 6, 2004
    • 0 Attachment
      > 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.

      > 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?

      --
      Eckehard Berns
    • Bram Moolenaar
      ... That would be good. It s very annoying if there is a problem in your vimrc but you never get a hint about it. ... I think I understand the issue. I have
      Message 2 of 22 , Feb 6, 2004
      • 0 Attachment
        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 ///
      • Eckehard Berns
        ... I thought about storing open document events for later use, but I don t know all consequences of this yet. And I can t use gui.starting since it s already
        Message 3 of 22 , Feb 6, 2004
        • 0 Attachment
          > 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.

          I thought about storing open document events for later use, but I don't
          know all consequences of this yet. And I can't use gui.starting since
          it's already reset to false and gui.in_use is true when the GUI delay is
          executed. Or did you refer to another "starting"?

          Hmmm, I think I understand your point. Things might get really
          complicated when there are plugins that might snap in because of
          something in the viminfo file. If I remember the sources correctly
          viminfo is parsed after the GUI has been fired up and thus there could
          be output in the GUI window. The .vimrc file shouldn't be a problem
          since it is run when the GUI isn't used for output yet.

          I think I will try my luck on this approach and try to hold back the
          dropped files until the gui is fully started. In the long run this seems
          to be the cleanest approach.

          > 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 might have expressed myself a bit unclear, but the handle_drop() (we
          can't really use gui_handle_drop() since we don't get actual mouse
          coordinates and would have to make up values for x, y, and modifiers)
          works fine once the application is fully started. So any subsequent
          drops on the app icon in the Dock will work fine and won't show a prompt.

          --
          Eckehard Berns
        • Bram Moolenaar
          ... The global starting , see globals.h. ... In this situation I suppose Vim would be started without file names. Thus you can use the global argument list to
          Message 4 of 22 , Feb 6, 2004
          • 0 Attachment
            Eckehard Berns wrote:

            > > 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.
            >
            > I thought about storing open document events for later use, but I don't
            > know all consequences of this yet. And I can't use gui.starting since
            > it's already reset to false and gui.in_use is true when the GUI delay is
            > executed. Or did you refer to another "starting"?

            The global "starting", see globals.h.

            > Hmmm, I think I understand your point. Things might get really
            > complicated when there are plugins that might snap in because of
            > something in the viminfo file. If I remember the sources correctly
            > viminfo is parsed after the GUI has been fired up and thus there could
            > be output in the GUI window. The .vimrc file shouldn't be a problem
            > since it is run when the GUI isn't used for output yet.
            >
            > I think I will try my luck on this approach and try to hold back the
            > dropped files until the gui is fully started. In the long run this seems
            > to be the cleanest approach.

            In this situation I suppose Vim would be started without file names.
            Thus you can use the global argument list to keep the dropped files.
            Then you only need to do something to open the first one once Vim has
            finished initializing.

            I suppose the delay is not needed for the Mac, thus we can skip that
            anyway. Or do you see some flicker when the gvimrc contains settings
            that change the size or colors of the window?

            You could actually handle the drop events in the delay, but instead of
            opening the files they should be put in the argument list that main()
            uses somehow. Don't know if this works without side effects...

            --
            Creating the world with Emacs: M-x let-there-be-light
            Creating the world with Vim: :make world

            /// 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 ///
          • Eckehard Berns
            ... The window does resize for me, the font changes and the initial window is all white. I don t actually know why. Creating the window is done in
            Message 5 of 22 , Feb 6, 2004
            • 0 Attachment
              > In this situation I suppose Vim would be started without file names.
              > Thus you can use the global argument list to keep the dropped files.
              > Then you only need to do something to open the first one once Vim has
              > finished initializing.
              >
              > I suppose the delay is not needed for the Mac, thus we can skip that
              > anyway. Or do you see some flicker when the gvimrc contains settings
              > that change the size or colors of the window?

              The window does resize for me, the font changes and the initial window
              is all white. I don't actually know why. Creating the window is done in
              gui_mch_init() and gui_mch_open() will show it. I'd think that this is
              the supposed way to do it. The window will be created with default
              values first. I don't know when code snaps in to use the values from
              .vimrc.

              However, this behavior doesn't change with or without the GUI delay.
              And on the Mac this doesn't get into your way since mapping a correctly
              sized window isn't as important as with modern window managers in X11
              which might try to find the best place to move the window to. Because
              of that, and because reading the initial filelist in the delay works
              nice I'd rather keep the GUI delay.

              > You could actually handle the drop events in the delay, but instead of
              > opening the files they should be put in the argument list that main()
              > uses somehow. Don't know if this works without side effects...

              I tried that. And it was easier than I thought. I was prepared to
              shuffle argv a bit, but when I saw the global_alist, it was quite easy.
              I then checked main() for usage of the global_alist between the
              argument parsing and the GUI delay. I could only make out the expanding
              of the filenames, which isn't needed (nor wanted) for the files from
              the AppleEvent. But maybe there is code hidden behind function calls
              somewhere. There's also the sourcing of the vimrcs. The argument list
              has never been available at that point for the Mac, so we don't change
              things to the worse.

              With the new code, Benji's vimrc addition to change to the directory of
              the first file in the argument list works again. My previous proposal
              broke that nice feature. One could argue that this would be the time to
              add this feature to the Vim binary, but I'm not sure about that.

              Here's the patch (I don't know if one could omit the #ifdef's since I'm
              doing nothing OS X specific--I'm just afraid of breaking Mac OS Classic
              versions and added them as a precaution):

              diff -cr ../vim62.238/src/gui_mac.c ./src/gui_mac.c
              *** ../vim62.238/src/gui_mac.c Mon Jan 26 18:16:14 2004
              --- ./src/gui_mac.c Fri Feb 6 20:13:03 2004
              ***************
              *** 1162,1167 ****
              --- 1162,1184 ----
              return (error);
              }

              + #ifdef MACOS_X_UNIX
              + if (starting == 1) {
              + int i;
              + char_u *p;
              +
              + /* these are the initial files dropped on the Vim icon */
              + for (i = 0 ; i < numFiles; i++) {
              + if (ga_grow(&global_alist.al_ga, 1) == FAIL
              + || (p = vim_strsave(fnames[i])) == NULL)
              + mch_exit(2);
              + else
              + alist_add(&global_alist, p, 2);
              + }
              + goto finished;
              + }
              + #endif
              +
              /* Handle the drop, :edit to get to the file */
              handle_drop(numFiles, fnames, FALSE);

              ***************
              *** 1189,1194 ****
              --- 1206,1214 ----
              setcursor();
              out_flush();

              + #ifdef MACOS_X_UNIX
              + finished:
              + #endif
              AEDisposeDesc(&theList); /* dispose what we allocated */

              error = HandleUnusedParms (theAEvent);

              --
              Eckehard Berns
            • Eckehard Berns
              ... Not a problem with Finder, but a open -a Vim would give me an error -10660. I have been playing around with different versions of Vim today and after a
              Message 6 of 22 , Feb 6, 2004
              • 0 Attachment
                > Thanks, but it didn't work. The problem is, Finder quits after I click
                > "Change All...". Anybody has the same "Finder quits" problem?

                Not a problem with Finder, but a "open -a Vim" would give me an error
                -10660. I have been playing around with different versions of Vim today
                and after a while I experienced this problem. It might be related to
                the fact that I re-enabled the BootCache in 10.3.2, but maybe this was
                a coincidence. What finally solved the problem for me was to empty my
                trash. I had the previously used version of Vim still in there and the
                LaunchService found it, but wouldn't return a path for it, since it was
                in the trash. Maybe your problem is related to this.

                --
                Eckehard Berns
              • Eckehard Berns
                ... This feature has already been implemented for the Mac GUI, it just broke for Mac OS X when borrowing more code from the Unix ports, I think. I have a patch
                Message 7 of 22 , Feb 6, 2004
                • 0 Attachment
                  > >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.

                  This feature has already been implemented for the Mac GUI, it just broke
                  for Mac OS X when borrowing more code from the Unix ports, I think. I
                  have a patch here which should detect the GUI version a bit better
                  (isatty(2) returned true even if Vim was started from Finder). It took a
                  bit of a search for the functions that would report values the Mac GUI
                  version wouldn't want to receive and I don't know if got them all with
                  these changes. What I tested worked fine for the GUI and the terminal
                  version.

                  diff -cr ../vim62.238/src/main.c ./src/main.c
                  *** ../vim62.238/src/main.c Mon Feb 2 21:05:35 2004
                  --- ./src/main.c Sat Feb 7 00:10:32 2004
                  ***************
                  *** 1156,1161 ****
                  --- 1156,1166 ----
                  want_full_screen = FALSE;
                  #endif

                  + #if defined(FEAT_GUI_MAC) && defined(MACOS_X_UNIX)
                  + if (gui.starting)
                  + want_full_screen = FALSE;
                  + #endif
                  +
                  /*
                  * mch_init() sets up the terminal (window) for use. This must be
                  * done after resetting full_screen, otherwise it may move the
                  cursor
                  diff -cr ../vim62.238/src/message.c ./src/message.c
                  *** ../vim62.238/src/message.c Mon Feb 2 21:05:35 2004
                  --- ./src/message.c Sat Feb 7 00:03:25 2004
                  ***************
                  *** 2152,2158 ****
                  /* On Unix use stderr if it's a tty.
                  * When not going to start the GUI also use stderr. */
                  if (
                  ! # ifdef UNIX
                  isatty(2)
                  # ifdef FEAT_GUI
                  ||
                  --- 2147,2153 ----
                  /* On Unix use stderr if it's a tty.
                  * When not going to start the GUI also use stderr. */
                  if (
                  ! # if defined(UNIX) && !defined(MACOS_X_UNIX)
                  isatty(2)
                  # ifdef FEAT_GUI
                  ||
                  ***************
                  *** 2216,2222 ****
                  * uses mch_errmsg() when started from the desktop.
                  * When not going to start the GUI also use stdout. */
                  if (
                  ! # ifdef UNIX
                  isatty(2)
                  # ifdef FEAT_GUI
                  ||
                  --- 2211,2217 ----
                  * uses mch_errmsg() when started from the desktop.
                  * When not going to start the GUI also use stdout. */
                  if (
                  ! # if defined(UNIX) && !defined(MACOS_X_UNIX)
                  isatty(2)
                  # ifdef FEAT_GUI
                  ||

                  --
                  Eckehard Berns
                • Benji Fisher
                  ... I think the Hit Enter prompt is supposed to show up when there is a message on the command line that you might want to read before continuing. For
                  Message 8 of 22 , Feb 6, 2004
                  • 0 Attachment
                    On Thu, Feb 05, 2004 at 02:59:04PM -0500, Alfred von Campe wrote:
                    > On Feb 5, 2004, at 14:26, Benji Fisher wrote:
                    >
                    > > If we document it, it becomes a feature, right? ;)
                    >
                    > Well, I wasn't trying to be facetious. Why does this behavior exist in
                    > the first place? When does the "Hit Enter" behavior actually serve a
                    > useful purpose? Instead of a patch that has undesired side effects,
                    > why doesn't the offending piece of code get completely removed from the
                    > source tree? Or at least enclosed in a "#ifndef MACOSX" section?

                    I think the "Hit Enter" prompt is supposed to show up when there is
                    a message on the command line that you might want to read before
                    continuing. For example, try

                    :!ls

                    in a directory where this will take more than a line or two. The prompt
                    is appropriate here.

                    I think the other responses on this thread answer the other
                    question better than I could. Executive summary: it is not that simple
                    ...

                    --Benji Fisher
                  • Bram Moolenaar
                    ... That is strange. Smells like a bug in isatty(). ... I wonder, after this change and starting gvim from a terminal window, do you also get the messages in
                    Message 9 of 22 , Feb 7, 2004
                    • 0 Attachment
                      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.
                      >
                      > This feature has already been implemented for the Mac GUI, it just broke
                      > for Mac OS X when borrowing more code from the Unix ports, I think. I
                      > have a patch here which should detect the GUI version a bit better
                      > (isatty(2) returned true even if Vim was started from Finder).

                      That is strange. Smells like a bug in isatty().

                      > It took a bit of a search for the functions that would report values
                      > the Mac GUI version wouldn't want to receive and I don't know if got
                      > them all with these changes. What I tested worked fine for the GUI and
                      > the terminal version.

                      I wonder, after this change and starting gvim from a terminal window, do
                      you also get the messages in a popup window? I would rather see them in
                      the terminal in this situation. But this would require reliably
                      detecting being started from a terminal, that might be difficult if
                      isatty() doesn't work.

                      --
                      hundred-and-one symptoms of being an internet addict:
                      68. Your cat always puts viruses on your dogs homepage

                      /// 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 ///
                    • Eckehard Berns
                      ... Hmm, not necessarily. ttyname(2) returns /dev/console , which should be considered a tty. So a better test might be to check ttyname also for Mac OS X.
                      Message 10 of 22 , Feb 7, 2004
                      • 0 Attachment
                        > > This feature has already been implemented for the Mac GUI, it just broke
                        > > for Mac OS X when borrowing more code from the Unix ports, I think. I
                        > > have a patch here which should detect the GUI version a bit better
                        > > (isatty(2) returned true even if Vim was started from Finder).
                        >
                        > That is strange. Smells like a bug in isatty().

                        Hmm, not necessarily. ttyname(2) returns "/dev/console", which should be
                        considered a tty. So a better test might be to check ttyname also for
                        Mac OS X. "open -a Vim" will report "/dev/console" also, so that should
                        be a good test to distinguish whether output can be reported to the
                        Terminal or not.

                        > I wonder, after this change and starting gvim from a terminal window, do
                        > you also get the messages in a popup window? I would rather see them in
                        > the terminal in this situation. But this would require reliably
                        > detecting being started from a terminal, that might be difficult if
                        > isatty() doesn't work.

                        It did popup a message window. When checking against ttyname the
                        behavior is corrected. The altered patch looks like this:

                        diff -cr ../vim62.242/src/main.c ./src/main.c
                        *** ../vim62.242/src/main.c Sat Feb 7 13:37:50 2004
                        --- ./src/main.c Sat Feb 7 15:08:51 2004
                        ***************
                        *** 1160,1165 ****
                        --- 1160,1170 ----
                        want_full_screen = FALSE;
                        #endif

                        + #if defined(FEAT_GUI_MAC) && defined(MACOS_X_UNIX)
                        + if (gui.starting && (0 == strcmp("/dev/console", ttyname(2))))
                        + want_full_screen = FALSE;
                        + #endif
                        +
                        /*
                        * mch_init() sets up the terminal (window) for use. This must be
                        * done after resetting full_screen, otherwise it may move the cursor
                        diff -cr ../vim62.242/src/message.c ./src/message.c
                        *** ../vim62.242/src/message.c Sat Feb 7 13:37:49 2004
                        --- ./src/message.c Sat Feb 7 15:05:27 2004
                        ***************
                        *** 2153,2159 ****
                        --- 2153,2163 ----
                        * When not going to start the GUI also use stderr. */
                        if (
                        # ifdef UNIX
                        + # ifndef MACOS_X_UNIX
                        isatty(2)
                        + # else
                        + (0 != (strcmp("/dev/console", ttyname(2))))
                        + # endif
                        # ifdef FEAT_GUI
                        ||
                        # endif
                        ***************
                        *** 2217,2223 ****
                        --- 2221,2231 ----
                        * When not going to start the GUI also use stdout. */
                        if (
                        # ifdef UNIX
                        + # ifndef MACOS_X_UNIX
                        isatty(2)
                        + # else
                        + (0 != (strcmp("/dev/console", ttyname(2))))
                        + # endif
                        # ifdef FEAT_GUI
                        ||
                        # endif

                        --
                        Eckehard Berns
                      • Bram Moolenaar
                        ... Aha. I suppose you could see the messages on /dev/console by opening it. (never had the idea to look there though). ... That looks like a good solution.
                        Message 11 of 22 , Feb 7, 2004
                        • 0 Attachment
                          Eckehard Berns wrote:

                          > > > This feature has already been implemented for the Mac GUI, it just broke
                          > > > for Mac OS X when borrowing more code from the Unix ports, I think. I
                          > > > have a patch here which should detect the GUI version a bit better
                          > > > (isatty(2) returned true even if Vim was started from Finder).
                          > >
                          > > That is strange. Smells like a bug in isatty().
                          >
                          > Hmm, not necessarily. ttyname(2) returns "/dev/console", which should be
                          > considered a tty. So a better test might be to check ttyname also for
                          > Mac OS X. "open -a Vim" will report "/dev/console" also, so that should
                          > be a good test to distinguish whether output can be reported to the
                          > Terminal or not.

                          Aha. I suppose you could see the messages on /dev/console by opening
                          it. (never had the idea to look there though).

                          > > I wonder, after this change and starting gvim from a terminal window, do
                          > > you also get the messages in a popup window? I would rather see them in
                          > > the terminal in this situation. But this would require reliably
                          > > detecting being started from a terminal, that might be difficult if
                          > > isatty() doesn't work.
                          >
                          > It did popup a message window. When checking against ttyname the
                          > behavior is corrected. The altered patch looks like this:

                          That looks like a good solution. To stay on the safe side I think we
                          should also use isatty(). And add a comment about why it's done this
                          way (in two years we will have forgotten all about it).

                          Here is the patch with my additions, please check it out:

                          *** ../vim-6.2.242/src/main.c Fri Feb 6 19:35:39 2004
                          --- src/main.c Sat Feb 7 15:34:40 2004
                          ***************
                          *** 1160,1165 ****
                          --- 1160,1173 ----
                          want_full_screen = FALSE;
                          #endif

                          + #if defined(FEAT_GUI_MAC) && defined(MACOS_X_UNIX)
                          + /* When the GUI is started from Finder, need to display messages in a
                          + * message box. isatty(2) returns TRUE anyway, thus we need to check the
                          + * name to know we're not started from a terminal. */
                          + if (gui.starting && strcmp("/dev/console", ttyname(2)) == 0)
                          + want_full_screen = FALSE;
                          + #endif
                          +
                          /*
                          * mch_init() sets up the terminal (window) for use. This must be
                          * done after resetting full_screen, otherwise it may move the cursor
                          *** ../vim-6.2.242/src/message.c Mon Feb 2 12:53:51 2004
                          --- src/message.c Sat Feb 7 15:39:47 2004
                          ***************
                          *** 2150,2159 ****

                          #if (defined(UNIX) || defined(FEAT_GUI)) && !defined(ALWAYS_USE_GUI)
                          /* On Unix use stderr if it's a tty.
                          ! * When not going to start the GUI also use stderr. */
                          if (
                          # ifdef UNIX
                          isatty(2)
                          # ifdef FEAT_GUI
                          ||
                          # endif
                          --- 2150,2164 ----

                          #if (defined(UNIX) || defined(FEAT_GUI)) && !defined(ALWAYS_USE_GUI)
                          /* On Unix use stderr if it's a tty.
                          ! * When not going to start the GUI also use stderr.
                          ! * On Mac, when started from Finder, stderr is the console. */
                          if (
                          # ifdef UNIX
                          + # ifdef MACOS_X_UNIX
                          + (isatty(2) && strcmp("/dev/console", ttyname(2)) != 0)
                          + # else
                          isatty(2)
                          + # endif
                          # ifdef FEAT_GUI
                          ||
                          # endif
                          ***************
                          *** 2214,2223 ****
                          #if (defined(UNIX) || defined(FEAT_GUI)) && !defined(ALWAYS_USE_GUI)
                          /* On Unix use stdout if we have a tty. This allows "vim -h | more" and
                          * uses mch_errmsg() when started from the desktop.
                          ! * When not going to start the GUI also use stdout. */
                          if (
                          # ifdef UNIX
                          isatty(2)
                          # ifdef FEAT_GUI
                          ||
                          # endif
                          --- 2219,2233 ----
                          #if (defined(UNIX) || defined(FEAT_GUI)) && !defined(ALWAYS_USE_GUI)
                          /* On Unix use stdout if we have a tty. This allows "vim -h | more" and
                          * uses mch_errmsg() when started from the desktop.
                          ! * When not going to start the GUI also use stdout.
                          ! * On Mac, when started from Finder, stderr is the console. */
                          if (
                          # ifdef UNIX
                          + # ifdef MACOS_X_UNIX
                          + (isatty(2) && strcmp("/dev/console", ttyname(2)) != 0)
                          + # else
                          isatty(2)
                          + # endif
                          # ifdef FEAT_GUI
                          ||
                          # endif


                          --
                          Q: How many legs does a giraffe have?
                          A: Eight: two in front, two behind, two on the left and two on the right

                          /// 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 ///
                        • Eckehard Berns
                          ... Mac OS X comes with a utility called Console, which is some kind of log viewer. And every output to /dev/console goes into
                          Message 12 of 22 , Feb 7, 2004
                          • 0 Attachment
                            > Aha. I suppose you could see the messages on /dev/console by opening
                            > it. (never had the idea to look there though).

                            Mac OS X comes with a utility called Console, which is some kind of log
                            viewer. And every output to /dev/console goes into
                            /Library/Logs/.../$LOGNAME/console.log (similar to .xsession-errors). I
                            had Console running at some point and caught the output of Vim messages
                            kind of by incidence :)

                            > That looks like a good solution. To stay on the safe side I think we
                            > should also use isatty(). And add a comment about why it's done this
                            > way (in two years we will have forgotten all about it).

                            Yes, checking isatty() also is important. I forgot about that. Someone
                            might redirect stderr to /dev/null or something, which must be tested
                            for.

                            > Here is the patch with my additions, please check it out:

                            Works fine for me. I tried a terminal Vim, GUI Vim started from
                            Terminal, and GUI vim started from Finder (and by "open -a Vim"). The
                            error dialog pops up only when there is no terminal to show the output.

                            I thought about the redirection and additional isatty() check some
                            more. I actually use a DropOutScript (wrapper around a shell script) to
                            open every file with the extension .vimsession by calling Vim with some
                            arguments. I redirect input and output as well as stderr to /dev/null.
                            Since this isn't a tty, ttyname returns NULL (I assume) and the strcmp
                            causes a SIGBUS. The line in main() therefor should read:

                            if (gui.starting && (!isatty(2) || strcmp("/dev/console", ttyname(2))
                            == 0))

                            After this little change, starting the GUI with redirected output works
                            again (and reports errors via a popup dialog.)

                            --
                            Eckehard Berns
                          • Axel Kielhorn
                            ... I removed the #ifdef and compiled Vim 6.2.242 for Classic. The Hit Return prompt is gone, I´ll watch out for side effects. Axel
                            Message 13 of 22 , Feb 8, 2004
                            • 0 Attachment
                              Am 06.02.2004 um 20:23 schrieb Eckehard Berns:
                              > Here's the patch (I don't know if one could omit the #ifdef's since
                              > I'm doing nothing OS X specific--I'm just afraid of breaking Mac OS
                              > Classic versions and added them as a precaution):
                              >
                              > diff -cr ../vim62.238/src/gui_mac.c ./src/gui_mac.c
                              > *** ../vim62.238/src/gui_mac.c Mon Jan 26 18:16:14 2004
                              > --- ./src/gui_mac.c Fri Feb 6 20:13:03 2004
                              > ***************
                              > *** 1162,1167 ****
                              > --- 1162,1184 ----
                              > return (error);
                              > }
                              >
                              > + #ifdef MACOS_X_UNIX
                              > + if (starting == 1) {
                              > + int i;
                              > + char_u *p;
                              > +
                              > + /* these are the initial files dropped on the Vim icon */
                              > + for (i = 0 ; i < numFiles; i++) {
                              > + if (ga_grow(&global_alist.al_ga, 1) == FAIL
                              > + || (p = vim_strsave(fnames[i])) == NULL)
                              > + mch_exit(2);
                              > + else
                              > + alist_add(&global_alist, p, 2);
                              > + }
                              > + goto finished;
                              > + }
                              > + #endif
                              > +
                              > /* Handle the drop, :edit to get to the file */
                              > handle_drop(numFiles, fnames, FALSE);
                              >
                              > ***************
                              > *** 1189,1194 ****
                              > --- 1206,1214 ----
                              > setcursor();
                              > out_flush();
                              >
                              > + #ifdef MACOS_X_UNIX
                              > + finished:
                              > + #endif
                              > AEDisposeDesc(&theList); /* dispose what we allocated */
                              >
                              > error = HandleUnusedParms (theAEvent);
                              >

                              I removed the #ifdef and compiled Vim 6.2.242 for Classic.
                              The "Hit Return" prompt is gone, I´ll watch out for side effects.

                              Axel
                            • Benji Fisher
                              ... [snip] ... Is this a change we should make in the standard distribution, or should we leave this to individual users (andd add an FAQ)? --Benji Fisher
                              Message 14 of 22 , Feb 19, 2004
                              • 0 Attachment
                                On Thu, Feb 05, 2004 at 08:39:53PM +0100, Eckehard Berns wrote:
                                > >>select a LaTeX file (*.tex) in Finder
                                > >>==> right click
                                > >>==> Open with, find and choose vim
                                > >>==> Change All...
                                > >>
                                > >>then double click a *.tex file, a pop-up says
                                > >> The operation could not be completed.
                                > >> An unexpected error occurred (error code - 10660)
                                >
                                > I had the same problems but could solve them by adding known extensions
                                > to the Info.plist file. If Mac OS X sees only a wildcard, it seems to
                                > get some problems with the default viewer.
                                [snip]
                                > ...
                                > <key>CFBundleTypeExtensions</key>
                                > <array>
                                > <string>tex</string>
                                > <string>*</string>
                                > </array>
                                > <key>CFBundleTypeIconFile</key>
                                > <string>doc-txt.icns</string>
                                > ...

                                Is this a change we should make in the standard distribution, or
                                should we leave this to individual users (andd add an FAQ)?

                                --Benji Fisher
                              • Dan Grillo
                                ... We should add this to the distribution. As shipped it doesn t work! --Dan -- Dan Grillo dan@grillo.net (650) 917-0685 fax (775) 248-7762
                                Message 15 of 22 , Feb 19, 2004
                                • 0 Attachment
                                  Benji Fisher writes:
                                  |
                                  | > >>then double click a *.tex file, a pop-up says
                                  | > >> The operation could not be completed.
                                  | > >> An unexpected error occurred (error code - 10660)
                                  | >
                                  | > I had the same problems but could solve them by adding known extensions
                                  | > to the Info.plist file. If Mac OS X sees only a wildcard, it seems to
                                  | > get some problems with the default viewer.
                                  | [snip]
                                  | > ...
                                  | > <key>CFBundleTypeExtensions</key>
                                  | > <array>
                                  | > <string>tex</string>
                                  | > <string>*</string>
                                  | > </array>
                                  | > <key>CFBundleTypeIconFile</key>
                                  | > <string>doc-txt.icns</string>
                                  | > ...
                                  |
                                  | Is this a change we should make in the standard distribution, or
                                  | should we leave this to individual users (andd add an FAQ)?
                                  |
                                  | --Benji Fisher


                                  We should add this to the distribution. As shipped it doesn't work!

                                  --Dan
                                  --
                                  Dan Grillo dan@... (650) 917-0685 fax (775) 248-7762
                                Your message has been successfully submitted and would be delivered to recipients shortly.