You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Primarily for list and map expressions, but could also apply to function calls and property chains. The best heuristic for deciding whether to wrap a statement seems to be if the statement is "too long" e.g. greater than 80 characters. But the visitor + string builder approach makes this difficult, because you don't know the line length until you already appended the line.
A simple approach would be to (1) produce the line with no wrapping (2) check the length of the line (3) re-do the line with wrapping if the unwrapped line was too long.
Ideally we would reuse the pieces instead of computing them twice, and also be able to handle nested expressions intelligently. Not yet sure what all that entails.
Until then, a simpler heuristic is the number of elements (e.g. wrap if more than 3 elements), but I suspect it might be just wrong enough to be annoying.
The text was updated successfully, but these errors were encountered:
Or we could simply preserve the user's choice, i.e. if an expression was wrapped (spanned multiple lines) then wrap it, otherwise don't. It will still wrap or not wrap in a consistent way without getting in the user's way.
Primarily for list and map expressions, but could also apply to function calls and property chains. The best heuristic for deciding whether to wrap a statement seems to be if the statement is "too long" e.g. greater than 80 characters. But the visitor + string builder approach makes this difficult, because you don't know the line length until you already appended the line.
A simple approach would be to (1) produce the line with no wrapping (2) check the length of the line (3) re-do the line with wrapping if the unwrapped line was too long.
Ideally we would reuse the pieces instead of computing them twice, and also be able to handle nested expressions intelligently. Not yet sure what all that entails.
Until then, a simpler heuristic is the number of elements (e.g. wrap if more than 3 elements), but I suspect it might be just wrong enough to be annoying.
The text was updated successfully, but these errors were encountered: