Oh, certainly. If you mean "!open -a <weapon-of-choice>" as better
than e.g. ":maca raiseTerminal:" + config option?

I was more thinking of whether there are common cases of invoking
MacVim for one-offs, where providing a generic method of switching
back to the previous app would be useful (well, preferably the
invoking app, but I don't know how to track that).

(As admitted though, I don't really work like that myself today.)

Best regards,
Niklas


On Wed, Feb 4, 2009 at 11:16 PM, Gregory Seidman
<gsslist+vim@...> wrote:
>
> Seems like overkill. How about !open -a Terminal
>
> --Greg
>
> On Wed, Feb 04, 2009 at 11:01:59PM +0100, Niklas Lindstr?m wrote:
>>
>> Hi!
>>
>> Personally I work like that very rarely (although with a switch like
>> this I'd consider practicing it a bit more). I wonder if a macaction
>> for Command-Tab might do?
>>
>> Say :maca switchApp:?
>>
>> Manual version:
>>
>>     !osascript -e 'tell application "System Events"' -e 'keystroke tab
>> using command down' -e 'end tell'
>>
>> (Autocommand:ed with VimLeave, or VimLeavePre if the last vim closes MacVim.)
>>
>> (Hm.. This might be very useful for stuff like "It's All Text" as well..)
>>
>> Best regards,
>> Niklas
>>
>>
>> On Wed, Feb 4, 2009 at 10:15 PM, bj?rn <bjorn.winckler@...> wrote:
>> >
>> > Hi,
>> >
>> > Here's a general situation that I run into all the time:  I'm in
>> > Terminal and type 'mvim' to open a file to make one small change and
>> > then close it again.  When I close the window I need to manually
>> > switch back to Terminal with Cmd-Tab even though the Terminal window
>> > is layered right under the MacVim window I just closed (Mac OS X will
>> > raise another MacVim window even if it is layered below the Terminal
>> > window, which I guess is the correct behavior for most programs but in
>> > this instance it is a nuisance).
>> >
>> > I've been searching for a way to figure out which app the window under
>> > the topmost MacVim window belongs to and then switch to the app that
>> > owns that window when I close my MacVim window, but I cannot find any
>> > way of doing this.  So, I came up with another (not very elegant)
>> > idea: add an action called "raiseTerminal:" and call that when the
>> > window closes by starting MacVim like this:
>> >
>> >        mvim -f -c "au VimLeave * maca raiseTerminal:"
>> >
>> > (I am already doing this more or less, but I call "hide:" instead but
>> > it is kind of annoying if there are other MacVim windows open as they
>> > will be hidden.  By the way, the above command (with "hide:") is what
>> > I set my EDITOR environment variable to so that MacVim pops up when I
>> > edit Git commit messages.)
>> >
>> > An obvious extension the above idea is to add a user default so that
>> > you may choose which app "raiseTerminal:" actually will raise (e.g.
>> > iTerm).
>> >
>> > Does anybody have any better ideas on how to deal with this problem?
>> > Would anybody find the above functionality useful (I would use it all
>> > the time with EDITOR).
>> >
>> > Bj?rn
>> >
>> > >
>> >
>>
>> >
>>
>
> >
>

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

> Hmmm...it only happens if MacVim forks; i.e. if you start with "mvim
> -f path/filename" then everything works fine.
>
> Does anybody have any ideas why forking would cause this (Nico,
> Ben, ...?).

I haven't tested this, but I guess this is what happens:

1.) Vim starts up, parses vimrc (and sets autochdir)
2.) Vim changes the current directory because of autochdir
3.) Vim forks, which basically kills vim and restarts it as a child
process
4.) The child process inherits the (changed) current directory
5.) During child startup, vim tries to open the relative path
6.) Since the current directory has changed, the relative path is not
resolved correctly

The best fix I can think of is to store the original directory during
vim startup chdir() back to that in the child process before calling
exec(). Any better suggestions?

Nico

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

Hi,

I started profiling MacVim's drawing/regex code. I made the
interesting discovery that 'cursorline' can have a large impact on
drawing time. So if MacVim's draws very slowly for you, `:set
nocursorline` might make it faster for you for now. That's probably a
better workaround than a full `:syntax off`.

Hope this helps someone,
Nico

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

>> Yes, I see the same behaviour on one machine but it works fine on
>> another.  Where it works, I built MacVim myself.  Where it doesn't,
>> I'm using the official pre-built snapshot 42.  I'm not suggesting a
>> correlation, just an observation.  Both machines are Intel with
>> 10.5.6.
>>
>> [... trying a build ...]
>>
>> I just built MacVim on the machine where it doesn't work and the "new
>> window on activation" still doesn't work.  This suggests some other
>> setting must be causing the failure.
>
> Michael, thanks for confirming the problem.
>
> Are you using identical .[g]vimrc files on both machines?  Does the
> problem persist if these (and the .vim folder) are moved out of the
> way?  Is the problem intermittent or does it fail to open a new window
> _every_ time MacVim is reactivated?  (Tiago: can you answer these
> questions as well please.)

Yes, my configuration is identical across all machines that I use.  I
use git to hold my configuration/dotfiles and the repo is hosted on
Amazon S3; so all my machines are easily synchronised.

Unfortunately, the problem still occurs (each and every time) even
when ~/.[g]vimrc and ~/.vim are removed.  Something else appears
responsible for this problem.

Personally, this bug doesn't bother me so much.  I tend to keep a
single vim window up all the time... and it never closes.

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

> The attached patch grabs the font file through curl and then loads the
> font from the ttf file. I tried to fix the tiger build problems too; I
> hope that worked out.

This patch has now been merged.

I pulled the latest version from the repo today on a machine that had
both python 2.4 and 2.5 installed, and for some reason the loadfont
module was compiled with 2.4 but the script executed with 2.5, which
resulted in a crash.

The attached patch makes compilation of the loadfont module more
portable. I first added a few additional parameters to the gcc
invocation in the makefile, but that will probably cause other
problems in the future. Instead, the patch now uses python's
distutils, which is the recommended way to build C extensions for
python. With this patch, the crash went away and the icons were
generated correctly.

Nico


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

Hi All,

My much loved MacVim started crashing on startup today. Everytime I
start it I get a "The application Vim has unexpectedly Quit.... Ignore/
Report.../Relaunch" dialogue.

In the console I'm getting the error message:

6/02/09 2:52:43 PM [0x0-0x225f25d].org.vim.MacVim[31513] dyld: Library
not loaded: /usr/lib/libruby.1.dylib
6/02/09 2:52:43 PM [0x0-0x225f25d].org.vim.MacVim[31513]   Referenced
from: /Applications/MacVim.app/Contents/MacOS/Vim
6/02/09 2:52:43 PM [0x0-0x225f25d].org.vim.MacVim[31513]   Reason:
image not found

I had recently removed the /Library/Ruby, and /System/Library/
Ruby.framework folders in order to resolve a conflict I was having
(see
http://blog.carlmercier.com/2007/12/14/how-to-fix-that-rubygems-mess-on-leopard/
for the bigger picture if you're interested). I've since restored
these folders but the problem persists.

Other things I've tried include:

* tried reinstalling both the stable, and snapshot releases of macvim
* tried removing my ~/Library/Preferences
* tried removing my ~/.vim* config files

This is on a newer Intel silver Imac running OS X 10.5.6.

Any help anyone could provide would be greatly appreciated as I'm
really missing MacVim (stuck using vim in the terminal till i get this
fixed)

Cheers,
Toby

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

> I had recently removed the /Library/Ruby, and /System/Library/
> Ruby.framework folders in order to resolve a conflict I was having

Removing system frameworks and libraries is always a bad idea :-)

>
What is the output of `otool -L /Applications/MacVim.app/Contents/
MacOS/Vim` and `otool -L /Applications/MacVim.app/Contents/MacOS/
MacVim` on your machine?

Nico

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

Hi Nico,

On Feb 6, 3:37 pm, Nico Weber <nicolaswe...@...> wrote:
> Removing system frameworks and libraries is always a bad idea :-)

I'm beginning to think you might be onto something there :)

Incedently, it did fix my problem, and I've not had any other issues.
I just figured that it might be related due to the reference to /usr/
lib/libruby.1.dylib in the console. Also- I restored the two folders
I'd removed and the problem persists...

One thing I also did which I havn't undone was replacing /usr/bin/ruby
with a symlink to my /usr/local/bin/ruby, I'll put the original back
and see.

> What is the output of `otool -L /Applications/MacVim.app/Contents/
> MacOS/Vim` and `otool -L /Applications/MacVim.app/Contents/MacOS/
> MacVim` on your machine?

$ otool -L /Applications/MacVim.app/Contents/MacOS/Vim
/Applications/MacVim.app/Contents/MacOS/Vim:
	 /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 11.0.0)
	 /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 128.0.0)
	 /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
version 5.4.0)
	 /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current
version 5.0.0)
	 /System/Library/Frameworks/Python.framework/Versions/2.3/Python
(compatibility version 2.3.0, current version 2.3.5)
	 /usr/lib/libruby.1.dylib (compatibility version 1.8.0, current
version 1.8.2)
	 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.10)
	 /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
	 /System/Library/Frameworks/CoreServices.framework/Versions/A/
CoreServices (compatibility version 1.0.0, current version 18.0.0)
	 /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
version 227.0.0)
	 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation (compatibility version 150.0.0, current version
368.33.0)
	 /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 824.47.0)
	 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/
ApplicationServices (compatibility version 1.0.0, current version
22.0.0)
	 /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
(compatibility version 300.0.0, current version 567.37.0)


Cheers,
Toby

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

Toby,

On 05.02.2009, at 20:51, Toby wrote:

>> What is the output of `otool -L /Applications/MacVim.app/Contents/
>> MacOS/Vim` and `otool -L /Applications/MacVim.app/Contents/MacOS/
>> MacVim` on your machine?
>
> $ otool -L /Applications/MacVim.app/Contents/MacOS/Vim
> /Applications/MacVim.app/Contents/MacOS/Vim:
>  /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> (compatibility version 1.0.0, current version 11.0.0)
>  /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> (compatibility version 2.0.0, current version 128.0.0)
>  /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
> version 5.4.0)
>  /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current
> version 5.0.0)
>  /System/Library/Frameworks/Python.framework/Versions/2.3/Python
> (compatibility version 2.3.0, current version 2.3.5)
>  /usr/lib/libruby.1.dylib (compatibility version 1.8.0, current
> version 1.8.2)

What's the output of `ls -l /usr/lib/libruby.1.dylib`? On my system,
it's

      $ ls -l /usr/lib/libruby.1.dylib
      lrwxr-xr-x  1 root  wheel  87  1 Nov  2007 /usr/lib/libruby.
1.dylib -> ../../System/Library/Frameworks/Ruby.framework/Versions/
Current/usr/lib/libruby.1.dylib

That is, on my system it's a symlink to the system's ruby. Perhaps you
only have to recreate this symlink like this:

      $ cd /usr/lib
      $ sudo rm libruby.1.dylib # move old one out of the way
      $ sudo ln -s ../../System/Library/Frameworks/Ruby.framework/
Versions/Current/usr/lib/libruby.1.dylib libruby.1.dylib

Does that help?

Nico

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

Nico,

It worked!- I owe you one :)

I recreated that symlink and everything is hunky dory and I can use
MacVim again.

So the moral of this story is if you're a Ruby developer who uses
MacVim, _don't_ remove /System/Library/Frameworks/Ruby.framework.

You can remove /Library/Ruby, and point /usr/bin/ruby etc at your
local version. Just leave the Framework there and MacVim is happy, and
no issues with conflicting ruby versions either.

Thanks again Nico!

Cheers,
Toby

On Feb 6, 4:30 pm, Nico Weber <nicolaswe...@...> wrote:
> Toby,
>
> On 05.02.2009, at 20:51, Toby wrote:
>
>
>
> >> What is the output of `otool -L /Applications/MacVim.app/Contents/
> >> MacOS/Vim` and `otool -L /Applications/MacVim.app/Contents/MacOS/
> >> MacVim` on your machine?
>
> > $ otool -L /Applications/MacVim.app/Contents/MacOS/Vim
> > /Applications/MacVim.app/Contents/MacOS/Vim:
> >    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
> > (compatibility version 1.0.0, current version 11.0.0)
> >    /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
> > (compatibility version 2.0.0, current version 128.0.0)
> >    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
> > version 5.4.0)
> >    /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current
> > version 5.0.0)
> >    /System/Library/Frameworks/Python.framework/Versions/2.3/Python
> > (compatibility version 2.3.0, current version 2.3.5)
> >    /usr/lib/libruby.1.dylib (compatibility version 1.8.0, current
> > version 1.8.2)
>
> What's the output of `ls -l /usr/lib/libruby.1.dylib`? On my system,  
> it's
>
>      $ ls -l /usr/lib/libruby.1.dylib
>      lrwxr-xr-x  1 root  wheel  87  1 Nov  2007 /usr/lib/libruby.
> 1.dylib -> ../../System/Library/Frameworks/Ruby.framework/Versions/
> Current/usr/lib/libruby.1.dylib
>
> That is, on my system it's a symlink to the system's ruby. Perhaps you  
> only have to recreate this symlink like this:
>
>      $ cd /usr/lib
>      $ sudo rm libruby.1.dylib # move old one out of the way
>      $ sudo ln -s ../../System/Library/Frameworks/Ruby.framework/
> Versions/Current/usr/lib/libruby.1.dylib libruby.1.dylib
>
> Does that help?
>
> Nico
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

While surfing for something else I tripped over http://ohlogh.net
For grins I submitted macvim - the resulting report is interesting -
http://www.ohloh.net/p/macvim/analyses/latest

Brian

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

Niklas Lindström wrote:
> I wonder if a macaction for Command-Tab might do?

This is a nice idea.

The window under the topmost MacVim windows clearly belongs to the
second most recently used app, which is the first choice doing a
single Cmd-Tab.

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

On Feb 6, 2009, at 12:00 AM, Toby wrote:

>
> So the moral of this story is if you're a Ruby developer who uses
> MacVim, _don't_ remove /System/Library/Frameworks/Ruby.framework.
>
> You can remove /Library/Ruby, and point /usr/bin/ruby etc at your
> local version. Just leave the Framework there and MacVim is happy, and
> no issues with conflicting ruby versions either.
>

Just throwing in some unsolicited advice here, but You're Doing It All
Wrong™.  Stuff in /usr/bin and *especially* /System is for the system
and the system alone.  Your custom symlink will quite likely be
overwritten in a future software update.  MacVim isn't the only thing
that will break when removing the system ruby framework.

The correct way to install a custom ruby is to put it in /usr/local
or /opt/local—as you have—and then put /usr/local/bin in your PATH
before /usr/bin.  Then your custom version will be the one found by
default when you run ruby, but nothing that relies on the system
version in /usr/bin or /System will break.

Don't fight the system, and it won't fight you :)


Jason

2009/2/6 Nico Weber:
>> The attached patch grabs the font file through curl and then loads the
>> font from the ttf file. I tried to fix the tiger build problems too; I
>> hope that worked out.
>
> This patch has now been merged.
>
> I pulled the latest version from the repo today on a machine that had
> both python 2.4 and 2.5 installed, and for some reason the loadfont
> module was compiled with 2.4 but the script executed with 2.5, which
> resulted in a crash.
>
> The attached patch makes compilation of the loadfont module more
> portable. I first added a few additional parameters to the gcc
> invocation in the makefile, but that will probably cause other
> problems in the future. Instead, the patch now uses python's
> distutils, which is the recommended way to build C extensions for
> python. With this patch, the crash went away and the icons were
> generated correctly.

Thanks Nico, I've merged this patch.  I did notice one _very_ minor
thing: if you type make twice in a row, then the second (and any
consequtive calls to) "make" will unpack the font zip file again.  Any
idea why this is?

Björn

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

> Thanks Nico, I've merged this patch.  I did notice one _very_ minor
> thing: if you type make twice in a row, then the second (and any
> consequtive calls to) "make" will unpack the font zip file again.  Any
> idea why this is?

No idea. (couple minutes pass) This is because `unzip` uses the file
modification date from the zip file, see:

$ ls -l Envy*
-rw-r--r--  1 thakis  eng   83856 May 26  2008 Envy Code R Bold.ttf
-rw-r--r--  1 thakis  eng  172849 Feb  5 10:30 EnvyCodeR.zip

Hence, make thinks the zip file is newer than the ttf file and unpacks
it again. I can't find a flag that tells unzip to set the extraction
date on the files it creates, but the patch of this mail works around
the problem.

Nico

ps: Not a real patch; group's web interface doesn't support
attachments:

--- a/src/MacVim/icons/Makefile
+++ b/src/MacVim/icons/Makefile
@@ -11,6 +11,9 @@ loadfont.so: loadfont.c

  Envy\ Code\ R\ Bold.ttf: EnvyCodeR.zip
         unzip -jo EnvyCodeR.zip
+       # unzip uses the file date from the zip file. Change the file
date to
+       # "now", so that the zip is not unzipped in every `make` run.`
+       touch Envy\ Code\ R\ Bold.ttf

  ENVYCODE_URL=http://download.damieng.com/latest/EnvyCodeR
  EnvyCodeR.zip:


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

2009/2/6 Nico Weber:
>
>> Thanks Nico, I've merged this patch.  I did notice one _very_ minor
>> thing: if you type make twice in a row, then the second (and any
>> consequtive calls to) "make" will unpack the font zip file again.  Any
>> idea why this is?
>
> No idea. (couple minutes pass) This is because `unzip` uses the file
> modification date from the zip file, see:

Thanks, I have merged and pushed the patch.

Björn

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

I apologize in advance if this question has been discussed prior
(quick google search provided no hits). When Vim starts on my mac
(double clicking the Vim.app icon) Instead  of the usual :intro being
shown and it editing a blank document it displays a continue prompt
and then shows the netrw for my home directory.

Is it possible to return the :intro and edit blank document
functionality? Perhaps I can edit the source and make a custom patch
for myself. Does anyone know where to start looking for this or is
this an artifact of the mac port?

Thanks for the ideas.

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

Hi Sukima,

which Vim.app are you using? I'm using MacVim.app from
http://code.google.com/p/macvim/
, which shows :intro just as usual (the other Vim.apps that I know do
that as well, even though I haven't tried them in a while).

Does this still happen if you temporarily rename your ~/_vimrc, your ~/
_gvimrc, and your ~/.vim directory?

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

2009/2/6 Tobia Conforto <tobia.conforto@...>:
>
> Niklas Lindström wrote:
>> I wonder if a macaction for Command-Tab might do?
>
> This is a nice idea.
>
> The window under the topmost MacVim windows clearly belongs to the
> second most recently used app, which is the first choice doing a
> single Cmd-Tab.

Yes, Niklas' idea is certainly better than my "switch to terminal"
idea.  Of course, Greg is right when he said its overkill to implement
this as an action in MacVim when it can already be done with the
"open" command (I didn't think of that).

As long as there is no advantage to implementing this functionality in
MacVim (since it can already be achieved with applescript etc) I will
just let it rest.

Thanks,
Björn

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

2009/2/5 Nico Weber:
>
>> Hmmm...it only happens if MacVim forks; i.e. if you start with "mvim
>> -f path/filename" then everything works fine.
>>
>> Does anybody have any ideas why forking would cause this (Nico,
>> Ben, ...?).
>
> I haven't tested this, but I guess this is what happens:
>
> 1.) Vim starts up, parses vimrc (and sets autochdir)
> 2.) Vim changes the current directory because of autochdir
> 3.) Vim forks, which basically kills vim and restarts it as a child
> process
> 4.) The child process inherits the (changed) current directory
> 5.) During child startup, vim tries to open the relative path
> 6.) Since the current directory has changed, the relative path is not
> resolved correctly

Yes, that must be what is happening.

> The best fix I can think of is to store the original directory during
> vim startup chdir() back to that in the child process before calling
> exec(). Any better suggestions?

This sounds a bit too hacked together, but the only other solution I
can think of is to fork earlier.

At the moment (as far as I can understand) we only fork after reading
the rc-files because a user may add "f" to 'guioptions'.  Now, my
question is: does anybody really _need_ this functionality?  If we
crippled this option we could fork right after parsing the command
line arguments and it would fix the above problems and potentially
others (that we do not yet know about) as well.  Another side-effect
of this is that we don't have to perform initializations twice which
would cut down on startup times.

I would be much more comfortable with this solution.  Comments?

Björn

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

On Feb 7, 7:37 am, björn <bjorn.winck...@...> wrote:
> At the moment (as far as I can understand) we only fork after reading
> the rc-files because a user may add "f" to 'guioptions'.  Now, my
> question is: does anybody really _need_ this functionality?  If we
> crippled this option we could fork right after parsing the command
> line arguments and it would fix the above problems and potentially
> others (that we do not yet know about) as well.  Another side-effect
> of this is that we don't have to perform initializations twice which
> would cut down on startup times.
>
> I would be much more comfortable with this solution.  Comments?

I can't speak for anyone but myself, but I could do without the -f
option (or guioptions=f). In the situation where I *would* use this
feature, when writing a commit message for git or svn, I simply use
vim in the command line, rather than MacVim. But I imagine some people
may use MacVim in this situation, or for writing email messages, maybe
they will weigh in if this is the case.

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

Hi,

Am 09.02.2009 um 17:03 schrieb alexanderkahn:

>
> On Feb 7, 7:37 am, björn <bjorn.winck...@...> wrote:
>> At the moment (as far as I can understand) we only fork after reading
>> the rc-files because a user may add "f" to 'guioptions'.  Now, my
>> question is: does anybody really _need_ this functionality?  If we
>> crippled this option we could fork right after parsing the command
>> line arguments and it would fix the above problems and potentially
>> others (that we do not yet know about) as well.  Another side-effect
>> of this is that we don't have to perform initializations twice which
>> would cut down on startup times.
>>
>> I would be much more comfortable with this solution.  Comments?
>
> I can't speak for anyone but myself, but I could do without the -f
> option (or guioptions=f). In the situation where I *would* use this
> feature, when writing a commit message for git or svn, I simply use
> vim in the command line, rather than MacVim. But I imagine some people
> may use MacVim in this situation, or for writing email messages, maybe
> they will weigh in if this is the case.
I for one use this option on a daily basis, in fact my EDITOR variable
is set to
'mvim -f'.

Greetings,
Holger


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

2009/2/9 Holger Rapp:
>
> Am 09.02.2009 um 17:03 schrieb alexanderkahn:
>
>> On Feb 7, 7:37 am, björn wrote:
>>> At the moment (as far as I can understand) we only fork after reading
>>> the rc-files because a user may add "f" to 'guioptions'.  Now, my
>>> question is: does anybody really _need_ this functionality?  If we
>>> crippled this option we could fork right after parsing the command
>>> line arguments and it would fix the above problems and potentially
>>> others (that we do not yet know about) as well.  Another side-effect
>>> of this is that we don't have to perform initializations twice which
>>> would cut down on startup times.
>>>
>>> I would be much more comfortable with this solution.  Comments?
>>
>> I can't speak for anyone but myself, but I could do without the -f
>> option (or guioptions=f). In the situation where I *would* use this
>> feature, when writing a commit message for git or svn, I simply use
>> vim in the command line, rather than MacVim. But I imagine some people
>> may use MacVim in this situation, or for writing email messages, maybe
>> they will weigh in if this is the case.
> I for one use this option on a daily basis, in fact my EDITOR variable
> is set to
> 'mvim -f'.

Ok, hold on for a moment here.  I suggested deprecating "f" in
'guioptions' ONLY.  It will still be possible to pass the "-f" flag on
the command line!!!  (I would assume _lots_ of people use this flag.)

Björn

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

> Ok, hold on for a moment here.  I suggested deprecating "f" in
> 'guioptions' ONLY.  It will still be possible to pass the "-f" flag on
> the command line!!!  (I would assume _lots_ of people use this flag.)
Alright, misunderstood you here. I wasn't aware of this feature and I
agree
that it seems pretty useless. I would guess that forking is done for
mvim even
before the vim process is spawned... However, I also could do without
this in
guioptions.

Greetings,
Holger


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

> > The best fix I can think of is to store the original directory during
> > vim startup chdir() back to that in the child process before calling
> > exec(). Any better suggestions?
>
> This sounds a bit too hacked together, but the only other solution I
> can think of is to fork earlier.
>
> At the moment (as far as I can understand) we only fork after reading
> the rc-files because a user may add "f" to 'guioptions'.  Now, my
> question is: does anybody really _need_ this functionality?  If we
> crippled this option we could fork right after parsing the command
> line arguments and it would fix the above problems and potentially
> others (that we do not yet know about) as well.  Another side-effect
> of this is that we don't have to perform initializations twice which
> would cut down on startup times.
>
> I would be much more comfortable with this solution.  Comments?

Here's what I wrote a year ago on this subject:
http://groups.google.com/group/vim_mac/browse_thread/thread/9fcc068f20e82942/b00\
9aced253e89ad

In short, forking earlier has its problems too. You probably don't
want to do command line flag handling yourself (so that things like "-
gf" vs "-fg" and "-f" after "--remote" etc are handled correctly). But
vim might already modify the environment when parsing command line
flags, so parts of the environment might need to be restored even if
forking earlier.

To me, this sound like trading one can of worms for another.

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

2009/2/9 Nico Weber:
>
>> > The best fix I can think of is to store the original directory during
>> > vim startup chdir() back to that in the child process before calling
>> > exec(). Any better suggestions?
>>
>> This sounds a bit too hacked together, but the only other solution I
>> can think of is to fork earlier.
>>
>> At the moment (as far as I can understand) we only fork after reading
>> the rc-files because a user may add "f" to 'guioptions'.  Now, my
>> question is: does anybody really _need_ this functionality?  If we
>> crippled this option we could fork right after parsing the command
>> line arguments and it would fix the above problems and potentially
>> others (that we do not yet know about) as well.  Another side-effect
>> of this is that we don't have to perform initializations twice which
>> would cut down on startup times.
>>
>> I would be much more comfortable with this solution.  Comments?
>
> Here's what I wrote a year ago on this subject:
>
http://groups.google.com/group/vim_mac/browse_thread/thread/9fcc068f20e82942/b00\
9aced253e89ad
>
> In short, forking earlier has its problems too. You probably don't
> want to do command line flag handling yourself (so that things like "-
> gf" vs "-fg" and "-f" after "--remote" etc are handled correctly). But
> vim might already modify the environment when parsing command line
> flags, so parts of the environment might need to be restored even if
> forking earlier.
>
> To me, this sound like trading one can of worms for another.

Hmmm...let me be a bit more precise:  I suggest forking right after
command_line_scan().  This way we don't need to parse any command line
flags ourselves.  Isn't this easier than fixing every problem such as
the one with 'autochdir' each time they pop up?

What parts of the environment may have changed before that?  I had a
quick look but couldn't see any problems.

Sure this may be "trading one can of worms for another", but I would
like to understand the two alternatives better than I do now so that I
can make up my own mind as to which is the lesser of the two evils.
Also, it seems we now have new problems (i.e. 'autochdir') that we
were unaware of when you wrote that other post regarding forking.

Thanks,
Björn

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

> Hmmm...let me be a bit more precise:  I suggest forking right after
> command_line_scan().  This way we don't need to parse any command line
> flags ourselves.

I agree, this looks like a good place to do this. For some reason, I
had assumed that vim executes the commandline flags as it parses them
(e.g. -c 'cd otherdir'), but that's not true.

Nico

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

2009/2/10 Nico Weber:
>
>> Hmmm...let me be a bit more precise:  I suggest forking right after
>> command_line_scan().  This way we don't need to parse any command line
>> flags ourselves.
>
> I agree, this looks like a good place to do this. For some reason, I
> had assumed that vim executes the commandline flags as it parses them
> (e.g. -c 'cd otherdir'), but that's not true.

Nico, I prepared a patch but I'd appreciate it if you'd look over it
before I merge.  In particular, I got rid of prepare_getout() since
Vim hasn't even initialized by the time we fork now.  Still, there is
some allocation of structures going on before we fork...do you think
any of this needs to be "undone" before forking?  Somehow it seems
"safer" to just lets things be, but I'm not at all sure about this.
(Patches 1 and 2 are the interesting ones.)

Anybody else wishing to evaluate these patches are of course also
welcome to chime in.  I haven't tested them much myself yet so there
may very well be some glaring bugs in there!

As for startup times: with these patches startup is another 200ms or
so faster on my machine (its down to about .5s now).  Nothing
revolutionary, but I do notice the difference.  Opening a window with
Cmd-n or with 'mvim' should be equally fast now.

Björn

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

Hi,

I think this would be very handy when using split windows.

Thanks for MacVim!

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

Hi,

On 10.02.2009, at 17:12, Pedro Borges wrote:

> I think this would be very handy when using split windows.

I'm not entirely sure what you're asking for, bug try doing `:set
fuopts=maxhorz` before entering fullscreen mode, and then enter
fullscreen mode. Does that do what you want?

Nico

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