berryzplus
berryzplus
この提案を前に進めたくなってきました。 ## 支持する理由 1. appveyor上で、7zip は [cinst 7zip](https://chocolatey.org/packages/7zip.install) されています。 2. azure pipelines上で、7zip は cinst 7zip されています。 3. 開発者がローカルで cinst 7zip するのが「大変か？」というと[そうでもありません](https://chocolatey.org/docs/installation#installing-chocolatey)。
SonarQubeはサーバアプリの名前 SonarCloudはクラウドサービスの名前 いずれもSonarScannerというクライアントアプリが解析したデータを受信して結果表示を行うものです。 だから、同じだと思っていても間違いではないです。 まぁ、別モノなんですけど（笑
対応しない理由は、ないと思っています。 「どうやって」の部分ですぐに答えが出ないので、しばらく放置になると思っています。 VS CodeやAtomが対応しているという構文解析機構との組み合わせがキーになってくるのかな、と。
> 正規表現キーワードというのがあったと思うので、それを使えばできると思います あれ？じゃやれば？と思ってしまいました・・・ なんで止まってるんでしたっけ？ `m/^\s*#\s*\w+/` ってことですよね、要するに。
個人的には、要らないと思います。 サクラエディタには「標準にない検索機能」が実装されているので検索ダイアログがカスタム実装されていますが、検索ダイアログはもともとWindows標準に存在しています。個人的には現状のフルカスタマイズを、標準との機能差分のみを実装するシンプルな形に整理していく方向にしたいです。 このPRは「フルカスタマイズの機能を増やそうぜ！」なので逆方向ですね。 ---- 横方向にリサイズ可能とする リサイズなので、日本語でいう「伸縮」を考えておかないといかんです。 * 「伸ばす」に関してはこの対応で良いと思います。 * 「縮める」に関しては考慮が入ってないと思います。 最小幅を決め打ってやればよいと思いますが、現状は「考慮なし」に見えます。 ---- 見切れ対策の方法論 方法論は大きく分けて2つあります。 * 表示幅を拡げる 「幅が足りない」に対して「拡げる」のは妥当な作戦です。 * 折り返し表示する 必要かどうかは別にして、Webではよく採られる作戦です。 windows標準の検索ダイアログはどちらにも対応していません。 vscodeの検索ペインは両対応です。 「対応しない」と「両対応する」の二択で考えるのがいいんじゃないかと思います。 ※当面「必要なし」がぼくの見解ですが。
> 処理内容を読み取りにくいと思いますが、自分なりに考慮はしているつもりです。`WM_SIZING` のハンドラの `OnSizing` メソッドでデフォルトサイズ（`WM_INITDIALOG` メッセージのハンドラの `OnInitDialog` で取得しているウィンドウのサイズ）より小さくならないように対処を加えています。 これは見落としでした。スミマセン。 > 検索ダイアログはもともとWindows標準に存在しているというのは認識していませんでしたが `FindText` や `ReplaceText` WindowsAPI の事ですかね？ そうです。CのAPI関数は既にdeprecatedですが、比較的最近（vistaが出たときくらい）に新しいCOMインターフェースが提供されて置き換わったと思っています。 > なお検索と置換に関してはVisual StudioもVSCodeもダイアログを表示するのではなくてエディタ領域の右上に小さいUI領域が出ます。VSCodeではこれの事を `Find Widget` というようです。 あれ？visual studio はダイアログが出るような・・・（Ctrl + Shift + F...
小話 > Windows 2000 : クラシックスタイル > Windows XP : Visual Style > Windows Vista, Windows 7 : Windows Aero > Windows 8 : フラットデザイン > Android : 2014年にGoogleがMaterial Designを提唱...
前提知識 ⇒ [UDフォント](https://www.morisawa.co.jp/fonts/udfont/) UD=Universal Design。文字を判別しやすくデザインしました、ってことらしいです。 v2.3.0 からおかしくなったってことはプロポーショナルフォント対応が原因ですね。 [プロポーショナルフォント対応](https://github.com/sakura-editor/sakura/commit/66f5d68d3f6a4bbf65b6f02fea35e560298e9a07) プロポーショナルフォント対応ってなんかおかしくね？という話題は過去 #326 で議論していました。一応、次期リリース候補に入ってるんですが、原因対処はできず終いだった認識です。 > 残念です。 といわれても仕方ない感じなので、次リリース(v2.4.1の次)にはなんとか含めたいと思います。 以下、ぼんやりと考えている対応案・・・。 問題の本質はたぶん、以下を混同していることだと思います。 - プロポーショナルフォントを使えるようにする。 - エディタビューをプロポーショナルフォントを表示できるように拡張する。 サクラエディタって、ちょっと昔のコンソール（＝CUIクライアント）と同じで等幅フォントだけを使うように設計されているんです。だから、フォント選択ダイアログでは等幅ではないフォントを選択できないようにしていました。この制約を外すのが「プロポーショナルフォントを使えるようにする。」だと思います。ただ制約を外して「文字表示は等幅フォントを使って行う」の仕様に手を入れないと、水平方向の文字間隔がやたらと広い「微妙な表示」になってしまいます。これに対処するのが「エディタビューをプロポーショナルフォントを表示できるように拡張する。」という対処になります。後の世から見て「結果として対応がマズかったのかもね。」というのが現状です。どうしたらいいかは、ぼくらがこれから考えないといかんです。
> 「sakura(デバッグ版)」になるのは、`_GSTR_APPNAME_`ですね。 > `_APP_NAME(_T)` は `_T("sakura")` で固定でデバッグ版でも同じです。 あ、そうですね（汗
通知機能を追加するのに windows 10 の通知の話が出ないカオスとか...orz サクラエディタは基本的にレガシーアプリなので、通知アイコン(タスクトレイのあれ)で実装するのもアリかも知れないと思いました。