yapf: Add knob to never ever break line after "'dictkey':"
Currently if one or more of dict’s entries are longer than column_limit (or simply contain multiline string), yapf will break line after all dict’s keys in dict.
I’ve tried disabling indent_dictionary_value but this makes yapf just align value right under key, which is something I dislike more than breaking line and inlining value 😉
Eventually, I’ve developed custom utility for my project that performs my way cleanup after yapf, but after 12h of programmering I can’t help but feel that its hacky and fragile, which is why I’m opening ticket here.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 8
- Comments: 20 (5 by maintainers)
Commits related to this issue
- Add ALLOW_SPLIT_BEFORE_DICT_VALUE knob. If set to False, don't split before a dictionary value even if it goes over the column limit. Fixes #378 — committed to google/yapf by bwendling 7 years ago
Yes, I’d want that to not split, or if it does, it should be the only key that splits. The problem is right now you go from this:
to this:
Where I’d prefer either not splitting that line at all, or
@gwelymernans Pretty sure
ALLOW_SPLIT_BEFORE_DICT_VALUEhas regressed. Using only that knob in my.style.yapfthis:turns into:
and if I add
INDENT_DICTIONARY_VALUE = True, I still get the not-exceeding-max-len param'short_param'wrapping its valueWhat combination of knobs do I have to enable/disable to get my expected outcome, just like OP, to be like this?
@gwelymernans , any plans to integrate https://github.com/google/yapf/commit/848efddd27a8547ecce0876eeed12c197a3d4234 -et-al? Or should I not expect that to reach master?
Based on the description in this comment, it sounds like the patch goes at least some way to solving the issue. Personally I’d be happy with the behaviour described there!
Is it worth merging those changes as they are, even if folks want to do more work in this area in the future?
Sorry about the late response, guys. This fell off my plate. I’m going to try for a more cohesive approach that @rafalp suggested. If that falls through, I’ll go for 848efdd.