Issue #16112 has been updated by duerst (Martin D=FCrst).


k0kubun (Takashi Kokubun) wrote:

> * It would reduce the number of problems for editors like Sublime Text, V=
SCode, and Atom.

I'm surprised some of the currently most popular editors can't handle such =
situations. I'm not using one of these editors, but would like to check how=
 the editors I use behave. For this, it would be good to know a file (and s=
ome relevant line numbers) that currently has both tab-indented and space-i=
ndented lines. Can somebody give an example?

----------------------------------------
Misc #16112: Reduce the possibility of "expand tabs" commit occurrences
https://bugs.ruby-lang.org/issues/16112#change-80909

* Author: k0kubun (Takashi Kokubun)
* Status: Open
* Priority: Normal
* Assignee: =

----------------------------------------
## Problem
* While we agreed to use only spaces for indentation of C code in [Bug #142=
46], we sometimes hit "expand tabs" commit when we just edit a part of exis=
ting lines with hard tab indentation.
* "expand tabs" commit bothers people when we need to perform a revert or a=
 backport.
* However, because [Bug #14246] aimed to eventually make indentations consi=
stent, we do not want to just drop "expand tabs".
  * One of the motivations to solve [Bug #14246] is that having hard tabs m=
akes preprocessed MJIT header ugly and it makes debugging on GCC hard. As M=
JIT may introduce C-code inlining for sources outside vm.c in the future, w=
e want to fix the issue in almost all C sources which can be run on runtime.

## Possible Solutions
There would be some options to approach the problem. I'd like to hear opini=
ons about these options.

1. Expand all tabs at once for all files managed by auto-style.
  * In [Bug #14246], this was clearly objected for the reason "Indents shou=
ld become consistent over time".
  * In my understanding, not folliwng "Indents should become consistent ove=
r time" would be problematic mainly for polluting "git blame" and conflicts=
 on backport.
      * For the first point, we can use `-w` option of `git blame` to ignor=
e that.
      * For backport, it's a trade-off with many "expand tabs" commits. We =
need opinions about this from @usa and @nagachika .
  * Also reverting a commit before the commit expanding all tabs would be b=
othering, for a short while.
2. Skip expand tabs for existing lines when indentation is not changed, and=
 expand tabs only in newly-added lines.
  * If editors are configured properly, "expand tabs" would not happen for =
new patches in this approach.
  * Even in this approach, at least we will not go to the opposite directio=
n of eventually achieving [Bug #14246]. So it seems acceptable.
3. Prepare a local pre-commit hook to expand tabs in newly-added or edited =
lines, and let people who do not want an "expand tabs" commit use it.
4. Make pull request CI fail when there's diff to be expanded, and let peop=
le who do not want "expand tabs" commit things from pull requests.

---Files--------------------------------
Screen Shot 2019-08-19 at 2.43.06 PM.png (48.8 KB)


-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>