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#1347
Problem: Highlight for popupmenu kind and extra cannot be set.
Solution: Add PmenuKind, PmenuKindSel, PmenuExtra and PmenuExtraSel
highlight groups and use them. (Gianmaria Bajo, closes#12114)
MacVim's docs for 'fuoptions' above didn't terminate a code block which
resulted in the 'gdefault' help tags being broken as they were treated
as code blocks as well. Fix up the docs properly.
Add "MACVIM REFERENCE" to syntax rule to reflect the new header to make
it look less weird. Also remove the "last changed date" header since I
rarely update it and it's not particularly useful given how in MacVim
the runtime is always bundled anyway.
Also, when investigating using Neovim's treesitter vim docs generating
tool for MacVim (to generate a web version of the documentation), found
a few typos / formatting issues. Fix them here.
Problem: 'statusline' only supports one "%=" item.
Solution: Add support for multiple "%=" items. (TJ DeVries, Yegappan
Lakshmanan, closes#11970, closes#11965)
The latest Vim runtime update upgraded sh.vim from version 204 to 205,
which contains a bug (https://github.com/vim/vim/issues/11937). Since we
are releasing MacVim soon, simply revert this change to have a stable
build and we will revert this when Vim has fixed this upstream.
Problem: .clangd and .stylelintrc files don't get a filetype.
Solution: Use yaml for .clangd and json for .stylelintrc files. (Mark
Skelton, closes#11916)
This fixes the issue where particularly tall characters will get clipped
at the row boundary. This happens because even though a font describes
the line height with font metrics, individual glyphs do not have to
respect them, and we can see with emoji rendering sometimes they can
poke upwards past the line height. Also, it's trivially easy to
construct composing characters that become really tall, e.g. "x゙̂⃗", or
Tibetan scripts like "ཧཱུྃ".
To fix this, we do the following:
1. Remove the explicit clipping call at rendering.
2. Fix partial redraw to not lead to clipping / corruption. This is
quite tricky, because let's say we have a character that is tall
enough to touch other lines, if those lines are redraw but not the
line with the tall char, the redraw will paint over the parts of the
glyphs poking through. Alternatively if we redraw the line with the
tall chars we also need to expand the redraw region to make sure
other lines get repainted as well. To fix this properly, we should do
a proper glyph calculation when we receive the draw command before we
issue before we call `setNeedsDisplayInRect`, but since right now we
only extract glyph info later (during drawRect call), it's too late.
We just do the hacky solution by storing a variable
`redrawExpandRows` that tracks how many lines to expand for all
lines. It's a little hacky since this will affect all lines
permanently regardless if they have tall characters or not. The
proper fix may come later as an optimization (or when we do hardware
rendering via Metal).
3. Re-order the rendering so we have a two pass system, where we first
draw the background fill color for all rows, then the text. This
helps prevent things like Vim's window split or cursorline from
obscuring the text.
4. Add a preference to turn on clipping (old behavior). This helps
prevent odd issues with really tall texts (e.g. Zalgo text) making it
hard to see what's going on. The preference `MMRendererClipToRow` is
not exposed in UI for now as it's a relatively niche. It will be
exposed later when we have a dedicated render tab in settings.
Note that a lot of these characters only show their full height by doing
`set maxcombine=8` because the default (2) is quite low.
Part of the fix for #995
Problem: :runtime completion can be further improved.
Solution: Also complete the {where} argument values and adjust the
completion for that. (closes#11874)