The end marker must appear on line of its own without any trailing
whitespace.
Whitespace is incorrectly allowed before all end markers. Limiting this
only to heredocs where "trim" was specified, and with the correct
indent, is currently an intractable problem given that contained syntax
groups (in this case :let) cannot be limited to start patterns.
Highlight interpolated expressions when "eval" is specified.
cloess: vim/vim#15511https://github.com/vim/vim/commit/d164f2a521f8e52e587727657fb1c19e9a25f32a
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
It addresses the following issues:
- Fix highlight of let and var javascript keywords
According to runtime/doc/syntax.txt, Identifier is for variable names.
let/var are not variable names, they are keywords
- Add highlighting for "from" keyword in javascript
- Fix highlight of function keyword in javascript
According to docs, Function is for function names, so the function
keyword should just be Keyword.
- Fix highlight of static keyword in javascript
According to vim docs: StorageClass static, register, volatile, etc.
closes: vim/vim#15480https://github.com/vim/vim/commit/ea76096fa98ac26c23703bffdc4d9b3dc8a94d7e
Problem: filetype: goaccess config file not recognized
Solution: detect 'goaccess.conf' as goaccess filetype, also
include a basic syntax and ftplugin (Adam Monsen)
Add syntax highlighting for GoAccess configuration file.
GoAccess is a real-time web log analyzer and interactive viewer that
runs in a terminal in *nix systems or through your browser.
GoAccess home page: https://goaccess.iocloses: vim/vim#15414https://github.com/vim/vim/commit/0aa65b48fbe64e18a767b207802483026baecb5d
Co-authored-by: Adam Monsen <haircut@gmail.com>
- Reword a few sentences and reformat a few paragraphs.
- Supply absent capitalisation and punctuation.
- Make listed highlighting groups and code stand out.
- Prefix all Java-related global variables with "g:".
- Add spaces around each variable assignment operator.
- Acknowledge that some Javadoc variables are maintained in
the HTML syntax file.
Also, move the overridable _default_ HTML group links before
the HTML syntax file inclusion in order to implement the
documented diverged settings.
related: vim/vim#15399https://github.com/vim/vim/commit/3749dff093d8c3ba0cd34cebf42bd4d3d93afe26
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Progress OpenEdge 11.6 added a new C-like single-line comment syntax; such
comments begin with `//` and proceed to the end of the line.
Add a new syntax group `ProgressLineComment` to implement highlighting for this
syntax. Rename the existing group from `ProgressComment` to
`ProgressBlockComment`, and introduce a cluster named `ProgressComment` to
encapsulate both.
closes: vim/vim#15339https://github.com/vim/vim/commit/4d68054c1e49b937a1aa9567196b97b36fe99c27
Co-authored-by: Daniel Smith <daniel@rdnlsmith.com>
Problem:
- `syn region ...`s in syntax/mysql.vim match function names inaccurately.
- no syntax rules for mysql window function.
- coarse highlight definition in syntax/mysql.vim.
Solution:
- add `\<` before the function name for accuracy.
- add syntax rules for mysql window function.
- enhance the highlight definition.
closes: vim/vim#15311https://github.com/vim/vim/commit/6e37575760022be047cad0e1cf1e30c18fab21ad
Co-authored-by: Yinzuo Jiang <jiangyinzuo@foxmail.com>
It seems that nvim-treesitter stops treesitter highlight when changing
filetype, so it makes sense for builtin ftplugins to do this as well.
Use :call and v:lua here to allow separation with '|'.
With the variables defined, distinctly highlight parts of
a method declaration header: its name and parameter list
parens, from its type parameters, return type, and formal
parameters; and distinctly highlight parts of a lambda
expression: its parameter list parens and the arrow, from
its formal parameters and identifiers.
closes: vim/vim#15083https://github.com/vim/vim/commit/01a4fb104dbee6a8b7ef20394a2a7c5b49cf49ca
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
In the presence of parameterised types whose names begin
with a capital letter and end with a less-than sign "<" that
introduces a type argument or a list of comma-separated type
arguments, followed by a greater-than sign ">", a variable
"g:java_highlight_generics" can be defined to have some
components of such types uniformly coloured (by picking
highlight groups for javaGenericsC{1,2}, javaWildcardBound).
For example,
------------------------------------------------------------
java.io.InputStream stream = java.io.InputStream.nullInputStream();
java.util.function.Function<String,
java.util.function.BiFunction<String, String, String>> updater =
property -> (oldValue, newValue) -> oldValue;
java.util.logging.LogManager.getLogManager()
.updateConfiguration(stream, updater);
------------------------------------------------------------
Note that the diamond form and explicit type arguments do
not qualify for this kind of recognition.
For example,
------------------------------------------------------------
new java.util.HashSet<>().<String>toArray(new String[0]);
------------------------------------------------------------
References:
https://docs.oracle.com/javase/specs/jls/se21/html/jls-4.html#jls-4.5https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.9https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.12.2.1closes: vim/vim#15050https://github.com/vim/vim/commit/beb02ed674bc61f179c4ff71e93bdeeb44fe9c4e
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Also:
- Restore the capability to mark as an error braces nested
in parens with g:javaInParen.
- Try not to fold top-level-type bodies. (Defining multiple
package-private top level types in a single source file is
not recommended as it can impose order among compilation
units; so it is assumed that only one such top level type
is usually defined.)
- Compose ‘method header’ highlighting and block braces
folding.
- Do not highlight block braces whenever ‘method header’
highlighting is requested.
This bundling of ‘method headers’ and block braces for
highlighting can be traced back to Vim v5.0; however, no
comment or documentation entry conveys any justification.
For example, it is hard to discover the connection between
block braces for "while", "if", etc., statements and method
body block braces. The former behaviour can be attained in,
e.g. ~/.vim/after/syntax/java.vim:
------------------------------------------------------------
if exists("g:java_highlight_functions")
syn clear javaBlock javaInParen
syn match javaBlockOther "[{}]"
syn region javaBlock transparent matchgroup=javaBlockStart
\ start="\%(^\|^\S[^:]\+\)\@120<!{" end="}" fold
hi def link javaBlockStart javaFuncDef
hi def link javaBlockOther javaBlockStart
if exists("g:java_mark_braces_in_parens_as_errors")
syn match javaInParen contained "[{}]"
endif
endif
------------------------------------------------------------
Note: Read ‘a method header omitting a _throws_ clause’ for
every ‘method header’ appellation used above.
https://github.com/vim/vim/commit/371bab05947b32f26d1b32922e5dc38343a875bc
Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
