> Excellent work.  Is the main editor window double buffered?

The main editor window seems to be the default Cocoa text component
which is double buffered (like everything in OS X  (if you don't use
legacy apis ;-) )).


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

2007/7/28, björn <bjorn.winckler@...>:
> I agree...this is how it could be done:  I would implement a Vim command
> called e.g. ':action' which is used like this:
>   :action vimNewWindow:
> When executed, ':action' passes the argument (vimNewWindow:, the name of an
> action message) to the GUI.  Then it would be possible to do this:
>   :menu File.New\ Window :action vimNewWindow:

But this command only makes sense for Cocoa, I'm not sure whether
creating a command for only one GUI port is a good idea.

- Jiang

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Bjorn Winckler wrote:

> I think I was a bit unclear in my previous post, so in order to understand
> the problem I will say something about the menu handling in Cocoa.
> Hopefully this will clarify the situation.
>
> 1.  The text on that goes on the right hand side of the menu item is handled
> by Cocoa.  You can only specify which "accelerator key" should go there
> (specifically, you can specify a printable key, e.g. "o", and modifiers, e.g.
> "Cmd") and Cocoa will do the drawing.  Hence, it is not possible to display
> things like ":e".  (I'm just restating what Jiang said in his post here.)
>
> 2.  There are no "menu accelerators", where one letter of the menu item is
> underlined and pressing Alt+'that letter' brings up a menu and then pressing
> another letter will select a menu item in that menu.  That is, you cannot
> navigate through menus with the keyboard (correct me if I'm wrong here, but
> I don't know of any way to do so).
>
> 3.  Cocoa intercepts key presses, checks if any menu item is "bound" to that
> key combination (the Cmd key is always part of such a binding).  If Cocoa
> finds a menu item bound the key combination, it briefly highlights the menu
> on the menu bar which contains that menu item, and calls the 'action
> message' of that menu item.  This 'feature' can be disabled by hacking a
> little, so that key presses go straight to Vim, but this means that the menu
> won't get highlighted (a minor disturbance, but this is the behaviour you
> expect from an OS X application, so I would like to preserve it.)
>
>
> Now to get back to my proposal.  If there was a command like this in Vim:
>   :menukeyequiv File.Open <D-o>
> Then, you could make all the usual bindings (i.e. the usual ones for an OS X
> app) in a .vim file which gets sourced some time after menu.vim has been
> sourced (thus also making it possible to internationalize key equivalents).
> The implementation of :menukeyequiv itself would simply pass the key
> combination (e.g. <D-o>) and the appropriate vimmenu_T* ( File.Open) to the
> GUI, which can then set the key equivalent of the menu item.  Then, if the
> user presses <D-o>, Cocoa intercepts this event, sees that it is bound to
> the "Open" menu item under the "File" menu and calls its action message (in
> this case, vimMenuItemAction:, which tells Vim to execute a menu item with
> gui_menu_cb()).

That sounds very good to me.

> The negative side effect of this is noticed if somebody tries to remap <D-o>
> with :map, since :map will think that <D-o> is not already bound to
> something.  When the user then presses <D-o> it is intercepted by the GUI
> and the <D-o> event never reaches Vim.   Of course, if you make it clear (
> e.g. in :help MacVim) what is going on, then this should not be such a big
> problem.  (The key equivalent would be forced to contain the Cmd modifier
> because this is expected behaviour.)

Well, if someone wants to map <D-o> he will have to remove any menu item
that captures this key.  I don't think this is a problem, people are
aware a key may already be in use.  The only problem may be that
removing the menu can be a bit complicated.  Ideally there would be a
menu command to delete the menu associated with a specific key.  But
having the user find the menu and using the menu name itself would also
be OK.

> Without something like I outline above, you can of course do what the Carbon
> port does:  make all the usual (as in "OS X app usual") bindings in a .vim
> file (<D-o>, <D-c>, etc.) with :map, but this means that the text on the
> right hand side of all menu items will be empty, and the menu highlighting I
> mentioned above won't work.  From a OS X point of view this is quite
> confusing, but it I guess it makes "Vim-sense".

It also means you have to keep key mappings and menu entries in sync,
everything is there twice.

> Since I am trying to make Vim more OS X like I would strongly prefer the way
> I suggested above (i.e. I want the key equiv text on the right hand side
> _and_ the highlighting), but I will not do it if it is deemed to clash too
> much with how Vim works.

Agreed.

> I agree...this is how it could be done:  I would implement a Vim command
> called e.g. ':action' which is used like this:
>   :action vimNewWindow:
> When executed, ':action' passes the argument (vimNewWindow:, the name of an
> action message) to the GUI.  Then it would be possible to do this:
>   :menu File.New\ Window :action vimNewWindow:
>
> That seems like a good solution to me...any objections?

Sounds good to me.

--
hundred-and-one symptoms of being an internet addict:
50. The last girl you picked up was only a jpeg.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> Memory usage is something that is on my TODO list;  I expect there
> to be quite a bit of memory leaking at this point in time.

So I decided to delete MacVim and wait for the next version (too
buggy for usage, and not enough time to hack on it), and couldn't
delete it because it was still "in use" . Turns out there were still
two Vim processes running MacVim had started when I tested it a few
days ago. So you're leaking processes as well :-P

Bye,
Nico

ps: I don't like the name MacVim (mainly because the mac version of
vim is hosted at macvim.org, so the current version is already
associated with Mac Vim (at least for me). What about AquaVim? ;-)



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

If you ever do figure out how to get Vim in the "Open With" menu, you
may not like it. For example, my user paths aren't loaded when I load
Vim via the Finder. If I want to run a compiler that's not in a standard
folder (like LaTeX), this is pretty annoying.

So here's another option. Try out OnMyCommand. If you're a Vim user,
then you'll probably appreciate this app for lots more reasons.

http://free.abracode.com/cmworkshop/on_my_command.html

OMC adds contextual menu items that truly are contextual. That is, you
use the program "OMCEdit" to add menu items that pop up based on what
you're clicking on. Those menu items can call UNIX commands or execute
AppleScript or do lots of other useful things.

I use an "Open File with Vim" item that is activated on a File or Folder
click (that is not the Finder window). It's "Execution Mode" is "Silent
(popen)" and it escapes special characters with backslash. When I
right-click an item in the Finder and then select this menu item, it
executes:

/bin/bash --login -c "cd __OBJ_PARENT_PATH__ && vi __OBJ_NAME__"

I have a similar menu item called "New File in Vim" that is nearly the
same, except that it activates on a Finder window and executes this:

/bin/bash --login -c "cd __OBJ_PATH__ && vi"

That is, it changes to the folder selected in the Finder and then opens
vi. This lets me create new files pretty easily.

So that's how I solve the problem.

--Ted

Ron Olson wrote:
> Hi all-
>
> No matter how I try, I can't seem to get Vim registered in such a way so
> that if I right-click on a file, it shows up in the "Open With" menu
> item. Is there any known specific way to make this work?
>
> Thanks,
>
> Ron
>
> >

--
Ted Pavlic <ted@...>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Jul 30, 2007, at 11:02 , björn wrote:

> If you ever do figure out how to get Vim in the "Open With" menu, you
> may not like it. For example, my user paths aren't loaded when I load
> Vim via the Finder. If I want to run a compiler that's not in a
> standard
> folder (like LaTeX), this is pretty annoying.
>
> I guess MacVim suffers from the same problem -- the "Open With"
> menu is there, but no care is taken to load the user's paths.
>
> This could be fixed by sourcing the user settings, whenever a Vim
> process is launched from MacVim.  However, I'm not sure how to
> 'source the user settings'...how do you figure out which one it is
> (could be .profile, .bashrc, etc.), and is there a way of reading
> it short of launching /bin/sh (or whatever) and checking which
> environment variables got set?
>
> Has anybody got any ideas on how to do this?

One can set variables "property list style" in ~/.MacOSX/
environment.plist. Finder reads that when it starts and all GUI
applications launched from Finder will inherit those settings.

Far from pretty but it would work.

-- Trenton


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

This is from Macvim.org:

=====
The following instructions from Peter Cucka are written for the gvim.app
helper application, but they may also apply to Vim.app itself.

It might take some work to get the Finder to recognize the new
Info.plist. If my reading of this document is correct, there are two
ways to do this. One is to replace your old /Applications/gvim.app with
the new version and then reboot your Mac. The other is to create a new
directory somewhere, untar the attached archive into it, and then
navigate to the new directory from the Finder (you might also need to
restart the Finder, or log out and back in again).

If the new gvim.app has been registered correctly, it should appear in
the Open With list for all files with a .txt extension. To associate
gvim.app with .c (or other) files, you will need to Get Info on a .c
file, search for gvim in the Open With list and Add it, and then Change
All to make gvim the default app. All .c files will then open with gvim
(but, oddly, gvim still won't show up in the Open With list; if you want
it to, you'll have to edit the Info.plist file to register a new .c
document type.)
=====

Ron Olson wrote:
> Hi all-
>
> No matter how I try, I can't seem to get Vim registered in such a way so
> that if I right-click on a file, it shows up in the "Open With" menu
> item. Is there any known specific way to make this work?
>
> Thanks,
>
> Ron
>
> >

--
Ted Pavlic <ted@...>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> I guess MacVim suffers from the same problem -- the "Open With" menu is
> there, but no care is taken to load the user's paths.

Note: It looks like the problem I've always had has less to do with Vim
and more to do with the "gvim" droplet (I think I got it from vim.org
ages ago) that allows me to easily open files in Vim.

It has a "script" in its resources that has this:

=====
#!/bin/sh

VIM_APP_DIR=/Applications

. /sw/bin/init.sh

${VIM_APP_DIR}/Vim.app/Contents/MacOS/Vim -go "$@" &
script (END)
=====

This seems a little silly to me. Changing that to something more
reasonable should fix any old path troubles I had.

--Ted


> This could be fixed by sourcing the user settings, whenever a Vim
> process is launched from MacVim.  However, I'm not sure how to 'source
> the user settings'...how do you figure out which one it is (could be
> .profile, .bashrc, etc.), and is there a way of reading it short of
> launching /bin/sh (or whatever) and checking which environment variables
> got set?
>
> Has anybody got any ideas on how to do this?
>
>
> /Björn
>
> >

--
Ted Pavlic <ted@...>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

> - app should no longer hang when resizing window

Still happens for me (only if I hit the zoom button first, though).
Zoom button behaviour is still broken (should toggle between "best
size" (whatever that means; for me a "vertical maximize" makes most
sense with vim) and "user size" (usually the size the window had
before you hit the zoom button the first time...check out the HIG for
the exact wording. The default Cocoa handler for that does the Wrong
Thing.)

And the toolbar is still broken: As soon as I hit Cmd-t to open a new
tab, a second star appears below the "chevron" (I believe that's the
right term -- the thingie to click on to reveal the overflow toolbar
buttons). I have columns=80, if you can't reproduce it I can send you
a screenshot.

And it's a bit weird that the window turns white during resizing. I
guess this is an implementation artifact (you're talking to vim
processes over some pipe)?

> If MacVim ever hangs like Nico described when he resized the
> window, that means the "communication queues" between MacVim and
> Vim are clogging up.  Please let me know if you discover any such
> behaviour and I will most likely be able to fix it very easily.
> Unfortunately this is timing related, so if you have a faster/
> slower machine than I do you might run into problems that I will
> never have.  I have gone through the code to eliminate all the
> problem areas I could find, so hopefully nobody will have any
> problems now.

Sorry ;-) I've got a 2.4 GHz Core 2 Duo.

> I will try to release a new snapshot weekly (on Sunday night
> central european time, most likely), and announce new snapshots on
> this list.

w00t.

> (It serves no major purpose anymore, so I might disable it
> permanently soon.)

+1.

Can you set gui.border_offset (or gui.border_width, whatever you use)
to something more than 0? Having letters at the left edge of the
window looks weird to me.

Oh, I just tried to do some actual work with MacVim (I opened
gui_mac.c), and after hitting zoom (first thing I do with the "old"
vim), thinking "oh, damn, wrong", hitting zoom again (because that
undoes zoom in every sane application) and thinking "damn, wrong
_again_", the window was completely broken: Only the first 13.5
toolbar icons were drawn (the right half of nr 14 ws missing) and
there was no text visible at all, only patches of color. Hitting Ctrl-
L didn't help.

Looking forward to the next snapshot :-)

Bye,
Nico



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I've put together a new gvim.app that does a better job at this. Check out:

http://links.tedpavlic.com/zip/gvim-login-and-open-with.app.zip

I've included lots of different file types and made icons for them that
you'll see if you set gvim as the default handler for the file type.

If you don't see the "Open With", you should try some of the
instructions from #4 from:

http://macvim.org/OSX/index.php#FAQ

In particular, try moving the gvim.app out of /Applications and then
back again. Also try doing "Open Contents" on gvim.app and then clicking
"Contents" and "Resources." Also try doing a "Get Info" on gvim.app.
And, finally, restart your Finder (which can be done by logging out and
logging back in).

I did all of this today, and now I see "gvim" in my "Open With" menu
nearly everywhere I see "TextMate" (because TextMate's Info.plist was my
inspiration).

NOTE: gvim.app is designed to open up each file in a new window rather
than using the currently open Vim. If you'd like the existing Vim to
handle the new file, you can make similar changes to Vim.app's
Info.plist file.

--Ted



Ron Olson wrote:
> Hi all-
>
> No matter how I try, I can't seem to get Vim registered in such a way so
> that if I right-click on a file, it shows up in the "Open With" menu
> item. Is there any known specific way to make this work?
>
> Thanks,
>
> Ron
>
> >

--
Ted Pavlic <ted@...>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

This version of the "script" Resource that comes with the gvim droplet
works much better:

=====
#!/bin/sh

#
# This script makes sure the login paths are set
#

if [ "${THE_GVIM_SCRIPT_IS_RUNNING}" == "" ]; then
          export THE_GVIM_SCRIPT_IS_RUNNING=1
          exec /bin/bash -l $0 "$@"
else
          VIM_APP_DIR=/Applications
          exec ${VIM_APP_DIR}/Vim.app/Contents/MacOS/Vim -go "$@" &
fi
=====

--Ted

Ted Pavlic wrote:
>> I guess MacVim suffers from the same problem -- the "Open With" menu is
>> there, but no care is taken to load the user's paths.
>
> Note: It looks like the problem I've always had has less to do with Vim
> and more to do with the "gvim" droplet (I think I got it from vim.org
> ages ago) that allows me to easily open files in Vim.
>
> It has a "script" in its resources that has this:
>
> =====
> #!/bin/sh
>
> VIM_APP_DIR=/Applications
>
> . /sw/bin/init.sh
>
> ${VIM_APP_DIR}/Vim.app/Contents/MacOS/Vim -go "$@" &
> script (END)
> =====
>
> This seems a little silly to me. Changing that to something more
> reasonable should fix any old path troubles I had.
>
> --Ted
>
>
>> This could be fixed by sourcing the user settings, whenever a Vim
>> process is launched from MacVim.  However, I'm not sure how to 'source
>> the user settings'...how do you figure out which one it is (could be
>> .profile, .bashrc, etc.), and is there a way of reading it short of
>> launching /bin/sh (or whatever) and checking which environment variables
>> got set?
>>
>> Has anybody got any ideas on how to do this?
>>
>>
>> /Björn
>>
>

--
Ted Pavlic <ted@...>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

björn wrote:
> I have uploaded a new snapshot of MacVim to:
>
> http://code.google.com/p/macvim/
>
> Let me know if you have any problems with this snapshot.  The major
> changes are:
> - based on vim 7.1.* instead of 7.0.*
> - no process leaks
> - less memory leaks (it might still leak some)
> - app should no longer hang when resizing window
> - warning is given when close button pressed
> - distributed objects used for interprocess communication
>

:q on the last buffer closes the window and not the app? Is that
intentional?

>
> P.S. If you dislike the status line, open terminal and type:
>    defaults write org.vim.MacVim statuslineoff 1
> (It serves no major purpose anymore, so I might disable it permanently
> soon.)

What do you mean it serves no purpose? I have a custom config that shows
various things about the file.

Robert



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

> Arghm!  Ok, I will keep digging.  I've never managed to recreate
> this crash on my machine though, so I'm not sure what gives.

It's more a hang than a crash.

> As for zoom button behaviour...hold down Cmd when you resize.
> Presto!  I also think that height-only zoom should be the default,
> but for some reason I got the impression that Vim users preferred
> the zoom-to-all-i've-got style.  I will switch the role of the two
> with the next snapshot (I certainly _never_ zoom to fill the screen).

Much nicer. The problem with zoom without cmd is that it resizes the
window to max height and about .75*max_width on first click, max
height and width on second click, and then toggles between these two
states (instead of toggling between the original size and whatever
the optimal size is). zoom-to-all-i've-got is completely useless with
a decent (24'' or 30'') external monitor or a MBP with a good
resolution imho :-P

> I've noticed some peculiarities with the toolbar as well...check
> out screenshot #3 (how nice that I managed to capture this on a
> screenshot :) ).  It's weird...I'm wondering if it is a bug in
> NSToolbar...I certainly have no control over it and it is not
> considered part of the "content view" of the window, so there
> should be no way to accidentally draw on top of it.  (And I don't
> even do any drawing myself...)

I doubt this is a bug in NSToolbar. It works in too many
applications ;-) If it's not fixed by the weekend, I might see if I
can fix this.

> Oh, I just tried to do some actual work with MacVim (I opened
> gui_mac.c), and after hitting zoom (first thing I do with the "old"
> vim), thinking "oh, damn, wrong", hitting zoom again (because that
> undoes zoom in every sane application) and thinking "damn, wrong
> _again_", the window was completely broken: Only the first 13.5
> toolbar icons were drawn (the right half of nr 14 ws missing) and
> there was no text visible at all, only patches of color. Hitting Ctrl-
> L didn't help.
>
> Have you (or anybody else for that matter) managed to reproduce
> this?  I've terrorized the zoom button more than I care to admit
> and never experience any zooming problems.  Maybe I'll just disable
> window resizing. ;)

Might be Intel-specific. It's quite easy to reproduce: Launch

      ~/Desktop nico$ MacVim-snapshot-r38/MacVim.app/Contents/MacOS/
Vim -g ~/src/vim7/src/gui_mac.c

, hit zoom (windows turns white, becomes somewhat large), zoom
(window fills screen, still white), zoom (window is a bit smaller
again, has some patches of color in it). Happens every time.

Bye,
Nico



--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

>> P.S. If you dislike the status line, open terminal and type:
>>    defaults write org.vim.MacVim statuslineoff 1
>> (It serves no major purpose anymore, so I might disable it
>> permanently
>> soon.)
>
> What do you mean it serves no purpose? I have a custom config that
> shows
> various things about the file.

I think he means the GUI status bar, not Vim's status bar. The GUI
status bar doesn't do anything atm.


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Ted Pavlic wrote:

> I've put together a new gvim.app that does a better job at this. Check out:
>
> http://links.tedpavlic.com/zip/gvim-login-and-open-with.app.zip
>
> I've included lots of different file types and made icons for them that
> you'll see if you set gvim as the default handler for the file type.
>
> If you don't see the "Open With", you should try some of the
> instructions from #4 from:
>
> http://macvim.org/OSX/index.php#FAQ
>
> In particular, try moving the gvim.app out of /Applications and then
> back again. Also try doing "Open Contents" on gvim.app and then clicking
> "Contents" and "Resources." Also try doing a "Get Info" on gvim.app.
> And, finally, restart your Finder (which can be done by logging out and
> logging back in).
>
> I did all of this today, and now I see "gvim" in my "Open With" menu
> nearly everywhere I see "TextMate" (because TextMate's Info.plist was my
> inspiration).
>
> NOTE: gvim.app is designed to open up each file in a new window rather
> than using the currently open Vim. If you'd like the existing Vim to
> handle the new file, you can make similar changes to Vim.app's
> Info.plist file.

For MS-Windows we have both "Open in new Vim" and "Open in existing
Vim", because both are useful at times.

I assume that for the Mac we can't have more than one entry.  The best
compromise then is to open the file in a new tab page in the existing
Vim.  Can it be made to function that way?  The nice thing about it is
that when you are already editing a file using "Open with Vim" won't
take away that file from you.

--
hundred-and-one symptoms of being an internet addict:
61. Your best friends know your e-mail address, but neither your phone number
     nor the address where you live.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi all!

Ted, that looks quite convenient; thanks.

However, my main problem with gvim.app and the like is that they
expect Vim.app to reside directly in /Applications. I prefer to have
subfolders there for different stuff (mainly to separate added apps
from ones coming with OS X - when possible). What I do do, which the
regular use case also implies, is have gvim.app and Vim.app in the
same folder. Therefore I'd recommend that any launch scripts expect
only that. A crude example (also sourcing .profile) of how to achieve
that is at:

     <http://tech.groups.yahoo.com/group/vim-mac/message/4268>

. There may be better ways.

Best regards,
Niklas



On 7/31/07, Ted Pavlic <ted@...> wrote:
>
> I've put together a new gvim.app that does a better job at this. Check out:
>
> http://links.tedpavlic.com/zip/gvim-login-and-open-with.app.zip
>
> I've included lots of different file types and made icons for them that
> you'll see if you set gvim as the default handler for the file type.
>
> If you don't see the "Open With", you should try some of the
> instructions from #4 from:
>
> http://macvim.org/OSX/index.php#FAQ
>
> In particular, try moving the gvim.app out of /Applications and then
> back again. Also try doing "Open Contents" on gvim.app and then clicking
> "Contents" and "Resources." Also try doing a "Get Info" on gvim.app.
> And, finally, restart your Finder (which can be done by logging out and
> logging back in).
>
> I did all of this today, and now I see "gvim" in my "Open With" menu
> nearly everywhere I see "TextMate" (because TextMate's Info.plist was my
> inspiration).
>
> NOTE: gvim.app is designed to open up each file in a new window rather
> than using the currently open Vim. If you'd like the existing Vim to
> handle the new file, you can make similar changes to Vim.app's
> Info.plist file.
>
> --Ted
>
>
>
> Ron Olson wrote:
> > Hi all-
> >
> > No matter how I try, I can't seem to get Vim registered in such a way so
> > that if I right-click on a file, it shows up in the "Open With" menu
> > item. Is there any known specific way to make this work?
> >
> > Thanks,
> >
> > Ron
> >
> > >
>
> --
> Ted Pavlic <ted@...>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I agree; my behaviour is very similar. It would be great though if
folders and files could be dropped on MacVim windows (which I noticed
is not possible now). The behaviour of Carbon Vim would work great I
think - where a dropped item is directly :edit-ed, unless the command
line is active, in which case the file location is appended.

Best regards,
Niklas


On 7/31/07, Nico Weber <nicolasweber@...> wrote:
>
> > There have been a few request (already) that new files open in tabs
> > instead of in a new window for MacVim, so I will change the current
> > behaviour so that new files ( i.e. dragged onto dock icon, "Open
> > with...") will open in tabs in the current window.
>
> I prefer if they are opened in a new window :-P I use tabs to hold
> sets of related files (which I store in sessions), and when I double-
> click a file it's not related to an existing window, so I want a new
> one. Plus, that's how nearly all mac apps work...
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> There have been a few request (already) that new files open in tabs
> instead of in a new window for MacVim, so I will change the current
> behaviour so that new files ( i.e. dragged onto dock icon, "Open
> with...") will open in tabs in the current window.

I prefer if they are opened in a new window :-P I use tabs to hold
sets of related files (which I store in sessions), and when I double-
click a file it's not related to an existing window, so I want a new
one. Plus, that's how nearly all mac apps work...


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

björn wrote:
>     :q on the last buffer closes the window and not the app? Is that
>     intentional?
>
>
> This is expected (Apple) behaviour for apps with multiple windows (e.g.
> see what happens when you close the last window in Safari).
>
> The thing that is confusing is that the application you are running is
> MacVim (the GUI) and not Vim, which is just a process associated with
> one of MacVim's windows.  When you type :q, you are telling Vim to quit,
> but to MacVim this only means "close the window".  To me this is not so
> much of an issue, since I am used to hitting <D-q> to close apps on a
> Mac anyway, but if you are coming from another OS this might seem weird.
>

Yes, it seems wierd since the carbon gvim closes with :q the last
window. Isn't that the "expected" vim behavior though? Is the object to
Macify Vim on OSX?

Robert


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---