In macOS 13 Ventura, the general terminology of "Preferences" has been
renamed to "Settings". The main menu's "Preferences…" item is
automatically renamed to "Settings…" by the OS when building against the
macOS 13 SDK, but we still need to update documentation to match.
Add a new Vim script function `showdefinition()` that allows Vim script
to call back to macOS's data lookup feature and show the definition /
URL preview / etc for any text, at a designated row/col position. If the
row/col are not provided this function will just show it at the cursor.
Also, add a new autoload/macvim.vim for utility functions to call
showdefinition() for selected texts and the word under cursor. Make a
new right-click popup menu "Look Up" call that when there are selected
texts in visual mode to make the lookup functionality easier to access
for users without a trackpad (since Ctrl-Cmd-D is a little obscure and
unwieldy to use). For the utility functions, it was a little hard to
determine how to get the text under visual selection without yanking (we
don't want to pollute the register here), and just implemented a
function to take care of all the edge cases including visual/block/line
modes and selection=exclusive. It could be useful in other situations.
As a side refactor, change the message handler in MacVim from if/else to
switch case. In optimized builds, they both essentially optimize to the
same thing, but for debug builds, the if/else statements have to step
through one by one, and switch case just makes more sense for a giant
message ID lookup like this.
Part of Epic #1311
This adds support for looking up data under the mouse cursor. Usually it
will bring up a dictionary, but other times it could be a Wikipedia
article, Siri knowledge, etc. Apple doesn't really have a good name for
it, other than "looking up data", "quick look" (a confusingly similar
name with the other Quick Look OS feature), or "show definition". You
can activate this by doing Ctrl-Cmd-D when the mouse is over a cursor.
If you have a trackpad, you can also either activate this using Force
click or three-finger tap (depends on your system preference settings).
Note that for Force click, this could potentially make it impossible to
use the MacVim `<ForceClick>` mapping in Vim, which allows you to map a
force click to a Vim command (#716). This is handled by having a new
setting (under a new "Input" preference pane which will have more
populated later) that allows you to choose whether to use Force click
for data lookup or Vim's `<ForceClick>` mapping. If you have configured
to use three-finger taps though this setting wouldn't do anything, and
`<ForceClick>` is always send to the Vim mapping.
Also, this is lacking a lot of features that a normal macOS application
would get, e.g. looking up selected texts (e.g. if you have "ice cream",
you may want to select the whole thing to look up the phrase, rather
than just "ice" or "cream"), data detector, and much more (e.g. custom
API support). They will be done later as part of #1311.
Technical details below:
The way the OS knows how to look up the data and present it is by
talking to the NSTextInput/NSTextInputClient. Previously MacVim
implemented NSTextInput partially, and didn't implement the critical
firstRectForCharacterRange:actualRange and characterIndexForPoint:
functions. First, in this change we change from NSTextInput to
NSTextInputClient (which is the newer non-deprecated version), and
implement those functions, which allows the OS to query the text
storage.
By default, the OS sends a quickLookWithEvent: call to us whenever the
lookup happens but for some odd reason this isn't automatic for Force
clicks, presumably because some apps want to handle Force clicks
manually (this is why some apps only work for three-finger taps but not
Force clicks for lookups). This isn't documented but I found references
in iTerm/Firefox, and basically we just need to manually handle it and
send off quickLookWithEvent: when handling Force clicks.
For implementing the NSTextInputClient properly, the main issue is
making sure that can work properly with input methods / marked texts,
which is the other primary purpose for this class (other than inputting
keys). For data lookups, I'm representing the grid as a row-major text
(with no newline/space in between) and expose that to the OS. This
already has some issue because it doesn't handle Vim vertical splits
well, as MacVim doesn't really have access to detailed Vim text buffers
easily (unless we do a lot of calls back-and-forth). This means wrapped
texts won't be looked up properly, which I think is ok. Also, the OS
APIs deal with UTF-8 indices, so we can't just convert row/column to raw
indices and have to do a lot of character length calculations
(especially for wide chars like CJK or emojis) to make sure the returned
ranges are consistent and valid. For marked texts though, this presents
a challenge because Vim doesn't really have a strong enough API to
communicate back-and-forth about the marked positions and whatnot (it
only let the GUI know where the current cursor is), and it's hard to
implement APIs like `markedRange` properly because some marked texts
could be hidden or wrapped (if you implement some of these functions
improperly Apple's input methods could start misbehaving especially when
you use arrow keys to navigate). In the end I kept the original
implementation for treating the marked texts as a range starting from 0,
*only* when we have marked text. Kind of a hack but this makes sure we
work both in marked text mode (i.e. when inputting texts) and when doing
lookups. For simplicity I made it so that you can't do data lookups when
in marked text mode now.
Input method:
This change also fixes a quirk in input method as a driveby change.
Previously the logic for calculating the rect for where the candidate
list was quite broken, but now it's calculated correctly using the
desired range and the current cursor position. This matters when say
using Japanese IM and using the left/right arrow to jump to different
sections of the text. If the desired range is in a wrapped line, the new
logic would attempt to pin it to the left-most column of where the
cursor is in the range.
Data detection:
Note that the default implementation is quite bare, and lacks a lot of
smart data detection. For example, if you put your mouse over a URL, it
won't properly select the whole URL, and addresses and dates for example
also won't get grouped together properly. This is because these require
additional implementation (e.g. using NSDataDetector) instead of coming
"for free", and will be handled later. In fact, Apple's WebKit and
NSTextView cheats by calling an internal API framework called "Reveal"
(which you can find out by intercepting NSTextView's calls and/or
looking at WebKit's source code) which is much more powerful and
supports looking up package tracking, airline info, and more, but it's
not available to third-party software (that's why Safari's lookup is so
much better than Chrome/Firefox's).
This isn't tested right now. Future task needs to add XCTest support to
properly test this as there are a lot of edge cases involved here.
Fix#1191
Part of Epic #1311, which contains other items to be implemented.
Problem: Quitting/unloading/hiding a terminal buffer does not always work
properly.
Solution: Avoid that ":q!" leaves an empty buffer behind. ":bunload!" also
kills the job and unloads the buffer. ":hide" does not unload the
buffer. (Yee Cheng Chin, closes#11323)
Problem: There is no real need for a "big" build.
Solution: Move common features to "normal" build, less often used features
to the "huge" build. (Martin Tournoij, closes#11283)
Problem: Too many #ifdefs.
Solution: Graduate the +cmdwin feature. Now the tiny and small builds are
equal, drop the small build. (Martin Tournoij, closes#11268)
Problem: Cannot specify another character to use instead of '@' at the end
of the window.
Solution: Add "lastline" to 'fillchars'. (Martin Tournoij, closes#11264,
closes#10963)
Problem: The 'splitscroll' option is not a good name.
Solution: Rename 'splitscroll' to 'splitkeep' and make it a string option,
also supporting "topline". (Luuk van Baal, closes#11258)
Problem: Evaluating "expr" options has more overhead than needed.
Solution: Use call_simple_func() for 'foldtext', 'includeexpr', 'printexpr',
"expr" of 'spellsuggest', 'diffexpr', 'patchexpr', 'balloonexpr',
'formatexpr', 'indentexpr' and 'charconvert'.
Problem: matchaddpos() can get slow when adding many matches.
Solution: Update the next available match ID when manually picking an ID and
remove check if the available ID can be used. (idea by Rick Howe)
Add a setting that could pin the command-line portion of Vim to the
bottom of the MacVim window. This is useful when smooth resizing is set,
guioption+=k, or in full screen. In those situations, the MacVim window
size is usually not direct multiples of the Vim text sizes. Previously
the command-line would be drawn like other texts, and hence not aligned
to the bottom and hence looking aesthetically a little off.
When this setting is set, the command-line portion would be aligned to
the bottom of the window. This essentially moves the gap (due to the
extra height of the window) from the bottom to be between cmdline and
the rest of Vim. When cmdheight is changed, or other situations (e.g.
typing too much cmdline height to be increased), the gap will be
adjusted as well.
Implementation-wise, this was done by passing the `commandline_row` var
from Vim to MacVim, which serves as a good estimate of where the
command-line is. This works better than just using the `cmdheight`
option as it is closer to the current state of the cmdline. One issue is
that in hit-enter prompts, the row is set to the 2nd to last row to
anticipate more messages, and we just add a big hack by incrementing the
row by 1 in hit-enter state so only the "Press Enter..." part is aligned
to bottom. We also have to do something similar to when it's showing
"--more--" for similar reasons.
- An alternative would have been to modify Vim to provide us the
information we want (the number of rows below the status line) but
it's pretty tricky to do as cmdline_row is used in lots of places.
It's easier / simpler to do a simple hack like this to localize the
damage.
Close#833
Problem: When opening/closing window text moves up/down.
Solution: Add the 'splitscroll' option. When off text will keep its
position as much as possible.
Adds a setting that allows for smoothly resizing the window. Previously,
MacVim would only allow resizing in fixed increment of the grid size and
snap to such sizes. This was a little more consistent with how terminals
tend to work, and allows for optimal window sizing, and it was also an
artifact of the old MacVim renderer where it didn't have a stateful
renderer that could repaint the text view.
The snapping could be jarring for users more used to modern text editors
which allow for smoothly resizing of the window though, and it makes
third party tools that could snap macOS windows to the side not work
properly as there's usually a gap near the bottom. With guioption-k,
MacVim already allows for decoupling the window size from the Vim's grid
size anyway, so adding smooth resizing allows to work much better under
those assumptions.
In addition to allowing smooth resizing, this change also makes it so
that the CoreText renderer will fill to the right a little bit when
rendering the rightmost column when MacVim's window size isn't exactly
the Vim grid size. Previously, if a color scheme has NonText color (e.g.
desert), or the user has 'cursorline' set, smooth resize (or in full
screen or guioption-k) would leave a gap to the right, looking a little
ugly. This allows the last column's to fully fill to the right,
resulting in a much more consistent look when resizing the window.
Close#948
Problem: Only created files can be cleaned up with one call.
Solution: Add flags to mkdir() to delete with a deferred function.
Expand the writefile() name to a full path to handle changing
directory.
