フォーラムの返信を作成しました。
- 作成者投稿
- ent参加者
ご検討ありがとうございます。
急いでおりません、気長に待ちます。
ent参加者江村様
ご対応ありがとうございます。
動作確認しました。ent参加者江村様
ご回答ありがとうございます。
置換の場合にも「折り返しあり」オプションの追加をお願いいたします。(私的には オプションのOn/OFFは検索時と連動でよいと思います)
タイトルについては短くするしかないんですね、承知しました。
ent参加者江村様
お返事ありがとうございます。少し言い過ぎました。申し訳ありません。
「速さ(早さ)」も「安定」も両立できるように取り組まれていることはフォーラムを見ていればある程度分かります。
ただ今回のようにあまりにも基本的なところで不具合が入ると、信頼が揺らいでしまいます。「安定リリース」をできる限りその言葉の意味通りのものにしてほしいという意見としてとらえて下さい。
ent参加者江村様
ご対応ありがとうございました。治っていました。
正式版はきちんとテストして出荷してください。
ベータ版で不具合がないことが分かるまで1週間様子を見るとか。
正式版は必ず最終ベータ版をそのまま正式版とするとか。今までのやり方を見ていると最終ベータ版から正式版の間に何か修正されてベータテストしないままいきなりリリースされているように見えることが良くありました。正式版ユーザーまでベータテストさせられている気持ちになることがあります。
個人的には愛用しているエディタですが、社内に勧めにくい理由でもあります。
以上です。
ent参加者セット内の任意の一文字 [ ] の指定もアウトでした。
[BD]
を指定してどこにもマッチしません。正規表現そのものがダメなのでしょうか。
非常に困っております。設定をもとに戻すことは可能でしょうか。ent参加者どうやら最初に | を使った検索ができないようですね。(何が「最初」になるのか 全く分かりませんが、、)
1回目の検索で
D
を検索条件にすると Dにマッチし、2回目の検索条件を変更して
(D|B)
にすると今度は きちんとマッチするようになりました。
ただ、検索結果を表示するステータスバーは 0個の一致が見つかりました、などが出てきており 状況に一致しない不具合もありそうです。ALT+F3を実行して検索結果をクリアーすると (D|B) がマッチしない状況になりました。
こちらの状況としては以上です。
ご確認をお願いいたします。
ent参加者江村様
上記ご対応ありがとうございます。
ただ、「前の条件との論理和」がONの状態で覚えさせてあるダイアログを再び開いて、クリップボードを貼り付けした際に、前の条件との論理和 のチェックがOFFになるようです。
条件変わらないように貼り付けできますか?それから
> フィルター後のステータスバーの表示:0行が一致しました
の件ですが
以下の手順で再現しました。1.フィルターされるテキストファイルを開く
2.高度なフィルター、ダイアログを開く
3.(あらかじめコピーしてあった)複数行の文字列を貼り付ける(1.のデータで一致するものがある)
4.前の条件との論理和 をチェック(条件すべてに チェックON)
5.フィルター ボタンをクリック
6.エディタ部がフィルタされて表示されているこの状態で、エディタの左下を見ると 「0行が一致しました」と出ています。
ご確認をお願いいたします。
ent参加者江村様
高度なフィルターを試してみました。おおむねこれで良さそうです。
以下の点を確認お願いします。
・フィルター後のステータスバーの表示:0行が一致しました (と表示されることがあった)
⇒ フィルターされた件数が表示されるべきでは?(別のPCだとうまくフィルター行数が出てきたので環境依存かもしれません)要望
1.インポートした文字の各行が、フィルターにマッチしたのかどうか知りたい。インポートした項目の列に フィルター結果(マッチ|アンマッチ) が表示できるととても良い。
(1000行インポートして、フィルターしたときに 999行の条件が実際にマッチしたとか、1件の条件はマッチしていないとか、そういうことが知りたい)
2.文字列(矩形範囲)の選択から フィルターに追加、などができるとなおよいです。
3.高度なフィルターのダイアログはモーダル表示ですが、エディタ部に移動できるようにはできませんか?
4.「前の条件との論理和」がONにしてあることが今回の私の使い方では必須となります。こちらのオプション含め、高度なフィルター画面にある条件を任意の初期値表示に変更できると普段使いが便利になるので、そういう初期設定(およびリセット)ができるようになりませんか。ent参加者江村様
機能の紹介ありがとうございます。
高度なフィルターを試してみます。
ent参加者江村様
ご質問ありがとうございます。
業務データの加工で、特定のキーのレコードを抽出するために検索文字数を多く必要としています。
例えば1レコードを特定するキーの長さが30文字、探したいキー数が1000件あったとすると
(key1|key2|key3|…….|key1000)
という正規表現で検索しています。
実際には1000件は 1万文字を超えるため、300件ごとに区切って正規表現を作り検索しています。可能な限り上記の作業の分割を少なくするために、入力(検索)可能文字数を大きくしてほしいです。
また、ドロップダウンの表示については
現状のようなスペース表示にならないような対策もしくはドロップダウンでは全体の文字が確認できなくてもよいですが、検索文字がセットされていると認識できる別の方法(例えばツールチップで、検索文字列の最初と最後の何文字かだけを表示)を追加してほしいです。(ドロップダウンで一望できる文字数はもともと少ないので、こういう確認ができるとすごく便利です)以上です。
ご検討をよろしくお願いいたします。
ent参加者江村様
本件について以下確認をお願いいたします。
1.検索ダイアログでの検索文字数の上限についてですが、現状の1万文字を、5万文字までなどに増やせないでしょうか。レジストリ設定変更でも構いません。
2.長い文字(1行で、1万文字未満の正規表現を書いた文字列 )を選択して CTRL+F キーを押したとき、に検索テキストに文字がセットされる状況として、以下2点 おかしく感じます
2.1 検索ダイアログに 選択した文字が入力されないことがあります(全角文字で5000文字未満 のケース、ダメでした)⇒数文字だけが、インプットされるようです
2.2 検索を実行するとハイライトされるので検索条件になっていることはわかったが、検索ダイアログの検索文字列がすべてスペースで見えてしまう⇒きちんと文字で表示してほしいent参加者江村様
返事が遅くなりました。
おっしゃる通り、検索中 新規作成して作業できるのは確認できました。
でもやっぱり、それまでのウィンドウが操作不能なままなのは 不便です。「ファイルから検索」のプロセスを分離できないでしょうか。
ent参加者江村様
「ファイルから検索」の最初のステップの画面:「検索中:指定したフォルダ内のファイルを数えています」の状態で
エディタのタブの移動もできず、エディタの編集もできませんでした。そこから先は試さず(待ちきれず)、「キャンセル」しました。
バックグラウンドの対応はまだされていませんか?
もしくは何かオプションの組み合わせが悪いのでしょうか。
ご確認お願いします。
ent参加者江村様
ご対応ありがとうございます。確認しました。
ent参加者江村様
表題の件の追加はいつ頃行われますか?
投稿を見て期待して待っておりましたが、最近のいくつかのバージョンにはまだ実装されていないようなので。。ent参加者江村様
今回のケースだと、[複数選択をコピーする時、常に改行コードを挿入する] チェック ボックスを解除 でもOKなのですが、
そもそも、想像するに
[複数選択をコピーする時、常に改行コードを挿入する] チェック ボックスをONにする理由は
以下の文字列で 101,103,105 を3つ同時選択している状態でコピーした際に、
192.168.0.101
192.168.0.102
192.168.0.103
192.168.0.104
192.168.0.105貼り付けた結果が、
101
103
105
となるようにするためにあるのですよね(このほうが良いと思います)。 [複数選択をコピーする時、常に改行コードを挿入する] チェック ボックスを解除 で同じことをすると 101103105 が貼り付けられますね(これはあまり期待しない結果だと思います)。ですので [複数選択をコピーする時、常に改行コードを挿入する] チェック ボックスはONのまま生かすことを考えると
以下の動作をするオプションが新たにあれば良いのかなと考えています。
・ CTRLキー押下で、(行番号クリックで)1行選択時に末尾の改行コードを含めない
現在でも SHIFT+ENDキーで行頭からの選択をすると行末の改行コードは含まれませんよね。それと同じ行選択が行番号クリックでも意図的にできればよいかと考えます。いかがでしょうか。実際の 使い勝手のほどはわかりませんが、、、
ent参加者江村様
ありがとうございました。
期待通りのことができました。
ent参加者江村様
ご対応ありがとうございます。
修正されていたのを確認しました。
ent参加者範囲選択を期待通りに変更することができました。ありがとうございます。
[複数選択でタイプする間、選択を保持する] チェック ボックスのOn/OFFによって上記のコマンドを使い分けするのは面倒なのですが、このチェックボックスの
ON/OFF状態を判断するマクロも教えていただけますか。そうすればIF文でどちらの場合にも同じように範囲選択を変更することができるようになります。
よろしくお願いいたします。
ent参加者江村様
ベータ版リリースありがとうございます。
修正(追加)された一覧をみて、なるほど、並べ替えの場合には選択範囲を基準にするのは有りだな、と思いました。別々のオプション設定になったことは納得できます。
確認してみたところ、以下の動作が不自然でした。
1.[カスタマイズ] ダイアログ ボックスの [編集] ページに [箱型選択または複数選択が存在する時、選択された文字列のみを調べる ([重複行の削除] コマンド)] オプションを チェックOFFの状態で 以下の文字列の 196 のみ選択して重複行を削除 を実行。
192.168.0.101
192.168.0.103
192.168.0.104
192.168.0.106
192.168.0.100
192.168.0.101⇒当然どの行も削除されずに残りますが、箱型選択の範囲が行全体へ拡張されてしまいます。選択範囲は変わらないほうが良いです。
ent参加者確認が遅くなりました。すみません。
EmEditorで正式版リリースのみダウンロードするようにしていたのでベータ版のリリースに気づきませんでした。
可能なら個別の(こちらの)スレッドに ご案内いただけると助かります。こちらのスレッドのみ定期的に見ていました。確認とフィードバックと改めての要望を以下に書きます。
1.暗黙的な動作の変更を行ったのみで、設定画面にはオプションの追加はしていない
という事でよろしいでしょうか。
どこをどう変えたのか、やはりこちらのスレッドにご説明いただけると、こちらの確認範囲が明確になるため、きちんと書いてください。
どこが変わったのかなと、こちらが調べるのは無駄な手間です。
確認するほうの手間を減らす(勝手な理解による誤解を防ぐ)ための配慮(変更箇所をご説明いただく)をお願いします。2.変更内容は #28424 の記述の通りでしょうか?
まず、現時点のベータ版で不具合があります。
#28422 の操作をすると、「複数選択はすべて空です」のメッセージが出ます。(ここまではおっしゃる通りの動作なのでOKです)
そのダイアログを閉じると、なぜか1行削除される動作が起きるケースがありました。
どういう状況か今のところ把握できず、説明ができませんが、今回この件は私にとっては重要でないので調べることは致しません。3.を確認お願いします。3.現時点での範囲選択をした状態での「重複行を削除」の動作結果は重複「行」を削除をしているわけではない。(重複していない「行」まで削除を行っているので不自然 )
範囲選択をしていようが、普通に複数行選択をしていようが、「行」に対する処理となっていないと「重複行を削除」の表示から受ける印象と異なり不自然に感じます。
(英語版とかだと、印象が違うんでしょうか?)本当の希望は、デフォルトの動作を以前の状態へもとに戻していただくことです。
しかしながらすでに正式版に組み込んでしまった機能ですからデフォルトの動作はこのままでよいので過去の動作に戻るようにオプション設定をお願いします。過去の「重複行を削除」の動作とは、「矩形選択かどうかによらず、選択された行に対して、1行全体の内容をそれぞれ比較して行をユニーク化する」です。
以上、ご確認よろしくお願いします。
ent参加者江村様
通常の「重複行を削除」コマンドは行全体を比較して行単位で削除されるべきだと思います。(現在のコマンド動作は別のコマンド名にしたほうが良いのでは、、)
できれば、オプションで 従来通りの動作で使用できるようにしてください。よろしくお願いします。
ent参加者江村様
いち利用者の立場からすればEmEditorの内部事情は分かりませんので、もしかしたら(Windows10の環境でも関係する)改善のヒントになるかもしれないと思って報告しております。
不具合のある環境でDrectWriteをなぜOnにしたいのか?ですが、描画の結果(見た目)が全く同じなら こだわることはなかったです。
DirectWriteをONにするとフォントのレンダリングモードが調節できるなど好ましい点があったためです。このトピックをずるずると続ける気はありませんが、最後にVmWare Workstation 15 Playerでも試してみていただけますか。VirtualBoxは使っていません。
江村様は この描画不具合に関しては DirectWrite ON の場合に OSの違いによるEmEditor内部のロジックの違いはないということをおっしゃっているのですよね。
EmEditor内部の違いがないからこそ外部(=OS)の違いのせいだといわれることは理解しました。致命的な問題ではないことも理解してます。だからもうWindows7での描画の不具合については気にしないことにします。
そろそろWindows7を切り捨てる時が来ているということは承知しました。あと1年もすれば私の業務PCも、プライベートなPCもWindows10に切り替わる計画です。ent参加者このトピックに続けるべきか迷いましたが、、
以下のパターンで操作をすると、確実に画面描画がおかしくなるやり方をやっと発見しました。(これは、タスクトレイクリックとか、ウィンドウ初期表示の件とは無関係です。)
・Windows7(業務用PC(物理PC )、仮想PC(VmWarePlayer) の2台で検証 )にて、再現しました
・DirectWrite:ON
・行番号表示:ON
・(ほかにも何かきっかけとなる設定があるかもしれませんがそこまでは把握せず)上記の状況で、
1.何行でもよいので エディタ部に文字を入力します。既存のファイルを開いてもよいです。
2.Ctrl+ALT+Delete を押し、スクリーンロック(まだロックしていない)の画面を出します。
3.何もせずにESCキーをすぐに押して復帰します
4.EmEditorの「行番号」を表示している領域にマウスカーソルを持っていきます。4.の直後、行番号を含めてエディタ部の描画が真っ黒になります(色の設定によるかもしれませんが)。
マウスをさらに行番号の上でホバーさせると行番号の描画が1行ずつ復帰しますが、エディタ部はなにも描画されないままです。
エディタ部をクリックすると、エディタ部が再描画されました。…以上のようなことが、少なくとも ハードウェア設定が完全に異なる2台で再現できました。
ご確認お願いします。
- 作成者投稿