berryzplus

カスタムメニューじゃない方法でメニューを足すとなると、 子を持つメニューのためのコードを2箇所追加せにゃならんのでやや大変です。 （「最近使ったファイル」とかと同じ実装にするってことだから。） タブ右クリックメニューは、 もともとカスタムメニューの枠組みで提供される機能なので、 このへんいじれば比較的簡単に内容を変えられます。 https://github.com/sakura-editor/sakura/blob/5c39c84cac4049979f4a67f27b554c860694beb1/sakura_core/env/CShareData.cpp#L1402-L1406 https://github.com/sakura-editor/sakura/blob/5c39c84cac4049979f4a67f27b554c860694beb1/sakura_core/env/CommonSetting.h#L444-L451 メンバ変数の使い方は、雰囲気で分かるはず・・・ :smile:

なんかみんな、この機能が大好きみたいですね :smiley: めちゃめちゃ複雑な機能なので不具合も多いんですが、 その割には果敢に新機能が追加されまくってきた歴史がある気がします。 （普通は不具合が出ると、その領域の進化が停滞するので。） > 考えるべきはどのようにして 0,0,0,0 のような値が書き込まれたかでしょうか。 これは単に初期値ですね。 sakura.iniを消してsakura.exe起動、何もせずそのまま終了、 で 0,0,0,0 が書き込まれるのを確認できました。 > 新しくアウトラインウィンドウが表示できないことから、 > 表示されているけど見えていない状態に陥っているような。 再現状態（＝アウトラインウインドウが見えてない）で `spy++` を使ったら アウトラインウインドウが「ない」のか「見えてないだけ」なのか分かるかも知れません。 ダイアログベースのウインドウなのでキャプションから推定するしかないのが痛いですが。

## 前振り 手順通りやって再現できたので見解報告します。 @ds14050 さんの想定が当たってそうです。 ## 調査結果 > 新しくアウトラインウィンドウが表示できないことから、 > 表示されているけど見えていない状態に陥っているような。 `Spy++` で確認したところ、幅0px のウインドウになっていました。 ## 問題の本質を探る考察 1つ目の操作群は、メインウインドウに.cppファイルをドロップしたときの挙動です。 2つ目の操作群は、sakura.exe のコマンドラインに.cppファイルを指定したときの挙動です。 両者の挙動に差異があり後者の挙動が「おかしい」のであれば、 それはコマンドラインからの起動に関するバグなのだと思います。 起動時のアウトラインウインドウの表示に関しては、何やら問題対策をした形跡が残っています。 https://github.com/sakura-editor/sakura/blob/b3278eb2cd41edf11c5e8c9ad2126d48677c9475/sakura_core/_main/CNormalProcess.cpp#L184 初期化処理関数の中に上記呼出しが複数入っているんですけど、正常ルート（＝.cppファイルをコマンドラインから開いたときに通ると思われるルート）にはこの呼出しがないんです。 どうすべきなのかは、ぶっちゃけ見えていませんが、 他のクラスのクラスメンバを操作するコードに違和感を持っています。 CEditWndが作成時に行うべき処理が漏れてるから、外側のコードが必要なんじゃないか？みたいな。

ちなみに。 > とにかく，ini が異常な状態であったということで，それを修正すれば私の環境では問題なくなりましたので，私としては本件はクローズさせていただきたいと思います． https://github.com/sakura-editor/sakura/issues/1177#issuecomment-580298260 の通り 0,0,0,0 はただの初期値なので、iniの異常で起きた不測の事態ではないと考えられます。 現状で対策案はないけど、引き続き調査＆対策しといたほうがよい案件だと思います。

この事象は分からんです。 `シングルクオート(=0x27)` がメールアドレスの account part に使える文字になっていることが原因のような気がします。 対策としては、メールアドレスの終端の次の文字がメールアドレスの先頭文字と一致する場合、先頭文字をメールアドレスに含めない、というようなコードを書くことになりそうです。 この周辺は検出ロジックが超低レベルであること、レイアウト・ロジック単位の取り違え問題が関連することなどから、修正とレビューの難易度が非常に高い気がします。 間違ってたらすまん！でどんどん進めちゃうのも一つの作戦かもしんないです・・・。

検証しようと思って画像よく見たら先頭のシングルクォートに下線が付いてますね。 過去版 [v2.3.2](https://github.com/sakura-editor/sakura/releases/tag/v2.3.2.0) でも試しましたが同じ現象でした。 つまり、GitHub移行後に壊したわけではない　。。。（　￣Д￣）ﾖｯｼｬ!! どうも2016年頃に「記号類が含まれるメールアドレス」を検出できるようにしたらしくって、その時の変更の影響っぽい気がします。責任逃れしてもしゃあないんですけど(笑)。 たまたま、いまGWですし、今年のGWは全世界的に `Let's enjoy stay home!` ですし、ボチボチ原因調査して対策打つのに絶好なタイミングだったりするのでちょっと対応してみたいと思います・・・。

> #792 の影響ですかね。 ぬふっ！ちょっと調べて思いついたことが #792 に全部書かれてた！ あんまし成長しとらんなぁ...orz 報告画像をよく見ると先頭のシングルクォートがURL強調の範囲に含まれています。問題内容は「URLとして検出される範囲がおかしい」だと考えられます。 `'[email protected]` の 2文字目 `a` から始まる部分を URL強調範囲 として認識させるのは難しそうなので、しばらく時間がかかりそうに思います。

_サクラエディタが扱えるデータは1行当たりのデータ量が1GBを越えない、総行数が65535行未満のファイルのみです。この制限は_ x64 ビルドでも同じです。Tab→空白変換を行うとタブ幅設定の数分だけ文字数が増えますが、適切なエラー処理が記述されていないため異常を検出できずにクラッシュします。` こんなん、他にもいっぱいあるんじゃなかろうか、と。 考えることは主に、 何故こんなことが起きるか？ どうしたらこれが直るか？ 修正案をマージするにはどうしたらよいか？ だと思います。 自分の見立てでは、レビューに参加している人であれば容易に「どうしたら直るか？」までたどり着ける実力を持ってそうです。障害になるのは３つ目で、無責任に「OK」を出せる人が圧倒的に少ないことです。 根治策はおそらく、制限を取っ払うのでなく制限を公開することだと思います。 無論、この問題の原因を「メモリバッファの変換にCNativeWを使っていることだ！」とすると事実上の制限を外せるんですけど、その場合にエラー処理を書かなくてよいかというと違うと思うので、どう対応するにしても「それなりにめんどくさい」です。

> 総行数は65535行以上も扱えると思います。 ここ、自分が書き間違っていますね:smiley: 65535行(uint16_tの最大)ではなく、int32_tの最大が正しいです。 Grepに関しては、int64_tの最大までの行数を扱えます。

### 関連チケット #789 カラーマーカー(SourceForgePRからのコンフリクト解消とマージ) #804 検索文字のハイライトをスクロールバーにもほしい