Sounds somewhat familiar. I worked at a place that replaced a basic LAMP stack with microservices written in Perl and MongoDB as a backing store, for the sole purpose of raising complexity.
And left Mongo on the default settings for the time (speed of return over reliability of saving data), so they ended up with a reporting replica which was MySQL.
Don't think I've seen anything before or since which was architected so exactly backwards.
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.
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.
if !exists("g:python_recommended_style") || g:python_recommended_style != 0
" As suggested by PEP8.
setlocal expandtab tabstop=4 softtabstop=4 shiftwidth=4
endif
So if you use "set sw=2" then it leaves tabstop and softtabstop at 4.
You can set that g:python_recommended_style to disable it.
Also sw=0 uses the tabstop value, and softtabstop=-1 uses the shiftwidth value.
I agree Vim's behaviour there is a bit annoying and confusing, but it doesn't really have anything to do with tabs vs. spaces. I strongly prefer tabs myself as well by the way.
Even when you DO use tabs Vim will use spaces if sw/ts/sts differ by the way. Try sw=2 and using >>, or sts=2 with noexpandtab.
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.
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.)
The part where the user is on a line indented by 2, hits return, and gets a line indented by 2+4=6 doesn't sound like soft tabs at 4 to me. And I wouldn't expect hitting backspace to then only remove 1 space (if it actually removed 2 that makes more sense, but is inconsistent with what what it just added). At that point, hitting return and getting a line indented by 8 might make sense but is weird.
Another comment suggests it's using 2 and 4 for different settings and that's causing problems.
2 is the base indent of the line where the : was added. Autoindent adds 4 spaces for the current tab stop. Autoindent isn't using some counts of indents, it's taking "spaces in previous line + tab stop".
Backspace doesn't unindent in vim by default, it removes spaces one at a time. That's a difference between the ts=4 (tab stop) and sts=4 (soft tab stop) is sts also applies to backspace. But the default is that it doesn't because the out of the box default believes that backspace operates on physical characters (spaces) not soft/fake ones (tabs expanded to spaces) by default.
I don't know if that is the right default, and it is definitely a baroque exercise to get all the settings right for some languages, but there is a consistency to the defaults even if those defaults don't meet some modern expectations from newer code editors.
(Also, I just realized above I confused tw [text width] and ts [tab stop]; my vim skills are rusting a little.)
"CBE" refers to Commander of the most excellent order of the British Empire [0] which is a title conferred by the monarch on those deemed to have performed especially well in the service of the nation.
So you can see how its value might be diluted by this instance.
I should write that down; -Z would've been really useful when my SSH server was falling over in a heap and I was left scrolling through strace to work out what happened.
I always enjoy reading stories of yak-shaving adventures whenever they come up, so when I ran into my own back in November, I thought it might be fun to write up as a post.
This adventure starts with a small email problem, balloons into a Debian upgrade, and then it all goes sideways. Let me know what you think!
Oh goodness, this is the kind of thing I've been trying to find for years now: some method of making a computer from scratch, as in from raw materials.
The Great Tinkertoy Computer [1] is made from raw materials, although its specific rather than a general purpose computer, and had computer aided design although back in the day it was via a PDP-10.
These kinds of articles are always fun: essentially playing golf with the size of an executable or some other file format.
To plug my own entry in the genre, back in 2006 a few members of the Nintendo DS emulation scene tried to put together the smallest DS ROM that would still do something visible on the system: https://imrannazar.com/hacks/the-smallest-nds-rom
We ended up with a 352-byte file with two minimal executables, for the ARM7 and ARM9 cores. I've yet to see a .nds file smaller than that.
Reddit first came up with the phrase "spicy pillow" to describe that combination.