berryzplus
berryzplus
> パッチを適用したビルドを数年使用してきて便利なので投稿してみただけですので > あまり詳しいことはわかりませんが少し書き直してみました。 ようやく分かってきました。そういうこと（c++開発者ではない）っすね。 プログラムは本来、英語が読めればなんとなく読み解けるものですよね。 c/c++に詳しい人ばかり相手にしていてそのことを忘れていました。 それなら、誰かが引き継いで機能取込までもっていく方向ではどうでしょうか？ 現状が既に実績のあるマージコードであってもベースが色々変わってるので、追加の修正やら確認がいると思っています。
履歴の性質が異なるので、単純に「お気に入り」を有効にする対応ではマズそうに思います。 |項目|追加タイミング|削除タイミング| |--|--|--| |ファイル履歴|ファイルを開いたとき(開いた後に登録しようとする)|件数超過で古いものから削除、お気に入りダイアログで削除（一度お気に入り登録したものはお気に入りダイアログ以外で削除できなくなる）| |検索履歴|検索するとき(検索する前に登録し、登録した検索条件で検索する)|件数超過で古いものから削除、お気に入りダイアログで削除、検索コンボで削除| ファイル履歴は、新しく追加できなくなっても困らないです。新しい履歴が登録できないだけなので。 検索履歴は、新しく追加できなくなると困ります。新しい検索条件で検索できなくなるからです。 人によっては困らないかも知れませんが、普通は困るような気がします。 取込しようとしているパッチでこのあたりの仕様を考慮できているようには見えないので、 仕様変更提案は「一旦却下」が妥当かと思います。
> 取込しようとしているパッチでこのあたりの仕様を考慮できているようには見えないので、 > 仕様変更提案は「一旦却下」が妥当かと思います。 これ、要するに保持可能な履歴の全件をお気に入りにできたらマズい、というだけの話なので、 全件をお気に入りにすることが不可能なように対策入れたらよい気がしています。 対策を入れるべき箇所 - 設定読み込み処理（＝CShareData_IOの該当関数） 不正な設定値を無視するコードを入れる - UI（＝お気に入りダイアログ） 不正な設定値を保存できないようにする 対応が難しい、ないし、「めんどくさい」であれば、やはり「お蔵入り」で確定が妥当です。 何が妥当？、何が適切？の論議はおいておいて、とりあえず入れてしまってある既存実装は他にもあるので、 「入れてしまえ！」で良い人がいればそれもアリだと思います。
> [ブランチは手元にあるのですが](https://github.com/k-kagari/sakura/tree/feature/remove-shared-cache)、性能の変化の検証をしてPRにまとめる作業に手を付ける気にならず放置中です…。 あら。。。 * 関連PR出したら競合するのかしら？ 競合するでしょうね・・・ * 文字幅キャッシュの構築ってそもそもどれくらいかかるのかしら？ そんなに時間はかかってないでしょうね・・・ * 文字場キャッシュの構築ってそもそも必要なのかしら？ 文字幅計算の対象になる文字数が多く、かつ、重複する文字が多い場合には効果あるでしょうね・・・ 文字幅キャッシュに関して気付いた他の問題 * 文字幅キャッシュを作成する必要があるかどうかを判定していない * MapViewOfFileが失敗した場合が考慮されていない * 文字幅キャッシュの構築はエディタプロセス側だけで必要な処理だが、コード上その意図が読み取りづらく「そもそもここで構築するのが不適切なんじゃね？」という本質的なギモンに辿り着きにくい
2.3.3に1票です。 GitHub移行は大きな転機と思いますが、実はまだ何もしてないので2.4じゃない気がします。 過去はその時々のコミッタさんが独断で決めてたように見えました。一度だけ、どうします？って見たけどあの後にリリースはなかった気がします… げんたさん時代は…というか3年前以前のことはよく知らんです。
最初に書いた2.3.3.0への同意は、6末リリース前提では新機能までは行かないだろうとの読みから出たものです。せっかくリリースするなら更新するだけの付加価値を付けるべきの意見には賛同します。 タイミングはおそらくnowがベターです。 入れれば確実に付加価値となるような何かを6末リリースに間に合うように選定してみてはどうでしょう。この一年の累積修正もカウントしていいと思います。
64bitOSで動かした時、たまに起動が重たくなる事象に対する暫定対応というのを週末にPR予定です。
@KageShiron さん > しかし、実際の利用者は破壊的変更を求めてない気もするので、 たぶん…いや、絶対そうだと思ってます。 ある変更が破壊的なものでないと証明する手段がないってのは困ったことです。 （手段がないからできません、じゃ意味無いんですが... :smile: ） @m-tmatma さん > すごく簡単に作れます。 アンケートは「聞きたい人」が「答えてもいい人」に向けるメッセージなんだそうです。 答えやすい設問を作るのは結構難しいです。 設問作るの得意な人がいたらすごく助かる感じです。 > 64bitOSで動かした時、たまに起動が重たくなる事象に対する暫定対応というのを週末にPR予定です。 この件、「暫定」でも修正量が多いので間に合わない気がしてきました。 詳細は今夜、別issueで。
> アンケート良いですね。次リリースバージョンの初回起動時だけアンケート促すダイアログとか入れたいなーと思いました（うざいですかね。一度起動だけなら良いかな、と）。 前にあった「緊急事態向けに CDROM に入れて携行」な用途では 初回起動時に出しちゃうとちゃぶ台返しされそうな感じですね・・・ 情報収集量の期待値は減りますが、インストーラの完了画面にボタンorリンクが無難かと。 あとは「ご利用に関するアンケートへのご協力をお願いしています。ご協力いただけますか？」をチェックさせるのもいいかも知れません。言質をとったら最期、あとはやりたい放題です。 当然、デフォルト選択は「はい」:smile: > あと、ヘルプメニューから「GitHub Issues」「アンケート」に直接飛べるリンク張りたいな、と思っています。 #74 の話題と統合できるとかっこよさそうです。 近年のvisual studioに搭載されてる評価機構はよくできてますよね。 あんな感じ・・・
> これって何をする予定だったか、覚えてますか? 暫定策を提案するつもりでした。 そこをケアしても他の原因にも手を打たなければ遅延は解消しないのでやめました。 遅延の原因は3つあると見ています。 うち1つは着手済み(プロセス起動時の排他制御絡み)です。 うち1つはいずれ着手予定の初期表示時の同期制御絡みです。 最後の1つはまだ秘密です。大規模修正が必要なので、準備ができるまで内容は伏せときたいです。