Wu, Zhenyu [Thu, 9 May 2024 18:35:13 +0000 (20:35 +0200)]
patch 9.1.0401: filetype: zsh module files are not recognized
Problem: filetype: zsh module files are not recognized
Solution: Detect '*.mdh' and '*.epro' as C filetype, '*.mdd' as zsh
filetype, determine zsh-modules '*.pro' from from it's content
(Wu, Zhenyu)
closes: #14737
Signed-off-by: Wu, Zhenyu <wuzhenyu@ustc.edu> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0400: Vim9: confusing error message for unknown type
Problem: Vim9: confusing error message for unknown type
(Doug Kearns)
Solution: For an unknown type, display only the type name in the error
message (Yegappan Lakshmanan)
fixes: #13153
closes: #14736
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0399: block_editing errors out when using del
Problem: block_editing errors out when using del
(@Jamarley)
Solution: Change ins_len from size_t to int and
properly check that it doesn't become negative
There is a check in os.c that verifies that `ins_len` does not become
negative:
```
if (pre_textlen >= 0 && (ins_len = len - pre_textlen - offset) > 0)
```
However this only works, if ins_len can actually become negative and
unfortunately, ins_len has been declared as `size_t` so instead of
becoming negative it will wrap around and be very large.
So let's define it as integer, after which the condition above
properly catches this condition.
patch 9.1.0395: getregionpos() may leak memory on error
Problem: regionpos may leak memory on error, coverity
complains about dereferencing Null pointer
Solution: free all list pointers (after v9.1.394),
return early if buflist_findnr() returns NULL
Github is complaining about "This file has errors" and is just noisy
and for that reason does not ping maintainers if a new issue/PR is
created.
Let's just rename it to MAINTAINERS file instead and update the
documentation.
patch 9.1.0394: Cannot get a list of positions describing a region
Problem: Cannot get a list of positions describing a region
(Justin M. Keyes, after v9.1.0120)
Solution: Add the getregionpos() function
(Shougo Matsushita)
fixes: #14609
closes: #14617
Co-authored-by: Justin M. Keyes <justinkz@gmail.com> Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
D. Ben Knoble [Mon, 6 May 2024 17:52:53 +0000 (19:52 +0200)]
runtime(sh,zsh): clear $MANPAGER in ftplugin before shelling out
Say you use Vim and set MANPAGER='vim -M +MANPAGER --not-a-term -'; then
:{Zs,S}hKeywordPrg (or K) will crap out and spew terminal garbage into
less when bash's "help" fails. This was introduced by 2f25e40b1
(runtime: configure keywordpg for some file types (#5566), 2023-08-23)
and may be present in other files touched by that commit.
Make the "man" invocation sensible by unsetting MANPAGER in the
environment.
Note that changing MANPAGER for `:terminal` is not needed; Vim within
Vim is perfectly fine.
closes: #14679
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0392: tests: Vim9 debug tests may be flaky
Problem: tests: Vim9 debug tests may be flaky
(Shane-XB-Qian)
Solution: Give a few more lines so that line-wrapping won't
cause a hit-enter prompt
The two tests Run_Test_debug_running_out_of_lines() and
Run_Test_debug_with_lambda() test debugging of Vim script functions.
Depending from what file-path the tests are run, it may cause
line wrapping to occur on the following output:
Entering Debug mode. Type "cont" to continue.
command line..script
/home/chrisbra/code/vim-upstream/src/testdir/XdebugFunc[15]..function
<SNR>9_Crash
and if the window is too small, this will cause a hit-enter prompt and so
the WaitForAssert() fails, causing failure of the following tests.
So increase the (internal) Vim window by a few more lines, so that even
if line-wrapping occurs, no hit-enter prompts happens and so the tests
can finish.
Philip H [Wed, 1 May 2024 16:42:11 +0000 (18:42 +0200)]
patch 9.1.0386: filetype: stylus files not recognized
Problem: filetype: stylus files not recognized
Solution: Detect '*.styl' and '*.stylus' as stylus filetype,
include indent, filetype and syntax plugin
(Philip H)
closes: #14656
Signed-off-by: Philip H <47042125+pheiduck@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0381: cbuffer and similar commands don't accept a range
Problem: cbuffer and similar quickfix and locationlist commands don't
accept a range, even so it is documented they should
(ilan-schemoul, after 8.1.1241)
Solution: Define ex commands with ADDR_LINES instead of ADDR_OTHER
runtime(java): Improve the recognition of the "indent" method declarations (#14659)
There is a flaw in the current implementation that has been
exacerbated around v5.2. It lies in the recognition of all
three indentation styles simultaneously: a tab, two space,
and eight space character(s). With it, it is not uncommon
to misidentify various constructs as method declarations
when they belong to two-space indented members and other
blocks of a type and are offset at eight space characters or
a tab from the start of the line.
For example,
------------------------------------------------------------
class Test
{
static String hello() { return "hello"; }
public static void main(String[] args)
{
try {
if (args.length > 0) {
// FIXME: eight spaces.
System.out.println(args[0]);
} else {
// FIXME: a tab.
System.out.println(hello());
}
} catch (Exception e) {
throw new Error(e);
}
}
}
------------------------------------------------------------
A better approach is to pick an only indentation style out
of all supported styles (so either two spaces _or_ eight
spaces _or_ a tab). Note that tabs and spaces can still be
mixed, only the leading tab or the leading run of spaces
matters for the recognition. And there is no reason to not
complement the set of valid styles with any number of spaces
from 1 to 8, inclusively.
Please proceed with the necessary change as follows:
- rename from "indent" to "indent2" for a 2-space run;
- rename from "indent" to "indent8" for an 8-space run;
- continue to have "indent" for a tab run;
- define an "indent" variable with a suffix number denoting
the preferred amount of indentation for any other run of
spaces [1-8].
As before, this alternative style of recognition of method
declarations still does not prescribe naming conventions and
still cannot recognise method declarations in nested types
that are conventionally indented.
The proposed changes also follow suit of "style" in stopping
the claiming of constructor and enum constant declarations.
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0380: Calculating line height for unnecessary amount of lines
Problem: Calculating line height for unnecessary amount of lines with
half-page scrolling (zhscn, after 9.1.0280)
Solution: Replace "limit_winheight" argument with higher resolution
"max" argument to which to limit the calculated line height
in plines_m_win() to (Luuk van Baal)
fixes: #14650
closes: #14652
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0378: Vim9: no comments allowed after class vars
Problem: Vim9: no comments allowed after class vars
(Christian Robinson, after 9.1.376)
Solution: Allow trailing comments after class vars
(Yegappan Lakshmanan)
closes: #14651
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0377: Formatting text wrong when 'breakindent' is set
Problem: formatting text wrong when 'breakindent' is set
(Gary Johnson)
Solution: temporarily disable 'breakindent' option when formatting text,
so that the breakindent is not wrongly taken into account for
the line length
Problem: When :edit an existing buffer, line('w$') may return a
wrong result.
Solution: Reset w_valid in curwin_init() (Jaehwang Jung)
`do_ecmd()` reinitializes the current window (`curwin_init()`) whose
`w_valid` field may have `VALID_BOTLINE` set. Resetting `w_botline`
without marking it as invalid makes subsequent `validate_botline()`
calls a no-op, thus resulting in wrong `line('w$')` value.
closes: #14642
Signed-off-by: Jaehwang Jung <tomtomjhj@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0372: Calling CLEAR_FIELD() on the same struct twice
Problem: Calling CLEAR_FIELD() on the same struct twice.
Solution: Remove the second CLEAR_FIELD(). Move the assignment of
cookie.sourceing_lnum (zeertzjq).
closes: #14627
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0370: MS-Windows: patch number is zero in installer
Problem: MS-Windows: patch number is zero in installer
(jonathan-b-wiebe)
Solution: Set VIM_VERSION_PATCHLEVEL, fix a few typos in the installer
(RestorerZ)
fixes: #14629
closes: #14635
Signed-off-by: RestorerZ <restorer@mail2k.ru> Signed-off-by: Christian Brabandt <cb@256bit.org>
runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: #14620
Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0369: Vim9: problem when importing autoloaded scripts
Problem: Vim9: problem when importing autoloaded scripts
Solution: In `:def` handle storing to vim9 autoload export
(Ernie Rael)
Problem occurs when `import autoload ./.../autoload/...`. The autoload
in the specified path causes the use of an autoload_prefix which combines
with the `import autoload` to create trouble.
In `generate_store_var()` `case dest_script` use ISN_STOREEXPORT,
when needed, instead of ISN_STORES. When executing ISN_STOREEXPORT,
check for autoload_prefix.
patch 9.1.0368: MS-Windows: Hard to define the Vim Patchlevel with leading zeroes
Problem: MS-Windows: Hard to define the Vim Patchlevel with leading
zeroes for the installer
Solution: re-define VIM_VERSION_PATCHLEVEL_STR with leading zeroes,
interpret Patchlevel as decimal in Make_mvc.mak
(RestorerZ)
closes: #14471
Signed-off-by: RestorerZ <restorer@mail2k.ru> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0365: Crash when typing many keys with D- modifier
Problem: Crash when typing many keys with D- modifier (after 9.1.0227).
Solution: Don't treat a 0x80 byte inside a special sequence as the start
of a special sequence (zeertzjq).
closes: #14613
Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0363: tests: test_winfixbuf is a bit slow
Problem: tests: test_winfixbuf is a bit slow
Solution: use defer if possible, reset hidden option, use --not-a-term
when starting Vim using system() (Yegappan Lakshmanan)
closes: #14611
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0362: expanding rc config files does not work well
Problem: expanding rc config files does not work well
(Michał Sieroń, after v9.1.0327)
Solution: initialize chartab option, required to expand
evironment variables
fixes: #14597
Co-authored-by: author Signed-off-by: author Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0360: Vim9: does not handle autoloaded variables well
Problem: Vim9: does not handle autoloaded variables well
Solution: Better handle script-level exported variable references from
autoload files (Ernie Rael).
fixes: #14591
closes: #14607
Signed-off-by: Ernie Rael <errael@raelity.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0359: MS-Windows: relative import in a script sourced from a buffer doesn't work
Problem: MS-Windows: Relative import in a script sourced from a buffer
doesn't work (Ernie Rael)
Solution: Set a filename, so that we are not trying to use
script-relative filename (Yegappan Lakshmanan)
When a script is sourced from a buffer, the file name is set to ":source
buffer=". In MS-Windows, the ":" is a path separator character (used
after a drive letter). This results in the code trying to use the ":"
prefix to import the script on MS-Windows. To fix this, when importing a
script from a script sourced from a buffer with nofile, don't use
a script relative path name.
fixes #14588
closes: #14603
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
patch 9.1.0357: Page scrolling should place cursor at window boundaries
Problem: Page scrolling does not always place the cursor at the top or
bottom of the window (Mathias Rav)
Solution: Place the cursor at the top or bottom of the window.
(Luuk van Baal)
fixes: #14585
closes: #14586
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
projects / thirdparty / vim.git / log
