Tab just doesn't seem like the proper interface for something like this.
Tab just doesn't seem like the proper interface for something like this.
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.
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.
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.
Curious to hear what you think!
It seems contradicting to me.
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.
I guess it invokes the AI rather than controling it, maybe there'll be another key soon.
Changing the shortcut should be possible, but I haven't tried.
It's as if people developing autocomplete doesn't really code.
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.
Why are you manually indenting code?
I don't remember ever doing that in IDEA or VS Code for ~~python,~~ java or ts.
Edit: I borked about python, my bad.
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. if (foo):
bar()
hum()
how can anything other than a human decide if that 3rd line should be indented as it is or by one more level?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.
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 ```
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. 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. 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?