Q&A
多分、大問題になると思っているのはあなただけではないでしょうか。
Visual Studio Codeで改行コードを表示したいです。
目的は、ファイル内の改行の混入を検知したいためです。
ですので行ごとの改行を表示し分けられる必要があります。
今までサクラエディタを使っていて、当たり前にできていた機能なので、Visual Studio Codeでも当然できるだろうと思って試しているのですが難航しています。
以下の拡張機能を試したのですが全滅でした。
- line-endings - Visual Studio Marketplace
- code-eol - Visual Studio Marketplace
- code-eol 2019 (Line Endings) - Visual Studio Marketplace
CR, LF, CRLFの3種の改行コードが混在しているファイルを作って試したのですが、混在しているのに全行同じ改行コードを表示してしまい、正しい改行コードを表示することができませんでした。うその改行コードを表示するくらいなら表示しない方がマシです。
一部の改行文字だけでファイル内の改行文字がすべて同じと判断して表示しているのかなと思っています。
Visual Studio Codeで改行コードを表示し分けることはできますか？
できるのならその方法を教えてください。
「できない」という情報でも、あきらめをつけられるのでありがたいです。
Win10, Visual Studio Codeのバージョンは1.43.2です。
よろしくお願いします。
追記
本質問は、改行コードの表示の話です。編集した後の保存時に自動的に統一されるとかなどは、今回は関係のない話です。改行コードの混在の検知の方法の相談でもありません。そもそも少し大きめのプロジェクトなので、ツールを導入したり運用を変更したりなどは、簡単にはできない状況です。
例えばレビューをするときに、指定の改行になっていなかったり、改行が混在していた時などに、指摘をしてあげなければなりません。そういう場合、サクラエディタであれば簡単に確認ができるのですが、Visual Studio Codeではやり方がわからなくて困っていました。
私の環境では、一人でコードを書いているわけではなく多数のエンジニアがいて、それぞれエディタも自由に選んでいるので、混在は発生することを前提にものを考えなければなりません。
編集はどんなエディタで行われるかわかりません。そのファイルの改行コードをチェックする際に、サクラエディタでは容易にチェックできていました。それがVisual Studio Codeではできるのかできないのか、この点が質問です。
ちなみに問題があった場合には当然、そのままの状態で突き返してあげなければなりません。レビューだけなのに、勝手に改行を変更されたら大問題です。
レビュー依頼されたファイルをレビュー者が勝手に書き換えてはいけないということは、常識だと考えられるようになった方がいいと思いますよ。
レビュー者が書き換えると誰か言いましたっけ？
「問題があった場合には当然、そのままの状態で突き返してあげなければなりません。レビューだけなのに、勝手に改行を変更されたら大問題です」というのは、レビューNGでレビュー依頼者に突き返すときに、ファイル内容を変えてしまったらダメだよという意味です。伝わりにくかったですかね。
それを前提にしたら、「大問題になると思っている」のは私だけではなく、Zuishinさんも一緒ということでいいですか？それなら特に認識の相違はなさそうですね。
ちょっと話にならないなこの人。
え、どういうことでしょう？
あなたは、レビューNGでレビュー依頼者に突き返すときに、ファイル内容を変えても問題ではないと思ってるということですか？それは…まずいですよ。
普通のプロジェクトでは、レビュー依頼されたファイルを勝手に変えてはいけないんですよ。それは常識だと考えるようになった方がいいですよ。本当に。
同じチームの人に同情します。
私はちゃんとした人とは会話ができるのですが、あなたとは難しそうということがわかりました。
そうですか。それは何より。チームの人を気遣ってあげてください。いつも大変だと思います。
回答3件
0
ベストアンサー
こんにちは。
結論から述べると、現状の VS Code では不可能です。
何故なら、VS Code はファイルを開いた時点で EOL を自動的に正規化するからです。
VS Code で編集している限り、改行コードが混在している状態になること自体がありえないのです。
投稿2020/03/25 01:42
総合スコア4252
> VS Code はファイルを開いた時点で EOL を自動的に正規化する
これはどういう意味ですか？
まったく編集しなくても、ファイルを開いただけで、改行コードが統一された状態で保存しなおされるということですか？
それとも、ファイルの内容を変更するということはないが、ファイルのデータの改行コードを内部的に統一してしまっているという意味ですか？
「ファイルの内容を変更するということはないが、ファイルのデータの改行コードを内部的に統一してしまっている」の方です。VSC内部で管理するデータが「ファイル単位の改行コード」しかない、という話です。
恐らくそうですよね。んーその点はVS Code はポンコツ君なんですね…。
「改行コードが混在している状態になること自体がありえない」とあったので、「開いただけでファイル内容を変えてしまうの？」と思ったのですがさすがにそんなことはないですよね。
ありがとうございました。
VS Code では、開いた時点で表示されるデータはオリジナルのファイルと異なっている場合があるということです。
例えば、MIXED なファイルを開いて即座に保存するだけでもファイルの内容に変更が加わります。
まあそもそも MIXED な状態が異常だと考えたほうが良さそうなんですが、意図的に MIXED なファイルを VS Code で扱うことはできないということですね。
tamotoさん
「改行コードが混在している状態になること自体がありえない」というのがどうしても意味が分からないのですが…、これは単純に間違いということですよね。ありえないわけないですもんね。
とにかく質問の回答としては、「VS Code では機能的な問題で、改行コードを正しく表示し分けることはできない」ということですよね。ありがとうございました
えっと、そちらは、VS Code でファイルを編集している限り、という但し書き付きの話です。VS Code を使うと改行コードを混在させることがそもそもできないので、混在するようなファイルを作成することができない、という意味です。
回答の意図については理解の通りです。
ああ、なるほど。「VS Code でファイルを編集する人しかいない環境ならば」ということだったのですね。わかりました。ありがとうございました。
私の環境では、一人でコードを書いているわけではなく多数のエンジニアがいて、それぞれエディタも自由に選んでいるので、混在は発生することを前提にものを考えなければなりません。質問をするときにはそういうことも丁寧に伝えた方がいいのでしょうかね…。
VSCode使ってないので手元にないので確認出来ず申し訳ないですが、
CR+LFなソースコードでのヒアドキュメント内でもLFを混在できないのでしょうか？
Y.H.さん
確かにそれは面白い観点ですね。むしろ混在を許可してくれないといけないケースもありましたね。さすがですね。
…で試したのですが、勝手に統一しますね…。そしてこの質問の回答などから推測するに、勝手な改行の統一を防ぐ方法はないんじゃないかと思います。
そういうファイルを編集する際には、「VS Code は絶対に使ってはいけない危険なエディタ」ということになりそうですね。
使い始めなので間違っているかもしれませんが。もしVS Codeの編集時の改行コード自動統一を防ぐ方法をご存じの方がいらっしゃいましたら、よかったら教えてください。
Y.H. さん
ファイル単位で eol の自動判別がかかり、強制的にそれに統一された状態になる動きでした。
ヒアドキュメント自体を動作確認したわけではないですが、これを特別扱いできるような設計には見えません。
miu_ras さん
どうも VS Code はファイルを「読み込む」時点で改行コードを統一してしまうので、自動統一を防ぐ方法は無いと思います。
保存さえしなければオリジナルを変更してしまうことはないですが。
miuさん> 勝手に統一しますね…
tamotoさん> これを特別扱いできるような設計には見えません
やはりというかまぁVSCodeとしては単なるテキストファイルなのでヒアドキュメント内とか外とか各言語の構文は判断できませんよね。
Y.H.さん、tamotoさん
まぁ…そうですね…。コード中の判別はできなくとも、例えば拡張子を指定して、改行自動統一の機能をON/OFFする機能とかくらいはつけてくれてもいいような気はしますけどね…。本格的に使い始める前にVS Codeの闇を見つけた気がします。ありがとうございました。
まぁ皆さんの回答にある通り、質問の回答としては
現状のVisualStudioCodeでは不可能ということですね。
横から失礼します。
tamotoさんの回答でもう結論は出ているので、BAを付けては？
te2ji さんへのコメントの通り、何を言われたかわかってないので付けられないんだと思います。
う～ん、te2jiさんの回答に対する話しが理解できていないことが理解できていないというのは
置いておくとして、miu_rasさんが確認したかったVisual Studio Codeで改行コードを
表示し分けることが出来るか否かについては、tamotoさんの回答で【出来ない】ということを
理解されていると思うのですが。
レビューの為に改行コードを表示し分ける必要が是が非でもあるのであれば、
サクラエディタをレビュー時のみ使用すれば事足りるでしょう。
kainaさん
>サクラエディタをレビュー時のみ使用すれば事足りるでしょう。
便利だったら使ってみようと思っていた程度で、何がなんでもVisual Studio Codeを使わなければならないというわけではありません。なので、私が最低限必要としている基本的な機能が実装できていないということが分かったので、Visual Studio Codeを今後使うことはないかなと思っています。
0
構文チェックツールで検出するのが一般的だと思います。
追記/提案
VScode の現在の仕様上、改行コードの混在が必須なコードは取り扱いできません。
混在が必須でない場合、コーディング規約の話になるので、エディタで最終管理するのはあまり適切ではないです。チーム開発であれば、コミット前になんらかの lint ツールで規約に準拠しているか確認するのが適切と考えます。
投稿2020/03/25 01:23
編集2020/03/25 03:30
退会済みユーザー
総合スコア0
なるほど。ただ質問はVisual Studio Codeで行ごとの改行コードを表示できるのかです。質問自体にもお答えいただけるとありがたいです。
できないはずです。
tamoto さんの回答のリンク先を確認してください。
余談)
私としては、自動統一されるのは構わないと思ってましたが、リンク先見ると結構問題があるみたいですね。。。
もし混在させなければならないのであれば、VScode では対応できないようです。
一応念のため。表示の話ですよ。おそらくmaisumakunさんのコメントが正しくて、ファイルを開いただけでファイルの内容が勝手に変更されることはないはずだと思います。
「自動統一されるのは構わない」っていうのは、改行コードが混在していても、実際の改行コードと異なるものが表示されても構わないってことですか？それはあり得ないと思うのですが…
ファイルを開いただけで(メモリ内の)ファイルの内容が勝手に変更されます。保存しなければファイル自体は変わりませんが、自動保存していた場合はその限りではありません。
> 実際の改行コードと異なるものが表示されても構わないってことですか？
はい。私自身の環境において、特に問題になりません。
プロジェクトで統一した改行コードを使用して、もし混在時に VScode 上で意図しない改行コードを採用してしまった場合に、構文解析で警告が発生してくれればよいです。
＊混在が確認された場合、プロジェクト操作前に統一のため置換してしまうと思います。
ただ、余談に書いたとおり、統一されてはまずいケースが有るのは想定していませんでした。結構なケースが上がってますね＾＾；
構文解析ツールってなんか誤解を招きそうな言葉ですね＾＾；
lint系ツールを指してます。
追記に書きましたが、レビューの時などで混在がないか確認したいのです。開発者のエディタは自由だし、開発者のレベルもまちまちなので、混在することもありえ、もし混在していた場合には、指摘してあげないといけません。間違っても勝手に修正などしてはいけません。
te2jiさんとしては、「目視でチェックするのはやめて、これからは構文チェックツールをつかえ」ってことで、確かにそうなのかもしれませんが、一応この質問としては「VS Codeでできるの・できないの」という点のみを質問とさせてください。
git 等を使用しているのであれば、そちらで対応すべき案件かと。
まぁ、レビューってのは一例だよってことだと思いますけど。
GitHubを使ってレビューをすることも確かにあります。SVNにコミットされたファイルの場合もあります。本番作業用のシェルやSQLの場合なんかは、GitやSVNにコミットせずサーバーにファイルを置いてそれをみたりします。ファイルの渡され方はいろいろです。
ツールを使える場合もあると思いますけど、この世のあらゆる作業がそれで済むわけではないと思います。あくまでも本質問としては、Visual Studio Codeの表示に関することに限定していることをご理解お願いします。
レビューでなくフックの話でしょ。改行コードは勝手に書き換えていい。フックとは言わないか。git には自動的に改行コードを書き換える機能があります。
で、表示の問題ではなく読み込まれた時点ですでに元の改行コードは破棄されているんだって話はいつになったら通じるんでしょうか？
> miu_ras さん
> Visual Studio Codeの表示に関することに限定していることをご理解お願いします。
コメントもした上で、回答に追記していますが、現在の仕様上混在は許容されていません。
> Zuishin さん
> 改行コードは勝手に書き換えていい。
私もそう思ってたんだけど、ダメな例もあるみたいですよ。
まぁ、私のプロジェクトではなさそうですけどｗ
書き換えてはダメなファイルだけバイナリとして扱いますよね。ここで問題になっている、改行を統一すべきファイルは勝手に書き換えていいはずです。
あーそれだけバイナリ扱いするのか。。。もし出会ったら参考にします！
> 現在の仕様上混在は許容されていません
…。追記を書きましたので読んでください。
改行コードが混在するファイルは現実に存在するのです。それをVScode で開いて改行を表示し分けることができるのかできないのかという点が質問です。
レビュー依頼されたファイルをレビュー者が勝手に書き換えていいということは、少なくとも私の職場ではありえません。それが、勝手に書き換える職場があってもいいと思うのですが、とにかくそういう職場のルールは本質問と関係ありません。
いやね、普通はレビュー者が書き換えるんじゃなくコミット時に環境の違いが自動的に吸収されるんですよ。
で、質問の答えはもうとっくに出てますよね。これは余談です。
Gitにコミットすることだけがこの世のすべてではないのです。
すでに書いていることですがもう一度書いておきます。「GitHubを使ってレビューをすることも確かにあります。SVNにコミットされたファイルの場合もあります。本番作業用のシェルやSQLの場合なんかは、GitやSVNにコミットせずサーバーにファイルを置いてそれをみたりします。ファイルの渡され方はいろいろです。」
git でなくとも一つツールを入れれば済む話なので。
差し戻したりしなくて済みますし、無駄な仕事で給料泥棒しなくて済みます。
> 改行コードが混在するファイルは現実に存在するのです。それをVScode で開いて改行を表示し分けることができるのかできないのかという点が質問です。
回答/コメント、読んでます？VScode の仕様上できないって何度か書いてるんですけど。。。
以下は余談です。
> レビュー依頼されたファイルをレビュー者が勝手に書き換えていいということは、少なくとも私の職場ではありえません。
混在が「問題なのであれば」、レビューにかける前に、ルールを強制する仕組みを入れるといいですよ。ってことなんですけど、伝わっていますか？
> ファイルの渡され方はいろいろです。
この辺が問題なので整理してみては？って提案なんです。
そうですね…。20-30人くらいの小規模なプロジェクトだったら私の一存でどうとでもなるのですが、150人くらいの大きめのチームでかつ私には運用を変える権限もないので、私に言われてもと思ってしまいますが…。将来の参考にさせていただきます。ありがとうございます。
「そうですね」というのは、ようやく回答が理解できたということでしょうか？
このコメントだと、「余談」に対してコメントしているように思えます。
何度も簡潔に書いた回答が理解されなかったので、非常に不安なのですけど？
>VScode の仕様上できないって何度か書いてるんですけど。。。
「現在の仕様上、改行コードの混在が必須なコードは取り扱いできません」とか「仕様上混在は許容されていません」とあったので、表示できるできない以前にエディタとしてそういうファイルは取り扱いできない・許容していない＝開けないというような意味なのかと思って、何言ってんだろうと思ってしまったのです。が、「取り扱いできない・許容していない」という言葉を「ファイルは開けるけど、表示はできない」という意味で使っていたということなのですね。
ようやくわかりました。理解不足ですみませんでした。
ありがとうございました
まだわかってないという。
> 「取り扱いできない・許容していない」という言葉を「ファイルは開けるけど、表示はできない」という意味で使っていた
違います＾＾；
もう一度、皆の回答とコメントを読んでみてください。
VScode の仕様として混在を許容していないので、ファイルを読み込んだ時点でエディタ上の改行コードを正規化してしまいます。
つまり、混在したファイルは混在したままで取り扱えません。
あと、質問の方向転換がひどすぎますよ。。。質問内でも矛盾が始まっています。
>質問の方向転換がひどすぎますよ
私の質問は最初から改行コードの表示についてのみです。一切方向転換していません。
「取り扱いできるかできないか」とか「許容されているか否か」などと質問していた時間帯はないはずです。
>違います＾＾；
だとするならば、あなたは改行コードの表示ができるかできないかという質問とは外れた書き込みを続けているということです。
> 私の質問は最初から改行コードの表示についてのみです。
正規化された後の改行コードは、エディタの右下に表示されています。って回答になりますが、意味ありますか？
私達は
「改行の混入を検知したい」
のだと思って回答しているのですけれど。
なので矛盾が始まっていると指摘をしています。
> あなたは改行コードの表示ができるかできないかという質問とは外れた書き込みを続けているということです。
改行コードの表示は「できます」が、それはmiu_rasさんの求めている「各行ごとに異なる改行」にはならない、ということを、言い方を変えて説明しているだけかと思います。
>「改行の混入を検知したい」
大きく間違ってはいません。正確に言えば、ただ単に混入があるかないかだけ知れればいいのではなく、行ごとの改行コードを視認したいのです。
サクラエディタなら、1行ごとに改行コードが異なっても、どの行がどの改行コードなのかがはっきりと視認できるんです。その他、秀丸・Eclipseなど私が使ってきたエディタではみな当たり前にできる機能だったので、VScodeでも当然できるだろうと思っていました。
そして調べて拡張機能に各行に改行コードを表示する機能があると分かって入れてみたのです。すると行ごとに改行コードが表示されたので、これでよさそうと一瞬思ったのですが、改行コードが混在したファイルでテストしたら、すべての行に一律同じ改行コードが表示されました。拡張機能は個人作成なのでバグなのかなと思って、正しく表示できる拡張機能やその他何か方法がないかなど知りたくて質問しました。
>正規化された後の改行コードは、エディタの右下に表示されています。って回答になりますが、意味ありますか？
CR, LF, CRLFの3種が混在していた場合に、どれが表示されるのかわからないし、混在していることすらわかりません。それではまったく意味はありません。
>なので矛盾が始まっていると指摘をしています。
あなたにとって何が矛盾だと感じているのかよくわかりません。
私が「行ごとの改行」と書いたり、「改行コードの表示」と書いたりしているのが、質問している内容が変わっているととらえられたということですか。
確かに書き方は変わってますね。私は同じことのつもりでただ手を抜いて書いてしまったのですが、それが誤解を生んだということですね。
なるほど。それは私の書き方の丁寧さが足りていませんでしたね。
すみませんでした。
質問を丁寧に書き直したらどうですか？
あなたは「ちゃんとした人とは話ができる」となぜか思い込んでいるようですが、現実にはちゃんとした人にも伝わっていないようなので。
VScode で開くと改行コードが正規化されてしまうことを「関係ないこと」と判断して、質問を続けようとしていることが矛盾です。
もう一度だけ書くと
VScode の仕様として改行コードの混在を許容していないので、VScode ではファイルを読み込んだ時点でエディタ上の改行コードを正規化してしまいます。つまり、混在したファイルは混在したままで取り扱えません。
tamoto さんの回答のリンク先も含めて再度読み直してみてください。
alexdimaさんの25 Nov 2015のコメントですかね。もしそこなら「今はそういう動きになっている」「混在をサポートする前になぜ必要なのか教えてくれ」みたいなことを書いているので、何か考えがあって許容しない仕様にしたというよりも、混在を許容すべきケースがあることを知らなかったから今そうなってしまっているという内容に見えます。それ以外は「こういう場合に必要だ、修正してくれ」という苦情の嵐に見えました。とにかく「混在を許容しない」「取り扱いできない」と書いてある部分をどうしても見つけられませんでした…。
しかし私がどう解釈したかは別として、te2jiさんはこの部分を、「仕様だ」「混在を許容しない」「取り扱いできない」と書いてあると解釈したということですかね(その部分ではなく別の場所で、それが仕様だとか混在を許容していないと書いてあるという場合には場所を明示してください)。
そして、「混在を許容しない」「取り扱いできない」の部分を前提として、「混在を許容しない」「取り扱いできない」のだから表示できないのはいうまでもなく当たり前だろというような趣旨の回答だったということですね。
表示できるできないの質問なのに、なぜ「混在を許容しない」「取り扱いできない」という部分を繰り返すのかよくわからなかったのですが、ようやくわかりました。私が行間を読む力が足りていませんでした。お手数をおかけしてすみませんでした。
混在を許容しないのに表示できると思っていたというのが結構衝撃的です。
私には「The current file model normalizes the line endings as soon as the file is read 」と「混在を許容しない」「取り扱いできない」が結びつかないということのほうが衝撃でした。
根拠はその1文であってるということですね。
私はその文は「現在のモデルはファイルが読み込まれるとすぐに行末を正規化します」と単純に動作の説明をしているのだと、もっと言えば「混在ファイルだったらそういう風に扱います」と書いてあると解釈しました。
それに対しあなたは「混在を許容しない」「取り扱いできない」と否定的な内容が書いてあると解釈したということですね。
そこに大きな認識の相違があったと。よくわかりました。ありがとうございました
> 「混在ファイルだったらそういう風に扱います」と書いてあると解釈しました。
「正規化してしまう」＝「元の改行が何だったかは保持しない」＝「（Visual Studio Code内部では）混在を許容しない」ということです。
言語能力が驚くほど人と違いますね。正規化するのに混在が許されるってどういう状態なんだろう。正規化の意味がわからないだけなんだろうか。
maisumakunさん
もう大丈夫です。
「混在ファイルは取り扱いできない」と言われたので、そもそもファイルを開けないといっているのかなと思ってしまいました。
たとえて言えば、「少し古いはがきを使うには10円切手を足せば使えます」と「このはがきは取り扱いできません」の言い方の違いに、私には感じてしまったということです。
この場合、足しても使えないので、まだ全然大丈夫じゃないと思います。ちっともわかっているように見えません。
0
それぞれエディタも自由に選んでいるので、混在は発生することを前提にものを考えなければなりません。
.editorconfigなど、エディタを越えて書式管理するツールも整ってきています。
投稿2020/03/25 04:11
総合スコア146018
混在させる必要がある状況でないにもかかわらず、偶発的な「混在は発生することを前提」にするのであれば、なおのこと「管理側で自動統一する」というソリューションのほうが、誰の手も煩わせずに済むので合理的かと思います。
そうですね…。20-30人くらいの小規模なプロジェクトだったら私の一存でどうとでもなるのですが、150人くらいの大きめのチームでかつ私には運用を変える権限もないので、私に言われてもと思ってしまいますが…。将来の参考にさせていただきます。ありがとうございます。
あなたの回答
tips
プレビュー
