>> It's hard to know what here is really necessary, though. Perhaps some >> further discussion is in order. It may be that the MacVim defaults is >> 'good enough' and we don't need the others (and therefore the submenu). > > I'm not convinced about this menu -- do we really need it? The only > argument for, as I can see it, is that we can tell newbies to use it.
Or, perhaps even more likely, oldies who have big complex configurations that are causing problems and need to be avoided to properly track down a bug (the configurations, that is, not the people! :-p). > But isn't it just as easy to tell them to "mvim -u NONE" etc.? Well, it's just as easy to *tell* them, but it might not be so easy for them to do, particularly if they don't have mvim installed. I'm already a bit sick of typing /Applications/MacVim.app/Contents/MacOS/Vim in email replies. I could make a mapping for it or something, I suppose, but that doesn't make it easier for the recipients! Side issue: perhaps we could make a nice button in the prefs to install mvim like we have a nice button for installing that input manager thing that I don't use? > I certainly would never use such a menu, I'd rather just use mvim. Well, *I'd* use such a menu, which is why I missed it last week. I type pretty fast, but even with that, grabbing a menu item from an already-running app is easier than pulling up a new terminal window, typing a commandline, and then needing to close the terminal window later. Also, when I'm testing a snapshot, another MacVim executable you ask us to test, or a development version I haven't installed to /Applications, I'm not at all sure mvim would find and connect to the correct one. It wouldn't would it? Maybe it's better as an alternative. Command-Option-N to make a New Window With MacVim Defaults (probably with a more shortly named menu item). Telling people Command-Option-N is pretty easy. >> - Debug mode: doesn't work as prompting is done before the GUI starts >> - Easy mode: if people want this, they want something other than Vim... >> - Readonly mode: easily settable inside Vim so not worth the clutter >> - Servername: more useful from a script than the GUI, and I don't have >> the skills to do it anyway > > Again, I think this is in the realm of the "mvim" script. (As for > "easy mode" -- I am very dubious about these kind of things.) Yes. That's what I was saying, albeit in a quite implicit way. >> - Load a session (or other Vim script): potentially quite handy [...] > It seems like it would be good, but again: does anybody really use > this stuff? Well, nobody does at the moment, because it's not there! Would people use this stuff? I don't know. People do use Vim sessions, particularly the automatic Gnome session saving thing, I think. I think I'd use it too, but I can't be sure without it being there! Still, as I said, I'm thinking the plugin option is the better one anyway, and that requires no changes to MacVim code, so in a sense, it's a lower priority one: it's something users can do on their own if they want it. Though maybe if it were there by default it would help people. Do other editors have session saving? Do people use that? >> Also note, when I was editing the menus, I saw there was an Interface >> Builder minimum OS version option set to 10.5 rather than 10.4, so I >> changed it. That might be why the diff is so large. I don't know. > > It seems to have changed the nib formats from XML to the old-style > format -- it's use is discouraged. Something else seems to have gone > wrong too, the MainMenu.nib has new data that don't make any sense to > me (IBDocumentLocation, ...). OK. Yuck. I wonder it that's because of that setting change or just because of my version of Interface Builder or something else. I've never even opened the app until I tried to do this, so really have no idea what I'm doing... O well. I can put a patch together without changing that option, and hopefully it'll be better, once we get some kind of idea of what we do want to do with these ideas. > You should also use git-format-patch to make patches. That's hard when I don't use git. :-) I kinda gave up on it after a few hours. I managed to follow your instructions to get and update the repo, but couldn't easily figure out how to do anything else with it. Maybe I'll try to get the hang of it again when I have a few days to spare. Now that the repository isn't too many hundred megabytes I can possibly have another one of them around for fiddling with. Depends whether I feel it's worth the bother, I guess, which isn't looking all that likely, to be honest. > Anyway, sorry for the overall negative tone to my reply -- I'm not > saying that all these ideas should be discarded. I've also spent some > time thinking about these issues but I could never come to a > conclusion as to what to do about them. So lets hear what other > people have to say about Ben's ideas! Doesn't seem to be a huge amount of interest, though, does there? Hmm. Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
