Skip to content

Not showing new window in OS X 10.9 #1212

Closed

Description

@d-c

I can run Macvim.app in the current (8.2.3455 (172)) version on my OS X 10.9, but there is no new window with empty file (no matter what setup I use). I can select the recent file, but the new window with text doesn't appear. Drag'n'drop doesn't work either.

Last version I used without issues was a very ancient one. When I try to user a newer version, it breaks even the older one into the same non-working behaviour, so to get back to the working state is not easy. I cleaned up anything I found, what might have any connection to MacVim and tried to use older versions. Ended up with "Custom Version 8.2.539 (163)" released on 12 Apr 2020 which worked again.

When I try to run the native app (/Applications/MacVim.app/Contents/MacOS/MacVim) from the shell, it runs non-graphical vim. After I quit with :q it says:

2021-10-04 12:54:44.989 MacVim[34079:507] -[MMWindow setTitlebarAppearsTransparent:]: unrecognized selector sent to instance 0x7fb5dad3d8e0, but I don't return to shell before I quit the graphical interface.

If I try to select e. g. a file from Recents, it opens in terminal, but with very limited possibilities of work, no graphical window.

Activity

  1. eirnym commented on Oct 4, 2021

    @eirnym
    Contributor

    Hi,

    could you try with clean defaults and clean vimrc, like --clean?

    setTitlebarAppearsTransparent

    it's actually a very useful find! Looking by a "terminal" keyword, I'd like to ask you to test your setup with releases 164 and 166. with clean configuration and no defaults.

    As I see some problems in 168 and 169, I suggest to try 170/171 after that. There was no release message about fixes, but they might be fixed

  2. ychin commented on Oct 4, 2021

    @ychin
    Member

    I can try to run this in a VM. 10.9 is definitely on legacy support so it isn't very well tested. I think this is the transparent titlebar support and I think we just need to add some checks to make sure it doesn't call it on old version of OSX.

    Last version I used without issues was a very ancient one

    Do you know what "ancient one" means? a few months / a year / a few years ago?

  3. added this to the snapshot-173 milestone on Oct 4, 2021
  4. d-c commented on Oct 4, 2021

    @d-c
    Author

    I am sorry, I added those extra pieces into the original post, it might have been missed. So once again:

    1. I did try to manually remove all .vimrc and files found in ~/Library (everything found which had macvim in name/directory).
    2. IMHO the last version working on OS X 10.9 is 163 released on 12 Apr 2020.

    I tried to compile recent git version and it fails on XIB file for preferences compilation. The file is for X Code 8.0 and up, there is only XCode 6.2 on 10.9. I don't really understand UI Designer being mostly just a console guy. :-) Sorry.

  5. ychin commented on Oct 4, 2021

    @ychin
    Member

    Is there a reason why you need to build MacVim from scratch? Because we moved from NIB to XIB it could be hard for you to build locally on 10.9

  6. d-c commented on Oct 4, 2021

    @d-c
    Author

    No real reason. I just wanted to give it a try, with an opportunity to try a bit of debugging. But it's really of a very little use for me, I usually program in plain C.

  7. chuchana commented on Oct 20, 2021

    @chuchana

    I also can't get MacVim to open any windows on macOS 10.14.6 when I start it conventionally.

    Since opening it from a shell seems to work as expected, I created a one-line script to start it that way and tested it successfully.

    Then I tried to get rid of the script opening a terminal window by copying the script's content into a shell script section of an Automator Application. Weirdly, executing that application leads to the same result as opening MacVim conventionally. Even when I call my shell script from there instead of copying its content.

    I hope this can point someone in the direction of at least some part of the problem.

  8. d-c commented on Aug 7, 2022

    @d-c
    Author

    I tried a new 173 version and I must admit, that the issue is all the same:

    2022-08-08 00:21:15.198 MacVim[13815:507] -[MMWindow setTitlebarAppearsTransparent:]: unrecognized selector sent to instance 0x7fb8a1c7d590
    8H4C31H

    ...no new window...

  9. ychin commented on Aug 8, 2022

    @ychin
    Member

    Thanks for reminding me about this issue. I'll set up some VMs to test it.

    I do wish GitHub Action provides older VMs but I guess generally Apple dislikes maintaining older versions of OSes like this.

  10. ychin commented on Aug 8, 2022

    @ychin
    Member

    Btw @d-c , if you are comfortable, do you mind giving some context as to why you are using macOS 10.9? Reason I’m asking is that while it’s still the minimum version supported, it’s getting harder to support as time passes. For example, Sparkle 2 (the updater we use to update MacVim) requires 10.11. We are using Sparkle 1 which is fine for now but eventually we may have to upgrade.

    10.9 is 8 years old now, and both 10.10 and 10.11 have the same system requirements as 10.9 so hardware should not be an issue. Is it simply because you prefer it?

  11. d-c commented on Aug 8, 2022

    @d-c
    Author

    @ychin IMHO is 10.9 the Apple's top system according to ergonomic use, compatibility with SW (some of which was quite expensive), design and stability. I have used quite a lot of systems (and tough trainings on some of them), so I am not comparing just a few impressions.

    I have tried newer OS X and macOS systems. One difficulty for me is screen handling. It might be well readable on a retina screen, but $2k+ profi CGs by EIZO seem unreadable. Other is that newer systems are kind of broken in regard of security (from stupid "business" reasons - e. g. to let unprivileged users buy and run apps from store), which in turn is followed by more and more stupid remedies. And more incompatibilities to Unix rules and existing programs. The last more less usable was High Sierra, but it's unsupported for a long time now, so benefits are low.

    Yes, I know I will need to move away with my everyday work from 10.9 pretty soon, probably leaving an off-line working place to do photo, sound and video processing. But I am not sure whether to another Mac. *BSD system seems more convincing to me. But still searching...

  12. ychin commented on Aug 9, 2022

    @ychin
    Member

    I see. Ok those are good insights.

    compatibility with SW

    Lol tell me about it! Every OS update is a mix of excitement and trepidation for me.

    Kind of curious what you mean by incompatibilities to Unix rules though, but maybe we are getting off to a tangent.

  13. chdiza commented on Aug 9, 2022

    @chdiza
    Contributor

    @d-c Sorry to butt in here, but I was a staunch advocate of keeping support for Tiger here, back in the day, and thus I sympathize greatly with your desire to keep going with an old and non-crappy version of macOS.

    Long story short: depending on your workflow and your needs, you might not even need MacVim at all on 10.9. Perhaps you can get away with just building an up-to-date console Vim.

    Terminal emulators on macOS have improved immensely since I starting MacVimming around 2007 when it first appeared. (Holy crap! Has it been 15 years of MacVimming?) So much so that the advantages of using MacVim over a plain console Vim---which were many back in 2007---have dwindled down to almost nothing (for me, anyway).

    As it turns out, I'm switching to Linux, where there is no way to reliably map the Cmd key in Vim/gVim (without horrible side effects). This has forced me to retrain my Vim muscle-memory to use other modifiers besides Cmd, and it really only took about two days before it became natural. Well, guess what? The ability to have :map <D-something> was really the only reason left for me to use MacVim rather than console Vim. So on those occasions when I do use macOS, I would have no problem just using console Vim instead of MacVim.

    • I don't open files by double-clicking them in the Finder, so I don't need MacVim for that. (Even if I did open files that way, I could make a wrapper that would start console Vim.)
    • At least two terminal emulators on the Mac now have well-functioning fullscreen modes corresponding to "Non-native", aka., Tiger fullscreen, so I don't need MacVim for that.
    • Console Vim now supports truecolor, so MacVim has no colorscheme advantage.
    • I don't need to drag-n-drop anything onto MacVim, so I don't miss that when using console Vim.
    • Etc.
  14. ychin commented on Aug 9, 2022

    @ychin
    Member

    Sure @chdiza no problem I always want to hear what drives people to/away from MacVim. But yes how much value you derive from MacVim depends on whether it's the GUI part, or just the "not sucky terminal emulator" part of MacVim that entices you. To me, it was the "GUI of Vim" part that made me start using MacVim.

    MacVim does have the ability to do a lot more system integration, such as fully utilizing the Touch Bar or trackpad. There are also some features in progress (with different degrees of doneness) that are difficult to do on a terminal emulator due to the limits of the process boundary (e.g. overlaid scrollbars, smooth pixel scrolling, proper Option-key handling/mapping that would deprecate macmeta).

    But feel free to use whatever fits your needs. If there's any reason why you think terminal Vim is actually better than MacVim in terms of functionality though I'm curious to hear about it.


    But on the topic of supporting old versions of OSes, I hear you. I do want to support older versions as much as we can. Sometimes it could get tricky due to API incompatibility (old APIs go from supported to deprecated to removed), and it's difficult to test them in CI. But as long as there are no forcing functions that would force us to bump that number I don't plan to do so (Sparkle 1 still seems supported for now, but the upgrade to Sparkle 2 would probably one of the few reasons we would have to upgrade, unless we want to ship a separate binary that doesn't come with Sparkle updater).

  15. added 3 commits that reference this issue on Aug 9, 2022
    e7b40a2
    eb3920f
    1adb42b
  16. ychin commented on Aug 9, 2022

    @ychin
    Member

    Ok have a PR up which fixes this issue. I tested on a 10.9 VM and seems to work, and you can launch and use MacVim again.

    One issue that I found: native full screen doesn't seem to work: the Vim window would not resize properly and not take up the whole screen. Non-native full screen still works just fine though. This honestly feels a little like a niche case to me, and unless there is strong desire expressed here it's unlikely I'll fix that, since even just 10.13 seems to handle the native full screen transition just fine. The full screen API and MacVim's handling of it is a alway kind of convoluted and I would much rather spend my time on fixing other issues.

  17. chuchana commented on Aug 9, 2022

    @chuchana

    Great! I actually prefer the non-native full screen mode because I find the native animations annoying and I like using [cmd] + [h] to hide the current program.

  18. chdiza commented on Aug 9, 2022

    @chdiza
    Contributor

    Native fullscreen mode, a.k.a., Lion-mode, is an abomination :)

  19. chdiza commented on Aug 9, 2022

    @chdiza
    Contributor

    @ychin I don't think there's anything on which console Vim outperforms MacVim. (I mean, other than startup, but that's just the nature of a GUI.) MacVim does outperform the most popular other gVim, namely the GTK3 build on linux. (It's so laggy as to be unusable and I build the GTK2 version instead.)

  20. ychin commented on Aug 10, 2022

    @ychin
    Member

    Actually, if you use iTerm2, it supports modifyOtherKeys, which MacVim doesn't support yet (but it will soon). Anyway maybe we should stay on topic lol.

  21. added a commit that references this issue on Sep 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions