I tried CoPilot a while and my biggest gripe was tab for accepting the suggestion. I very often got a ton of AI garbage when I was just trying to indent some code.
Tab just doesn't seem like the proper interface for something like this.
I actually wish more editors had emacs style indenting where hitting tab anywhere on the line would re-indent it or otherwise cycle through indent levels if it was unclear, especially because you’re unlikely to get copilot suggestions in the middle of a word. Plus, it doesn’t break if there’s a syntax error elsewhere in the file.
It's one of those weird Emacs things that you get _so_ used to that everything else seems to waste your time.
Using code formatters and formatting on save or with a shortcut is OK, but not really the same to me.
That's probably why I'm stuck with Emacs:
1. No need to use the mouse.
2. Extremely efficient keyboard usage (maybe not the most efficient, but compared with common IDEs, certainly).
Makes it feel like I'm actually using a brain computer interface. The somewhat regular yak shaving is a bit of a bummer though. I like that I can modify everything to be exactly how I like it, but I wouldn't mind sensible defaults. Haven't found a distribution yet that works well without tinkering.
Exactly, and sometimes I don't want to save a file just for indentation to happen as a side-effect, especially if I can do `C-x H TAB` to correctly re-indent the entire thing.
That's particularly more helpful when some formatters will actually rewrite your code to either break lines up or squish things back into a one-liner.
Oh, didn't know about that. That makes a lot of sense. Reminds me of how hitting cmd+c on a line in PyCharm copies the entire line if there is no selection. Because what else would make sense?
I thought that was a great feature. Now I'm writing mostly languages with well-defined formatting rules and simply never need tab. This is even better.
We totally agree with this and that's why Zed will switch the keybinding for accepting an edit prediction to `alt-tab` when the cursor is in the leading whitespace of a line. This way you can keep using `tab` for indenting in that situation.
Also, when there's both an edit prediction and and LSP completion, Zed switches the keybinding to `alt-tab` to prevent the conflict with accepting an LSP completion.
Sorry, I assumed macOS: but you're right! For Linux (and Windows, once we ship support for it) the keybinding is alt-l to avoid conflicting with tab switching.
Ohhh, is that why I keep pressing tab and it doesn't accept the prediction lately? I thought it was a bug. It feels weird for tab to double-indent when it could be accepting a prediction - I wonder if alt-tab to do a manual indent rather than accept the current prediction might be preferable?
Edit - On the other hand, a related issue is that if the prediction itself starts with whitespace, in that case it would be good if tab just indents like normal; otherwise you can't indent without accepting the prediction.
After using Prettier to format my code and turning on format-on-save, I pretty much don’t use the tab key anymore. This doesn’t invalidate your point, - I am merely guessing as to why the tab key seemingly has been reassigned.
Yes, copilot's tab in vim is that made me think that AI is useless. However next iteration of AI coding tools made me rethink this (I am using https://github.com/olimorris/codecompanion.nvim with nvim now).
See, you're thinking of Microsoft Copilot, but code completion is provided by Github Copilot, so it'll need its own key. Which will also be labeled Copilot.
It's a timing issue too. Your hand can be travelling to the keyboard and between that and registering in the OS the AI suggestion inserted itself inbetween.
Yeah, IMO tab makes no sense for this as the default.
Since I code in Go and use tabs regularly, I remapped my auto-complete AI key for Supermaven in Neovim to ctrl-L which I have no other occasion to use regularly. Now tab works properly and I can get auto-complete.
if check_something():
wall_of_text = textwrap.dedent("""
this
is
a
multiline
string
""".strip("\n"))
I hope you agree it's ugly. And you want to make it
if check_something():
wall_of_text = textwrap.dedent("""\
this
is
a
multiline
string
""".strip("\n"))
But I don't know any formatter which does this automatically. Because the change here not only changes the looking, it changes semantic. The formatter has to understand that after `textwrap.dedent(_.strip("\n"))` the result does not change and that's hard. So formatter just leave it alone. But it's extremely obvious to a human. Or maybe extremely obvious to a LLM too.
How does the IDEA/VSCode know when you're done with the if?
if foo:
bar # Obviously this is indented
but_is_this() # supposed to be under the if?
how.about(this) #?
how.do_you(de) # indent in Python, if not manually?
And this is one reason I still don't understand the use of python in large teams!
I suppose with very good tests, you might be able to catch something like this, but it seems impossible to me how a PR reviewer might catch a "bug" like this and not just assume that it's intentional.
One of my biggest gripes with python is the fact that the only way to create a local scope for variables is with functions.
I understand if statements not having their own scope for simplicity's sake, but the fact that `with` blocks don't is simply mind-bobbling to me.
```
with open("text.txt", 'w') as f:
f.write("hello world")
f.write("hello world") # at least the handle was automatically closed so it will give an IO error
```
It’s actually very useful to have context managers outlive their with blocks. They are not only used for files:
One example would be a timing context manager:
with Timer() as t:
…
print(t.runtime)
Another example is mocks, where you want to inspect how many times a mock was called and with what arguments, after the mock context manager has finished.
I know it makes sense in the "scope-less" python philosopy but it still feels weird for me as a scope (ab)user in C++ and has caused me one headache or two in the past
Completely agree, this is a common argument ever since Python existed. I've also used it for almost 25 years and these kind of indentation errors just don't happen. I see it the same as forgetting closing brace. Python programming writing C code might forget it initially, but C programmer absolutely will not forget it, it's in their muscle memory. And the same applies for dealing with indentation.
How, though? Every code editor I've used supports holding indentation at a certain level until you change it, so if you write:
if foo:
bar()
and hit enter after the "bar()", it would drop you down so that the next thing you type would be under the "b". It's not really different from using curly brackets from the perspective of typing in code.
Tab just doesn't seem like the proper interface for something like this.