5 ms·

I think a more ideal solution would be to achieve the flexibility of elastic TabStops without having to actually change the way it's represented under the hood.

I think a more ideal solution would be to achieve the flexibility of elastic TabStops without having to actually change the way it's represented under the hood. My conviction from personal experience is that your personal tools need to be adaptable to fit any organization. This splits largely along tech stack culture lines. Our shop was originally Ruby before we started moving to NodeJS, we all use spaces for indentation. So unless I want to force my whole team to start using tabs, I can't use elastic tabstops. This isn't a viable improvement until it can accommodate the existing state of affairs. The other obstacle in the way is code linters. I have to make a case to turn off linter rules at my shop and if the only objection I have is that it makes a workflow I haven't even tried yet difficult to implement, it's not going to be taken seriously if it requires work from the whole team. The way I usually accomplish workflow improvement objectives is to find a way to accommodate both my needs and the status quo while thinking deeply about the underlying context creating the obstacle. Environment managers get gnarly when you have to commit .env files to the codebase. Every time someone changes the .env file and commits, on pull the expected behavior of the system changes. Not having a .env file committed to the codebase caused issues with the insufficient handling of environment by our CI process. So I use .env-local for overriding the environment and one line in the codebase overrides the .env file in case .env-local exists. That way I don't have to care about what's in .env and I won't get surprising behavior upon pulling the repo. One year later I got around to eliminating the 12 factor violation. One month after that we decided to replatform. -_-

scrollaway 8y ago
Nowadays with prettier, gofmt and similar, there's almost no languages remaining without high quality, fast formatters which can run on save. So changing from spaces to tabs should be as simple as updating to tabs:true in prettier config.
- vinceguidry 8y ago
  It still changes all the spaces into tabs. The only acceptable impingement on the rest of the team's workflow for changes in my workflow is 'none'.
  - wwweston 8y ago
    Which is half of why this is an insoluble problem. There's no solution that doesn't impose some workflow or wetware overhead on introduction. Installing "Tabs for indentation, spaces for alignment" on wetware is probably the best solution in terms of maximizing utility for minimized development/workflow costs. But even that is going present a wetware tax for some developers, and it's not superior in terms of utility to the article's proposal.
    - vinceguidry 8y ago
      We don't know that there's no solution. One of your siblings suggested having the editor just use space alignment. I can't see any reason why that wouldn't work either and was the idea I had in mind. But installing ideas onto wetware is perhaps the most expensive thing that can ever be considered. Because it often involves fighting a war.
- deleted 8y ago
  [deleted]
- zamber 8y ago
  We've got a git hook that prettifies and runs unit tests on commit. Works very nicely. Formatting is one flame war, another is code style. We've automated that too with sticking to airbnb. If there are any warning a commit does not pass.
allenz 8y ago
For compatibility, it's feasible to represent elastic tabs with spaces. All we care about is the new behavior. The editor can parse for aligned columns.

scrollaway 8y ago

Nowadays with prettier, gofmt and similar, there's almost no languages remaining without high quality, fast formatters which can run on save. So changing from spaces to tabs should be as simple as updating to tabs:true in prettier config.

vinceguidry 8y ago
It still changes all the spaces into tabs. The only acceptable impingement on the rest of the team's workflow for changes in my workflow is 'none'.
- wwweston 8y ago
  Which is half of why this is an insoluble problem. There's no solution that doesn't impose some workflow or wetware overhead on introduction. Installing "Tabs for indentation, spaces for alignment" on wetware is probably the best solution in terms of maximizing utility for minimized development/workflow costs. But even that is going present a wetware tax for some developers, and it's not superior in terms of utility to the article's proposal.
  - vinceguidry 8y ago
    We don't know that there's no solution. One of your siblings suggested having the editor just use space alignment. I can't see any reason why that wouldn't work either and was the idea I had in mind. But installing ideas onto wetware is perhaps the most expensive thing that can ever be considered. Because it often involves fighting a war.
deleted 8y ago
[deleted]
zamber 8y ago
We've got a git hook that prettifies and runs unit tests on commit. Works very nicely. Formatting is one flame war, another is code style. We've automated that too with sticking to airbnb. If there are any warning a commit does not pass.

allenz 8y ago

For compatibility, it's feasible to represent elastic tabs with spaces. All we care about is the new behavior. The editor can parse for aligned columns.