[PATCH 4 of 4] Contrib: vim syntax, remove unecessary ngxBlock
OOO
othree at gmail.com
Fri Mar 3 15:37:36 UTC 2017
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 <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
--
OOO
More information about the nginx-devel
mailing list