Can someone tell me what's this suppose to mean

buffer.c(4487) : error C2275: 'char_u' : illegal use of this type as an expression
        c:\projects\vim\src\vim.h(324) : see declaration of 'char_u'

char_u is just an alias for unsigned char and used all over the codebase . Why is this error occuring ?

line 4487 is

    char_u *block_start = s;

where s itself is a pointer to char_u

This is not backwards compatible, if the %{} result contains any percent sign it's likely to be broken.
I see two alternatives: 1) provide a function that can be used inside %{} to evaluate (might not work for highlighting).
2) provide a new % item and keep %{} as-is.

This is not backwards compatible, if the %{} result contains any percent sign it's likely to be broken.
I see two alternatives: 1) provide a function that can be used inside %{} to evaluate (might not work for highlighting).
2) provide a new % item and keep %{} as-is.

How about %[] then ? I think [] aren't used for anything yet. Highlights are pretty important so I'd rather like to go with 2 to remain backword compatable.

Though to be honest I don't think there are many use cases where %{} evaluates to string with % . Even in that case the % can just be escaped with another %

@brammool I've moved the functionality to new %[expr] item . Hopefully haven't missed anything . Let me know what you think about this :)

Edit:
By the way do you know why appveyor CI is failing those errors aren't making any sense to me

I think that would be an acceptable solution. Let's await anybody else commenting.

@brammool I think I've a better idea then creating a new % item . We could check for a char at start of expr that cann't exist on valid vim expr. I've just pushed an implementation of that . I think valid vimL_expr doesn't contain ':' at begining(I could be wrong though) . So here result of %{expr} doesn't get evaluated while result of %{:expr} gets evaluated . This should be backword compatable and doesn't require a new item . If ':' is valid as first char ofa vimL expression or you think ':' is confusing please let me know a char that can be used for this purpose :) . Also let me know what you think of this idea ...

For %{} is stated that there cannot be a "}" inside the
expression. For %[] that would be a "]", which is much more common.

I think if we are going with %{} structure I think we should leave the end marker as changing it will definatly be a breaking change to anyone using %{} .

Using %{: expr } is a bit more cryptic. How about %{% expr %} ?

I think if we aren't changing the end marker then we can switch to using %{%expr} . How about %{!expr} . Since there's already a %! evaluating item might be a familiar syntax .

Edit:
Ok ! won't work as it's a valid expression element . I think we can finalize %{%expr} for evaluation and %{expr} retains it's regular behavior . I've already made the changes to use '%'. If you agree I think this proposal can be merged to vim . You can review the changes and let me know if you have any problem about the code .

@brammool I think github doesn't send mails about edits .That's why you got an older version of the comment.

To sum it up here's where I'm at.

! would have been better but . ! is not operator in vimL . So it can be at start of a valid statement . That's why we can't use that . Also we can't change the end marker as that will break all %{} statements out there .
For example if some one has stl=%{my_function()} that now will have to be changed to stl=%{my_function()%} . That entirely defeats the purpose of being backword compatable with changes in this pr .

I think we can finalize %{%expr} for evaluation and %{expr} retains it's regular behavior . I've already made the changes to use '%'. If you agree I think this proposal can be merged to vim . You can review the changes and let me know if you have any problem about the code .

I do think that using %} for the end might work better. Not allowing a
"}" inside the expression can be a problem, e.g. when using a
dictionary. If we do not change it now it will be set in stone.

I do think It would have been better to have %} . But it's already on the stone . Do you really want to make a breaking change about it ? If you do I don't have problem making it . To be clear we are no longer introducing a new item. %[] was droped now we are changing the behavior of already existing %{} item to extend it's abilities while remaining 100% backword compatable . Changing the end marker will break all existing uses of %{} item . I'm just asking for confirmation because I'm really confused about you trying to make incompatable changes :D .

Changing the end marker will break all existing uses of %{} item

No, the suggestion is to require the new end marker (%}) when using the new start marker (%{%). Existing users of %{...} won't be affected, but it allows for clearer parsing of %{%...%}.

No, the suggestion is to require the new end marker (%}) when using the new start marker (%{%).

@jamessan thanks for clearifiing . Now that makes a lot more sence :) .

@brammool I've changed the end marker for %{% expressions to %}

So now for %{%myfunc()%} results of myfunc() will be evaluated and %{myfunc()} would act as before. This is what you asked for right ?

I wonder if we can use %{!, since using ! in front of an expression
would result in a boolean, which doesn't make sense to insert into the
status line. So even though it's not invalid, it would never be
actually used.

There are lots of boolean pieces of information which can make sense to put in the status line. I wouldn't count on %{! not being used. It's syntactically valid, so why risk it?

I wonder if we can use %{!, since using ! in front of an expression
would result in a boolean, which doesn't make sense to insert into the
status line. So even though it's not invalid, it would never be
actually used.

There are lots of boolean pieces of information which can make sense to put in the status line. I wouldn't count on %{! not being used. It's syntactically valid, so why risk it?

I agree. And it would be nice if a ternary could be used here, in which case the first part of the expression would be a bool. Warning: contrived example ahead:

 %{% !is_active ? resolveInactive() : resolveActive() %}

Codecov Report

Merging #8190 (8753387) into master (918b089) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #8190      +/-   ##
==========================================
- Coverage   89.35%   89.33%   -0.02%     
==========================================
  Files         148      148              
  Lines      166793   165713    -1080     
==========================================
- Hits       149038   148040     -998     
+ Misses      17755    17673      -82     

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 918b089...8753387. Read the comment docs.

@brammool I think we shouldn't use ! . As jamessan
nickspoons pointed out there can be valid usecases .

@brammool is this ok to merge ? Or something left to be done ?

Please also add a test for infinite recursion, so that it runs into
MAX_STL_EVAL_DEPTH.

Please use formatting like in the other Vim code: { on a separate line,
empty line after declarations

Thanks for the review. I've added test for inf recursion and fixed formating as you recomanded. I actually don't know what formating rules vim follow , didn't see anything related to formatting in CONTRIBUTING.md