The Tool Was Never the Layer
Every few months I open a config file to fix one specific irritation, and by the time I close it the irritation is gone, the keybindings are different, and I genuinely cannot reconstruct what started the session. This isn't a memory problem. It's evidence about where the value actually was.
The standard story treats this as a small failure of discipline. You went in to fix a slow startup or a clashing shortcut, you got absorbed, you came out having touched fifteen things unrelated to the original complaint, and the honest move is to feel a little sheepish about it. Scope creep, we'd call it anywhere else. But scope creep implies there was a scope, a real problem with edges, that the session then wandered past. What if there wasn't one? What if the problem statement was never load-bearing, just the permission slip that got you to open the file?
Here's the test I trust: ask what problem you're solving right as you sit down, and watch whether the answer survives contact with the tool. If it does, you fix the thing and leave, because the problem has a shape independent of the fiddling and the fiddling either closes that shape or it doesn't. If it doesn't survive contact, if the moment your hands are on the keys the original complaint stops mattering and gets replaced by whatever's now visibly improvable, that's not you getting distracted. That's the problem statement admitting it was decorative. The real activity was always "open this thing and adjust it," and the complaint was just this week's excuse.
I don't think this is unique to editors, though editors are the purest case because the config is infinite and the payoff for any given change is nearly nil. It shows up anywhere a tool is both expressive and personal: an inbox full of filters nobody but you will ever read, a note-taking system migrated for the fourth time this year, a phone home screen rearranged on a Sunday for no occasion. In each case there's a plausible-sounding problem you could name if asked, and in each case the problem is doing less work than the fact that the interface rewards fiddling with a small, immediate, legible sense of things being more correct than they were an hour ago. That sense is real. It's just not evidence that anything upstream of the tool needed fixing.
The reason this matters is that "what problem am I solving" is usually asked as a discipline, a way to keep yourself honest before you burn an afternoon. It's a good question when the problem is actually somewhere else and the tool is just where you go to address it, a keyboard shortcut for a workflow issue, a linter rule for a team disagreement. But when you ask it fifty times over a tool you keep returning to, and it dissolves fifty times, the question has stopped functioning as a check and started functioning as a ritual you perform on the way to doing the thing you were always going to do anyway. At that point the honest move isn't to keep asking it more sternly. It's to notice that the tool itself, the fact of reconfiguring it, is the activity, and stop pretending it needs a downstream justification to be worth the time.
None of this is an argument that fiddling is bad. Plenty of things people do are worth doing without cashing out as solved problems, chess, gardening, running further than any errand requires. The mistake isn't the fiddling, it's the paperwork we make it fill out, the insistence that every hour at the config has to have been in service of something else or it doesn't count. Sometimes the tool is the end user. You were never solving a problem at that layer because there was never a problem down there to find, only a place you liked being.