Problem: Vim9: hard to debug vim9_class errors from CI
Solution: Include the line number in assert_xxx() calls. Include the
entire error message in the tests. Fix the indentation in the
test file. Add tags for new error codes.
closes: #13206
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: error codes spread out
Solution: group them together and reserve 100
more for future use
Reserve 100 error codes for future enhancements to the Vim9 class
support
closes: #13207
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Vim9: object variable "this." should only be used in
constructor
Solution: Disallow to this in normal object methods (other than
constructors)
closes: #13152closes: #13212
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: h-east <h.east.727@gmail.com>
Commit f6fc255e8d (v9.0.1834) updated xxd.1 but the xxd.man
page wasn't re-generated. So let's just regenerate it now.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filename expansion using ** in bash may fail
Solution: Try to enable the globstar setting
Starting with bash 4.0 it supports extended globbing using the globstar
shell option. This makes matching recursively below a certain directory
using the ** pattern work as expected nowadays. However, we need to
explicitly enable this using the 'shopt -s globstar' bash command.
So let's check the bash environment variable $BASH_VERSINFO (which is
supported since bash 3.0 and conditionally enable the globstar option,
if the major version is at least 4. For older bashs, this at least
shouldn't cause errors (unless one is using really ancient bash 2.X or
something).
closes: #13002closes: #13144
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: missing support for ro-vars in interface
Solution: Support only read-only object variables in an interface,
add additional checks when parsing class definitions.
closes: #13183
cloess: #13184
cloess: #13185.
closes: #13188
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
ftplugin/rmd.vim:
- Set 'commentstring' dynamically according to code region.
syntax/rmd.vim:
- Include syntax highlighting of fenced languages dynamically.
- Add conceal char for line break.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: runtime tests fail with tiny vim
Solution: check for tiny vim, run runtime tests in CI
even for tiny version
closes: #13169closes: #13170
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Dominique Pellé <dominique.pelle@tomtom.com>
Problem: No filetype detection for Authzed filetypes
Solution: Detect the *.zed file extension as authzed filetype
closes: #13129
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Matt Polzin <mpolzin@workwithopal.com>
Problem: Crash when allocating large terminal screen
Solution: Don't allow values > 1000 for terminal
screen columns and rows
closes: #13126
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: r_CTRL-C works differently in visual mode
Solution: Make r_CTRL-C behave consistent in visual mode
in terminal and Windows GUI
in visual mode, r CTRL-C behaves strange in Unix like environments. It
seems to end visual mode, but still is waiting for few more chars,
however it never seems to replace it by any characters and eventually
just returns back into normal mode.
In contrast in Windows GUI mode, r_CTRL-C replaces in the selected area
all characters by a literal CTRL-C.
Not sure why it behaves like this. It seems in the Windows GUI, got_int
is not set and therefore behaves as if any other normal character has
been pressed.
So remove the special casing of what happens when got_int is set and
make it always behave like in Windows GUI mode. Add a test to verify it
always behaves like replacing in the selected area each selected
character by a literal CTRL-C.
closes: #13091closes: #13112
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: problem calling class method from other class
Solution: Fix this problem, fix readonly object access, update error
messages.
Calling a class method from another method without the class name prefix
doesn't work properly.
A readonly object variable is modifiable outside the class using a
nested object assignment.
Remove the unused E1338 error message.
Update error messages.
closes: #13116
Signed-off-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
closes: #12990closes: #12992
this partially reverses commit 71badf9 by commenting out the line that
intentionally sets the filetype to an empty string.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Fix the issue introduced by #12557. `:substitute` commands in plugins
need to take into account whether `gdefault` is set or not because
that depends on the user.
closes: #13097
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add a small section about the distributed Editorconfig plugin at :h
usr_05.txt just below the matchit plugin. While editing that help
document, also add a bit of more documentation about standard plugins
and local help file additions.
Regenerate $VIMRUNTIME/doc/tags file with all the new tags from the rust
runtime files.
While at it, update the Editorconfig help page (and re-generate the
helptags file).
closes: #13078
Signed-off-by: Christian Brabandt <cb@256bit.org>
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>
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>
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>
