Compiling:

• To build the project:
  • patch vim7 src with MacVim patch
  • make vim7 src with --enable-gui=macvim
  • build MacVim.xcodeproj
• To install:
  • copy MacVim.app to /Applications (or anywhere you want it)
  • in ~/.profile add this line: alias gvim='/Applications/MacVim.app/Contents/MacOS/Vim -g'
• To run:
  • Double click MacVim icon
  • with the above alias you can type 'gvim' in terminal to open MacVim (if the -g switch is left out, then Vim is started in terminal mode)
  • in terminal mode of Vim, type :gui and MacVim will start
• Technical notes:
  • to build a universal binary, the compiler AND linker needs the flags '-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386'; also, make needs argument --with-mac-arch=both
  • vim runtime files are copied to 'MacVim.app/Contents/Resources/vim/runtime/'

Weirdness:

• [obsolete] When the text system (Cocoa) comes across multi byte characters it automatically chooses a font for those characters; this font may not be the same height as the one set on the text storage and hence the program must account for the fact that lines may have differing heights. We get around this problem by resizing the window to fit the text storage after the layout manager has performed layout. As a side-effect the user sees how the window resizes when certain multi byte characters are being displayed.
• [obsolete] Remember to set 'inputReceived = YES' in MMBackend handlePortMessage:, otherwise Vim will not inform MMVimController of changes it makes (e.g. in response to a key down event).
• The way delegate messages from the tab bar are handled are based on lots of assumptions on how the code works. See comments in tabView:... delegate messages in MMWindowController.
• [obsolete] The insertion point is automatically moved to wherever changes are made in the text storage. To set the position manually (via setSelectedRange:), first call endEditing on the text storage.
• Delegate messages from the tab view need to be able to differentiate whether the message was sent due to the user clicking a tab with the mouse, or if the vim task initiated the change. To facilitate this, flags must be set whenever the vim task does something that results in these delegate messages being sent. See comments in the tabView:...Item: messages in MMWindowController.
• In Vim the first tab has index 1, in the gui the first tab has index 0. This is compensated for in MMBackend.m.
• The PSMTabBarControl does not reorder the NSTabView when a user drags tabs around, so we must rely on [PSMTabBarControl representedItems] to get the correct order of tabs (the order which the user can 'see'). WARNING! This means that the code cannot rely on calls like [NSTabView selectTabViewItemAtIndex:] etc. since the NSTabView has the 'wrong' order.
• The MMVimController is added to the NSEventTrackingRunLoopMode, otherwise updates from Vim would not reach the MMVimController while the user resizes the window using the mouse.
• It seems that (oneway void) DO messages can arrive when another such message is being processed. For this reason, no input is sent to Vim whilst in processCommandQueue:. Instead, messages are queued and sent when processCommandQueue: has finished. Otherwise the invariant that all Vim messages must appear in the same order they were issued will be violated.
• Text storage dimensions are not ever directly modified, instead a message is sent to Vim asking it to change the "shell size". Otherwise, a message asking Vim to change the shell size might get lost and Vim and MacVim will have inconsistent states.
• gui_mch_browse() and gui_mch_dialog() are blocking calls, but you can't put up dialogs in Cocoa which block until the user dismisses them (it uses callbacks). This complicates the browsing somewhat.
• When binding menus to :action note that that action will be used for all modes. The reason for this is that MacVim needs to be able to execute such menu items even when no windows are open (e.g. newVimWindow:) and the default menu action relies on Vim to deal with it.
• The 'help' key is treated as a special key by Cocoa; when the user presses this key the mouse cursor changes to a question mark and the application is put into 'context help mode'. The key down event is never sent down the responder chain. To get around this problem we are forced to subclass NSApplication and look for the 'help' key in sendEvent: (see MMApplication).

Design decisions:

• Output is queued and sent to the MMVimController only when [MMBackend flushQueue] is called in order to minimize the amount of messages sent back and forth between the task and gui. Also, this makes sure that commands reach MacVim in the same order they were issued by Vim.
• Drawing commands are stored in a buffer (drawData) and put on the output queue whenever [MMBackend flush] is called. This buffer might no longer be needed now that there is a general output queue. However, the existing code works, so why change it?
• [obsolete] The gui listens for tasks on a named port whose name is derived from CFBundleIdentifier (which is defined inside Info.plist of the app bundle). In order to run two different copies of MacVim at the same time, they need to have differing bundle identifiers; otherwise one copy will not be able to create the named listening port and all tasks will connect to the first copy.
• The gui creates a named NSConnection which vends the MMAppController object.
• All tabs share one text view and its associated text storage. There used to be one text view per tab, but this only complicated the code since Vim has no concept of different views (as in NSView).
• Vim holds the actual state. MacVim should never change Vim related states directly, instead it must ask Vim to change the state and wait for Vim to reply with an actual state change command.
• If MacVim wants to change the state of Vim it must go through processInput:data:, this is an asynchronous call.
• MacVim can query state information synchronously by adding a suitable message to MMBackendProtocol, however this must not change the state of Vim!
• If MacVim or Vim dies, the NSConnection is invalidated and connectionDidDie: is invoked.
• Input may reach the backend whenever the run loop is updated. This can cause problems if more input is received whilst already processing other input. At the moment new input is dropped if the backend is already processing other input.

Keyboard stuff:

• input ends up in one of the following methods (1) insertText: (2) doCommandBySelector: (3) performKeyEquivalent:

• (1) handles: printable keys (a, Space, 1, ...) and (also ). if Ctrl+Option is held [NSEvents characters] will translate the input to control characters; note that if the translation fails, then Shift and Option modifiers are NOT includeded in [NSEvent characters], but they are included in [NSEvent charactersIgnoringModifiers]. e.g. given , characters returns 1, charactersIgnoringModifiers returns .

• (2) handles: Ctrl+key, enter, backspace, escape. same note on translation of Ctrl+key as above holds true. come Ctrl+key combos are by default mapped to several commands, so Ctrl+keys must be intercepted in keyDown:

• (3) handles: Cmd+key, arrow keys, function keys, help key Cmd+letter keys never reach the app if this method isn't overridden (but Cmd+function keys do) Cmd+function key must not be intercepted here or input methods won't work

• and are two different characters (the former is 0xa0)

• Cocoa translates to Ctrl-C so this must be taken care of

• with various modifiers is very special, check MMBackend how it is handled

Bugs:

• Using NSString initWithBytesNoCopy:::: causes crash when trying to set window title.
• NSTabViewItem setInitialFirstResponder: seems to have no effect, so we manually set the first responder when the tab item selection changes.
• PSMTabBarControl never removes itself as an observer, which can cause all sort of weird problems (crashes etc.), so this is taken care of at cleanup.
• PSMTabBarControl retains its delegate, so the delegate is forcibly set to nil at cleanup, else there will be a memory leak.

Features (!supp indicates that a feature is not supported):

• Multiple top-level windows: each window runs its own vim process (they are completely independent)
• Tabs: uses PSMTabBarControl to show tabs, can reorder tabs by dragging them, has overflow menu, new tab button on tabline
• Menubar: accelerators !supp, actext hint displayed as tool tip instead of on menu, each window has its own menu, set key equivalents with :menukeyequiv command
• Toolbar: toolbariconsize supported (tiny&small equiv to 24x24 px, medium&large equiv to 32x32 px), toolbar supports 'icons' and 'text' options (but not 'tooltip' which is always on), each window has its own toolbar, custom toolbar items
• Cocoa input protocols: input managers, character palette input etc. supported, marked text partially supported, cocoa key bindings (DefaultKeyBinding.dict) are disabled
• Mouse: resize (vim) windows, selection, different mouse cursors, autoscrolling whilst selecting (horizontal autoscroll !supp)
• Drag and Drop: drag files onto dock icon to open in tabs, drag text and files onto text view
• Zoom: Command-click to zoom to fill window, otherwise only zoom height, hold down Option to zoom all windows
• Resize: live resize (although terribly slow), :set lines will not make window higher than can fit the screen (no such restrictions on width at the moment)
• Pasteboard: star-register works with the mac os x pasteboard
• Open/Save dialog: use with :browse
• Gui dialogs
• Fonts: bold/italic/underline traits supported, font changes with ':set gfn', or use font panel
• File type associations: add more associations by editing Info.plist
• Start GUI from terminal, type :gui
• Scroll bars
• Wide characters: but composed characters !supp
• Printing: !supp
• Find/Replace dialog: !supp
• External editor protocol: !supp
• Services menu: some simple minded provider entries
• Encodings: !supp (enc, tenc always set to utf-8)
• Autosave window position
• Smart cascading of new windows
• Client/server support (only gui window can become server)