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
...


   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.

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

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?

Something like this:

...
syn keyword ngxDirective contained zone_sync_ssl_verify
syn keyword ngxDirective contained zone_sync_ssl_verify_depth
syn keyword ngxDirective contained zone_sync_timeout
syn keyword ngxDirective contained http2
syn keyword ngxDirective contained http3
syn keyword ngxDirective contained http3_hq
syn keyword ngxDirective contained http3_max_concurrent_streams
syn keyword ngxDirective contained http3_stream_buffer_size
syn keyword ngxDirective contained js_preload_object
syn keyword ngxDirective contained js_shared_dict_zone
syn keyword ngxDirective contained quic_active_connection_id_limit
syn keyword ngxDirective contained quic_bpf
syn keyword ngxDirective contained quic_gso
syn keyword ngxDirective contained quic_host_key
syn keyword ngxDirective contained quic_retry

?

--
Best regards,
 Gena
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Reply via email to