[PATCH] Contrib: vim syntax, update core and 3rd party module directives.

[Maxim Dounin]

Hello!

On Sat, Jul 22, 2023 at 02:56:22PM +0300, Gena Makhomed wrote:

> On 20.07.2023 19:32, Maxim Dounin wrote:
> 
>  > (Also, it might be a good idea to keep directives introduced by
>  > commercial extensions separately.)
> 
> In addition to ngxDirectiveBlock and ngxDirective I should
> introduce ngxDirectiveBlockCommercial and ngxDirectiveCommercial
> and [allow users to] use different color for commercial directives
> of "nginx" and "nginx block" types ?
> 
> Or I should just make separation of commercial directives
> in the contrib/vim/syntax/nginx.vim file by grouping,
> spaces and comments, without any distinguish
> between commercial and open-source directives
> in the user-visible level? Something like this:
> 
> # nginx directives
> 
> syn keyword ngxDirectiveBlock contained http
> syn keyword ngxDirectiveBlock contained stream
> ...
> syn keyword ngxDirectiveBlock contained match
> 
> ...
> 
> syn keyword ngxDirective contained absolute_redirect
> syn keyword ngxDirective contained accept_mutex
> ...
> syn keyword ngxDirective contained zone_sync_ssl_verify_depth
> syn keyword ngxDirective contained zone_sync_timeout
> 
> 
> # nginx-plus commercial extensions directives
> 
> syn keyword ngxDirectiveBlock contained otel_exporter
> 
> ...
> syn keyword ngxDirective contained internal_redirect
> syn keyword ngxDirective contained mqtt
> syn keyword ngxDirective contained mqtt_preread
> syn keyword ngxDirective contained mqtt_rewrite_buffer_size
> syn keyword ngxDirective contained mqtt_set_connect
> syn keyword ngxDirective contained otel_service_name
> syn keyword ngxDirective contained otel_span_attr
> syn keyword ngxDirective contained otel_span_name
> syn keyword ngxDirective contained otel_trace
> syn keyword ngxDirective contained otel_trace_context
> ...

I think just grouping as suggested would be enough.

> >>    syn keyword ngxDirective contained add_header
> >> +syn keyword ngxDirective contained addition_types
> >>    syn keyword ngxDirective contained add_trailer
> >> -syn keyword ngxDirective contained addition_types
> 
> > It looks like order changes here (and in multiple other places)
> > are caused by a changed alphabetical order in the tooling being
> > used, which now places "_" after [a-z].
> 
> As I understand - it just ignore "_", placing "addition_types"
> after "add_header" but before "add_trailer",
> because of order "h" < "i" < "t".
> 
> > Apart from being an unneeded change, this does not look like a
> > correct order to me: it generally contradicts order of characters
> > in ASCII, and also doesn't play well with how nginx uses "_" (as
> > "foo" and "foo_bar" are expected to be close to each other, and
> > both before "foobazz").
> 
> tooling used - is unix command line utility sort, via vim syntax:
> 
> :'<,'>!sort
> 
> for sorting selected block of lines.
> 
> in the system, Rocky Linux release 8.x, such settings:
> 
> LANG=en_US.UTF-8
> 
> so, in this case:
> 
> LC_COLLATE=en_US.UTF-8
> 
> and as I understand, this is not vim bug or sort utility bug,
> this is en_US.UTF-8 collation bug - I don't know hot to fix this bug.

Indeed, it seems to ignore "_" with LC_COLLATE=en_US.UTF-8 on 
Linux (checked on Ubuntu 22.04).

> In future I will use
> 
> LC_ALL=C
> LC_COLLATE=C
> 
> to sort lines in the ngxDirective`s block
> via external unix command line sort tool,
> or will use internal vim sort command via
> 
> :'<,'>sort

Yes, that would be awesome.

> As I understand, - I should sort directives only
> in ngxDirective and ngxDirectiveThirdParty blocks
> and leave all other blocks in the existing "random" order?
> 
> Or I should not sort any blocks of lines
> and I should just append new lines to end
> of the each block, to minimize the patch size?

I think it make sense to keep sorting where it is already in 
place, but preserve manual ordering in groups where manual 
ordering is already used (such as importance-based ordering in 
ngxDirectiveBlock and ngxDirectiveImportant blocks, and date-based 
in the ngxDirectiveDeprecated block).

[...]

-- 
Maxim Dounin
http://mdounin.ru/