4 ms·

Like vim, for example? Which supports replacing tab inputs with spaces...

jampekka 3y ago
I code practically exclusively with vim. The replacement is buggy and has many corner cases that come up constantly. As in all editors. Tab indentation has no bugs or corner cases.
- Two9A 3y ago
  And I've been using vim exclusively for north of fifteen years with Tab replacement, never had a problem with the editor getting confused about what happens with spaces when I hit Tab. Some detail about the corner cases you've run into would be great, if they're happening constantly I can see how it would be a bugbear.
  - jampekka 3y ago
    For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent): if True: # Two space indent And continue to add another if block in that, the autoindent will give you four spaces: if True: # Two space indent if True: # Four space autoindent And if you make a new line after the last row there and hit a backspace, it'll erase one space instead of four, giving an indentation of 3 (+2) spaces. And if you start a new line after that, you'll get an indentation of 8 spaces in total. Ending up with: if True: # Two space indent if True: # Four space autoindent # Hitting backspace gives this # Hitting a tab gives this This is just a one case, but things like this tend to happen quite often when editing code. Even if it's been originally PEP-8 indented. Usually it's not what the Tab does, but what the Backspace or Autoindent does. I'm not exactly sure what exact Tab/Backspace/Autoindent rules underlie the behavior, but I can imagine there having to be quite a bit of hackery to support soft-tabs. For me this kind of Tab/Autoindent/Backspace confusion is frequent enough that I'd be very surprised if others don't find themselves having to manually fix the number of spaces every now and then. And when watching over the shoulder I see others too occasionally having to micromanage space-indents (or accidentally ending up with three space indented blocks etc), also with other editors than vim.
    - WorldMaker 3y ago
      As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these. The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general way for an entire "workspace" for every editor that supports or has a plugin that supports .editorconfig.
      - jampekka 3y ago
        Well, yes. But that's one more small thing to config and manage. Not a big deal in isolation but such small things add up to significant yank. With Tabs we wouldn't have this yet another papercut to tool over.
      - Dylan16807 3y ago
        Of course you can override it, but is there any excuse for that default behavior? It sounds ridiculous.
        WorldMaker 3y ago
        The defaults are either 4-space or 8-space soft tab stops. 8 spaces it the oldest soft tab behavior. 4-space soft tabs have been common for C code among other languages for nearly as many decades. It is only relatively recently that Python and JS and several Lisp-family derivatives have made 2-space tab stops much more common of a style choice. Unfortunately there is no "perfect" default as these are as aesthetic preferences as anything else. (It is one of the arguments for using hard tabs instead of soft ones in the eternal tabs versus spaces debates because editors can show hard tabs as different space equivalents as a user "style choice" without affecting the underlying text format.)
        Dylan16807 3y ago
        Soft tabs at 4 would be fine, though worse than autodetect. But that is not the behavior described in the above post.
- theamk 3y ago
  When looking at the code, tab-containing files are the most inconsistent ones, especially when viewed via general tools (less, diff, even web viewers). Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead: ... some lines start with spaces, some with tabs. This looks fine in someone's IDE but the moment you use "diff" or "grep" which adds a prefix, things break and lines become jagged. ... one contributor uses tabs mid-line while other use spaces. It may look fine in their editor with 6 character tabs, but all the tables are misaligned when looking in app with different tab size. Given how many corner cases tabs has, I always try to avoid them. Spaces have no corner cases whatsoever and always look nice, no matter what you use to look at the code. (the only exceptions are formatters which enforce size-8 tabs consistently everywhere. But I have not seen those outside of golang)
  - wwweston 3y ago
    > Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead: ... some lines start with spaces, some with tabs. People using tabs for alignment can happen when you've got a tab-camp-person who hasn't yet realized how they're terrible for alignment. But "some lines start with spaces, some with tabs" happens for precisely two reasons: * you have a codebase with contributors from both camps * people thought in-editor tooling was the solution (now you have two problems) > Spaces have no corner cases whatsoever This is tooling and (as you realized) stop preference dependent.
- deleted 3y ago
  [deleted]

I code practically exclusively with vim. The replacement is buggy and has many corner cases that come up constantly. As in all editors. Tab indentation has no bugs or corner cases.

Two9A 3y ago
And I've been using vim exclusively for north of fifteen years with Tab replacement, never had a problem with the editor getting confused about what happens with spaces when I hit Tab. Some detail about the corner cases you've run into would be great, if they're happening constantly I can see how it would be a bugbear.
- jampekka 3y ago
  For example with vim (debian) defaults, if you happen to have a 2-space indented Python (the first two spaces are for HN formatting, the first if should start at zero indent): if True: # Two space indent And continue to add another if block in that, the autoindent will give you four spaces: if True: # Two space indent if True: # Four space autoindent And if you make a new line after the last row there and hit a backspace, it'll erase one space instead of four, giving an indentation of 3 (+2) spaces. And if you start a new line after that, you'll get an indentation of 8 spaces in total. Ending up with: if True: # Two space indent if True: # Four space autoindent # Hitting backspace gives this # Hitting a tab gives this This is just a one case, but things like this tend to happen quite often when editing code. Even if it's been originally PEP-8 indented. Usually it's not what the Tab does, but what the Backspace or Autoindent does. I'm not exactly sure what exact Tab/Backspace/Autoindent rules underlie the behavior, but I can imagine there having to be quite a bit of hackery to support soft-tabs. For me this kind of Tab/Autoindent/Backspace confusion is frequent enough that I'd be very surprised if others don't find themselves having to manually fix the number of spaces every now and then. And when watching over the shoulder I see others too occasionally having to micromanage space-indents (or accidentally ending up with three space indented blocks etc), also with other editors than vim.
  - WorldMaker 3y ago
    As with most things in vim, it is definitely manageable in settings such as tw=2 (tab width) and sts=2 (soft tab stop). This is why a lot of older Python files, in particular, are littered with vim modelines with settings like these. The nice modern twist is .editorconfig files and the plugins that support them including for vim. You can use those to set such standard language-specific config concerns in a general way for an entire "workspace" for every editor that supports or has a plugin that supports .editorconfig.
    - jampekka 3y ago
      Well, yes. But that's one more small thing to config and manage. Not a big deal in isolation but such small things add up to significant yank. With Tabs we wouldn't have this yet another papercut to tool over.
    - Dylan16807 3y ago
      Of course you can override it, but is there any excuse for that default behavior? It sounds ridiculous.
      - WorldMaker 3y ago
        The defaults are either 4-space or 8-space soft tab stops. 8 spaces it the oldest soft tab behavior. 4-space soft tabs have been common for C code among other languages for nearly as many decades. It is only relatively recently that Python and JS and several Lisp-family derivatives have made 2-space tab stops much more common of a style choice. Unfortunately there is no "perfect" default as these are as aesthetic preferences as anything else. (It is one of the arguments for using hard tabs instead of soft ones in the eternal tabs versus spaces debates because editors can show hard tabs as different space equivalents as a user "style choice" without affecting the underlying text format.)
        Dylan16807 3y ago
        Soft tabs at 4 would be fine, though worse than autodetect. But that is not the behavior described in the above post.
theamk 3y ago
When looking at the code, tab-containing files are the most inconsistent ones, especially when viewed via general tools (less, diff, even web viewers). Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead: ... some lines start with spaces, some with tabs. This looks fine in someone's IDE but the moment you use "diff" or "grep" which adds a prefix, things break and lines become jagged. ... one contributor uses tabs mid-line while other use spaces. It may look fine in their editor with 6 character tabs, but all the tables are misaligned when looking in app with different tab size. Given how many corner cases tabs has, I always try to avoid them. Spaces have no corner cases whatsoever and always look nice, no matter what you use to look at the code. (the only exceptions are formatters which enforce size-8 tabs consistently everywhere. But I have not seen those outside of golang)
- wwweston 3y ago
  > Sure, if people would only ever use tabs for indentation and spaces for alignment, things could be good. But this almost never happens, instead: ... some lines start with spaces, some with tabs. People using tabs for alignment can happen when you've got a tab-camp-person who hasn't yet realized how they're terrible for alignment. But "some lines start with spaces, some with tabs" happens for precisely two reasons: * you have a codebase with contributors from both camps * people thought in-editor tooling was the solution (now you have two problems) > Spaces have no corner cases whatsoever This is tooling and (as you realized) stop preference dependent.
deleted 3y ago
[deleted]