Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: no-mixed-spaces mode #19

Open
cxw42 opened this issue May 27, 2020 · 2 comments
Open

Request: no-mixed-spaces mode #19

cxw42 opened this issue May 27, 2020 · 2 comments

Comments

@cxw42
Copy link

cxw42 commented May 27, 2020

Please see attached foo.txt. Line 2 has fifteen leading spaces. Running

wtf -v -s -y 8 foo.txt | xxd -g1

changes the first 8 spaces to a tab and leaves the last 7 spaces:

	CHANGED 8 spaces to tabs on 1 lines
00000000: 30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66  0123456789abcdef
00000010: 0a 09 20 20 20 20 20 20 20 68 65 6c 6c 6f 21 0a  ..       hello!.

I would like to request a mode in which any trailing group of spaces after a leading group of tabs would be converted to a single tab. Unlike -y N, this would convert every group of up to N spaces to a tab.

The use case is Linux kernel coding, which uses hard tabs. I care more about consistency than exact-column indentation. clang-format will give me tab+space mix, and I'd like to use wtf to convert those last few spaces to one additional tab per line.

Thanks for considering this request!

@dlenski
Copy link
Owner

dlenski commented May 27, 2020

Unlike -y N, this would convert every group of up to N spaces to a tab.

So how would you handle (say) a line that started with "\t \t "? Would that get converted to two tabs or 3 or 4? How about " \t \t"?

The use case is Linux kernel coding, which uses hard tabs.

Last time I checked, Linux kernel devs want hard tabs for offsetting indented blocks (so that individual devs can customize their width), and spaces for matching continuation lines (visually lining up), e.g.

if (condition) {
\tfunction_with_long_arguments(first_arg, second_arg.
\t                             this_third_arg_should_be_indented_with_spaces)
}

If you change those spaces on the second line to tabs, I expect you're gonna get your patches rejected.

Once you decide how to resolve the ambiguity, and if you still want it… this should be easy to implement. Patches welcome :)

@cxw42
Copy link
Author

cxw42 commented May 28, 2020

"\t \t "

Good question! I hadn't thought about that. If it were me, I would expand the tabs to N spaces, then reslice from the beginning. So "\t \t " with N=8 would become 18 spaces -> 3 tabs.

matching continuation lines

I've seen some of that code as well. I'm trying to be a good corporate citizen (as it were) and follow statements like "spaces are never used for indentation" here and "[l]ine up argument lists by tabs, not spaces" here. If you know other guidance overriding those, please let me know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants