-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PatchUnicode-1051 現在のドキュメント内容をGrep(2) #1696
Conversation
✅ Build sakura 1.0.3844 completed (commit 80a1835c03 by @dep5) |
結局 Moca さんが無関係なフランス人を指している件を突っ込んどきます 😃 |
berryzplus さん beru さん #1639 の続きですが 使用したバージョンはこれです https://github.com/git-for-windows/git/releases/tag/v2.29.2.windows.2 わたしの使い方がおかしいかもしれないですね。 |
163bf04 のコミットに、前のPRのコミット 1f088c1 の内容は含まれていますね。自分の確認間違いでした。コミットメッセージだけを見て変更が移行されたかを確認していました。 さて動作確認してみましたが期待通りの動作ではありませんでした。現象としては #1639 (comment) に書いたものと同様です。
そもそも何故 patch ファイル経由で操作してるんでしょうか?git client の機能で別のブランチのコミットを取り込んだり出来るのに…。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CDlgGrep::OnBnClicked
において
if (::IsDlgButtonChecked(GetHwnd(), IDC_CHK_FROMTHISTEXT)) {
の条件判定は無い方が動作がより自然になると思いますがどうでしょうか?
sakura_core/dlg/CDlgGrep.cpp
Outdated
@@ -557,6 +558,20 @@ BOOL CDlgGrep::OnBnClicked( int wID ) | |||
return TRUE; | |||
case IDCANCEL: | |||
// ::EndDialog( hwndDlg, FALSE ); | |||
if (::IsDlgButtonChecked(GetHwnd(), IDC_CHK_FROMTHISTEXT)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dep5 さん、この if の判定は不要だと思います。
この判定がある事で下記の操作を行うと不自然な挙動になります。
自分が正しいと思う挙動についてですが、
- Grepダイアログを開いてから検索条件を変更する
- 検索を実行してからGrepダイアログを閉じて再度Grepダイアログを開いた場合は、検索前にコントロールに設定していた検索条件が復帰される
- 検索を実行せずにGrepダイアログを閉じて再度Grepダイアログを開いた場合は、検索条件を変更する前の検索条件がコントロールに設定される
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
そもそもどうしてこういう挙動になるのかという話ですが、CEditWnd
クラスのメンバーとして CDlgGrep
型のインスタンス m_cDlgGrep
が存在しています。なのでGrepダイアログを閉じても再度Grepダイアログを開いた時にそのインスタンスが使いまわされます。そのため、CDlgGrep
のメンバー変数 m_szFile
, m_szFolder
等に設定されている内容はダイアログを閉じる前の状態が保持されます。その為に過去の値が再度Grepダイアログを開いた際に、CDlgGrep::OnInitDialog
→ CDialog::OnInitDialog
→ CDlgGrep::SetData
の順に処理が呼び出されて、CDlgGrep::SetData
メソッドにおいて、CDlgGrep
のメンバー変数 m_szFile
, m_szFolder
等の値が DlgItem_SetText
関数でコントロールに設定されます。
@dep5 さん、
gitのサブコマンドは色々とあって慣れていないとややこしいです。ちなみに自分は TortoiseGit と WinMerge というソフトに慣れていて、大体それを使って rebase 等の操作をしています。patchファイルは殆ど使いません。 なおVS Codeにも標準でGitの機能があります。自分はそれにあまり慣れてなくて複雑な操作は行えませんが、簡単な事をする分には結構お手軽ですよ。 |
✅ Build sakura 1.0.3847 completed (commit f93e048a59 by @dep5) |
✅ Build sakura 1.0.3848 completed (commit 5f35047edc by @dep5) |
beruさん #1639 (comment) で全部説明してもらっているのにすいません。 わたしもその挙動に賛成です。 ソフト起動後初めて開いた文書では「編集中のテキストから検索」のチェックが外れています。 git commitすると元に戻すのが大変ですが #1696 (comment) |
nGrepTreeResult = -1; | ||
break; | ||
if( hWndTarget ){ | ||
for( HWND hwnd = hWndTarget; NULL != hwnd; hwnd = NULL ){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ここって1回しか回らないように見えますがどうしてforループになっているんでしょうか?
確認しました。メンバ変数
おぉ、そうだったんですね。ケースが色々なので確認が大変ですね。。
自分は作業ブランチにはどんどんコミットは気軽に入れてます。amend で上書き出来るし後から複数のコミットを1コミットに統合したりは気軽に行えるので。変更前の状態に戻したい時は別のブランチに切り替えています。
WinMergeは既にお使いでしたか、失礼しました。なおあれのテキストエディト部分は Crystal Edit (link) のクラスが使われています。サクラエディタに比べるとちょっと機能不足ですが、それでも素のエディトよりはずっと良いですね。
うーん、分からないです。ログインしてページを見てましたが Retry 的なボタンは無いですね。 |
気になる点として空の文書で Ctrl + G キーを押してGrepダイアログを開いた後に「編集中のテキストから検索」にチェックを入れて、適当に「条件」に
空の文書ではなく適当に
という事でまっさらの空の文書で「編集中のテキストから検索」にチェックを入れて検索を行うと、何故かこれから開くGrep結果の文書から検索してしまう動作になっているんでしょうか? |
beruさん 空の文書での挙動ですが、「編集中のテキストから検索」をチェックしないで通常のGrepを行うと 空の文書に対して「編集中のテキストから検索」を行ってテストしていたので、おかしいと思っていませんでしたが、 |
@dep5 さん
こちらはMocaさんのパッチの記述が元からこうなっているんですね。
確かに元から通常のGrepを空の文書で行うとその文書がGrepウィンドウとして再利用されてそのウィンドウに結果が表示される動作ですね。 その実装をベースにしているので「編集中のテキストから検索」にチェックを入れて空の文書でGrepを行うと、同様にその文書がGrepウィンドウとして再利用されてそのウィンドウに結果が表示される動作になるという事ですね。 副作用としてヘッダで出力された検索条件や検索対象からもGrepしてしまうと。。
自分はこの挙動は不自然だなと感じましたが、元のパッチの動作という事でこのPRではこのままで良いと思います。 もしこの動作はおかしいよという意見がどんどん出てきた場合は後で別のPRで修正を入れたほうが良さそうですね。 しかし差分の量がとても多いのでコードの挙動が色々なケースで問題が無いかについては追い切れなそうです。dep5さんはよくまとめ上げたなと思います。すごいですね。。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
動作確認してみて問題無いと思います。
他の方から数日中に Request changes が入らなければ Merge したいと思います。 |
中身見てる余裕がないのでsonarcloudの再実行だけしときます。
CodeFactorの警告は、いつも通り見当違いなのでスルーでよいと思っています。 |
SonarCloud Quality Gate failed. |
「旧パッチ適用だから」、おっけーっす 😄 |
@berryzplus さん、sonarcloudの再実行と確認ありがとうございます。 Mergeします。もし何か問題が見つかったら別のPRで対処しましょう。 |
PR の目的
#1639 のコミットを整理しました。
Mocaさん、novice123さん作の
PatchUnicode-1051 現在のドキュメント内容をGrep を適用します
カテゴリ
PR の背景
新規の文書・編集中の文書をGrepしたい場合、一時的にでもファイルとして保存する必要がありました。
PR のメリット
ファイルに保存していないテキストを、Grepできるようになります
検索結果のカウントなどもできます
PR のデメリット (トレードオフとかあれば)
Grepでファイルを編集中の場合、Grepする対象が変わります。
Grep置換では使えなくしました
仕様・動作説明
Grep
新規のテキスト
(前)不可 (後)可
ファイルを編集中
(前)ファイルをGrep (後)テキストをGrep
ファイルに保存済み
(前)ファイルをGrep (後)ファイルをGrep?
Grep置換
機能をオフにしてあります。
PR の影響範囲
テスト内容
テスト1
手順
関連 issue, PR
#1639
参考資料