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/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
