Hi I made a sample and take screenshot[1]. This one (remove current ngxBlock) is a blocker for some other changes.
[1]:https://www.flickr.com/photos/othree/32843758310/ 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 <mdou...@mdounin.ru>: > Hello! > > On Fri, Mar 03, 2017 at 06:56:59PM +0800, othree wrote: > >> # HG changeset patch >> # User othree <oth...@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel -- OOO _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel