-
-
Notifications
You must be signed in to change notification settings - Fork 219
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
Auto-indent according to guidelines #3
Comments
I'm looking at this now a bit. Starting with #4, though because that would make this issue a bit less painful. |
OK, #4 is fixed, so now the documents should be formatted on save if you have that setting enabled. While it would be much better to have the code auto indented as you type, this might make it less painful. I'll keep looking at this issue and see if I can figure out a good way to do it. |
Cool! You mentioned I might want to add more examples, so I'll provide some more here. Also, though, www.4clojure.com has a great auto-identer for their text fields. Just go there, pick a problem from the problem list, and start typing some clojure into the text box. You'll see what I mean. Here are some examples. If an argument list is broken up between lines, the first argument on the second line should vertically align with the first argument on the first line:
Same thing with any collections (maps, vectors, etc), although since they don't have a function in the form, all items should be considered as if they were arguments:
Similar to
Multi-arity functions also have the body forms vertically aligned with their argument vector, similar to single-arity, but it looks a little unorthodox at first because there's a single-space indentation there (line 3 and 5):
|
Wow, many thanks for this! Before I realised you had provided this I pushed a change that should fix many of the cases, I think. Please try it out and report back if you agree. I'll close the issue soon and we can open separate issues for any remaining cases. |
You're fast! On first pass, was working great, but I think it's interacting a little unpredictably with the parinfer extension as I'm using it a little more. Can you tell me whether you're testing with parinfer, and if so, whether you're in "indent" mode or "paren" mode? I think your auto-indentation should have a config flag so I can turn it off, just in case someone doesn't like it or it interacts unpredictably with another plugin. I think the optimal combo would be to have your plugin handle indentation and parinfer handle parens, which means you'd be using indent mode:
In this case, Indent Mode would give Calva (new name! :) ) full control of indentation, while Parinfer corrects parens. For now, I'll turn off Parinfer and let you know if I see anything that's not formatting right with your auto-indentation. |
Disabled Parinfer, and found it working really well. There are only a couple things so far that need correcting: The multi-arity function behaves a little strangely. It seems the first body form in a multi-arity function tries to vertically align with the last arg in the arg vector:
But this works correctly, which is awesome:
So I think the multi-arity thing is specific to having a vector as the first thing in a list form, which is really specific to multi-arity functions I think. The other thing I noticed turns out to really be an edge case, but still worth fixing. When typing out a map form starting in the very first column of a file, when you hit enter after the first line, it puts a space in front of the cursor instead of behind the cursor, which results in this (notice the space after
But I was pleasantly surprised to find that these all work great:
Nice work so far! I think the odd interaction with Parinfer is basically Parinfer's fault. I noticed the github page for the vscode version now says the developer will be getting back to it later in the year, which would be awesome. Works really well in Atom, and I know he wants feature- and quality-parity between the two, so I'll be looking forward to that as well. |
Quick follow-up: for the second issue I mentioned (the issue with the map), the same thing happens with vectors and sets. It's probably all the same code handling it in the extension, so fixing one will probably fix all, but thought it's worth giving a couple more test cases:
There is another issue I found. I have three different examples, but I think they're all the same thing. Basically, when you are calling a function, if you're approaching your 80 character limit on the line and want to put the first argument on a new line, the function name and the argument should be vertically aligned (i.e., the argument should be indented in just that one space):
The indentation is actually doing this (and behavior is similarly incorrect for anonymous functions and lists):
|
Another one. Actual behavior:
Desired behavior:
|
Another one: when a form is complete (the final matching paren is typed) and you hit enter, your indentation level should go back to where the form started. Actual behavior:
Desired behavior:
|
This is great feedback! Though, it does seem like my extension is clashing with Parinfer now. 😢 When I worked with the auto-indentation I disabled everything that I thought could interfere and forgot to enable Parinfer when my indentation seemed to work. There might be other things differing between yours and mine setup, because for me the Released a new version with a sort of hackish way to deal with maps, vectors and sets not being treated well. Please check it out. ❤️ |
There is the case when parens and brackets are used inside strings and comments, that they will still be counted for indentation. I think I know how to avoid that, but it is not implemented yet, FYI. |
You're right that Speaking of parinfer.... is there any way for your plugin to force another plugin's code execution to happen after yours? I think if you could guarantee that parinfer will always execute in the editor after calva, then calva would handle the auto-indenting and parinfer can adjust parens accordingly. I don't know if that's possible though. As for specific examples, these are looking good:
So I think the only outstanding ones are these, which I think are just multiple examples of a single issue:
|
Side note: I think the cmd-click to definitions might be broken, or at least it isn't working on my machine as of this morning. I hadn't used that feature over the weekend, but I do know it was working Friday during business hours. (I'm on Pacific Time in the US.) I'm using OSX High Sierra 10.13.3, VSCode 1.12.1, most recent Calva extension, and the same versions of the two dependencies you suggest putting in profiles.clj:
I have these two calva settings set at the user level, otherwise all defaults:
I open VSCode, open the integrated terminal, start a REPL with Is it still working on your machine? EDIT: here is an exception and stack trace I'm getting in the REPL itself. I think it might be happening when it's trying to run the tests on save, and I don't know if it could be related to the cmd-click issues. Today is the first I've seen the exception, and I see it in more than one project:
|
That's bad! It is still working on my machine, though… Can you try with the Also, the compiler seems to complain about a bad |
About outstanding issues (except for the worrying mystery with evaluation of files and running tests failing for you). We have:
I'll make a keyboard shortcut for toggling the indent-correction so as to ease the coexistence with Parinfer, for now. And have look at 2 and 3, which shouldn't be too tricky to fix. (2 actually gets better treatment with Parinfer enabled, 3 clashes totally with Parinfer.) |
New version realeased. Added a command with keyboard shortcut |
Downloaded the new version. It's working more consistently now. Toggling indentation adjustment doesn't seem to affect the "go to definition" functionality one way or another (but the toggle key shortcut does work well). It seems like cmd-click works for most functions, but there is a namespace or two where cmd-click doesn't even work inter-project (i.e., one file won't allow you to go to a definition in another file). It could be something messy with the project, though, because I think it's a specific namespace or two. I haven't seen the exception being thrown since I updated, so that's great. So I think we're ok now! Sorry for the false alarm. Not sure what was happening before. ¯_(ツ)_/¯ |
There are many moving parts, no wonder some false alarms are set off! 😄 I have just published a new version that I hope fixes multi-arity and folding of arguments below non-special forms when the first line does not contain arguments. (Phew, don't know if that made any sense, but the last known indentation quirks, anyway.) I might have introduced some new problems, of course. Please help me test it. |
Working great! Thanks! |
Many thanks for the sparkling review! It is now keeping me warm here in a Stockholm where spring and winter are still fighting it out. |
Ha, you're welcome! Stay warm! |
In issue #2, @tjbrandt writes:
For formatting/indenting, a good example is using a
let
form.Consider the following snippet:
As you're typing that out, hitting the
return
key after:first-val
should, if honoring the style guide, put your cursor directly belowx
, so that when you then typey
, thex
andy
should be vertically aligned. However, VSCode instead either puts you back at the beginning of the next line (if auto-indent is off) or indents you only 2 spaces (if auto-indent is on).But then, hitting
return
after typing the closing bracket]
after:second-val
, the cursor should then be placed on the next line and indented two spaces, according to the style guide. But VSCode "intelligently" decides that you're trying to indent everything at the same indentation as the last couple variables, so it then puts you directly under they
, even though this time that's not what you wanted.The text was updated successfully, but these errors were encountered: