Configure operators

[stuta]

I would like to change the operators ' .. ' to '..' (saves space) and ' ^ ' to '^' (shows the highest priority). We have huge codebase and we don't want to change every source file.

I tried to look from the source code but I could not find where I can do the change.

Or would it be a good idea to put all operators to config?

[tammela]

I don't follow, could you give more concrete examples?

[stuta]

Example:

r = r..(b % 2^i - b % 2^(i - 1) -- this is what we have now
-->
r = r .. (b % 2 ^ i - b % 2 ^ (i - 1) -- this is how it's formatted with LuaFormatter

[tammela]

That's possible but I don't see a clear implementation for the configuration file yet.

Adding a configuration field for spaces around each operator is just too much.

I will think about it...

[stuta]

Maybe configuration could be one option something this:

operators: {
  '=': ' = ',
  '+': ' + ',
  '..': '..',
  '^': '^',
  ... 
}

Or configuration could be Lua file.

I was also thinking of configuring this to convert simple Lua scripts to Javascript format by changing syntax options, but there is this project that does it https://github.com/mingodad/ljs. If output syntax is fully configured then this could be used to convert Lua to any language.

[Koihik]

Maybe configuration could be one option something this:

operators: {
  '=': ' = ',
  '+': ' + ',
  '..': '..',
  '^': '^',
  ... 
}

Or configuration could be Lua file.

I was also thinking of configuring this to convert simple Lua scripts to Javascript format by changing syntax options, but there is this project that does it https://github.com/mingodad/ljs. If output syntax is fully configured then this could be used to convert Lua to any language.

I thought formatter should not provide the feature of convert Lua into other languages.

[Koihik]

Example:

r = r..(b % 2^i - b % 2^(i - 1) -- this is what we have now
-->
r = r .. (b % 2 ^ i - b % 2 ^ (i - 1) -- this is how it's formatted with LuaFormatter

It seems reasonable that the space around '^' is removed because the priority of '^' is highest. But '..' doesn't have the highest priority, which makes the result strange sometimes. For example:

"xx" .. 2 + 3
-- after format:
"xx"..2 + 3 -- strange without brackets

[stuta]

Yes, and that's why all operators should be changeable. I know that some people prefer a tight format.

"xx"..2+3

[stuta]

I don't need this to be a preference.

All I need now is to find a place in code where I can modify them myself, please.

[Koihik]

I don't need this to be a preference.

All I need now is to find a place in code where I can modify them myself, please.

Maybe in function visitExp of FormatVisitor.cpp. You can judge what linkOperator is, and then decide whether you want a space or not.

[adriweb]

I don't need this to be a preference.

It sure would be nice to have it as a preference, though :) We're hitting the same "issue" on our codebase.

[tammela]

@karanankit01 Can you take a look at this one?

[stuta]

I use in my Luacheck -based formatter rule that normally concatenation is '..', but if either side is number then the concatenation is ' .. '. It also stips all extra parentheses.

[karanankit01]

@karanankit01 Can you take a look at this one?

Sure, I will look into this to make a preference based formatting .

[karanankit01]

In preference based formatting the highest priority operator select the formating status which may lead to strange result for lower priority operator formatting. And for such cases, dealing with each operator with configuration field will not be a good idea as stated by @tammela

Adding a configuration field for spaces around each operator is just too much.

[stuta]

I was able to change the operator. Is there a way to know the previous and next statement type inside FormatVisitor::visitExp()?

It is needed to get valid syntax because 2+3.."xx" is not valid.

[tammela]

@stuta yes, take a look at ANTLR4's visitor pattern and how you can traverse the AST