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