フォーラムの返信を作成しました。
- 作成者投稿
Yutaka Emura
Keymasterkazuikeさんは書きました:
メールでも同じようなご質問をいただいているので、同じお客様ではないかと察しています。よろしければ、以下のような手順を試していただけないでしょうか?
私はメールをお送りしていないので、別の方かと思います。
すぐにでもレジストリの内容をお送りしたいところではありますが、残念ながら終電の時間が迫ってきておりますので、週明けにでもお送りしたいと思いますが、先の私の投稿と入れ違いになっているかもしれませんので、それで別の対応があれば、また教えてください。
よろしくお願いいたします。お返事ありがとうございます。エクスプローラ プラグインを使わなければ問題がないということなので、これは、エクスプローラ プラグインの問題だと思います。ですから、もうレジストリの情報は送っていただかなくても結構です。もしエクスプローラ プラグインが必要なければ、エクスプローラ プラグインを閉じたまま使っていただけると幸いです。
さて、エクスプローラ プラグインのバグだとするとその解決法ですが、何か、ネットワークでオンラインになっていないプリンタなどのデバイスはPCがないでしょうか? 割り当てられているドライブで使用できないデバイスなどはないでしょうか? 何か他の問題のない PC と比較して違うところで思い当たる点がありましたら、教えていただけると幸いです。よろしくお願いいたします。
Yutaka Emura
KeymasterSongmuさんは書きました:
マクロ記述時に、文字コードをutf-8で書く方法はありませんでしょうか?utf-8のテキストを編集しているときでも、選択範囲
Window.document.selection.Text;
には、文字コードがShift_JISの文字列が入ってしまいます。また、アウトプットバーに
Window.OutputBar.writeln(“hoge”)
等で出力するときも、Shift_JISに変換しないと文字化けしてしまいます。エディタの既定文字コードをutf-8に設定すれば良いのかもしれませんが、
その方法はありますでしょうか?
言語の設定等でutf-8を追加する方法が見当たりませんでした。旅行中のためお返事が遅れて申し訳ありません。
マクロはすべて Unicode の扱いになっています。問題はファイルを保存ときに何のエンコードで保存するかになります。
document.Encoding = eeEncodingUTF8;
とすれば、次回保存ときに、UTF-8 で保存されます。試していただけますでしょうか?
Yutaka Emura
Keymasterkazuikeさんは書きました:
報告の続きです。スタートメニューからEmEditorが起動できたり、できなかったりする件ですが、最後に開いたファイルによって、その後の動作が変わるようです。
具体的には、
正常に開けるファイルを開いて閉じた後は、スタートメニューからEmEditorが起動できます。
正常に開けなかったファイルを「開く」で開いて閉じた後は、スタートメニューからEmEditorが起動できなくなります。(正確には、起動してもすぐ終了してしまいます)今、私は旅行中のため、お返事が遅くなり申し訳ありません。
メールでも同じようなご質問をいただいているので、同じお客様ではないかと察しています。よろしければ、以下のような手順を試していただけないでしょうか?
もし可能でしたら、レジストリ エディタ (regedit.exe) で、HKEY_CURRENT_USERSoftwareEmSoftEmEditor v3 を選択してから右クリックしてエクスポートを選択しファイルに名前を付けて保存し、さらに HKEY_LOCAL_MACHINESoftwareEmSoftEmEditor v3 を選択して同様にエクスポートをして別名のファイルに保存を行っていただけますでしょうか? それらのファイルを Zip 形式で圧縮してから、添付ファイルでメールで [email protected] あてに送っていただけると幸いです。
さらに、もう一度、コントロールパネルからアンインストールを行い、アンインストールの途中に、データを保存するかどうかのプロンプト ダイアログ ボックスが表示されるので、そこで「いいえ」をクリックすると、情報が完全に削除されます。アンインストールの後、Windows を再起動してから、最新版を再インストールしていただけると幸いです。それでもまだ問題が残っているかどうか試していただけると幸いです。
それでは、よろしくお願いします。
Yutaka Emura
Keymasterqtvさんは書きました:
開発お疲れ様です。タブ設定で使用していて、ファイルを閉じるときには「閉じる」を使っています(キーを割り当てて使っています)。
ときどき、プラグインのカスタムバーにフォーカスがある状態で「閉じる」を設定したキーを押すことがあるのですが、その場合はファイルではなくカスタムバーが閉じてしまいます。
メニューから「閉じる」を選ぶと、その場合はファイルが閉じて、カスタムバーは残っていました。
キー操作でも同様の動きにならないでしょうか。そうすると、 Ctrl + F4 でカスタム バーが閉じなくなるのですが、それでもよろしいでしょうかね? 「フォーカスのあるカスタム バーを閉じる」コマンドがあった方がいいでしょか?
Yutaka Emura
Keymasterアンケートの選択項目に、
CSV (カンマ区切り)
TSV (タブ区切り)
セミコロン区切りを追加しました。
Yutaka Emura
Keymasterfusaさんは書きました:
こんにちは。マクロを組んでいるときに
間違って無限ループに陥った場合には
プロセス停止したのですがマクロを止める方法はないものでしょうか?
何かマクロの動作を途中で止めるキーがあればいいなあと思うのですが、止める方法があるのでしたら教えてください。
残念ながら、マクロを止める方法はないです。将来的には、止める方法を考えたいと思っています。
Yutaka Emura
Keymasterrenagonさんは書きました:
リプライありがとうございます。> 通常、 Ctrl + H は、置換ダイアログを表示します。確定後の場合、置換ダイアログは表示されますか?
はい、表示されます。
ちなみに、私は、EmEditorでも、Ctrl + Hは、”左を1文字削除”にアサインしています。
> EmEditor のバージョン、OS のバージョンなど、できるだけ詳細な情報を教えていただけると幸いです。
EmEditorのバージョン; EmEditor Professional Version 8.05
OSのバージョン; Windows XP Professional Version 2002 Service Pack 3あと、IME 2007のプロパティで設定したキー設定が効かないのはは、Ctrl + Hだけでなく、以下があります。
Ctrl + P
Ctrl + N
Ctrl + O私のキー設定(ユーザ定義と表示されますが)は、デフォルトの”Microsoft IME”をベースに、上の3つとCtrl + Hを含め、計4つの変更を加えた状態です。
以上ですが、よろしくお願いします。
お返事ありがとうございます。
確認ですが、IME の確定前の場合、Ctrl+H が効かないということですが、この場合も、やはり置換ダイアログが表示されるのでしょうか?
メモ帳だと、IME の確定前の場合でも、左一文字削除ができるのでしょうか?Yutaka Emura
Keymasterrenagonさんは書きました:
EmEditor上で、IME 2007を使って日本語の編集していると、IME 2007のプロパティで設定したキー設定が効かないことに気付きました。例えば、”Ctrl+H”で、”前字削除”としてますが、反応がありません。
少し前は問題なかったですし、他のアプリケーション(例えば、メモ帳)上では、きちんと、IME 2007のキー設定は有効です。
何か解決法のヒントあればお願いします。
こちらでテストしてみましたが、確定前の文字でしたら、Ctrl + H でも、ちゃんと前字削除できます。確定後の文字はできないですが、それはメモ帳も同じでした。通常、 Ctrl + H は、置換ダイアログを表示します。確定後の場合、置換ダイアログは表示されますか? EmEditor のバージョン、OS のバージョンなど、できるだけ詳細な情報を教えていただけると幸いです。
Yutaka Emura
Keymasterfusaさんは書きました:
こんにちは。EmEditorのメニューのプルダウン位置がおかしいので
ご報告します。過去に報告されていたらすいません。
EmEditorの表示位置をデスクトップの下のほうにやっておいて
メニューをプルダウンさせたとき
たとえば、ファイルメニューを表示したときに
普通は
[ファイル]
[新規作成]
[開く]省略
[すべて保存して閉じる]
[すべて閉じる]となりますが、
メニュー下端がデスクトップからはみ出してしまうときには
[ファイル]メニューアイテムの上のほうに表示されますよね。どのソフトもこうなっていて自然なのですが
EmEditorだけは、この上方向のプルダウンの場合[新規作成]
上方向は省略
[すべて保存して閉じる]
[すべて閉じる]
[ファイル]このようにならずに
[ファイル]の部分に[すべて閉じる]がかぶさって表示されてしまいます。表示がこれだけならあまり問題にならないのですが
操作性に問題がでてきてしまいます。私の場合、印刷をしたい場合はこのような操作になります。
[ファイル]メニューをクリック=マウスDown+マウスUp
そのあとに、[印刷]メニューをクリック=マウスDown+マウスUpと、2回クリックするわけです。
ところが、EmEditorの場合は[ファイル]メニューをクリックするときに
上方向にプルダウンしてしまうとマウスDown
[ファイル]メニュー展開
[すべて閉じる]の上にマウスが来ることになる。
マウスUp
そして[すべて閉じる]が選択されるという挙動になってしまいます。
実際、この挙動のおかげで、なんども思い描かない
マクロが動いてしまったりして
かなり不便に感じていたというか、なぜそんな操作が起きてしまったのかわからない状態になってしまった
ことがありました。調べた限りですが、EmEditorと同じ実装になっている
ソフトウェアはありませんでした。OS標準的なUIへの改善を望みます。
よろしくお願いします。プルダウンのポイントが
プルダウン方向の上下にかかわらず
トップメニューの下端になっているコトに問題があるように思います。環境はv8.05ですが
かなり以前から誤動作しっぱなしなので
最新版でも実装が変わってなければ同じ問題があると思います。v9 の次の alpha 版では、ご希望の動作になるようにしました。ご意見ありがとうございました。
Yutaka Emura
KeymasterAye Wongさんは書きました:
Yutakaさんは書きました:
Aye Wongさんは書きました:
お疲れ様です。alpha33で報告させていただいた問題は解決したことを確認しましたが、CSVモード周りで別の問題を発見しました。セルに改行を含むCSVの扱いに難があるようです。
例えば、a,”
“と入力してからCSVモードを有効にすると不自然なところに2列目が現れます。
また、以前、処理に掛かる時間が問題なので、列の幅の自動縮小には対応しないと伺いましたが、ファイルの行数に上限を設ける、遅延及びバックグラウンド実行するなどして、限定的に対応は可能ではないかと思いましたがいかがでしょう?
そして、CSVの罫線は、カーソル位置の罫線とは別の色であってほしいと思いました。
書くのを忘れておりましたが、現在のところ、改行を含む CSV には対応しておりません。どうかご了承ください。
どのような動作になるのかを試されたでしょうか?明らかにバグのような動作をします。また、再現手順や依存関係は分からないのですが、一度、改行付きCSVでクラッシュをしたことがあります。
改行を含むCSVをサポートしていただきたいと言っているわけではありませんが、CSVをEmEditorで開いてみたら改行を含むCSVだったということは良くあることだと思われますので、少なくともこのような挙動は改善されるべきだと思いますがいかがでしょうか?
確かに動作がおいかしいのは直さなければなりません。警告メッセージも必要だと思いますので調べます。どうもありがとうございます。
Yutaka Emura
KeymasterAye Wongさんは書きました:
お疲れ様です。alpha33で報告させていただいた問題は解決したことを確認しましたが、CSVモード周りで別の問題を発見しました。セルに改行を含むCSVの扱いに難があるようです。
例えば、a,”
“と入力してからCSVモードを有効にすると不自然なところに2列目が現れます。
また、以前、処理に掛かる時間が問題なので、列の幅の自動縮小には対応しないと伺いましたが、ファイルの行数に上限を設ける、遅延及びバックグラウンド実行するなどして、限定的に対応は可能ではないかと思いましたがいかがでしょう?
そして、CSVの罫線は、カーソル位置の罫線とは別の色であってほしいと思いました。
書くのを忘れておりましたが、現在のところ、改行を含む CSV には対応しておりません。どうかご了承ください。
Yutaka Emura
Keymasterobottさんは書きました:
>>やはり、巨大ファイルの場合のみ
>>バイナリで違うファイルになっていませんでした。>>この下再表記:
>>この結果から、推測すると、、、
>>貴エディタは、巨大ファイルの変更点の記憶方法に
>>問題が有り、このような時に、実は変な文字コードによる変更は記憶していないので、、
>>上記結果の様になるのではないでしょうか?
>>説明追記:
>>巨大はファイルの場合は変な文字コードによる変更は単純な上書き時には反映されず、
>>小さいファイルの場合は変な文字コードによる変更は、必ず反映される。何度も何度も、巨大ファイルでって書いてるのに、、、、、
>>つまり、300MB 以上の巨大ファイルの場合、ファイルの保存時、変更のある行は、エンコードの変換が行われますが、変更のない行は、エンコードの変換を行わずに保存することによって、速度の向上と使用メモリの削減を行っています。これは、EmEditor の仕様であり、不具合ではありませんが、ファイルを開いたときの警告表示が紛らわしい場合は、表示を見直します。
仕様を誤認させるダイアログ表記、、、十二分に、不具合だと思いますが、、、、、、
再現する単純な巨大ファイルを作って確かめてましたよ、、、、、まったくの徒労に終わったけれど、、まっ、それはそれとして、、
仕様を誤認させない様な表記に変更するのでしょうから、、仕様変更要望として、、
1.文字コード異常時のダイアログでの選択肢として、全ての変な文字コードの変更が実際に行われる処理も欲しいですね。
もちろん、多少は時間がかかる旨明記するとして、
そうするとユーザーが全ての変な文字コードが変更された物を別ファイル名にして、元のファイルとバイナリ比較したりして調べる事が出来るから、上記変更要望は対応して頂けますか?
対応して頂けるとしたら、いつ頃でしょうか?ご回答お待ちしています。
[カスタマイズ] の [高度] タブで、[変更されていない行を元のファイルから読む] のチェックを外していただければ、ご希望のようにすべての文字コードが変更されたものを別ファイル名として保存することができます。
Yutaka Emura
Keymaster2ndさんは書きました:
こんにちは、2nd です。ずいぶんご無沙汰です。題名の件、不具合とはいえないかもしれませんが、こちらに書き込みさせて頂きます。
EmEditorを使用して速度が遅いと感じるところは殆どありませんが、一点だけ『トレイアイコンから「新規作成して貼り付け」を実行すると待たされる』という現象が起きています。
待たされるとはいっても2秒程度なのですが、他の機能が高速なため、かえって目立ってしまいます。
お時間の取れたときにでもご確認をお願いいたします。
ワークスペースの自動復元の機能を使用していますか? 使用している場合は、ワークスペースのウィンドウの処理を行ってから、その新しいタブとして文書の新規作成を行うため、時間がかかってしまいます。自動復元の機能を使用していない場合は、以前と同じ速さで表示されると思うのですが、いかがでしょうか?
Yutaka Emura
Keymasterobottさんは書きました:
やっぱり巨大なファイルでの確かめは一度たりとも行われていないのですね、、仕方が無いので、、、、
時間が有る時に、再現する単純なデータを作ってみます。私の理解が悪くて、申し訳ありません。巨大ファイルの場合だけ問題が発生するということを、よく理解しておりませんでした。既定の設定では、[カスタマイズ] の [高度] タブで、[変更されていない行を元のファイルから読む] がチェックされていて、[一時ファイルを使う最小ファイル サイズ] テキスト ボックスに指定するファイル サイズが、300 MB になっています。つまり、300MB 以上の巨大ファイルの場合、ファイルの保存時、変更のある行は、エンコードの変換が行われますが、変更のない行は、エンコードの変換を行わずに保存することによって、速度の向上と使用メモリの削減を行っています。これは、EmEditor の仕様であり、不具合ではありませんが、ファイルを開いたときの警告表示が紛らわしい場合は、表示を見直します。
この度は、obott 様には、何度も書いていただくことになり、ご迷惑をお掛けして申し訳ありませんでした。ご報告をいただき、ありがとうございました。
Yutaka Emura
KeymasterHmmさんは書きました:
いえ、EOFではなくテキストが途中までしか選択できないのです。つまり一文の途中ということです。例えば文頭から文末にかけて選択して行きますと、最終行に改行がない場合は、最終行の途中までしかテキストが選択できません。
最終行に改行がある場合は、すべてのテキストが選択できます。
複数の環境で確認しておりますので、単純な不具合かと。もしよろしければ、問題が再現するファイルを zip に圧縮して [email protected] 宛に添付ファイルで送っていただけますでしょうか?
Yutaka Emura
Keymasterフォントを変更しても発生するでしょうか? それでも発生する場合、問題の発生するファイルと、画面図を zip で圧縮して、 [email protected] 宛に送っていただければ、私の方で再現テストを行ってみます。その際、OS の種類、フォントの種類やサイズ、読み込んだ後にステータス バーに表示されているエンコード (シフト JIS など) を書いて送っていただけると幸いです。
Yutaka Emura
Keymaster確かにおかしいですね。これは調べて修正します。どうもありがとうございます。
Yutaka Emura
Keymasterこちらでテストを行ったファイルを http://www.emeditor.com/pub/sjis.zip に公開しましたので、ダウンロードして試していただけると幸いです。この中の sjis1.txt は、obott 様が書いていただいたコードの羅列をテキスト ファイルにしたものです。sjis1.txt を EmEditor で Shift-JIS で開こうとすると、警告メッセージが出ますので、そのまま続行して開くと、「行、桁の表示方法」が、「論理座標(2バイト文字を2桁と数える)」の場合、2 行 883 桁目の「┗」と「・」の間にカーソルが移動し、「・」が変換できない文字であることがわかります。そして何も編集しないで sjis2.txt に名前を付けて保存を行います。両者のファイルをバイナリ比較すると、以下のようになります。
>fc /b sjis1.txt sjis2.txt
Comparing files sjis1.txt and sjis2.txt
00000374: 86 81
00000375: 49 45
00000376: 86 81
00000377: A2 45
00002DA4: EE FA
00002DA5: EF 40
00002DA6: EE FA
00002DA7: F0 41再現しますでしょうか?
>問題が発生する文字に自動的にジャンプする機能ジャンプした位置がぜんぜんずれていました。
というのは理解せずに書いてしまい申し訳ありませんでした。
>以上の操作ではファイルの全部を開いたことになっていないのでしょうか?
巨大ファイル コントローラで、「ファイル全体を開く」がチェックされていれば、ファイルの全部を開いたことになります。
以上、どうぞよろしくお願いいたします。
Yutaka Emura
KeymasterEmEditor に問題がないと書いた理由は、以前の obott 様の羅列されたすべての文字を使用したファイルの保存前と保存後のバイナリ比較の結果ファイルに相違が発生したという私のテスト結果が、obott 様の書かれていたようにバイナリ比較で相違が無いという obott 様のテスト結果と、矛盾していたためです。申し訳ありませんが、バイナリ比較の方法に問題があると考えられないでしょうか? どのような方法でバイナリ比較をされたのでしょうか? 私の場合、コマンド プロンプトで、「fc /b file1 file2」 を行うことでバイナリの比較を行いました。
巨大ファイルを開く場合、巨大ファイルコントローラを使用して開いているのでしょうか? その際、ファイル全体を開いて保存しているのでしょうか? あるいはファイルの一部を開いて保存しているのでしょうか? ファイルの一部を開いて保存する場合、開いている部分以外に不正な文字が存在していても、そこは変換無しで保存するため、ファイルの保存前後でバイナリに違いが発生しないことになります。
前回羅列された文字はどこから抽出されたものでしょうか? 小さなファイルからでしょうか? 巨大ファイルからでしょうか? どのファイルから抽出された文字の一覧もわかると何か手がかりが得られるかと思います。
もしファイルを共有していただけないのでしたら、お手数ですが、前回も書いたように、Version 9 の最新版 (現在は alpha 33) を、 http://jp.emeditor.com/modules/newbb/viewforum.php?forum=12 からダウンロードしてお試しいただけますでしょうか? その方法で、確実に問題の文字を特定することができます。どうぞよろしくお願いいたします。
Yutaka Emura
KeymasterFujiiさんは書きました:
現象が起きているのはUTF-16ではなく、US-ASCIIやシフトJISのファイルでした。あと、考えられるのは、フォントの問題で、プロポーショナル フォントを使用すると、文字によっては文字間が一定ではなく見えることがあります。
また、設定のプロパティの [表示] タブで、[文字間] で 0 より大きな数字が入っていると、文字間が空いて表示されます。ご確認いただけますでしょうか?
Yutaka Emura
KeymasterAye Wongさんは書きました:
http://www.post.japanpost.jp/zipcode/dl/kogaki/lzh/26kyouto.lzhこちらのcsvをcsvモードで開いてみましたが、正しく列がそろえられていないようです。ご確認ください。
こちらでは問題が再現できませんでした。Textの設定のプロパティの [ファイル] タブで、[CSV の検出] がチェックされているか確認していただけますでしょうか?
Yutaka Emura
Keymasterobottさんは書きました:
>obott さんとの結果と異なるのですが、こちらのテストでは、変換前と変換後の2つのファイルをバイナリで比較すると上の4つの文字が異なっていました。しょうがないので、、
時間をかけてなぜこちらでの結果とそちらでの結果が違うのか確認してみました。全ての問題の文字コードが存在する小さいファイルを作ってみました。
サイズ 387,344バイト
と
サイズ 1,673,682,382バイト
(サイズは適当です、このサイズだから異常が起きるとかの確認はしていません)の2つのファイルで確認してみたところ、、、
小さい方は元と変更後のファイルがバイナリで違いが有りました。
大きい方は元と変更後のファイルがバイナリで違いが有りませんでした。
この結果から、推測すると、、、
貴エディタは、ひょっとして巨大ファイルの変更点の記憶方法に
問題が有り、このような時に、実は変な文字コードによる変更は記憶していないので、、
上記結果の様になるのではないでしょうか?そのくせ。
ダイアログには
「指定したエンコードで変換できない文字が含まれています。
編集を続行して保存するとファイルの中身が破壊されます。」
と表示していると、、、思われますが、、いかがでしょう?
EmEditor に問題があるとは考えていません。
「ベータ版の不具合の報告」フォーラムに公開している Version 9 の最新版 (現在は alpha 33) では、問題が発生する文字に自動的にジャンプする機能が追加されていますので、そちらでお試しいただけますでしょうか?
どうぞよろしくお願いいたします。Yutaka Emura
Keymastermonoさんは書きました:
カスタマイズダイアログのショートカットタブ下部にあるボタンの文字が切れてしまっています。
Vistaでx64バージョンを利用しています。調節しておきます。ありがとうございます。
Yutaka Emura
KeymasterFujiiさんは書きました:
EmEditor Professional Version 8.05を使用しているのですが、時々文字と文字の間が空いて表示されます。アルファベット、日本語に関係なく半角スペースが入っているように見えます。一旦閉じて同じファイルを開きなおすと正しく表示されるので、再現させるのが難しいのですが、現象が起きるのはいつも複数のグループを表示させているときです。
もしかすると、UTF-16 (Unicode サイン無し) を Shift-JIS で開こうとしているのではないでしょうか? 開いた後、UTF-16LE で読み直してみてはいかがでしょうか?
Yutaka Emura
KeymasterHmmさんは書きました:
常駐機能にクリップボード履歴機能の追加をご検討ください。秀丸やQXエディターのQClipのような、単純なクリップボードの履歴機能です。
ショートカットキーで履歴を呼び出し、「選択と同時に貼り付け」が出来ると便利です。
実装の際はこの「選択と同時に貼り付け」が重要で、秀丸でも追加して頂いた機能です。これがないと、選択した後に、再度ペーストという操作が必要になります。拡張としましては、QClipのようにあらかじめ用意した文章を選択できても便利です。
EmEditor v9 alpha には、既に、クリップボード履歴の機能が付いています。スニペット プラグインがバックグラウンドで実行されている状態で、 Shift + F8 を押すか、General フォルダ内の Clipboard History を選択すると、クリップボードの履歴が表示され、選択すると貼り付けができます。
また、編集メニューの「クリップボード リングの回転」または既定では Ctrl + Shift + V を押し続けることにより、過去のクリップボード履歴にたどることができます。
- 作成者投稿