弾性タブストップの欠点は何ですか？[閉まっている]

ここを見てください：タブとスペースの典型的な聖戦。

弾性タブストップをご覧ください。すべての問題が解決し、非常に便利な新しい動作が多数追加されました。

弾性タブストップは、タブ対スペースの議論でも言及されていますか？何故なの？弾力性のあるタブストップのアイデアには非常に深刻な欠点があり、誰もそれを人気のあるエディターに実装したことはありませんか？

編集：「なぜ彼らは言及されていない」にあまりにも重点を置いて謝罪します。それは本当に私が意図したものではありませんでした。その質問はおそらく話題外です。私が本当に言っているのは、明らかに有益なアイデアのより広範な採用を妨げるこの最大の欠点は何ですか？（すべてがすでにそれをサポートしている理想的な世界で）

（そこには、Microsoft Connectのリクエストすでにだ判明弾性タブストップのVisual Studioの実装は、およびEclipseの要求はあまりにも。プラスについて尋ねる質問があります弾性タブストップを実装する他のエディタは）

聖戦は主観的

ニックの弾力性のあるタブストップは、多くの人々が実行可能なソリューションに同意するのに役立つ素晴らしいコンセプトですが、この聖戦を完全に終わらせることは非常に疑いますが、結局のところ、それは好みの問題であり、多くのプログラマーは動きません妥協の犠牲を払っても、この問題に関する彼らの立場から少し離れています。それが第一の理由でしょう。

たとえば、「スペース」側の多くの人は、適切なレンダリング（たとえば、SCMのWebビューで変更セットを表示する）のためにソフトウェアに追加のロジックが必要になるため、それを嫌います。

実装の問題

しかし、最も明白な理由はちょうどそのあるエントリへの技術的な障壁：それはだ根本的に異なる概念 IDEやテキストエディタでの年数（そうでない場合は数十年）のために実装されたものから。かなり異なる方法で行を処理するためにそれらの一部を書き直す必要があります。これは、行処理コードで深く緊密なカップリングを被る可能性の高い古いシステムや大きなシステムにとって困難です。ただし、ゼロから始める方がはるかに簡単です（NickのデモやGoのtabwriterパッケージを考えてください）。

個人的な逸話として、私はしばらく前に作者に近づいて、見えているemacsのサポートがあるかどうかを尋ねたことを覚えています。この特定の場合、彼はこれが些細ではない理由としてこれに言及しました。また、この機能の実装と大衆への提供を支援するために、コミュニティからの支援を求めました。

私たちは十分気にしますか？

3番目の理由は、一部の開発者は問題にこだわっていず、努力をサポートするために余分なマイルを費やすことをあまり気にしていないからです。ほとんどの場合、spaces-vs-tabsの競合はビジネスのブロッカーではないため、問題の背後にあるドライブはそれほど多くありません。

あなたがそれを望むなら、あなたはそれのために戦わなければなりません。これは、オープンソースソフトウェアで実行可能です。そして、これらを十分に変更する場合、クローズドソースのものは、たとえそれが非常に小さい部分であっても、ユーザーベースの一部を失うリスクを負う必要があります。

それで、あなたがそれを望むならば、ニックに手を貸してください。

多くの場合、ワードプロセッサを使用して、ワードの配置を制御する非表示の自動ルールを使用せずに、ドキュメントを思いどおりに表示する必要がありました。編集者がなぜそれらの単語をそこに置くことを主張しているのかを理解しようとして1秒を費やしたくありません。

これを聞いたのは初めてです。良いアイデアかどうかはわかりませんが、すでにコードを自動的にフォーマットするツール（インデントなど）があるので、ほとんど役に立たないようです。

vimで賢い弾性タブストップを開いて編集するとどうなりますか？タブは自動的にクリーンアップされますか、それとも混乱が残りますか？

私が見た主な欠点は、おそらく差分、バージョン管理を壊し、それらをサポートしていないエディターと互換性がないことです。それらをサポートするために多くのコード変更が行われる可能性があり、「コードをフォーマットするための別のタブ」機能よりも重要なことがあります。結局のところ、indentメモリが提供される場合、上記のすべてを行うすべてを使用できます。

正直に言うと、最初の興奮を乗り越えてしまえば、そんなに役立つとは思いません。たとえば、とにかく行末のコメントは好きではありません。コメントは常に別の行に書きます。それにより、弾性タブの主な用途が失われます。

その後も、もちろんそれらを使用して、関数の引数（およびパラメーター）と割り当ての長いリストを調整できます。

しかし、前者については、すべての引数を1レベルだけインデントする傾向があり、それは完全にうまく機能します。

void foo(
    int x,
    int y,
    string z
)

そして、私は表示されませんどのように変更する必要が。

割り当ての調整に関しては、私はそれを行いません。私は割り当ての周りに単一のスペースを置きます、それだけです。また、私は多くの課題を一緒にクラスター化しない傾向があるため、読みやすさの問題はめったにありません。

要約すると、弾性タブは絶対に持ってゼロ私のために有用であることを。これはもちろん非常に個人的な好みですが、変化する可能性がありますが、うまく機能することがわかり、弾性タブのサポートの欠如は他の人が同じように考えているためだと思います。

エディターがそれらを実装する場合、私はまだそれらを使用しません。

欠点の1つは、隣接する行のタブストップをグループ化するため、ある行グループで整列してから次の行でインデントが必要な場合に機能しないことです。

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

私が欲しかったもの：

def foo( bar,
         xyzzy ):
    wibble()

中括弧言語の場合、これは問題ではないかもしれません。通常は、アニメーションのように開き括弧を独自の行に置くことでこれを解決できますが、空白に敏感な言語の場合、これはすぐに痛みになります。そして、スペースを使用することに頼らざるを得なくなります。

なぜ垂直タブ文字（VT、ASCII 11）を弾性タブストップの使用を示すのに役立たせないのですか？主流のプログラミング言語では目的を果たしませんが、それらすべての有効な空白として解析されます。

これは、エラスティックタブストップの使用が外部化された慣習ではなくなったことを意味します（たとえば、「このファイルはエラスティックタブストップでフォーマットされています。オンにしてください」）。

既存のテキストエディタでは、通常、垂直タブの代わりにグリフまたは単一のスペースが表示されます。これは理想的ではありませんが、少額の支払いが必要です、IMO。

テキストエディタのほとんどのIDEには実装されていないため、これらのドキュメントは言及されていません。それらは、プロジェクトで実際にほとんど使用されない目新しいものです。

パンチカードの時代からプログラミングのレイアウトにスペースが使用されてきました。タブが登場し、明らかに誰かが自分が良いアイデアだと思った（彼らは間違っていた：p）。

最近のほとんどの編集者がタブをスペースに自動的に変換できる時代には...かなり無意味です。

タブとスペースのように些細なことを処理するためにさらに別のツールをインストールしなければならないことは確かに私にとって魅力的ではなく、同僚の大部分にとってはそうだとは思わない。

IDEがそれらをサポートしていれば、彼らは多くの用途を見つけると思います（Microsoft！）。ひとたびフラワーボックスを横に倒して、見やすく読みやすくすることができたら、彼らはそうするでしょう。突然ソースコードにコメントが追加される可能性があります（これは良いことです）。

「次の場合は...」というリストにコメント「ツールチップ」を追加することもできるので、必要に応じて大きなコメントブロックを非表示にして簡単に表示できます。ドキュメントの一部を形成するコメントブロックを含めることもできます（サンドキャッスル型のものではなく、メソッドヘッダーだけでなく、コードに埋め込まれた適切なユーザー可読ドキュメントスニペット）

短所：本当に1だけが変更されたときに行の束が変更されたように見えると、ソースdiffが悪く見える場合があります（エディターがタブをスペースに変換してファイルを保存した場合）。または、エラスティックタブが1文字（または2つのタブストップ）で実装されている場合、エディターの外部でソースを表示すると見た目が悪くなる可能性があります。

ただし、行末の「タブタブ」はコメントブロックを伸縮させ、それに応じて後続の行（ダブルタブ間隔）にすべてのコメントを並べます。

私がそれを見る方法は次のとおりです。人気のあるツールのほとんどが既に弾性タブストップをサポートしていれば、多くの人がそれらを使用するでしょう。viのナビゲート/編集モード、構文の強調表示、およびIntellisenseでも同じことが起こりました。いずれの場合でも、確立された知恵は、それは有用ではないか、必要ではないというものでしたが、実装されて、それが始まりました。

もちろん、弾性タブストップの影響は比較的小さくなります。ほとんどの人は現状に十分満足しているので気にしません。同様の推論は多くの状況に当てはまり、一部の人々は自分の持っているものに満足しているだけで、より高度なものに切り替える理由を見つけられません。言い換えれば、弾性タブストップの最大の問題は、他のほぼすべての良いアイデアと同じです。それは牽引力を得る必要があります。

しかし、それは、この機能を段階的に採用できないという意味ではありません。チーム全体で使用を開始するには新しいコンパイラと新しいIDEが必要ですが、すべてのプログラミング言語は段階的に採用されました。同じことは、すべてのハードウェアアーキテクチャと他の多くの例にも当てはまります。また、既存のツールとの統合の欠如が目を引くものではありません。たとえば、自動ツールで理解されていた以前の読みにくい形式を段階的に置き換えた「unified-diff形式」も同様です。 （パッチなど）。これらのツールは時間の経過とともにアップグレードされています。

他の人が言及した相互運用の問題に感謝しますが、それにもかかわらず、私たち全体でこれをthisすることなく採用するチーム（私のようなチーム）は確かに存在します。差分、マージなどの外部ツールは最初はサポートしていませんが、ベンダーにこの機能を含めるよう奨励する役割を果たします。これは常に進歩がなされてきた方法です。一時的な移行期間には多少の苦労が必要ですが、最終的には価値があります。

私がそれに関して持つ最大の問題は、ドキュメント全体で一貫性のない間隔です。プログラマーとして、ループまたはifステートメントが「標準」インデントで表示されてから、さまざまなインデントで通知されることにイライラすることを知っています。個人的には、私が見ているコードのブロックだけでなく、ドキュメンテーション全体に中括弧が並んでいるのが好きです。

全体的には良いアイデアだと思いますが、個人的には好きではありません。

弾性タブストップのjEditの実装を試してみましたが、これは私が使い慣れているプログラミング言語（主にHTML / XMLおよびCに似た言語）で驚くほどうまく機能します。ただし、Pythonコードを使用した場合のレンダリング方法は次のとおりです（タブの代わりにスペースを使用して、物事がどのように整列するかを示します）。

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

間隔に依存するPythonのような言語の場合、これは弾力性のあるタブストップによって提供される機能を無効にしない限り、重大な問題です。VimやEmacsのようなエディターは、オプションの名前と無効化の方法を知っていれば、ほとんどの種類の機能の無効化を簡単にしますが、上記のようなコードではこの機能を無効にする必要があります。

そうは言っても、x86 ASM、C、C ++、Go、XML、HTML、および余白にあまり依存していない他のユーザーに最適です。

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

SchemeのようなLisp方言には、弾力性のあるタブストップが「ugい」コードを表示させる独自の規約があると言います。2つの列の規則に一致するようにタブストップ設定を変更し、異常な場所（関数とその引数の間）にタブストップを挿入した場合：

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

対より読みやすい：

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

確かに、これはPythonの例ほど悪くはありませんが、コードの可読性は間違いなく低下します。C＃やC ++のようなものでコーディングするときの機能は非常に好きですが、PythonやSchemeのようなホワイトスペースが機能的および/または視覚的に役立つ言語でコーディングするときの機能は嫌いです。弾性タブストップは、個別のインデントユーティリティを必要とせずに役立つように特別に作成されましたが、明らかにすべてのプログラミング言語を対象としているわけではありません。

Emacsはすでに閉じられていない括弧の存在下でインデントを処理し、ウィルマを自動的にfredに揃えます。Eclipseが同じことをしない理由はわかりません。OK、アイデアはありますが、無料です。

Emacsにあまり問題なくコメントを揃えさせることもできますが、知る限り誰も望んでいません。