弾性タブストップの欠点は何ですか？
ここを見てください タブ対スペースの典型的な聖戦 。
ここを見てください： elastic tabstops 。すべての問題が解決され、非常に便利な新しい動作がたくさん追加されました。
弾力性のあるタブストップはそのタブ対スペースの議論でさえ言及されていますか？何故なの？エラスティックタブストップのアイデアに重大な欠点があるので、人気のあるエディターに誰も実装したことがありませんか？
[〜＃〜] edit [〜＃〜]：「なぜ言及されていないのか」を強調しすぎたことをお詫びします。それは私が意図したものではありませんでした。 that質問はトピックから外れている可能性があります。私が実際に意味していることは、明らかに有益なアイデアの幅広い採用を妨げている最大の欠点は何ですか？ （すべてがすでにそれをサポートしている理想的な世界で）
（Microsoft Connectにはすでに Visual Studioのエラスティックタブストップの実装 に対するリクエストがあり、さらに Eclipseでのリクエスト も必要です。さらに、 エラスティックタブストップを実装する他のエディター ）
聖戦は主観的です
ニックの弾力性のあるタブストップは素晴らしいコンセプトであり、これは多くの人々が実行可能な解決策に同意するのに役立つ可能性がありますが、この聖戦を完全に終わらせることは非常に疑わしいです。結局のところ好みの問題そして、多くのプログラマーは妥協の犠牲を払っても、この問題に関して彼らの立場から1インチを動かさないでしょう。それが第一の理由です。
たとえば、「スペース」側の多くの人々は、それをそのまま嫌っていますソフトウェアに追加のロジックが必要適切なレンダリングを行うには（たとえば、SCMのWebビューで変更セットを表示するだけ） 。
実装の問題
しかし最も明白な理由は単なるエントリへの技術的な障壁：これは根本的に異なるコンセプトであり、長年実装されてきたもの（数十年ではないとしても）IDEやテキストエディタで。かなり異なる方法でラインを処理するようにそれらの一部を書き換える必要があるため、ライン処理コードで深く密な結合に悩まされる可能性が高い古いシステムや大きなシステムでは困難になります。ただし、最初から始める方がはるかに簡単です（ Nickのデモ または Go の tabwriter パッケージを考えてください）。
個人的な逸話として、私はしばらく前に作者にアプローチして、emacsのサポートがあるかどうか尋ねたのを覚えています。この特定のケースでは、彼はそれが簡単ではない理由としてこれを述べました。彼はまた、この機能を実装して大衆にもたらすのを助けるためにコミュニティに助けを求めました。
私たちは十分気にしていますか？
3番目の理由は、一部の開発者が問題に集中しておらず、努力をサポートするために余計に努力することをあまり気にしないということです。ほとんどの場合、スペースとタブの競合はビジネスブロッカーではないため、問題の背後にはそれほど大きな動機はありません。
必要な場合は、それと戦わなければなりません。オープンソースソフトウェアで実行できます。そして、これらを十分に変更すると、クローズドソースのものは、たとえそれが非常に小さい部分であっても、一部のユーザーベースを失うリスクを負うことになります。
それで、あなたがそれを望むなら、ニックに手を貸してください。
多くの場合、単語の配置を制御する隠された自動ルールがなくても、ドキュメントを希望どおりの外観にするためにワードプロセッサと戦わなければなりませんでした。エディターがなぜそれらの単語をそこに配置することを主張しているのかを理解するために1秒間費やす必要はありません。
初めて聞いた。それらが良いアイデアかどうかはわかりませんが、すでにコードを自動的にフォーマットするツール（インデントなど）を持っているため、ほとんど役に立たないようです。
Vimで賢い弾性タブストップを開いて編集するとどうなりますか？タブは自動的にクリーンアップされますか、それとも混乱が残りますか？
主な欠点は、私が見ているように、差分、バージョン管理が壊れている可能性があり、それらをサポートしていないエディターと互換性がないことです。それらをサポートするためのコードの変更は多分あり、「コードをフォーマットするための別のタブ」機能よりも重要なものがあります。結局のところ、メモリが機能する場合は、上記すべてを実行するindentをすべて使用できます。
垂直タブ文字（VT、ASCII 11）を伸縮タブストップの使用を示すために機能させるだけではどうですか？これは、メインストリームプログラミングで 目的なし を機能させます。言語、まだそれらすべての有効な空白として解析されている、私の知る限り。
つまり、エラスティックタブストップの使用は外部化された規則ではなく（たとえば、「このファイルはエラスティックタブストップでフォーマットされています。オンにしてください」）、ケースバイケースでオプトインするものです。
既存のテキストエディターは通常、垂直タブの代わりにグリフまたは単一のスペースを表示します。これは理想的ではありませんが、少額の支払いであるIMOです。
正直なところ、最初の興奮を乗り越えてしまえば、それほど役立つとは思いません。たとえば、とにかく行末のコメントが気に入らない–私はalways別の行にコメントを入力します。これにより、弾性タブの主な用途が失われます。
その後も、もちろんそれらを使用して、関数の引数（およびパラメーター）と割り当ての長いリストを整列させることができます。
しかし、前者の場合、すべての引数を1レベルだけインデントする傾向があり、それは完全にうまく機能します。
void foo(
int x,
int y,
string z
)
そして、私はanyを変更する必要があるとは思いません。
割り当ての調整に関しては、私はそれをしません。割り当ての周りにスペースを1つ入れます。それだけです。また、多くの割り当てを一緒にクラスター化しない傾向があるため、読みやすさの問題はほとんどありません。
要約すると、弾性タブには絶対にzeroがあります。もちろん、これは非常に個人的な好みであり、さまざまな場合がありますが、うまく機能することがわかり、エラスティックタブがサポートされていないのは、他の人も同じように考えているためだと思います。
Ifエディターがそれらを実装する場合、私はまだそれらを使用しません。
1つの欠点は、隣接する行のタブ位置をグループ化するため、行のグループに配置してから次の行にインデントを設定する場合に機能しないことです。
def foo( bar,
xyzzy ):
wibble() # Too much indentation
私が欲しかったもの：
def foo( bar,
xyzzy ):
wibble()
中かっこ言語の場合、これは問題にならない可能性があります。これは、通常、中かっこを（アニメーションのように）独自の行に置くことで解決できますが、空白を区別する言語の場合、すぐに問題になります。そして、スペースの使用にフォールバックする必要があります。
それらはテキストエディターのほとんどのIDEに実装されていないため、言及されていません。それらはプロジェクトでほとんど実際に使用されない目新しさです。
スペースは、パンチカードの時代からプログラミングのレイアウトに使用されてきました。タブがやって来て、誰かが明らかにそれを良いアイデアだと思った（彼らは間違っていた：p）。
最近のほとんどのエディターがタブをスペースに自動的に変換できる時代には...かなり無意味です。
タブとスペースのような些細なことに対処するためにさらに別のツールをインストールする必要があることは確かに私には魅力的ではありません。
IDE（Microsoft！）がサポートしていれば、多くの用途が見つかると思います。人々がフラワーボックスを側面で平手打ちし、読みやすくすることができれば、そうするでしょう。ソースコードに突然コメントが追加される場合があります（これは良いことです）。
「ツールチップ」というコメントを「もしも…」のリストに追加して、大きなコメントブロックを非表示にして、必要に応じて簡単に表示することもできると思います。おそらく、ドキュメントの一部を形成するコメントブロックを含めることもできます（サンドキャッスルタイプのものではなく、メソッドヘッダーだけでなく、コードに埋め込まれた適切なユーザーが読み取り可能なドキュメントスニペット）
短所：実際に1つだけ変更されたときに行の束が変更されたように見える場合、ソースの差分が悪く見える可能性があります（エディターがタブをスペースに変換してファイルを保存した場合）。または、エラスティックタブが単一の文字（または、おそらく2つのタブストップ）で実装されている場合、エディターの外部でソースを表示すると見栄えが悪くなる可能性があります。
でも、私はこのアイデアが好きだと思います。行の最後にある「タブタブ」は、コメントブロックを伸縮させ、それに続くすべてのコメントを並べます（ダブルタブの間隔がある）。
ここに私はそれを見る：人気のあるツールのほとんどがすでに弾性タブストップをサポートしていれば、多くの人々がそれらを使用するでしょう。同じことがviのナビゲート/編集モード、構文の強調表示、そして後でIntellisenseでも起こりました。いずれの場合も、それは役に立たない、または必要とされないという確立された知恵でしたが、実装されて、それは始まりました。
もちろん、弾性タブストップの影響は比較的小さいです。ほとんどの人は現状に十分満足しているので気にしないでください。同様の推論は、一部の人々が得たものに満足していて、より高度なものに切り替える理由が見られない多くの状況に適用されます。つまり、弾性タブストップの最大の問題は、他のほとんどすべての優れたアイデアと同じです。
ただし、この機能を段階的に採用できないという意味ではありません。チーム全体が新しいコンパイラと新しいIDEを使用してそれを使い始める必要があるにもかかわらず、すべてのプログラミング言語は段階的に採用されました。同じことがすべての単一のハードウェアアーキテクチャと他の多くの例に当てはまります。既存のツールとの統合の欠如がショーストッパーである場合も同じではありません。たとえば、自動化ツール（これらのツールは、時間の経過とともにアップグレードされています。
私は他の人が述べた相互運用の問題に感謝しますが、それにもかかわらず、私たち全体として、これをためらうことなく採用するチーム（私のような）が必ず存在するでしょう。差分、マージなどの外部ツールは、最初はそれをサポートしませんが、ベンダーが機能を含めるよう奨励するために私たちの役割を果たします。これは常に進歩があった方法です。それは一時的な移行期間のためにいくつかの苦痛を必要としますが、結局、それは価値があります。
私がそれで抱える最大の問題は、ドキュメント全体の一貫性のない間隔です。プログラマーとして、ループまたはifステートメントが「標準」インデントで表示されてから、さまざまなインデントで気付くのを嫌がることを知っています。私が見ているコードのブロックだけでなく、ドキュメンテーション全体にすべての中括弧が並んでいるのを見るのが好きだと私は個人的に知っています。
全体的にはいいアイデアだと思いますが、個人的には嫌です。
Emacsは、閉じられていない括弧がある場合にインデントをすでに処理しており、自動的にwilmaをfredに揃えます。なぜEclipseが同じことをしないのか分かりません。わかりました、アイデアはありますが、それは無料ではありません。
Emacsにコメントを揃えても問題はありませんが、AFAIKは誰もそれを望んでいませんでした。
私は、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方言には、エラスティックタブストップが「醜い」コードをレンダリングする独自の規則があると言います。タブストップ設定を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のような言語でコーディングするときの機能。弾性タブストップは、個別のインデントユーティリティを必要とせずに役立つように特別に作成されましたが、明らかにそれは意図されていません。すべてのプログラミング言語。