Most active commenters
  • _thisdot(3)

←back to thread

631 points cratermoon | 40 comments | | HN request time: 1.652s | source | bottom
1. chrismorgan ◴[] No.44462001[source]
> Like, just to calibrate here: you know how some code editors will automatically fill in a right bracket or quote when you type a left one? You type " and the result is "|"? Yeah, that drives me up the wall. It saves no time whatsoever, and it’s wrong often enough that I waste time having to correct for it.

I have not yet figured out why anyone would choose this behaviour in a text editor. You have to press something to exit the delimited region anyway, whether that be an arrow key or the closing delimiter, so just… why did the first person even invent the idea, which just complicates things and also makes it harder to model the editor’s behaviour mentally? Were they a hunt-and-peck typist or something?

In theory, it helps keep your source valid syntax more of the time, which may help with syntax highlighting (especially of strings) and LSP/similar tooling. But it’s only more of the time: your source will still be invalid frequently, including when it gets things wrong and you have to relocate a delimiter. In practice, I don’t think it’s useful on that ground.

replies(13): >>44462030 #>>44462032 #>>44462150 #>>44462206 #>>44462213 #>>44462300 #>>44462368 #>>44462389 #>>44462450 #>>44463659 #>>44463863 #>>44464038 #>>44466698 #
2. sonofhans ◴[] No.44462030[source]
Preach it. I’d rather hit right bracket than right arrow.
replies(1): >>44463775 #
3. atemerev ◴[] No.44462032[source]
Because otherwise it would break syntax highlighting until you finish writing the string. And no, sorry, I like my syntax highlighting, I won't turn it off.

This feature is useful for me. So are LLMs. If someone doesn't want to use this or that, they are not obliged to. But don't tell me that features that I find useful "suck".

replies(2): >>44462183 #>>44462186 #
4. BlindEyeHalo ◴[] No.44462150[source]
I think it is practical when highlighting text and then pressing " once puts quotes and the start and the end of the highlighted region.

But I agree that in normal input it is often annoying.

replies(1): >>44462189 #
5. willvarfar ◴[] No.44462183[source]
Sad this is downvoted, because syntax highlighting is a very plausible explanation for this editor behaviour.

You can perhaps imagine an editor that only inserts the delimiter if you type the start-string symbol in the middle of a line.

6. chmod775 ◴[] No.44462186[source]
> Because otherwise it would break syntax highlighting until you finish writing the string.

You can always insert the second " as a ghost(?) character to keep syntax highlighting working. But it's not like any modern language server really struggles with this anyways.

7. matejn ◴[] No.44462189[source]
I hate that even more, especially since Visual Studio introducted it. I had the habit of selecting some text, and then typing to replace it. Now when my replacement starts with a parenthesis or quote, the text just gets surrounded instead!

Maybe this is just an XKCD moment https://xkcd.com/1172/ ...

replies(1): >>44462267 #
8. tehnub ◴[] No.44462206[source]
Pair programming with coworkers over the years, many seem to have trouble with the keyboard, to the point where pressing right parenthesis is a significant burden and they don’t use right or down arrow to get out of the span but actually move their hand to their mouse and click out.
replies(4): >>44462218 #>>44462327 #>>44462686 #>>44463753 #
9. cess11 ◴[] No.44462213[source]
My REPL-style interfaces don't have it while my editors do, I don't feel either is particularly special and there are little pros and cons with both.
10. piker ◴[] No.44462218[source]
Okay, so optional accessibility issue?
11. jeffhuys ◴[] No.44462267{3}[source]
I think for the feature of wrapping, it is useful enough + just typing a->backspace->" is easy enough that I think it's a net win
replies(1): >>44466722 #
12. _thisdot ◴[] No.44462300[source]
I have this turned on in my code editors and Obsidian. The main advantage is reducing the cognitive load. You don’t have to double-check whether you remembered to close your string, bracket, or parenthesis — it’s just there.
replies(2): >>44462320 #>>44462333 #
13. elric ◴[] No.44462320[source]
The cognitive load of typing two quotes? Golly. That term is starting to take on "whatever" meaning, apparently.
replies(1): >>44462536 #
14. Cthulhu_ ◴[] No.44462327[source]
I've said it in another comment (might be here or Reddit, I don't even know anymore) and it feels like basic skills are just overlooked or taken for granted these days - computer use, mouse / keyboard / typing skills, reading comprehension, writing ability, communication skills, etc.

I'm nowhere near a hiring position but if I was I'd add assessing that to the application procedure.

It feels like this is part of a set of growing issues, with millennials being the only generation in between gen X / boomers and gen Z that have computer skills and can do things like manage files or read a whole paragraph of text without a computer generated voice + RSVP [0] + Subway Surfers gameplay in the background.

But it was also millennials that identified their own quickly diminishing attention spans, during the rise of Twitter, Youtube, Netflix and the like [1].

I want to believe all of this is giving me some job security at least.

[0] https://en.wikipedia.org/wiki/Rapid_serial_visual_presentati...

[1] https://randsinrepose.com/archives/nadd/ (originally published 2003, updated over time to reference newer trends)

replies(1): >>44469100 #
15. Cthulhu_ ◴[] No.44462333[source]
You don't have to anyway, a syntax error will show up on your screen pretty much immediately.
replies(1): >>44462544 #
16. rasur ◴[] No.44462368[source]
Emacs user here, and the whole "electric-mode" stuff (for matching parens or other balanced pairs of things) I find really quite useful. And closing a pair is usually something like shift+enter, which is quite simple (but also - at least in Emacs - generally completely configurable). I think the benefits outweigh the pitfalls, personally.

Can't speak to other editors though.. I don't want to sound like I'm trolling, but they generally feel quite clunky, compared to Emacs (ducks, runs ;p )

replies(1): >>44462644 #
17. matsemann ◴[] No.44462389[source]
> and it’s wrong often enough

How is it ever wrong, though? If I insert a (, and then a {, and the editor appends so that it's ({}), that's always ?correct. Can it ever not be.

Maybe because on a Norwegian keyboard { is a bit awkward, but I like it. Then even if we're 5 levels deep with useEffect(() => {(({[{[ I can just press ctrl+shift+enter and it just magically finishes up everything and put my caret at the correct place, instead of me trying to write ]}]})) in the correct order.

replies(5): >>44462525 #>>44462659 #>>44462725 #>>44465211 #>>44478008 #
18. 8n4vidtmkvmk ◴[] No.44462450[source]
I hated this feature until I realized I could just type the closing quote anyway and it wouldn't double up. Doesn't seem to bother me now that I'm used to it. Once in awhile my editor tries to get too clever and messes things up, but not often
replies(1): >>44463009 #
19. rcxdude ◴[] No.44462525[source]
It certainly can, because it doesn't necessarily know where the closing brace should be, especially when inserting as opposed to writing a completely new line. I'm often deleting random crap in the editors I use with the 'feature' as I'm adding delimiters. '"' tends to be even worse, because the distinction between opening and closing is not obvious.

e.g.:

(a + b > c) -> ((a + b > c) -> (()a + b > c) -> no, I was aiming for ((a + b) > c)

(it sound like you're talking about a different feature/implementation, though, since in the annoying case there's no 'completion' shortcut, it just appears)

20. _thisdot ◴[] No.44462536{3}[source]
The cognitive load of keeping track of all the open delimiters.

In my perceived experience, every time a delimiter is opened, it automatically closes, allowing you to move away from it without thinking.

Even in places where this is not available (Slack, comment boxes, etc.), I close the delimiter as soon as I open it

21. _thisdot ◴[] No.44462544{3}[source]
Which I'd like to avoid as early as possible
22. bbarnett ◴[] No.44462644[source]
There's nothing wrong with emacs. Both vim and emacs are just targeting different segments of humanity, that's all. Vim is clean, concise, slim, where as emacs is more bulky, cluttered, stifling.

It's just matching, and reflecting the way different humans think, and reason, that's all.

(yes, said in jest)

23. jltsiren ◴[] No.44462659[source]
Most editors are not smart enough to do it consistently right. For example, VS Code often inserts extra quotes when I try to break "long string" into "long " + something() + " string". And when I try to write a half-open interval [a, b) in a comment or within a string, the editor inserts an extra ].
24. thasso ◴[] No.44462686[source]
I'm shocked every time I go to City Hall and wait while the clerk types my name letter by letter with two fingers. Doesn't he do that every day?! How as it never occurred to him or anyone else that maybe, just maybe, they would benefit from a typing course. It’s just one example of a pattern I’ve noticed with a lot of office workers.
replies(1): >>44463335 #
25. Kon5ole ◴[] No.44462725[source]
>How is it ever wrong, though?

Whenever you edit something existing that already has the ), ] or } further down and you end up with a ()), []] or {}}. Or when you select some text that you want to replace and start with a quote only to end up with "the text you wanted to replace" instead of the expected ".

I never notice when it works but get annoyed every time it doesn't, so I feel like it never works and always sucks.

I guess it's muscle memory and some people are used to it, but it feels fundamentally wrong to me to have the editor do different basic editing things based on which character is being pressed.

26. whoisyc ◴[] No.44463009[source]
That’s what GP said about “harder to model the editor’s behaviour mentally” though. In a dumb editor you type a quote and you get a quote, in a “smart” editor whether or not you get two quotes, one quote, or no quote at all is context dependent and more confusing.
27. jjcob ◴[] No.44463335{3}[source]
Maybe it's not that important? Taking 5 seconds vs 2 seconds to type a name is probably not that much of a difference? Especially when most of the time you are typing stuff that you need to ask how to spell anyway?
replies(1): >>44463593 #
28. chrismorgan ◴[] No.44463593{4}[source]
It’s not five seconds versus two; it’s fifteen, and with more mistakes remaining at the end (which will sometime waste hours down the line). Because your inferior typist can’t keep up with the phone number being told them, and lose their place in the digits; and are having to concentrate so much on their typing that they don’t correctly interpret what you say to them; and so on. It’s a compounding effect.

Poor typists always slow down processes, and frequently become a bottleneck, local or global. If you can speed up a process by only ten seconds per Thing, by improving someone’s typing skills or by fixing bad UI and workflow, you only have to process 360 Things in a day (which is about one minute per Thing) to have saved an entire hour.

It can be very eye-opening to watch a skilled typist experienced with a software system that was designed for speed, working. In more extreme cases, it can be that one person can do the work of ten. In more human-facing things, it can still be at least a 50% boost, so that two skilled people can beneficially replace three mediocre.

replies(1): >>44498798 #
29. ◴[] No.44463659[source]
30. arkh ◴[] No.44463753[source]
> right or down arrow

If you have to use multiple keyboards, arrows, end, home etc tend to be at different position on the keyboard. Almost no better than using a mouse.

That's were old school vi / emacs shine. CTRL? Always same area, so ctrl-f to go forward? Same gesture whatever brand of a laptop I have to work on.

31. arkh ◴[] No.44463775[source]
Maybe the origin is the fact not everyone uses qwerty mappings.

On a french keyboard, ~#{[|\\^@]} all require the "alt gr" modifier key which is usually just right of the space key. So totally outside the realm of shift, caps lock, ctrl or alt.

32. feelamee ◴[] No.44463863[source]
> You have to press something to exit the delimited region anyway, whether that be an arrow key or the closing delimiter, so just…

Hah, fun about this is that I press exactly the matched symbol ( `}` to `{` , etc) to exit this delimited region and VS even understand what I want! Incredibly useless thing

33. kqr ◴[] No.44464038[source]
I've never noticed some editors do this because I always type both opening and closing symbols at the same time, and then back up into them if I want to fill them out. I think I learned it from my father and just anecdotally I make mistakes of unbalanced symbols nowhere near as often as others.
34. Attrecomet ◴[] No.44465211[source]
> can just press ctrl+shift+enter and it just magically finishes up everything and put my caret at the correct place, instead of me trying to write ]}]})) in the correct order.

I think here you are talking about a different thing -- completion of already started parentheses/"/whatever with content in-between, not the pre-application of paired braces or quotation marks, as the author did, no?

35. pxc ◴[] No.44466698[source]
> But it’s only more of the time: your source will still be invalid frequently, including when it gets things wrong and you have to relocate a delimiter. In practice, I don’t think it’s useful on that ground.

Maybe it's like a pale imitation of structural editing? There are editing modes for some editors that more or less ensure the syntax is always valid as you edit, and they of course include this feature.

36. pxc ◴[] No.44466722{4}[source]
But there have been sensible bindings for doing this forever, e.g.: https://github.com/tpope/vim-surround

There's no need to break normal editing behavior.

37. nyarlathotep_ ◴[] No.44469100{3}[source]
> read a whole paragraph of text without a computer generated voice + RSVP [0] + Subway Surfers gameplay in the background

Quite literally laughed out loud at this. I still cannot believe this is a thing people actually do; I thought it was a joke "genre" at first.

38. charles_f ◴[] No.44478008[source]
I can't count how many } I've deleted across the years because of that feature
39. johnnyanmac ◴[] No.44498798{5}[source]
Not to be be too caustic, but that above commenter really did embrace the whole spiriton on why "Whatever" is rising. That utter numbness to how inefficient this method truly is is a symptom (which is odd, since these sorts of topics are fixated on optimizing workflows).

We seem to value the actual craft less and less with each passing day. so everything slows down overall.

replies(1): >>44499290 #
40. jjcob ◴[] No.44499290{6}[source]
What I was getting at was that maybe typing speed is not the bottleneck. You have to look at how much time the clerk spends typing vs. eg. talking to the customer, clarifying details, explaining the process, reviewing documents, etc. If they spend 5% of their time typing, then even speeding up their typing speed by a factor of 5 will only lead to a 4% speedup, assuming they are fully booked (ie. no wait time between clients).