CppCXY / EmmyLuaCodeStyle

fast, powerful, and feature-rich Lua formatting and checking tool.
MIT License
140 stars 27 forks source link

[Question]: Way to align consecutive assignments/table assignments #97

Closed lmburns closed 1 year ago

lmburns commented 1 year ago

Is there a way to align consecutive assignments (both local/variable and table) without needing to have one of the assignments have an extra space in between the equals sign?

That is, the following will not align:

M.icons.lsp.err = M.icons.lsp.error
M.icons.lsp.information = M.icons.lsp.info

But this will:

M.icons.lsp.err  = M.icons.lsp.error
M.icons.lsp.information = M.icons.lsp.info

The only difference is that M.icons.lsp.err has an extra space after it. I would like to align consecutive assignments no matter what, regardless of whether or not there is an extra space there.

CppCXY commented 1 year ago

there is currently no such way, so you would like such an option?

lmburns commented 1 year ago

Yes I would.

I would much prefer to use this as my formatter instead of LuaFormatter because this has many more options. I like how I am able to give an extra space on some blocks and have them aligned, while leaving others alone. Though, I would like to be able to force all if I wanted that as well. Some of the things LuaFormatter has would be nice to have here (if possible). They are some of the following:

keep_simple_control_block_one_line

keep_simple_function_one_line

break_after_functioncall_lp

break_before_functioncall_rp

chop_down_parameter

Example This gets turned into: ```lua map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) ``` This, when using `CodeFormat` (same is mentioned below in bugs heading): ```lua -- First call (break_all_list_when_line_exceed: true, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], { expr = true }) -- Second call (break_all_list_when_line_exceed: true, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], { expr = true, }) ----- -- First call (break_all_list_when_line_exceed: false, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) -- Second call (break_all_list_when_line_exceed: false, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) ``` I would prefer to have the code formatted as this (which is how it is kept *only* if the code is already formatted like this): ```lua map( "n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true} ) ```

break_after_functiondef_lp

break_before_functiondef_rp

break_after_table_lb

Example That is, currently this: ```lua wk.register( { ["y"] = {[[v:lua.require'common.yank'.wrap()]], "Yank motion"}, ["yw"] = {[[v:lua.require'common.yank'.wrap('iw')]], "Yank word (iw)"}, ["yW"] = {[[v:lua.require'common.yank'.wrap('iW')]], "Yank word (iW)"}, ["gV"] = {[['`[' . strpart(getregtype(), 0, 1) . '`]']], "Reselect pasted text"}, }, {expr = true} ) ``` Would get formatted as this: ```lua wk.register( { ["y"] = {[[v:lua.require'common.yank'.wrap()]], "Yank motion"}, ["yw"] = {[[v:lua.require'common.yank'.wrap('iw')]], "Yank word (iw)"}, ["yW"] = {[[v:lua.require'common.yank'.wrap('iW')]], "Yank word (iW)"}, ["gV"] = {[['`[' . strpart(getregtype(), 0, 1) . '`]']], "Reselect pasted text"}, }, {expr = true} ) ``` But would instead be formatted as (if `break_after_table_lb`, `break_before_table_rb`, and `chop_down_table` are true): ```lua wk.register( { ["y"] = {[[v:lua.require'common.yank'.wrap()]], "Yank motion"}, ["yw"] = {[[v:lua.require'common.yank'.wrap('iw')]], "Yank word (iw)"}, ["yW"] = {[[v:lua.require'common.yank'.wrap('iW')]], "Yank word (iW)"}, ["gV"] = { [['`[' . strpart(getregtype(), 0, 1) . '`]']], "Reselect pasted text" }, }, {expr = true} ) ```

break_before_table_rb

Example That is, prefer this instead of: ```lua autocmd({ event = "BufDelete", buffer = 0, command = function() vim.opt.hlsearch = hlsearch vim.opt.lazyredraw = lazyredraw vim.opt.showmatch = showmatch end, desc = "Restore settings from optimizing large files" }) ``` ```lua autocmd( { event = "BufDelete", buffer = 0, command = function() vim.opt.hlsearch = hlsearch vim.opt.lazyredraw = lazyredraw vim.opt.showmatch = showmatch end, desc = "Restore settings from optimizing large files" } ) ```

chop_down_table, chop_down_kv_table

table_max_line_length, table_kv_max_line_length

Things that are not with LuaFormatter

Additions to already existing options

align_continuous_assign_statement

align_continuous_rect_table_field

align_if_branch

if fn.expand("%") == ""
                  or exclude_ft:contains(vim.bo[bufnr].ft)
                  or exclude_bt:contains(vim.bo[bufnr].bt)
                  or D.is_floating_window() then
    return true
end

Bugs

CodeFormat requires two calls to correctly align the calling arguments:

Example Original ```lua map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) ``` After ```lua -- First call (break_all_list_when_line_exceed: true, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], { expr = true }) -- Second call (break_all_list_when_line_exceed: true, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], { expr = true, }) ----- -- First call (break_all_list_when_line_exceed: false, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) -- Second call (break_all_list_when_line_exceed: false, align_call_args: true) map("n", "j", [[v:count ? (v:count > 1 ? "m`" . v:count : '') . 'j' : 'gj']], {expr = true}) ```

If there is anything else I can think of, I will add it here.

CppCXY commented 1 year ago

so many feature requests, I may need to modify the break line algorithm architecture

CppCXY commented 1 year ago

Please separate bug reporting and feature requests, I'll handle it

CppCXY commented 1 year ago

The original issue has been solved, other feature request please new issue