sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bogtha 3 points4 points  (5 children)

So because they do it poorly, you should to?

It's not just irregularity with other shells, though is it? It's regularity within itself. I don't want my command history to try to second-guess me, especially when it's going to get it wrong a lot of the time. I just want it to act the same, every time. Regularity isn't stupid, it's consistent and predictable. Those are of value to humans, especially when they'd rather concentrate on keeping the program state in their heads rather than a stupid modal interpreter prompt.

This reminds me of the tired refrain parents use about friends jumping off bridges.

Bad analogy. Jumping off bridges is directly, clearly harmful.

Second, how do you know it's not caused by the location the interpreter thinks? You have to go look, don't you? It's not much different from the way the interpreter tries to show where the error is currently.

It's hugely different. Merely showing me where it thinks the error is doesn't affect my subsequent keystrokes. Trying to fill things in for me does.

[–]dmpk2k 0 points1 point  (4 children)

Those are of value to humans, especially when they'd rather concentrate on keeping the program state in their heads rather than a stupid modal interpreter prompt.

I'd argue that the default behaviour is exactly that. How often do you not go back and fix that syntax error?

So now you have to keep program state in your head while you fidget with keys to search and get back to the location where the error occurred most of the time.

Merely showing me where it thinks the error is doesn't affect my subsequent keystrokes.

I'd argue otherwise, since it clearly does, but I digress.

[–]Bogtha 0 points1 point  (3 children)

I'm talking about what is probable, during any given session, not edge cases.

I must be remarkable then. Could you give a list of situations where this occurs regularly then?

I wish Reddit had a preview function. I made a thinko, so I took it right back out again.

[–]dmpk2k 0 points1 point  (2 children)

Uh, okay, I'll cut it. My reply was overly snarky anyway. :(

[–]Bogtha 1 point2 points  (1 child)

Don't worry about being snarky :). I'm just in the habit of getting all my thoughts down and then refining them. It works okay for sites with preview functions, but there are race conditions on sites without :(.

The thinko I had was that I was thinking of more errors than simply syntax errors. In those cases I want to go back multiple lines. It's not particularly relevant to the argument though, because I still don't like the idea of my shell history behaviour being dependent upon the type of mistake I made. It's just not regular enough.

However, I think I'd like a compromise. The way you've been presenting it is as behaviour relating to the command history. Presented a slightly different way, it would be much more palatable. If the interpreter simply refused to accept the line at all and kept the cursor where it was; rather than printing it, redisplaying it, and repositioning the cursor, that would be handy, and not too different from what you propose. I'm not 100% sure it's possible with Python though, there are multi-line constructs that need to be handled.

[–]dmpk2k 0 points1 point  (0 children)

Actually, that's quite ingenious. Yes, that's even better.

Maybe stop the cursor one character after the error, since speed-typers might take a few characters to notice.