Apple "Intelligence" Writing Tools was previously not working correctly
with MacVim. When the user chooses to replace the original selection
with the updated texts, MacVim mistreats the input and treat them as
commands instead of raw texts. The reason was that even though this
service uses the NSServicesMenuRequestor API to obtain the selected
texts, it does not use it to send over the replacement. Instead, it uses
NSTextInput's `insertText:replacementRange` to do so instead, which we
never implemented properly. The reason behind this choice was probably
because Writing Tools first shows a UI with user interaction and has a
delay between obtaining the texts and replacing them, like a regular
Services menu. This means the selection may already be invalid by the
time it requests a replacement.
To fix this, add a new IPC API `replaceSelectedText` to replace the
selected texts and redirect `insertText:replacementRange` to use it if
the replacement range is non-empty. This isn't the most correct
implementation of the protocol but should work in most cases. We don't
have a way to implement it "correctly" as MacVim does not have easy
access to Vim's internal text storage. Also make sure the Service
menu uses this API (for things like "convert to full width" and
Traditional/Simplified Chinese conversions). The old method of simple
injecting a normal mode command `s` before the text was horribly buggy.
It also works with visual block selection properly now.
The implementation uses Vim's register put functionality because Vim
doesn't have an API to simply replace a block of text, and everything
has to go through registers. At the same time, replace the
implementation for the old `selectedText` IPC API to not do this,
because Vim *did* end an API to do so for obtaining texts (via
`getregion()`) and it's more stable to use this than to manually
cache/restore registers.
Related: vim/vim#16596 (fixes `setreg()` which this uses)
Fix#1512
In #1547, flicker during font size change and showing tab/scrollbar were
reduced. Here, we do something similar for the flicker that happens when
entering non-native full screen, where the temporarily moved text view
shows a brief temporary draw before the updated Vim redraws over it,
leading to a flicker. Use the same mechanism here to block rendering and
offset the text view draw while we wait for Vim to preserve visual
stability as much as possible.
No need to do this for native full screen as the smooth but slow
transition means there isn't a sharp flicker anyway.
Also, reduce the "fill right" behavior of Core Text renderer (#1276).
It's designed to make smooth resizing more seamless but it fills all the
way to the right which makes situations like this or maximizing the
window jarrying as Vim looks stretched horizontally but not vertically
during the resize before Vim catches up and resizes/redraws. Just put a
sane cap of 4 cell widths. This way even if Vim is a little slow to
respond, smooth resize still looks good, but it won't stretch across the
whole screen.
Problem: Non-native full screen has an option to show the menu bar but
it does not work properly in some multi-monitor scenarios. On a MacBook
with a notch it would sometimes use the thicker notch menu bar height
even when going full screen on a regular monitor, and when using a
single Space for all displays it would also show a black bar on top on
the screen that does not have the menu bar.
Solution: Use the NSScreen visibleFrame API exclusively instead of
querying the menu bar height which seems to be inconsistent. There are
some quirks with this API (e.g. a one-pixel gap) but we already handle
it when handling non-native full screen on a laptop screen with notch so
it's best to consolidate the code paths.
Also, make the "show menu bar" option immediate when changing it in
preference pane. As a corollary, this also makes changing "smooth
scrolling" option immediate, as well as liveResizeDidEnd's delayed
pending resize.
MacVim would previously show a quick flicker when adjusting font (e.g.
Cmd =/-) or showing/hiding tabs/scroll bar when in fixed window size
mode (guioptions+=k or full screen). This was because after the state
change, Vim requests a resize asynchronously to the GUI to fit it in the
window. MacVim does so after changing the font/showing the tab, leading
to a momentary incorrect result before Vim then redraws the resized
grid. In normal GVim this is not an issue because Vim requests the
resize synchronously in a single-process environment, and we would like
to avoid that as the message passing between Vim/MacVim and designed to
be mostly non-blocking.
To fix this, after receiving the Vim resize request, we block all
further text rendering commands, until Vim has resized / redrawn,
preventing the short period of time where text view is drawing the old
state using the new font. For tabs / scroll bars, the text view itself
has moved after the new layout, so we temporarily apply a render offset
to make the text view pretend it didn't move and looks mostly the same
to the user while we wait for Vim to redraw with the updated grid.
There are some potential ways to still see flicker, but they are mostly
edge cases:
- When changing fonts, if Vim is slow and the user gets MacVim to
re-draw the text view (e.g. dragging the window to resize) while we
wait for Vim to resize, it would still draw an incorrect result (since
it has the new font, but old text grid). This should realistically
only happen if Vim takes an abnormal amount of time to respond.
- For tabs / scrollbars we have a similar issue. We immediately
place/remove them while we wait for Vim to resize, which could cause a
small visual discontinuity (easiest way is to toggle `go+=e`). From
testing, having the tab bar / etc immediately show up and hide feels
better as the user feels like something has happened, so keeping the
responsiveness is more important than delaying showing/hiding the tab
bar for visual stability (not to mention the deferral is more
complicated to implement).
If Vim takes a long time to resize/redraw, this change could make font
size change *feel* less responsive because nothing happens on the screen
until the fully redrawn screen is shown. This is ok, and if Vim takes so
long to resize then that's the actual issue to address.
This change also removes unnecessary code:
- Excessive and unnecessary redraws when showing/hiding tabs and setting
fonts. They were written a long time ago as temporary hacks which
survived till now. From testing this makes changing font size and
showing/hiding tabs feel a fair bit more responsive because Vim isn't
trying to redraw over and over again now.
- Stale "maximize" code that has long been unused. It was trying to solve
a similar issue but long obsolete and disabled.
We added a new step in #1540 to generate the image / icon set for the
dmg installer during the dmg build step, but the intermediate files were
erroneously placed in the same folder as the one being copied over,
causing them to be in the final dmg as well. Just use a scratch folder
instead.
This prevents using Cmd +/- to adjust font size resulting in guifont
being set from "-monospace-" to a non-user-friendly internal name like
".AppleSystemUIFontMonospaced-Regular".
Currently Vim syntax tests are quite broken and keep failing in MacVim
CI. There seems to be some Unicode / emoji handling bug causing tests to
fail sporadically, and the syntax tests also spam the console output as
they aren't redirecting output to /dev/null like normal Vim script
tests. Just disable them for now until this is fixed.
This should not cause much issues anyway. It's unlike MacVim will have
any downstream syntax/indent bugs as those files are mostly merged from
upstream as-is.
The existing background image for the MacVim dmg installer was quite
old. It did not have a 2x retina version, and design-wise it showed a
redundant MacVim logo when there's already a draggable MacVim app with
the same icon. Update the background image for a cleaner refreshed
design. Image was designed by Jason Long (@jasonlong).
Also, change the dmg's volume icon. We were using the MacVim logo as the
volume icon, but when mounting the image, it could lead to a confusing
state where the user sees a MacVim logo on the desktop, thinking it's
the app itself, but it's actually a dmg volume. Instead, use a new
designed volume icon with the macOS disk image icon overlaid with Vim's
logo/color for styling to make it clear it's a volume, not an app.
Tabs can now use colors defined by the Vim colorscheme under the
TabLine/TabLineFill/TabLineSel highlight groups. There are now 3
coloring modes available: default, automatic (the default mode that
generates matching colors using foreground/background colors), and Vim
colorscheme. The new mode looks quite nice in some colorschemes and
allows user customization, but for some existing ones it doesn't quite
look right as they were designed for non-GUI tabs, which is why it's not
the default.
MacVim window can now also use the tabline's fill color as the window
background color, which allows the title bar to show as a cohesive whole
when transparent title bar is set. This creates a nice look especially
when the colorscheme is designed for this.
Other tab coloring changes:
- Tabs now support high contrast mode (macOS accessibility setting) now.
The default colors will use higher contrast colors, and in all modes,
the tabs will be drawn with an outline similar to other system native
UI to aid visual differentiation.
- Tabs will also show a dimmed text color when the window has lost
focus, similar to other native title bar / tool bar UI elements.
- Fixed default colors to look a little better. Previously the fill
color and unselected tab background colors were the same.
In RTL locales (e.g. Arabic, Hebrew), macOS lays everything out in the
flipped direction, including most UI elements and native tabs. This
change makes sure MacVim tabs will obey the same convention and behave
intuitively in such locales. The buttons and UI elements in
MMTab/MMTabline already automatically get flipped. However, the logic of
handling the tabs placements, scrolling, and drag-and-drop use manual
calculations and need to be fixed up.
In order to keep scrolling stable, and for tabs animation to look
correct and the same as the left-to-right, we simply flip the frames we
use for tabs layout, by starting from 0 in X coordinate, and grow
towards the negative range. This helps keep most of the logic the same
while only needing to apply the X-flip adjustment in a couple places.
Also, as a minor adjustment, make the default widths of the tab just a
bit wider.
Use Apple Glossary for the new tab button translations. For the scroll
backward/forward buttons I took it from Firefox
(https://pontoon.mozilla.org/) under the arrowscrollbox strings.
This is not exposed in the user preference pane, as it should be a niche
case, but it's useful to have a way to turn off animations for either
accessibility or user preferences reasons.
When the GUI tab line is hidden (either due to `set showtabline` or `set
go-=e`), Vim stops sending update messages to the GUI. This means the
tabs were stale and would never get cleared, and the moment we show the
tabs we see a confusing animation when the tabs quicly try to rearrange
to match Vim's state. To fix this, just make sure to clean up and remove
all of them when we hide the tab line.
MMHoverButton was a bit inefficient in its image management. It always
made a new template image which then had to be converted into two other
images (image and alternateImage) for every button. Cache at least the
template images with weak references so we don't have to keep generating
new ones. For now, allow setImage: to create new images but they could
be changed to also just use cached images as well.
Also, fix memory leaks in the tabs codebase due to improper closure
usage in blocks. They were subtly capturing the self pointer which led
to the tab line and hover buttons never getting destroyed. Fix to make
sure we never accidentally capture self and try to capture as little as
possible.
Another leak happens in the usage of the local event monitor that we use
to intercept scroll wheel events. The API contract mandates that we
remove the monitor which the code never does. Make sure we do that, and
fix up the logic of the event interceptor to be more resilient and works
better with third-party software (which could inject horizontal scroll
events without holding down the Shift key).
Allows the user to set whether to show the tabs scroll buttons or not in
the preference pane as this is likely going to be a relatively popular
configuration.
Also, add new `macaction`'s for scrolling to selected tab and scrolling
backward/forward so the user doesn't have to use the mouse to scroll.
Fix misc issues with scrolling to a tab. The existing implementation
was animating both the bounds size and position which would cause issues
if the user resizes the window while still scrolling. Make sure the
animation only touches the position.
Also, the scrolling logic were using the physical locations of the
scroll bounds to determine scroll condition, which doesn't account for
the fact that it could be in the middle of animation. This led to rapid
clicking of the scroll buttons having some clicks being ignored.
Instead, fix it to always use the animated destination.
MMTabline was introduced in #1120, which replaced the ancient
PSMTabBarControl for representing Vim tabs. It uses animation to handle
tab layouts, but it only worked in some situations, due to the Vim IPC
API only sending a tabline update with all the tab labels with no way to
track individual tabs. Update the API so that Vim now sends individual
unique IDs in the update message as well to allow the GUI to track tabs
over time and animate them. Vim does not interally have a concept of
unique tab IDs, but we can use the pointer to the structure as such
because they are allocated as a linked list and will never change.
Extend MMTabline to have a new `updateTabsByTags` API to batch update
all tabs in one go, which will diff the new tags with existing tabs and
create/remove/move tabs as necessary. The scrolling logic has also been
moved inside it and it now only scrolls to selected tab when it has
changed or moved. When deleting tabs we won't scroll as usually the user
doesn't expect it. Dragging tabs also now work correctly when it is
removed during a drag, or another tab has been selected.
This does mean the add/close tab APIs are currently unused, as the only
entrypoint for modifying tabs from MacVim is currently only via
`updateTabsByTags`.
After this, different Vim operations will now animate correctly,
including `:tabmove`, `:bdelete` (which could remove multiple tabs at
once), `:tabnew`, `:tabclose`.
Only run the full suite of Vim tests when doing a tagged release.
Otherwise just either run GUI or non-GUI test on each platform. This
should catch most regressions in Vim upstream functionality, as even a
bad upstream merge should still exhibit the same issue in one of the
other (and most MacVim pull requests do not touch Vim to begin with).
This helps speeds up CI as currently it's quite time consuming to run
Vim tests twice.
We still run the whole thing for a release for now just to catch any
potential issues.
Given that building a dmg is fast, just always build it instead of only
doing so when doing a release. This allows a user to download fixes and
new features quickly to test it out locally. Note that the dmg will be
unsigned, however, and not officially blessed by the team. This is
essentially a nightly build for the project.
Add a sane upper limit to retention days for dev builds, just in case we
end up making a lot of artifacts this way (since we are doing this per
every commit to master now).
Also, remove the previous "--skip-jenkins" hack we passed to create-dmg.
It was necessary in previous runners due to permission issues but it
seems like new GitHub Actions images have relaxed on that so the script
runs without that flag now. This allows us to beautify the dmg image in
CI.
Problem: too many strlen() calls in os_unix.c
Solution: refactor os_unix.c and remove calls to strlen()
(John Marriott)
closes: #16496
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
We added code to rely on MAC_OS_X_VERSION_10_15, and therefore need to
add stub for that to make it buildable on older Xcode versions. Use this
opportunity to add the other missing ones to prevent future mistakes.
Problem: Crash after scrolling and pasting in silent Ex mode.
(fizz-is-on-the-way)
Solution: Don't move cursor to line 0 when scrolling.
(zeertzjq)
closes: #16506
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: N-Tripels and TriG files are not recognized
Solution: detect '*.nt' files as ntriples filetype and '*.trig' files
as trig filetype (Gordian Dziwis)
closes: #16493
Signed-off-by: Gordian Dziwis <gordian@dziw.is>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: Patch 9.1.1014 causes regressions
Solution: revert it for now
This reverts commit 57f0119358 since this
causes some regressions:
https://github.com/vim/vim/pull/16440#issuecomment-2600235629
So revert "patch 9.1.1014: Vim9: variable not found in transitive
import" for now.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Ignore the src/{LICENSE,README.txt} which are created from shadow
directories.
closes: #16499
Signed-off-by: ichizok <gclient.gaap@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Yee Cheng Chin
Sanjay Madan
John Marriott
glepnir
zeertzjq
Christian Brabandt
Gordian Dziwis
ichizok