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

Threading operators not always pretty #12

Open
tylerperkins opened this issue Apr 30, 2016 · 2 comments
Open

Threading operators not always pretty #12

tylerperkins opened this issue Apr 30, 2016 · 2 comments

Comments

@tylerperkins
Copy link

This plug-in has really shaped up! It helps make Clojure coding an even greater joy. I have noticed, however, that the threading operators, -> and ->>, are only replaced by pretty symbols when typing them. When a file that contains them is loaded, or when you use the Toggle Clojure Pretty Symbol action, they remain -> or ->>.

@swr1bm86
Copy link
Owner

swr1bm86 commented Apr 30, 2016

-> ->> is not always replaced by pretty symbols also because of the identation issue.

  • will replace pretty symbols
(-> a +)
  • will not replace pretty symbols
(-> a
    +)

maybe i can fix it using the idea you pointed out here #4

@tylerperkins
Copy link
Author

Ah, understood. I like your idea. Is it possible to apply my "padding" solution only when the arguments span more than one line? I.e., maybe there's no need to pad if the function/macro name is the last symbol in the line, and there are arguments below. But you do need to pad if some arguments (typically just the first) are on the same line as the function name, and there are more args. below.

An aside: I don't think it's a common style, but I've actually come to prefer making the indentation of succeeding lines just two spaces instead of lining up with the first argument of the thread macros:

(->> "abc"
  reverse
  (apply str))

The reason is that the first argument, "abc", is fundamentally different from the others, as with many other forms like if. In the threading macros, the first arg. is the starting data, while remaining arguments are forms that work to transform it. In other words, the first arg. is special, but the others are peers, in a sense, and should line up.

Of course, the same cannot be said for many other functions or macros, like comp, not=, >=, <=, and, or, not, union, difference, intersection. In these, all the args. are peers, and should be indented so that they all line up. So, yes indeed, this fix is needed.

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

No branches or pull requests

2 participants