Software VSCode

概要

最近、一番勢いのあるテキストエディタ。
へビューユーザーから、ライトユーザーまで幅広く使われてる印象。
自分も、長年愛用してた、Notepad++からメインエディタを変更。

設定

[Ctrl + Shft + P] から、 基本設定: 設定(JSON)を開く を選択。
最近は、HTMLっぽく見やすくなったが、逆に設定が面倒になったので、JSONへコピペした方が楽。

設定の同期

アドオンでは色々な同期ツールがあったが、v1.48.xから標準で搭載。
Settings Syncがインクルードされた感じと思われる。
設定のコメントにはsettingsSyncの単語が出てくるが、探すと無いので実際のところはわからない。

ツールバーの、歯車アイコンの上に追加され、Microsoftアカウントと、GitHubアカウントから選択。
アドオン版だとGitHubにレポジトリの用意が必要だったが、アカウントさえあれば同期出来る模様(さすが本家？)。

環境で異なる設定は除外したいが、マージ時にコントロール出来る感じはしなかった。今後のバージョンアップに期待。
ローカルパスを記述する設定だけ、ワークスペースに書くことで回避。なるべく基本的な設定だけにして同期するのが良いかと思う。

アドオン版の記事に書いてあった、// @syncも試したが、上手くいかなかった。
未だに健在なのをみると、まだアドオン版の方が高機能なのかもしれない(使ったこと無い)。

--user-data-dirを起動時に使用すると、好きな場所にユーザー設定を保存出来るのだが同期が出来なかった。
新規に作った場所でも駄目だったので、ユーザー設定の場所は固定らしい。ローカルネットワークで共通設定してた人は諦めるしかないかも？
とは言え、CドライブのRoamingに置きたくなかったので、自分はジャンクションを作成して逃した。
ジャンクションはネットワークに置けないのが残念。

--extensions-dirの方は使用したまま同期出来た。
複数台で使用してる場合はアドオンだけでもローカルネットワークに置くのもありかも。

リンク

【VSCode】公式版の設定同期機能 Settings Sync を早速使ってみた
https://serip39.hatenablog.com/entry/2020/08/18/173000

Font

色々試したが、 Source Han Code JP がオススメ。
散々悩んだが、 2:3 比率の、 Source Han Code JP に落ち着いた感じ。

日本が使える等幅フォントは少なく、大抵が 1:2 比率で、アルファベット間隔が狭く見辛い。
かといって、アルファベットだけ等幅のフォントを使うと、
コメントの日本語がプロポーショナルになって、凸凹して気持ち悪い。

標準では入ってないので、ダウンロードが必要。
インストール方法はこちらを参考にどうぞ。

Windows / Basic / windows-font
https://unitbus.github.io/pages/notes/windows/basic#windows-font

"editor.fontFamily": "'Source Han Code JP Regular', Consolas",

editor.fontFamily は、代用フォントを書く前提となってるので、
スペースある場合は、シングルクォーテーションで囲む。
他の太さにしたければ、 Regular の部分を、置き換えれば使用可。

以下のように間違って説明してるサイトが結構あるので注意。

// 間違い例
"editor.fontFamily": "Source Han Code JP Regular",

Markdown

改行の有効は、設定で変更できる。
cssも指定可能。相対パスは、ワークスペースの位置になる。

"markdown.styles": ["./document.css"],
"markdown.preview.breaks": true,

リンク

VS Code 標準Markdown Extensionsで、改行を有効にする
https://qiita.com/rma/items/75f502e784b7164b8813

検索の除外設定

ワークスペースに、複数のフォルダを登録してると、全体検索で大量結果が表示され困るのでフィルタを設定する。
基本は、表示設定 files.exclude が継承され、検索用にフィルタ search.exclude を追加出来る仕組み。

設定が反映されずに困ってたら、検索時にフィルタを有効にしないと意味が無いらしいので注意。

VSCode ファイル検索の除外設定
https://developer.feedforce.jp/entry/2017/11/24/195644

ワークスペース設定

言語固有の設定は、なるべくワークスペースに書くのがいいかと思います。

個人設定は同期されるが、ワークスペース設定は同期されない事から、
パスを使用した記述がある場合も、ワークスペース側に書くことをオススメします。

ワークスペースの仕様変更の話

vscode v1.17頃から、ワークスペースの仕様が変更があり、マルチワークスペースの概念が追加されました。

旧バージョンのvscodeでは、「ワークスペースにファオルダを追加」がなく、
「フォルダを開く」で開いたフォルダがワークスペースとなってました。

今は、新機能のマルチワークスペースの事を「ワークスペース」と呼ぶみたいです。
これに伴い、設定ファイルの概念もちょっと変わりました。

シングルワークスペースは今まで通り、.vscode/setting.jsonですが、同時にフォルダ設定として扱われます。
マルチワークスペースの場合は、中身はjsonですが、拡張子が.code-workspaceファイルになります。

ややこしいのが、マルチワークスペースを使用してる場合、${workspaceFolder}と変数を利用する場合に、
.code-workspaceの位置ではなく、登録してるそれぞれのフォルダ直下を指す事になります。
APIの指す「ワークスペース」と、GUI的な意味の「ワークスペース」に食い違いが起こってます…。

メリットもあって、シングルワークスペースの場合は、設定ファイルの場所が選べませんでしたが、
マルチワークスペースになって、自由に設定ファイルを置けるようになったので、共有する時に楽になりました。

ただ、注意点として、マルチワークスペースに追加したフォルダはfoldersオプションに記載されるのですが、
相対パスの表記は可能ですが、環境変数が使えない点です。

なのでまったく関係ない場所に.code-workspaceファイルを置くと、フォルダの指定は絶対パスで書くしか無く、
ユーザー名フォルダとか挟むと詰みます。これはvscode側で今後改善して頂きたい点です。

Python環境設定

// 環境変数のPYTHONPATHとは関係ありません、EXEまでの絶対パスを書きます
// たまにディレクトリ指定と書いてるサイトがあるが、アナライズでエラー出るので嘘
"python.pythonPath": "${env:APP_ROOT}/python/v2.7.15/python.exe"

// pythonエクステンション(v2021.12.1559732655)の更新でpythonPathが破棄されました
"python.defaultInterpreterPath": "${env:APP_ROOT}/python/v2.7.15/python.exe"

dotenvの指定

パッケージ毎に、環境変数を切り替えるには、.envファイルを使用し、設定にオプションを足します。
個人設定ではなく、ワークスペース設定に書くことをオススメします。

// 環境変数をワークスペースに置いてるファイルから設定
"python.envFile": "${workspaceFolder}/.env"

マルチワークスペースを使用してる場合、上記のように記述すると登録してるフォルダ直下の.envが適用されます。

dotenvの書き方

# .envの例、シャープでコメントとして認識
PY_PACKAGE_ROOT = C:/debug/python/packages
PYTHONPATH = ${PYTHONPATH};${PY_PACKAGE_ROOT}/packageA/v1.0.0
PYTHONPATH = ${PYTHONPATH};${PY_PACKAGE_ROOT}/packageB/v0.0.1
PYTHONPATH = ${PYTHONPATH};${PY_PACKAGE_ROOT}/site-packages

.envはフワッとした情報しか無く、一番理解に役立ったのは、結局DotENVというvscodeのエクステンションでした。
.envでは改行がコマンドの終了を意味するので、値に改行を含める場合はエスケープが必要です。

バッチコマンドのsetと違い、スペースは無視されます。
スペースを使いたい場合は、シングル、またはダブルクォーテーションで囲ってください。
値にダブルクォーテーションを含めたい場合はエスケープが必要です。

環境変数を使いたい場合は、${変数名}で取得します。
上から潤に一行ずつ定義されるので、.env内で定義した変数も使えます。
PYTHONPATHなど、複数行書きたい時に約にたつと思います。

.envファイルを作るメリットは、ワークスペースを切り替えた時に、環境変数を切り替える事が出来る点です。
vscode起動用バッチファイルを作成し環境変数を定義した場合は、vscodeを起動したまま切り替えができません。
バッチファイルでやるには、関係ないすべての環境変数を用意しないといけなく、現実的ではありません。

また、デバッグ用のランチャー設定でも同じ様に.envファイルが指定出来るので、手間も軽減します。
debug.envみたいに、拡張子の前にファイル名を付けても構いません。

ただ、各パッケージそれぞれで違う名前になってると、vscodeので設定ファイルでの記述が複雑になるので、
デフォルトで読む.envファイルの名前は統一しておいた方が良いかと思います。

大事なのは、${workspaceFolder}から下で、共通した場所に、.envファイルを置くことです。

pythonのデバッグが出来ない場合

急に、F5を押しても、別コンソールが出てしまい、デバッグが始まらない事があった。
launch.jsonの、 "console": "none", にしたら直った。

noneだと赤く表示されるが、使えるらしい。
この辺、バージョンで大きく変わるので過去の例です。

    "configurations": [
        {
            "cwd": "${workspaceFolder}",
            "name": "Python2",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "none",
            "envFile": "${workspaceFolder}/.env",
            "pythonPath": "${config:python.pythonPath}",
            "stopOnEntry": true,
            "debugOptions": [
                "RedirectOutput",
                ]
        },
    ]

リンク

Visual Studio Codeの設定「虎の巻」：Python編 (2/3)

追記

コマンドプロンプトのオプションで、レガシーコンソールを使用するのチェックを外したら元に戻った。
結局、何が悪いのかよくわからないので、調査中。
多分、windowsUpdateのタイミングで色々おかしくなった？

Tips

折り畳み

折り畳みルールにないケースでも、regionで囲むと畳んで表示できる。
インデントも関係なく使えるので、たまに便利。コード行が増えるのが難点。

# region
<実際のコード>
# endregion