Currently when a user uses Sparkle updater to update, they will see the
release notes beforehand. However, if they are updating across multiple
versions, they only see the latest one. Also, if they are using
automatic update, they will not see the release notes page. Users who
get MacVim from Homebrew or manually building from source also do not
see the release notes as those mechanisms are driven from command line.
This makes it harder to communicate new features and announcements to
these users.
Add a new "What's New" page that will be automatically shown whenever
the user has updated to a new version of MacVim. The last version of
MacVIm is tracked by the MMLastUsedBundleVersion value previously added
in #1357, which allows us to detect such update no matter what
installation method was used and display a dialog box. Other than
opening at launch, the user can also open it in the Help menu, and
there's an option to make it not open at launch if it's annoying to
the user.
The release notes is served by http://macvim.org/ (done in
https://github.com/macvim-dev/macvim-dev.github.io/pull/1) so we don't
have to bundle it locally and it makes it easier to update them. MacVim
will know the request a range of release notes (if updating across
multiple versions at once) so that all new versions will be visible.
Also, fix it so that both Sparkle updater and the new What's New page
will properly be shown on top of the new MacVim window that gets opened
when MacVim is launched. Previously when we get a new update, Sparkle
frequently gets hid behind the editor window.
Problem: charidx() and utf16idx() result is not consistent with byteidx().
Solution: When the index is equal to the length of the text return the
lenght of the text instead of -1. (Yegappan Lakshmanan,
closes#12503)
Problem: Some commands for opening a file don't use 'switchbuf'.
Solution: Use 'switchbuf' for more commands. (Yegappan Lakshmanan,
closes#12383, closes#12381)
Problem: No error when calling remote_startserver() with an empty string.
Solution: Give an error for an empty string. (Hirohito Higashi,
closes#12327)
Problem: no functions for converting from/to UTF-16 index.
Solution: Add UTF-16 flag to existing funtions and add strutf16len() and
utf16idx(). (Yegappan Lakshmanan, closes#12216)
Problem: Decrypting with libsodium may fail if the library changes.
Solution: Add parameters used to the encrypted file header. (Christian
Brabandt, closes#12279)
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)
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)
