MacVim.app snapshot r164 available for download

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

MacVim.app snapshot r164 available for download

Björn Winckler
I have uploaded a new snapshot of MacVim to the usual place:

http://code.google.com/p/macvim/


The major changes this time around are:

- Added "gui_macvim" to "has" command so that you can check for MacVim in scripts by going 'if has('gui_macvim') ...' (suggestion by "screwtape")

- Fixed Ctrl-C and Ctrl-Y bugs (fixing issue 5 and another ctrl bug reported by Jeremy Conlin)

- Ctrl-C and Cmd-. sends SIGINT to Vim

- Fixed Issue 7 (reported by "adambyrtek"): CSI bytes were not being detected

- Toolbar: fixed toolbar related bugs reported by Nico, also changed when the tabline separator is hidden/shown

- Command queue flushing has changed so that when Vim is busy processing stuff (like when loading session files) you get to see more of what is going on. (No more blank window for X seconds while Vim is working away.)

- Dialogs: Works with&without input fields.  I had a look at Jiang's GUI dialogs (thanks Jiang!) and did something similar, except dialogs with input fields still use (a variant) of NSAlert (it's a bit of a hack, but it works for now...I just wanted to maintain a unified look in the way alerts are presented).  In dialogs, enter selects the default button (the blue one), escape selects 'Cancel', all other buttons can usually be accessed by pressing the key corresponding to the first letter on the button (there is no visual feedback to indicate which key to press to activate a particular button...so you might have to experiment a bit).  It would be nice to be able to tab between buttons, but this seems not to be the "Mac OS X way".

- Warning when switching back to MacVim and a buffer has been modified outside of MacVim (fixing a bug reported by Jeremy Conlin a while back).  This support is still a bit flakey...it seems that you sometime have to press a key before the alert pops up (I will look into this).

- Now possible to scroll text by using track pad (or scroll wheel) over scrollbars (as suggested by Nico)

- "New Tab Containing Selection" services menu entry now also works if MacVim isn't already opened

- Termination changed:  Puts up an alert if a Vim process is unresponsive whilst terminating MacVim.  Also, when MacVim is really quitting, send SIGINT to all Vim processes so that they stop processing and quit (this may happen e.g. if the Vim process was running a very lengthy script).

- Various bugfixes, system gvim rc changes, etc.


Let me know how it works out for you.

/Björn

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Nico Weber-3

> - Dialogs: Works with&without input fields.  I had a look at  
> Jiang's GUI dialogs (thanks Jiang!) and did something similar,  
> except dialogs with input fields still use (a variant) of NSAlert  
> (it's a bit of a hack, but it works for now...I just wanted to  
> maintain a unified look in the way alerts are presented).  In  
> dialogs, enter selects the default button (the blue one), escape  
> selects 'Cancel', all other buttons can usually be accessed by  
> pressing the key corresponding to the first letter on the button  
> (there is no visual feedback to indicate which key to press to  
> activate a particular button...so you might have to experiment a  
> bit).  It would be nice to be able to tab between buttons, but this  
> seems not to be the "Mac OS X way".

Nice. If you enable "full keyboard access" (System preferences,  
Keyboard & Mouse, Keyboard Shortcuts tab, at the bottom -- or simply  
hit Ctrl-F7), you can use Tab to cycle through buttons and hit space  
to activate the current button. This works nicely in MacVim with the  
new dialogs, and doesn't work in old carbon vim. The "first letter"  
thing is a bit strange, but I guess hardcore vimmers will like it ;-)

Very nice work with the dialogs :-) (I guess this mainly goes to  
Jigod... :-) ).

> - Now possible to scroll text by using track pad (or scroll wheel)  
> over scrollbars (as suggested by Nico)

Thanks :-)

> Let me know how it works out for you.

I found no obvious problems at least :-) I'll tell you if I find some  
(Nit: Cursor doesn't change to a "resize" cursor if it's over a  
window marker as introduced by ":vsplit" for example. carbon vim  
doesn't do this either, but it keeps the normal arrow cursor and  
doesn't use an ibeam cursor. Resizing text windows with an ibeam  
cursor feels really strange).

That doesn't mean it has no problems: I can reproduce the "mvim -d  
file1 file2" hang again, and it still screws up the finder (as  
described previously). I'll try to debug that during the next two days.

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Björn Winckler

> - Dialogs: Works with&without input fields.  I had a look at
> Jiang's GUI dialogs (thanks Jiang!) and did something similar,
> except dialogs with input fields still use (a variant) of NSAlert
> (it's a bit of a hack, but it works for now...I just wanted to
> maintain a unified look in the way alerts are presented).  In
> dialogs, enter selects the default button (the blue one), escape
> selects 'Cancel', all other buttons can usually be accessed by
> pressing the key corresponding to the first letter on the button
> (there is no visual feedback to indicate which key to press to
> activate a particular button...so you might have to experiment a
> bit).  It would be nice to be able to tab between buttons, but this
> seems not to be the "Mac OS X way".

Nice. If you enable "full keyboard access" (System preferences,
Keyboard & Mouse, Keyboard Shortcuts tab, at the bottom -- or simply
hit Ctrl-F7), you can use Tab to cycle through buttons and hit space
to activate the current button. This works nicely in MacVim with the
new dialogs, and doesn't work in old carbon vim. The "first letter"
thing is a bit strange, but I guess hardcore vimmers will like it ;-)

Aha!  I saw some reference to this "keyboard access" stuff but for some reason I couldn't figure it out...thanks for pointing out how to use it.


> Let me know how it works out for you.

I found no obvious problems at least :-) I'll tell you if I find some
(Nit: Cursor doesn't change to a "resize" cursor if it's over a
window marker as introduced by ":vsplit" for example. carbon vim
doesn't do this either, but it keeps the normal arrow cursor and
doesn't use an ibeam cursor. Resizing text windows with an ibeam
cursor feels really strange).

I agree, the Ibeam is not very nice.  To implement multiple cursor support in a straight forward way (as far as I could figure out) you need to forward all "mouse moved" events to Vim and these are disabled by default in Cocoa (for a good reason, I suppose).  Anyway, I have done this once before so I will look into adding this functionality back.

That doesn't mean it has no problems: I can reproduce the "mvim -d
file1 file2" hang again, and it still screws up the finder (as
described previously). I'll try to debug that during the next two days.

I would appreciate any help with debugging these issues...I still have not been able to reproduce either of them yet.


/Björn

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Niklas Lindström
In reply to this post by Björn Winckler

Hello Björn (and contributors),

great fixes as usual; thank you.


> - Command queue flushing has changed so that when Vim is busy processing
> stuff (like when loading session files) you get to see more of what is going
> on. (No more blank window for X seconds while Vim is working away.)

There seems to be a new bug with this release though. It occurs when I
source larger session files. The effect is that loading slows down
almost to a halt, and the entire MacVim app beachballs most of the
time. Some things do happen, so after a long while the session will be
loaded. No MacVim window is noticeably responsive though (if I have
several vims running - the bug does occur even if using only one), and
the beachballing continues. <D-Q> doesn't work, neither does e.g.
<D-S-W>. I have to force quit eventually.

I there may be better ways to reproduce it, but a simple way is to do
the following.

First, I moved aside all my .*vim*-files to see if they affected this.
They did, and it seems it boiled down to doing:

    set columns=108
    set lines=76

So, move aside .vimrc, .gvimrc and .vim, then create an empty .vimrc with only:

    set columns=108
    set lines=76

in it. Then:

    1. edit some file, say .vimrc (a new, named empty buffer won't do)
    2. split the buffer vertically (:vsplit) (horizontally doesn't
seem to be enough)
    3. create a new tab and repeat step one and two.
    4. repeat step 3 a number of times (about 8-10 tabs is enough for
me - no less will do)
        -- record this as a macro for comfort.. ;)
    4. ":mksession" a session file and quit (the vim or MacVim, it
doesn't matter)
    5. ":source" the session, and the slowdown occurs almost immediately

My *guess* is that it may have to do with queue flushing, but it's
just a hunch (and trying to revert that part (flush/flushQueue) to the
code in 129 didn't seem to work - but I don't really know what I'm
doing ;) ).

Also note that running the Vim executable (i.e. in terminal mode) does
not trigger this bug. Loading a big session file works. And running
":gui" opens the resulting set in MacVim gui mode, fully working.

I'll gladly test any patches or new checkins, if time permits.

Best regards,
Niklas

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Niklas Lindström

Hi again,

.. just for clarity: it doesn't seem to matter when or how the window
is resized - it is enough to drag it to a bigger size or set them
manually after startup. The bug will appear in either case.

(So a "workaround" for the moment can be to not resize until after
sessions are loaded. Not sure how stable things will be then though.
I'll try this for a while.)

Best regards,
Niklas


On 8/20/07, Niklas Lindström <[hidden email]> wrote:

> Hello Björn (and contributors),
>
> great fixes as usual; thank you.
>
>
> > - Command queue flushing has changed so that when Vim is busy processing
> > stuff (like when loading session files) you get to see more of what is going
> > on. (No more blank window for X seconds while Vim is working away.)
>
> There seems to be a new bug with this release though. It occurs when I
> source larger session files. The effect is that loading slows down
> almost to a halt, and the entire MacVim app beachballs most of the
> time. Some things do happen, so after a long while the session will be
> loaded. No MacVim window is noticeably responsive though (if I have
> several vims running - the bug does occur even if using only one), and
> the beachballing continues. <D-Q> doesn't work, neither does e.g.
> <D-S-W>. I have to force quit eventually.
>
> I there may be better ways to reproduce it, but a simple way is to do
> the following.
>
> First, I moved aside all my .*vim*-files to see if they affected this.
> They did, and it seems it boiled down to doing:
>
>     set columns=108
>     set lines=76
>
> So, move aside .vimrc, .gvimrc and .vim, then create an empty .vimrc with only:
>
>     set columns=108
>     set lines=76
>
> in it. Then:
>
>     1. edit some file, say .vimrc (a new, named empty buffer won't do)
>     2. split the buffer vertically (:vsplit) (horizontally doesn't
> seem to be enough)
>     3. create a new tab and repeat step one and two.
>     4. repeat step 3 a number of times (about 8-10 tabs is enough for
> me - no less will do)
>         -- record this as a macro for comfort.. ;)
>     4. ":mksession" a session file and quit (the vim or MacVim, it
> doesn't matter)
>     5. ":source" the session, and the slowdown occurs almost immediately
>
> My *guess* is that it may have to do with queue flushing, but it's
> just a hunch (and trying to revert that part (flush/flushQueue) to the
> code in 129 didn't seem to work - but I don't really know what I'm
> doing ;) ).
>
> Also note that running the Vim executable (i.e. in terminal mode) does
> not trigger this bug. Loading a big session file works. And running
> ":gui" opens the resulting set in MacVim gui mode, fully working.
>
> I'll gladly test any patches or new checkins, if time permits.
>
> Best regards,
> Niklas
>

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Björn Winckler
In reply to this post by Niklas Lindström


> - Command queue flushing has changed so that when Vim is busy processing
> stuff (like when loading session files) you get to see more of what is going
> on. (No more blank window for X seconds while Vim is working away.)

There seems to be a new bug with this release though. It occurs when I
source larger session files. The effect is that loading slows down
almost to a halt, and the entire MacVim app beachballs most of the
time. Some things do happen, so after a long while the session will be
loaded. No MacVim window is noticeably responsive though (if I have
several vims running - the bug does occur even if using only one), and
the beachballing continues. <D-Q> doesn't work, neither does e.g.
<D-S-W>. I have to force quit eventually.

I there may be better ways to reproduce it, but a simple way is to do
the following.

First, I moved aside all my .*vim*-files to see if they affected this.
They did, and it seems it boiled down to doing:

    set columns=108
    set lines=76

So, move aside .vimrc, .gvimrc and .vim, then create an empty .vimrc with only:

    set columns=108
    set lines=76

in it. Then:

    1. edit some file, say .vimrc (a new, named empty buffer won't do)
    2. split the buffer vertically (:vsplit) (horizontally doesn't
seem to be enough)
    3. create a new tab and repeat step one and two.
    4. repeat step 3 a number of times (about 8-10 tabs is enough for
me - no less will do)
        -- record this as a macro for comfort.. ;)
    4. ":mksession" a session file and quit (the vim or MacVim, it
doesn't matter)
    5. ":source" the session, and the slowdown occurs almost immediately

My *guess* is that it may have to do with queue flushing, but it's
just a hunch (and trying to revert that part (flush/flushQueue) to the
code in 129 didn't seem to work - but I don't really know what I'm
doing ;) ).

Also note that running the Vim executable ( i.e. in terminal mode) does
not trigger this bug. Loading a big session file works. And running
":gui" opens the resulting set in MacVim gui mode, fully working.

I'll gladly test any patches or new checkins, if time permits.

Thank you for that very thorough report. :)

I will look into this, but if you want to try something yourself, then set MMFlushTimeoutInterval (in the beginning of MMBackend.m) to something much bigger (say 1 (the unit is seconds)).  If it is indeed related to queue flushing, then by making that constant big enough the behaviour should change.  Usually, when MacVim beachballs this means that the NSConnection buffers are filling up because too many DO calls are being made in quick succession.  Try to see what is happening in -[MMVimController sendMessage::] (add NSLog(@"%s%d", _cmd, msgid) in the beginning of that method)...if it is getting called a lot then you have found the problem.  (Remember that you have to 'make' whenever gui_macvim.m, MMBackend.m, or MacVim.m changes, all others are built by the Xcode project.)

Let me know if you figure anything out.  I will look at it myself when I get a chance.


/Björn

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Niklas Lindström

On 8/20/07, björn <[hidden email]> wrote:
>
> Thank you for that very thorough report. :)

No problems; glad to be of any help. ;)


> I will look into this, but if you want to try something yourself, then set
> MMFlushTimeoutInterval (in the beginning of MMBackend.m) to something much
> bigger (say 1 (the unit is seconds)).  If it is indeed related to queue
> flushing, then by making that constant big enough the behaviour should
> change.  Usually, when MacVim beachballs this means that the NSConnection
> buffers are filling up because too many DO calls are being made in quick
> succession.  Try to see what is happening in -[MMVimController
> sendMessage::] (add NSLog(@"%s%d", _cmd, msgid) in the beginning of that
> method)...if it is getting called a lot then you have found the problem.
> (Remember that you have to 'make' whenever gui_macvim.m, MMBackend.m, or
> MacVim.m changes, all others are built by the Xcode project.)
>
> Let me know if you figure anything out.  I will look at it myself when I get
> a chance.

Ah, running make as well.. I just rebuilt with XCode (*cough*). I had
tried changing MMFlushTimeoutInterval to 1.1f, but now I did it and
actually built it. ;D That did it!

Looking for a "threshold", it seems that 0.3f is enough (0.2f wasn't)
to make it work. I'll run with this and see how things fare.

Thanks for your quick reply!

Best regards,
Niklas

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Björn Winckler
> I will look into this, but if you want to try something yourself, then set

> MMFlushTimeoutInterval (in the beginning of MMBackend.m) to something much
> bigger (say 1 (the unit is seconds)).  If it is indeed related to queue
> flushing, then by making that constant big enough the behaviour should
> change.  Usually, when MacVim beachballs this means that the NSConnection
> buffers are filling up because too many DO calls are being made in quick
> succession.  Try to see what is happening in -[MMVimController
> sendMessage::] (add NSLog(@"%s%d", _cmd, msgid) in the beginning of that
> method)...if it is getting called a lot then you have found the problem.
> (Remember that you have to 'make' whenever gui_macvim.m, MMBackend.m, or
> MacVim.m changes, all others are built by the Xcode project.)
>
> Let me know if you figure anything out.  I will look at it myself when I get
> a chance.

Ah, running make as well.. I just rebuilt with XCode (*cough*). I had
tried changing MMFlushTimeoutInterval to 1.1f, but now I did it and
actually built it. ;D That did it!

It is my fault for not stating this clearly anywhere...unless you read the Makefile (or check Xcode) there is just no way you could know that!

Looking for a "threshold", it seems that 0.3f is enough (0.2f wasn't)
to make it work. I'll run with this and see how things fare.

That is very interesting...I will try to come up with a more permanent solution than "fudging MMFlushTimeoutInterval".  Thanks a lot for looking into this though.


/Björn


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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Björn Winckler

> I will look into this, but if you want to try something yourself, then set

> MMFlushTimeoutInterval (in the beginning of MMBackend.m) to something much
> bigger (say 1 (the unit is seconds)).  If it is indeed related to queue
> flushing, then by making that constant big enough the behaviour should
> change.  Usually, when MacVim beachballs this means that the NSConnection
> buffers are filling up because too many DO calls are being made in quick
> succession.  Try to see what is happening in -[MMVimController
> sendMessage::] (add NSLog(@"%s%d", _cmd, msgid) in the beginning of that
> method)...if it is getting called a lot then you have found the problem.
> (Remember that you have to 'make' whenever gui_macvim.m, MMBackend.m, or
> MacVim.m changes, all others are built by the Xcode project.)
>
> Let me know if you figure anything out.  I will look at it myself when I get
> a chance.

Ah, running make as well.. I just rebuilt with XCode (*cough*). I had
tried changing MMFlushTimeoutInterval to 1.1f, but now I did it and
actually built it. ;D That did it!

It is my fault for not stating this clearly anywhere...unless you read the Makefile (or check Xcode) there is just no way you could know that!

Looking for a "threshold", it seems that 0.3f is enough ( 0.2f wasn't)
to make it work. I'll run with this and see how things fare.

That is very interesting...I will try to come up with a more permanent solution than "fudging MMFlushTimeoutInterval".  Thanks a lot for looking into this though.

I have made some modifications in the way DO messages are handled.  I would like to ask anybody building the source code to update to the latest version and see if this causes any problems.  In particular you Niklas...can you check if the "beachball" problem you described is still there in the new version (r174)?  (You'll probably want to clean & rebuild everything, including Vim).  You'll see that MMFlushTimeoutInterval is still set to 0.1f...I would like to know if it works with that value now (if not, try to fudge it to see what difference it makes).


Thanks,
/Björn

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

Reply | Threaded
Open this post in threaded view
|

Re: MacVim.app snapshot r164 available for download

Niklas Lindström

Hi Björn,

great! I have built this (from pristine checkout copies of everything,
with older macvim removed from the system), and it seems to work fine
now (with the MMFlushTimeoutInterval kept as 0.1f -- i.e. no changes
to your code). I'll run with this now and see how it fares.

[Details: my configure step includes the flags "--enable-gui=macvim
--with-features=huge --enable-pythoninterp --enable-rubyinterp". I
have a local python 2.5 install and a newer ruby from MacPorts. All
seems to work great. I also start (after testing) MacVim by "open -a
MacVim" from bash, thus having my environment setup within vim
instances.]

Thanks a lot!

Best regards,
Niklas


On 8/22/07, björn <[hidden email]> wrote:

>
>
> >
> >
> > > > I will look into this, but if you want to try something yourself, then
> set
> > > > MMFlushTimeoutInterval (in the beginning of MMBackend.m) to something
> much
> > > > bigger (say 1 (the unit is seconds)).  If it is indeed related to
> queue
> > > > flushing, then by making that constant big enough the behaviour should
> > > > change.  Usually, when MacVim beachballs this means that the
> NSConnection
> > > > buffers are filling up because too many DO calls are being made in
> quick
> > > > succession.  Try to see what is happening in -[MMVimController
> > > > sendMessage::] (add NSLog(@"%s%d", _cmd, msgid) in the beginning of
> that
> > > > method)...if it is getting called a lot then you have found the
> problem.
> > > > (Remember that you have to 'make' whenever gui_macvim.m, MMBackend.m,
> or
> > > > MacVim.m changes, all others are built by the Xcode project.)
> > > >
> > > > Let me know if you figure anything out.  I will look at it myself when
> I get
> > > > a chance.
> > >
> > > Ah, running make as well.. I just rebuilt with XCode (*cough*). I had
> > > tried changing MMFlushTimeoutInterval to 1.1f, but now I did it and
> > > actually built it. ;D That did it!
> >
> >
> > It is my fault for not stating this clearly anywhere...unless you read the
> Makefile (or check Xcode) there is just no way you could know that!
> >
> >
> > > Looking for a "threshold", it seems that 0.3f is enough ( 0.2f wasn't)
> > > to make it work. I'll run with this and see how things fare.
> >
> >
> > That is very interesting...I will try to come up with a more permanent
> solution than "fudging MMFlushTimeoutInterval".  Thanks a lot for looking
> into this though.
>
> I have made some modifications in the way DO messages are handled.  I would
> like to ask anybody building the source code to update to the latest version
> and see if this causes any problems.  In particular you Niklas...can you
> check if the "beachball" problem you described is still there in the new
> version (r174)?  (You'll probably want to clean & rebuild everything,
> including Vim).  You'll see that MMFlushTimeoutInterval is still set to
> 0.1f...I would like to know if it works with that value now (if not, try to
> fudge it to see what difference it makes).
>
>
> Thanks,
> /Björn
>
>
>  >
>

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