Updated to Vim 9.0.1897
Special Notes
====================
As some of you may have read, Bram Moolenaar, the creator of Vim, has
[passed away](https://groups.google.com/g/vim_announce/c/tWahca9zkt4)
recently. He has worked tirelessly on Vim for more than 30 years and
this release is dedicated to him. If you would like, you could pay your
respects at [this discussion
thread](https://github.com/vim/vim/discussions/12737).
The Vim project has transitioned to new maintainers, and MacVim will continue
to be supported as long as Vim is around.
Features
====================
More flexible Python integration
--------------------
MacVim now allows you to use Python runtime (via `pythonthreedll`, used
for Python plugins) of any version at or above 3.9. Previously you had
to use the exact same version that was used to build MacVim (Python
3.11). The Python detection logic is also updated to always just find
the latest version of Homebrew Python instead of a fixed one, and it
will also now locate the default macOS / Xcode Python provided by the
Xcode Command Line Tools if that is the only Python available. This
should hopefully make configuring Python for MacVim a lot more seamless.
See `:h python3-stable-abi`. Vim v9.0.1776 / #1428.
New Vim features
--------------------
- New built-in support for [EditorConfig](https://editorconfig.org/) via
an optional package. Use `packadd editorconfig` to activate it. See
vim/vim#12902.
- `g<End>` now goes to the first non-blank char. v9.0.1753
- API changes
- `undotree()` now takes a bufnr v9.0.1686
- `printf()` now takes positional arguments v9.0.1704
- `virtcol()` now takes winid v9.0.1728
- quickfix items can now have user data v9.0.1688
- Miscellaneous security fixes.
Security Fixes
====================
- Fixed insecure usages of interprocess communication in MacVim
(CVE-2023-41036)
Fixes
====================
- Fixed MacVim to correctly set up the runtime folder in the app bundle.
As a corollary, `xxd` is now bundled with MacVim like most other Vim
distributions, and MacVim.app now provides man page for the CLI vim
commands if the user wants to associate man pages with the `mvim`
comamnd (see `:h macvim-PATH`). #1430
- Fixed Vim occasionally crashing and/or hung when autocmd calls
`serverlist()` on exit. #1427
Scripting
====================
- Scripting languages versions:
- Python now supports 3.9 or above.
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.9 or above
- Ruby 3.2
Currently, MacVim uses Distributed Objects / NSConnection as the IPC
mechanism. The child Vim process connects to the parent MacVim process
using NSConnection and registers itself. A security issue with this is
that NSConnection is global, and any process can connect to the app, and
MacVim isn't too hardened against this issue. Note that one reason why
we do need the ability for the MacVim app to accept random connections
is to support the `:gui` command from a random Vim process, and to
supported listing server names.
One issue is that while the app protocol (MMAppProtocol) is only a few
functions, we were exposing the entire app, which exposes functions like
`executeInLoginShell`, which could be invoked by the caller, which is
quite unsafe as it could be invoked by any third-party app. Fix this
issue by using `NSProtocolChecker` to make sure we only expose the APIs
that we want to expose.
Each Vim controller now also gets a randomized ID instead of an
incremental one. Currently the API for sending messages from Vim to
MacVim is public, meaning any app can send message to MacVim. Using a
randomized ID makes it more difficult for an attacker to guess the ID
(which used to always start at 1) and injects random commands to MacVim
pretending to be the Vim process.
Also, make sure if MacVim failed to register the NSConnection on launch,
just display an error and terminate. This usually happens if multiple
MacVim instances are opened, but also if an attacking app is trying to
register a connection first using the same name. This way the user would
know something is wrong instead of MacVim being opened by not able to do
anything as it didn't register the connection.
In the near future, the IPC mechanism will be switched to XPC, which is
the preferred way by Apple as Distributed Objects has been deprecated
for a long time. It will have proper security to only accept processes
within the same app to message each other. It will be done in #1157.
Previously, MacVim's build process simply used an Xcode post-build
script to copy the runtime folder to the target app bundle's
Contents/Resources/vim/runtime folder and called it a day. However,
that's actually not the correct procedure because the runtime folder
contains misc files (e.g. Makefile/testdir for testing) and they should
go through a install step using `make install` to properly deploy the
proper files to the target folder.
Fix this by changing the post-build script to call the relevant make
targets instead of just blindly copying it over. We still copy the
vim/view/etc and vimtutor binaries separately for now, because the mvim
script is a custom script for MacVim, although that could change in
future.
One of the corollary of using the builtin installation scripts is that
man pages (for CLI vim/gvim usage) are now properly generated. They are
now stored under `MacVim.app/Contents/man`, and a user can set MANPATH to
it if they so wish.
Another corollary is that we now bundle xxd with MacVim like most Vim
distributions. It was probably an oversight before, and now it's built
and bundled in the `MacVim.app/Contents/bin` folder like the
vim/view/mvim scripts.
One annoying thing with Xcode is that in order for incremental builds to
work properly we want it to only run this installation step if the
runtime folder has changed (it takes a couple secs to finish) and
Xcode's input file lists doesn't support recursive folder search. To fix
this, add a build step to manually generate the list of all runtime
folders called runtime_folder_list.xcfilelist which we pass to the build
step.
Fix#1417
Problem: Vim9: confusing error with .= in compiled functions
Solution: Check in error condition, if .= was attempted and in that case
give a different error message.
closes: #12972closes: #13066
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: "below" virtual text doesn't work with 'rightleft'.
Solution: Use column from right border with 'rightleft'.
closes: #13071
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: Vim9: lookup code for class/object repaeated
Solution: Refactor and make use of lookup functions
closes: #13067
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Since https://docs.scala-lang.org/sips/42.type.html which is implemented
in Scala 2.13 and in Scala 3 it possible to use string literals as
singleton types. So code like
```
someFunc["abc"]
```
is valid. Currently this code is not hightlighted correctly and worse if
there is an unclosed `(` in the string it breaks the formating in the
rest of the file.
I also submitted this patch to the mentioned project for this runtime
file: https://github.com/derekwyatt/vim-scala/pull/173 But there are no
commits there over the last 2 years and no response in the week since I
created it. Also the last change to the Scala syntax file:
https://github.com/vim/vim/pull/9594 is yet to be backported to that
repo. Therefore I am opening this PR as well to get some feedback on how
to proceed to get this fixed.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Vim added support for using Python 3 stable ABI in 9.0.1776, which
allows us to safely load Python libraries of a different version from
what Vim was built against. Modify our CI to use that. This allows user
to use whatever Python version they want as long as it's above the
minimum target. Given that macOS/Xcode still ships with 3.9 by default,
we build using 3.9 as the minimum version.
Also, change our Python detection script to work better. Change all
explicit versions in our paths to refer to the "Current" version instead
which for the most part should "just work" instead of requiring an exact
match every time we or Python update to a new version (e.g. Homebrew
will update the Current version to point to the latest Python3). Also
add support for finding Python 3 from Xcode Command Line Tools which was
previously not ok to use technically because it's 3.9 and before stable
ABI support we couldn't load it safely as MacVim was built using newer
versions.
Fix#1351.
Previously, Vim didn't always have up-to-date help tags. As a result, we
just manually generate the help tags when publishing a release (#1286),
even though it doesn't actually make sure the tags file in source is
actually accurate. However, Vim has since added CI checks to make sure
the help tags are correct, so we can change MacVim CI to do the same
thing as well. This way, the source version is always correct and we
won't rely on a build step during release to fix it, and it also makes
sure other methods to get MacVim (build from source, Homebrew) will be
correct as well.
Problem: Vim9: Problem trying to invoke class method
Solution: Lookup the class method insider other classes
closes: #13055
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: class members are accessible via object
Solution: Disable class member variable access using an object
Class methods can be accessed only using the class name and cannot be
accessed using an object. To be consistent with this, do the same for
class member variables also. They can be accessed only using the class
name and not using an object.
closes: #13057
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Currently, when quitting MacVim using Cmd-Q, if an autocmd queries
serverlist() during shutdown (e.g. VimLeavePre), there's a potential
that Vim will crash and then stuck in a spinloop and never gets killed
by the parent process.
The reason is somehwat complicated. MMAppController tells Vim to quit
but has a hard-coded timer before terminating the connection. If Vim
takes too long to respond somehow, it will see a "connectionDidDie"
message where it will be forced to quit. The serverlist() IPC API call
isn't properly guarding against an invalid connection and if an autocmd
triggers that call during this time, it will throw an exception and
crash.
Usually if Vim crashes, it should terminate cleanly, but couple things
cause this to not work properly:
- Vim's signal handler `deathtrap` tries to exit cleanly when a signal
is detected, and it tries to call all deferred functions (added by
:defer in Vimscript). The list of functions are allocated on the stack
rather than the heap.
- The ObjC exception is thrown inside a CFRunLoop (which is what called
connectionDidDie) and CFRunLoop silently handles the exception before
re-throwing it which triggers the actual abort signal to be caught by
Vim's signal handler, but at this time, the deferred functions data
structure is messed up as the stack is already gone since the first
exception unwound it. This leads to a bogus memory state and lead to
an infinite loop in `invoke_all_defer`.
MacVim also doesn't have a solid mechanism to shut down zombie processes
right now (it depends on Vim cleaning up after itself), so after MacVim
quits, the now-orphaned Vim process stuck consuming 100% CPU.
The fix is to simply guard against this and make sure we clean up the
connection properly when we detected it died, and to be more defensive
and make sure the serverlist call properly guard against invalid states
and exceptions.
Not tackling the other issues for now. There are some unfortunate
interactions here with an unwound exception causing invoke_all_defer()
to not work, but we just need to make sure to guard potential places
with try/catch blocks, as invoke_all_defer() is still useful. Also,
proper zombie process killing will be done at a later time, as we will
soon tackle removing Distributed Objects/NSConnection and revamp the
entire IPC stack anyway.
Fix#1423
Problem: Vim9: no support for abstract methods
Solution: Add support for defining abstract methods in an abstract class
closes: #13044closes: #13046
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Modified behavior:
- Change default value of g:html_use_input_for_pc from "fallback" to
"none". This means with default settings, only the standards-based
method to make special text unselectable is used. The old method
relying on unspecified browser behavior for <input> tags is now only
used if a user specifically enables it.
- Officially deprecate g:use_xhtml option (in favor of
g:html_use_xhtml) by issuing a warning message when used.
Bugfixes:
- Fix issue #8547: LineNr and other special highlight groups did not
get proper style rules defined when using "hi link".
- Fix that diff filler was not properly added for deleted lines at the
end of a buffer.
Other:
- Refactored function definitions from long lists of strings to use
:let-heredoc variable assignment instead.
- Corrected deprecated "." string concatenation operator to ".."
operator in more places.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Wrong order of arguments for error messages
Solution: Reverse order or arguments for e_aptypes_is_null_nr_str
closes: #13051
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Problem: Vim9: Calling an interface method using a child object fails
Solution: Search methods of parent class
When a class implementing an interface is extended by another class and
a child class instance is passed to a function that accepts the
interface, calling an interface method doesn't work properly.
closes: #13053
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Trailing white space in tests
Solution: Delete it
This causes test_codestyle to fail, so we need to remove it again.
Hopefully that makes the CI green again.
Note: I will start using annotated tags from now on.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: Need more tests for inheritance
Solution: Add access tests and fixes.
`inside_class` fix from yegappan. `object_index_from_itf_index` fix
access of member on class extending class implementing interface.
Based on tests from Vim9: Class/Object member variable access control #12979closes: #13032
related: #12979
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Ernie Rael <errael@raelity.com>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
This is a followup to 816fbcc262 (patch
9.0.1833: [security] runtime file fixes)
It basically disables that external commands are run on loading of the
filetype plugin, **unless** the user has set the `g:plugin_exec = 1`
global variable in their configuration or for a specific filetype the
variable g:<filetype>_exec=1.
There are a few more plugins, that may execute system commands like
debchangelog, gitcommit, sh, racket, zsh, ps1 but those do at least
do not run those commands by default during loading of the filetype plugin
(there the command is mostly run as convenience for auto-completion or
to provide documentation lookup).
closes: #13034
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Tim Pope <vim@tpope.org>
Problem: Vim9: incorrect duplicate class member detection
Solution: Incorrect duplicate class member detection when variable names
have the same prefix. Not able to access class member variables
using an object. Fix coding style issues
closes: #13042
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: missing test for patch 9.0.1873
Solution: add a test trying to exchange windows
Add a test, making sure that switching windows is not allowed when
textlock is active, e.g. when running `:s/<pat>/\=func()/`
Signed-off-by: Christian Brabandt <cb@256bit.org>
In case the current directory is present as valid $PATH entry, it is OK
to call the program from it, even if vim curdir is in that same
directory.
(Without that patch, for instance, you will not be able to open .zip
files while your current directory is /bin)
closes: #13027
Signed-off-by: Christian Brabandt <cb@256bit.org>
