[PATCH 4 of 4] Contrib: vim syntax, remove unecessary ngxBlock

OOO othree at gmail.com
Fri Mar 3 15:37:36 UTC 2017


I made a sample and take screenshot[1].
This one (remove current ngxBlock) is a blocker for some other changes.


And about the *ngxBlock* you talked about in the last paragraph.
I think you are talking about curly bracket block:

    http {
      include    conf/mime.types;
      index    index.html index.htm index.php;

I think it's not necessary for nginx conf file syntax highlight definition.
I can do more specific syntax highlight like ngxServerBlock for
`server { ... }` or another for `http { ... }`.
And made some constrain, ex: only allow *http* in *server*. Not allow
*http* at root level.
But it add lots of complexity. And I don't see the benefit worthy it.
Also breaks highlight in partial conf file (which will be included by
other conf file).

I will fix the rewrite commit.
But I have another question.
Maybe you have an idea about it.

    rewrite "/foo bar/" /bazz/ last;

For now, if I fix the bug. The "/foo bar/" part will be highlight as string.
But the /bazz/ part will be normal (no highlight).
I think they should both be highlight as string.
Do you have any idea?

Lots of directive have similar issue.
I have another change is about location path:

    location ~ /path/to/file {

Is to highlight /path/to/file part like a string.
I fell its better to see the conf.
But not sure is it good to everyone.

2017-03-03 22:05 GMT+08:00 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
> On Fri, Mar 03, 2017 at 06:56:59PM +0800, othree wrote:
>> # HG changeset patch
>> # User othree <othree at gmail.com>
>> # Date 1488538568 -28800
>> #      Fri Mar 03 18:56:08 2017 +0800
>> # Node ID 433844daf574dbf89390e574201b3db417337cdd
>> # Parent  b88ed85b7b4f3ea5a586f4f58251481348c502f1
>> Contrib: vim syntax, remove unecessary ngxBlock.
>> ngxBlock breaks highlighting for the following conf:
>>     rewrite "^/[0-9a-z]{40}/(.*)" /$1/ last;
> While current implementation of ngxBlock looks incorrect, I don't
> see how it breaks highlighting of the rewrite in question.  Could
> you please elaborate?
> On the other hand, the rewrite highlighting is clearly incorrect
> either. Rewrite arguments (much like any other directive
> arguments) can be escaped strings, and the rewrite parsing as
> implemented in the patch 2 doesn't take it into account, hence it
> will be broken with a configuration like:
>     rewrite "/foo bar/" /bazz/ last;
> In general, it might be better idea to start with general
> configuration syntax matching instead of focusing on the ad-hoc
> solutions for some particular directives.  And removing ngxBlock
> looks like a step in the wrong direction to me, as it is a basic
> concept of the configuration syntax.
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel


More information about the nginx-devel mailing list