On 5 August 2010 20:43, björn wrote: > On 5 August 2010 19:24, Michael Trim wrote: >> >> The Ctrl key functionality is part of the existing code, and is not >> relied on or provided by this patch. The Ctrl modifier just allows >> the user to force the opposite behaviour to the actual state of the >> 'dropsplit' option. Without modifier support the behaviour will >> always be as configured, so I think MacVim could still use this. > > Sorry, I wasn't quite clear: MacVim doesn't support the Ctrl modifier > as it is (due to some weirdness with the Cocoa drag&drop API). Since > your patch still relies on the Ctrl key I cannot benefit from it > (which is fine since there is already a setting to make dropped files > open in tabs/splits/... in MacVim). > > From my point of view, it would be nice to have this functionality in > all gvim ports, but since I guess other ports will keep relying on > modifier keys to distinguish different type of drops it doesn't matter > so much to me how it is done. (Of course, it would be feasible to > rewrite the drag&drop so that no modifier keys are required by having > one option which defines how dropped files should open [split/tab/...] > and then MacVim could make use of it. On platforms where modifiers > are supported they can modify the drop behavior similarly to how they > do now...)
Oh my, I did not read your post correctly. I see what you mean now. Sorry for being so obtuse. I still find the new options a bit unintuitive...ideally I'd like there to be one option that defines how drops are treated (tab/split/vsplit/add to arglist) but this doesn't account for how modifiers should be handled. Björn -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
