Fix :hardcopy not working in macOS 13 Ventura #1390
Conversation
ychin
force-pushed
the
fix-macos-13-ventura-printing
branch
from
62b7eca
to
842cd7e
Compare
runtime/autoload/macvim.vim
Outdated
|
|
||
| # Delete the file after it's opened in Preview for privacy. We don't have an | ||
| # easy way to detect that Preview has opened the file already (unless we use | ||
| # `open -W` which will stall Vim), so we just use a generous 10 secs timer. |
There was a problem hiding this comment.
Theoretically, it can be done using client-server architecture. A server can be either GUI main process itself or a shell script which will fork process properly.
Second proposition can be used from terminal and require less coding. I see the first one as a more clean though
What do you think on this idea?
There was a problem hiding this comment.
The main issue is actually that -W only terminates when Preview.app closes. A normal user may have multiple documents opened in Preview, which never closes, meaning that -W has to wait forever to finish. You can use some AppleScript to figure out when the document has opened/closed but it's somewhat convoluted and also requires asking permissions from the user.
Otherwise we could have simply used call system(open -W Preview.app; rm ... &) to open it in the background.
There was a problem hiding this comment.
I'll just remove that comment about -W.
There was a problem hiding this comment.
I agree, my idea was to call an external routine(script or via client-server architectrure) which will fork and wait and remove files as they not needed
There was a problem hiding this comment.
Please, keep the comment, it's useful
There was a problem hiding this comment.
Hmm, I can add something back. The key point here though is that -W does not do what we want, so the original comment was wrong. It only works if the user literally only has one file open and immediately close Preview, which is often not the case.
ychin
force-pushed
the
fix-macos-13-ventura-printing
branch
2 times, most recently
from
b5e4bde
to
377323c
Compare
MacVim's `:hardcopy` implementation just uses Preview to show the generated PostScript file and lets the user decide what to do with it. macOS 13 Ventura removed PostScript support from Preview, so we now have to manually convert it to PDF first using `pstopdf` (which is thankfully bundled with macOS). While we are at it, update the script so that we actually delete the file after sending it to Preview. Previously MacVim never did that and therefore leaks the file in a temp folder until Vim closes, which isn't ideal for privacy. Now, just set a 10 sec timer to delete the file after it's opened (we just need enough time to allow Preview to open and load the file, which doesn't take much time. The 10 sec timer is to account for slow computers). Fix macvim-dev#1347
ychin
force-pushed
the
fix-macos-13-ventura-printing
branch
from
377323c
to
e3a5374
Compare
|
Thanks, guys. I had worked around the printing issue on Ventura by adding se printexpr=system('ps2pdf\ '.v:fname_in.'\ '.v:fname_in.'.pdf\ &&\ open\ '.v:fname_in.'.pdf')\ +\ v:shell_error to my .vimrc file. I'll update my copy of MacVim when prompted, and test after commenting out the "se printexpr..." line. Michael |
|
There should be a pre-release version (176.1) coming out soon. If you want that version you can go to Advanced settings to enable the pre-release update channel. Otherwise though if it's been working for you ( |
|
Thanks, I think I'll just sit tight until 177 is released, I'm having a few problems with unstable software (not MacVim) at the moment... |
…inting Fix :hardcopy not working in macOS 13 Ventura
|
I'm on That means I need to wait for version-177 ? Thanks. EDIT1: My current workaround for printing (not viewing) is to grab the file path, go to EDIT2: Just tried @MichaelHendry 's workaround and it indeed does work to create/open a PDF in MacOS Preview:
|
|
@jubilatious1 you need r177 (which is not released yet) or you can get the pre-release version r176.1. Otherwise if the workaround works for you that works too. |
Updated to Vim 9.0.1677 Announcements ==================== Website -------------------- The official website for MacVim is now https://macvim.org. Previously it just forwarded to https://macvim-dev.github.io/macvim/. You can also read the MacVim documentation at https://macvim.org/docs/gui_mac.txt.html. #1385 Features ==================== Updater / What's New page -------------------- There is now a "What's New" page that will automatically be shown whenever MacVim detected that it has been updated to a new version (can be disabled in Settings). The page will also include all the release notes if you have updated across multiple versions. This feature is useful for users who turned on "Automatically install updates" or installs MacVim through other methods like Homebrew but would still like to see the release notes when a new version comes out. You can also access it through the Help menu. #1414 MacVim should now report its version in a much more consistent manner in the "About MacVim" page and when the updater reports there is a new version. It should look something like "r176 (Vim 9.0.1276)" where "r176" is the MacVim release number and the 9.0.1276 is the bundled Vim version. #1293 #1393 Sparkle (updater for MacVim) is now updated to 2.4.2. #1416 New Vim features -------------------- - New bundled colorschemes: wildcharm/retrobox/sorbet/zaibatsu (vim/vim#12163) - File encryption now has a new `cryptmethod`: `xchacha20v2`, which is designed to be more forward compatible with future Vim versions than `xchacha20`. (v9.0.1481) - `switchbuf` works for more commands. (v9.0.1546) - Statusline now supports multiple alignment "%=" items. (v9.0.1300) - New UTF-16 utility functions (`strutf16len` and `utf16idx`) (v9.0.1485) - Misc 'smoothscroll' bugs fixes General ==================== * Removed non-Unicode localization files, which helps cut down on app size. #1397 * Miscellaneous documentation fixes. #1415 #1375 #1386 #1363 (by @dkav) * The disk image for MacVim (MacVim.dmg) is now in APFS and uses better compression for better efficiency. #1409 Fixes ==================== * Printing a file in macOS 13 Ventura (using `:hardcopy` or File→Print) should work again. #1390 * Fixed a broken symlink to XPCServices in the Sparkle framework. #1367 * Fixed MacVim to not throw (safe) Objective C exceptions when quitting. #1371 * Fixed welcome message not being aligned properly in Simplified Chinese and show the Vim 9 prompt. #1381 * Removed some unnecessary test files in the runtime folders which were included erroneously. #1418 Scripting ==================== - Scripting languages versions: - Python is now built against 3.11, up from 3.10. Compatibility ==================== Requires macOS 10.9 or above. (10.9 - 10.12 requires downloading a separate legacy build) Script interfaces have compatibility with these versions: - Lua 5.4 - Perl 5.30 - Python2 2.7 - Python3 3.11 - Ruby 3.2
Fix broken printing in macOS 14. It was broken because the OS stopped supporting Postscript and removed the `pstopdf` tool. Fix the printexpr to detect when `pstopdf` doesn't exist and try to use `ps2pdf` instead. This is a third-party tool and it's not guaranteed to exist. If it doesn't exist, give an error prompt for the user to suggest installing Ghostscript first. Settled on this solution as printing is a relatively niche feature and it's not worth spending too much effort fixing this. Related: - macvim-dev#1390 / macvim-dev#1347: macOS 13 Ventura broke printing by removing Preview support for PostScript. The fix was to use `pstopdf`, which eventually got removed in macOS 14.
MacVim's
:hardcopyimplementation just uses Preview to show the generated PostScript file and lets the user decide what to do with it. macOS 13 Ventura removed PostScript support from Preview, so we now have to manually convert it to PDF first usingpstopdf(which is thankfully bundled with macOS).While we are at it, update the script so that we actually delete the file after sending it to Preview. Previously MacVim never did that and therefore leaks the file in a temp folder until Vim closes, which isn't ideal for privacy. Now, just set a 10 sec timer to delete the file after it's opened (we just need enough time to allow Preview to open and load the file, which doesn't take much time. The 10 sec timer is to account for slow computers).
Fix #1347