berryzplus

議題は、ファイルパス長が `MAX_PATH` を超えるファイルを扱えるようにするか？ 1. Windows 10 1607 には MAX_PATH 制限を外すオプションがある 1. サクラエディタ内の「パスを扱う文字列型」は `MAX_PATH` を超えるパス長を扱えない 1. Unicodeアプリは本来、最大 32,763字まで のパス長を扱うことができる 2.の「パスを扱う文字列型」は、共有メモリに突っ込むための固定長配列をstringっぽく使えるように拡張したテンプレート型なので、拡張すると共有メモリに影響が出ます。 どのように実装するかは置いておいて、 まずは MAX_PATH(260文字) を超えるパス長を扱いたいかどうかだと思います。

扱えると嬉しいなぁ・・・でも実装面倒だよなぁ・・・ というニュアンスの書込みは「MAX_PATHを超えるパス長を扱いたい」という意見にカウントしてOKですかね？ｗ 前提として「需要のあるなし」を把握しとかないといけないと思ってます。 「そんな長いパス、何かの間違いだよ」って意見が大勢をしめるかどうかです。 需要があるなら挑戦する意義はあると思いますので :smile:

ほとんどが未対応なんですねぇ・・・ん？ > サクラエディタ > > 強制終了しました。 強制終了しちゃうのは、扱えるように「する／しない」には関係なくマズくね？という印象です。 なんか前に「メッセージが出る」という話があったので、ダイアログが出て開けない感じになると思ってました。

ぷろーがー先生の名前が出てくるとわｗ > その後、 CLoadAgent::OnCheckLoad 内で CFile 型のローカル変数 cFile のコンストラクタ内で CFile::SetFilePath が呼ばれてその中で StaticString::Assign が呼ばれて wcscpy_s が呼び出す common_tcscpy_s の中で _VALIDATE_STRING マクロが呼ばれて最終的に __fastfail が呼ばれてﾀﾋんでます。 一応フォローしておくと、Microsoftの主張は、バッファオーバーランの危険性を意識しないと気付いたときに大変なことになってしまうよ、ということで、大変な事態の回避策として危険性を意識せざるをえないバージョンの新しいCRTを提案しているわけです。正確には「Releaseでも落ちる」ではなくて「Releaseでもinvalid_parameterエラーになる」で、global handlerを登録しておけば落ちることもないです。invalid_parameterエラーはMS独自仕様で普通の例外じゃありません。専用のハンドラを書かないとキャッチできない代物ですが回避策はあります・・・もちろん、それはMicrosoftが推奨しない回避策ではあるのですが。 サクラエディタで「パスを扱うための型（≒StaticString）」が用意されている理由は、「最近使ったファイル」などの共有メモリデータを扱うのに「決まったサイズの箱」が必要だったからだと想像しています。現在のwindowsには、アプリごとの「最近使ったファイル」を管理できる機能がありますが、昔のwindowsにはそんなものありませんでした。現状のサクラエディタにはwindows側の「最近使ったファイル」の機能も一部既に取り込まれています。win7以降でタスクバーやスタートメニューのサクラエディタを右クリックすると「最近使ったファイル」が出ますよね？あれはサクラエディタの機能じゃないんです。あれはwindows標準の「ファイルを開く」ダイアログを使うアプリに与えられる恩恵の１つです。まぁ、サクラエディタは標準ダイアログをカスタマイズして使ってますけど。 `MAX_PATH` を超えるパス長は、扱いたい、で良さそうですかね？ 次は、「じゃあどうやって？」の話題をしてく感じで進めたいと思ってます。

recentフォルダにショートカットをぶち込む機能は昔からあったかも、ということに気付く・・・。

## どうしましょ？ 検討課題「parse-buildlog.py の扱い」は「捨て」の一択で、議論の余地がない気がします。 他の課題も出て来ないようですし、検討は終わりにして「GHAに一本化する」を進めていいんじゃないでしょうか？ ## 「parse-buildlog.py の扱い」を「捨て」にする理由 * ビルド警告よりも詳細に問題点を報告してくれるツールを既に利用している * parse-buildlog.py の解析結果は活用されていない（≒なくてもプロジェクト活動に影響がない） * parse-buildlog.py はvs2019に対応していない（≒既に動いていない）

一本化は、「誰かが勝手にやる」で良いように思っています。 レビュアーの確保が難しいので、自分はレビュー側に回ります。 前提としてAZPのみで実施しているMinGWビルドをGHAで実施するようにactionsを実装する必要があります。 AppveyorとAzure Pipelinesのビルドを止めるのは、依頼があれば自分が実施できるはずです。（たぶん AppveyorとAzure Pipelinesのためのバッチは、消してしまったほうが分かりやすい気がしています。 消さなくてもよいですが、ルートフォルダのファイルが多過ぎる問題を緩和するために、少なくともルートフォルダから外したい気がします。

タスクリストを更新してみました。

> GHA 女子、というか主婦が好きなビタミンの類かと思いました。 GitHubActionsですね... このissueの出口政策が見えないっす。 - ドキュメント - 何のドキュメントでしょうか？ - Azure Pipelines や Appveyor ビルドで取得している各種環境変数 (#1183) には対応していない - 「先にそっちやろうぜ？」といいたい感じです。 - #922 には対応できないので、chm および installer のビルドは無効化している - 何故「無効化」している？ - 実行不可なのは英語環境での日本語chmのビルド「だけ」なはずでinstallerビルドは頑張ればできるような気がします。 -...

自分のなかで収まりがよい順番に並べ替えてみました。 ``` ---- Make githash.h ---- GIT_REMOTE_ORIGIN_URL : https://github.com/sakura-editor/sakura.git GIT_SHORT_HASH : eec7d9a0 GIT_COMMIT_HASH : eec7d9a00fe0f226dc245daa47a81a09b651e65e GITHUB_PR_URL : https://github.com/sakura-editor/sakura/pull/1183/commits GITHUB_PR_SHORT_HASH : 63f66831 GITHUB_PR_COMMIT_HASH : 63f6683199a96ddc41d3b34d3d82add248ddfc81 GIT_TAG_NAME : CI_BUILD_URL : https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.2614 APPVEYOR_URL...