フォーラムの返信を作成しました。
- 投稿
現在の動作仕様である点については了解しました。
この仕様からすると、
検索した結果、カーソルが移動し、カーソル下のハイライト表示されている状態になりますが、カーソルを左に一つ移動して文字を入力するとハイライトが解除されている状態は、テキスト選択が解除されているとは言えず、文字入力後もう一つカーソルを移動すると見た目はカーソルが移動しただけですが、テキスト選択が解除されているという事なんですね。将来仕様を再検討されるとのことで、改められる事を望みます。
返事ありがとうございます。
検索したxyzにabcを付け足しabcxyzになる操作をする場合、xyzが選択されている状態から、一旦左にカーソル移動し、abcと入力します。
この一旦左に時点でカーソル移動し、abcのaを付け足した時点で、カーソル位置のxyzの選択状態は解除されます。選択状態が解除されているのにも関わらず、F3を押すとabcxyzのxyzが再び選択されるのは動作としておかしいのではないでしょうか。
10.0.4で同様の操作をしている筈ですが、その時には違和感を覚えなかったことから、10.0.5から発生しているものとして書き込んでいます。
なかなか気に入る代替品が見つからず・・・
秀丸エディタのライセンスも持っているのでそちらや他を利用・検討しつつも、マクロや正規表現も含めて今ひとつなものばかり。ところで私の仮想PC環境の使い方は、テストパターンに応じて環境を作ってしまうので一時的使用ではなく1～2年くらいは入れっぱなしになってしまいます。
もし現在のライセンスが、先日の会議で無料アップグレードを決定した影響によるものなのだとしたら、希望としてはライセンスを2種類もうけてほしいところです。
私は今回のアップグレードでは有償で構わないと思っていました。
ものを作る上や作った後の、制作者としての喜びはもちろんあるでしょうが、その対価は払ってしかるべきだと思っていますから。もちろん企業での使用を考えればインストール先に応じてライセンスを求めるという形も必要なのはわかります。
でもUSBメモリへのポータブル版インストールのライセンス方法を利用すれば、USBメモリにインストールして使いたいPCに挿して使い回す(仮想PCもUSBメモリを認識させれば1ライセンスで済ませられる)事ができます。
通常インストールとの違いは、同時使用の数と使うときにUSBメモリを挿す手間です。
同時使用の数は、いわばユーザー数の制限に繋がっていることになります。でも何かを作ることに集中しているときに、それ以外のことに気を取られる煩わしさは経験したくないですから、通常インストールして使用したい、けれどそうすると、その手間に私の場合は5万円以上の出費となる可能性を含んでいることになります。
流石に自腹で5万円は大きいです。
しかもほぼ同時使用はなく、精々偶に2つの私占有PC上での同時(平行)使用ですから、躊躇わざるを得ません。せめて物理PCに限定するか、2～3倍程度の割増料金でも構わないので、業務で使用しつつ「人」にライセンスを割り当てる手段を設けてほしいです。
え・・・
その答えは流石にないだろうと思っていたのですが。仮想PCは古いOSや言語違い、といったバリエーションを揃え気軽にテストできる事が私にとってのメリットです。
複数のエディタを使うと操作の差から、例えば検索のつもりが置換になったりといった危険があるため、一つに揃えたかったのですが、EmEditorに纏めるといったいいくらかかるのやら・・・。
今、仕事で使用している仮想環境は20あります。
これでエディタが使いたいとなれば、56700円ですか。申し訳ないのですが、以前から使用している1ライセンスで以て会社の一台のPCでのみ使用し、自宅も含めそれ以外では使用しないようにしますので、過去の複数使用は勘弁していただけませんか。
代替品を探してEmEditorの使用はやめる事にします。
コストパフォーマンスの点であまりにも悪すぎる結果になってしまいますから。わかりました。
先ほど銀行経由での購入手続きを申し込みました。ちなみに念のためにお聞きしますが、仮想PCも実PCと同じく見做すのでしょうか。
今のところ仮想PCでは使用していませんが、将来使いたいと思ったときの為に知っておきたいと思います。指摘有り難うございます。
shellviewではありませんが、確かにHKEY_CLASSES_ROOT*ShellEmEditorなどのキーを作成・登録しています。
またEmEditorがそれらキーの先頭ではあるのですが、少なくとも先週まではこういう症状が出ていなかったんです。ただHKEY_CLASSES_ROOT*Shellの(Default)エントリに「Open」と書くことで以前の状態に戻りましたので、少なくともこの*Shell関連のWindows内の状態が変化したのは間違いなさそうです。
お騒がせしました。
なるほど。
普通の人って「ー」と「－」を区別しないで使っている事が多いのでIE上やファイル検索の際に同一視するようにしてしまったんじゃないかと推測できますね。
ただMicrosoftに対しては文字集合を許容するAPIと許容しないAPIくらいは明確にして分けるかフラグを付けるかして欲しいところですけど。気になったので試してみました。
試したのは>例：
>1.用意する変換元文：「―ー―ー―ー―ー―ー―ー―ー―ー―ー―ー」
>2.「―」のみ「あ」へ”変換(A)”を10回実行：「あーあーあーあーあーあーあーあーあーあー」3.ここで無いはずの「―」を「ぅ」へ”すべて置換(A)”：「あぅあぅあぅあぅあぅあぅあぅあぅあぅあぅ」<-本来なら置換箇所は無いはずなのにこれです。
まずVista x64では現象を確認できませんでした。
それから普段雑多な目的で使用しているXP SP2(070227-2300, shlwapi.dll: 6.00.2900.3121(xpsp_sp2_qfe.070418-1302))
そしてVMware上でWindows Update(Microsoft Updateにまだ変更していない)の適用以外をしていないほぼクリーン
(何かをインストールする際にはsnapshot機能を使って分岐先でおこなっている) なXP SP2(070227-2300, shlwapi.dll: 6.00.2900.3157()内詳細メモ忘れ)
上で試してみましたが、こちらは両方とも再現しました。
他の方が書かれているように、「大文字と小文字を区別する」「正規表現を使用する」の何れかかまたは両方にチェックが入っていると正常です。
後者の環境は数ヶ月間使っていなかったため最新のパッチが適用されていませんでしたので、適用してみましたがshlwapi.dllが6.00.2900.3231
(xpsp_sp2_qfe.071010-1316)に上がったものの症状は変わりませんでした。>将来的には、もっとカスタマイズできるようにしたいと思います。
その際には是非行番号ありきではないようお願いします。
具体的には行番号指定ナシの場合、単にファイルを開いたのと同じ挙動をして欲しいのです。
つまり、以前開いた事があって行番号等を記憶していれば、そこへジャンプし、記憶していな
ければファイルの先頭を指した状態になる、というものです。過去に何度か、検索結果を加工しつつタグジャンプをしている際に、「XXXX(数字)」形式に加工
されてしまった箇所で意図せずタグジャンプが出来てしまって意図しない結果を招いたという事が
あったものですから、出来れば検索結果も
ファイル名:行番号:行内容
としていただけると、ファイル名の最後が「(数字)」な場合に勘違いした挙動をされなくて助かります。
宜しくお願いします。仕事が立て込んでいてアクセスする余裕が無く、返事がすっかり遅くなってしまいました。
>意味が分りました。それはEvalするとことで解決しませんか？。
解決しますね。
他のスレでもevalの話が出ていたし理解していたのにまったく思い浮かびませんでした。
教えていただいて有り難うございます。あとはキーボードマクロの編集を複数平行して行うと先に編集したものからマクロメニューの保存が無効になる件だけですね。
返事いただいて有り難うございます。
残念ながら変数でもって処理内容を少し変えるようなものではなくて、例えば複数の箇所でカーソルの移動量が違ったり、カレントのテキストから複数行の文字列を拾ってそれをその場その場の方法で加工したりといった内容なのでマクロ自体に修正が必要なケース用です。
ファイルメニューからの保存は一々マクロフォルダのパスを指定し直す必要があるので面倒です。
>幾つか細切れにキーボードマクロを実行して複数ファイルに開いています。それらをコピー&ペーストで1ファイルにまとめてから、出来上がったJSEEファイルを選択して実行しています。
これをもっと手軽に、例えば複数行を選択した状態で右クリックし、コンテキストメニューから「カレントマクロとして取り込み」とでもいうような項目を用意しておいて、それを選ぶだけでマクロとして実行可能になるような機能を要望しています。
一時的なマクロなど、例えば残しておきたいわけではないマクロを少し修正して実行、といった事をマクロファイルの保存を省いておこないたいのです。
emacsやVzエディタなどにあるコンソールバッファと同様の機能のようですね。
標準入出力ハンドルのduplicateとstreamin/outで出来ますが、コマンドの入力
と結果の取り込み、そして編集の関係からするとI/F的にはプラグインで入力し、
標準出力からの結果をドキュメントウインドウに吐き出す形で実現した方が良さそ
うな気がします。
であればプラグインを作るだけでバージョン6でも出来ますね。> 「マイドキュメント」がエクスプローラプラグインのデフォルトのパスになりますが、2回目以降の起動時には「マイコンピュータ」
> 下の移動先パスがツリーが展開された状態で表示されます。
>
>
>
>ご質問の意味がよくわからないのですが、エクスプローラ プラグインの初期表示のことでしょうか? もし可能ならスクリーンショットをメールでお送りください。よろしくお願いします。エクスプローラ プラグインの初期表示のことです。
EmEditor新規インストール後、最初の起動時には「マイ ドキュメント」にフォーカスが設定され、「マイ ドキュメント」「マイ コンピュータ」「マイ ネットワーク」「ゴミ箱」はツリーが展開されずに表示され、続いてデスクトップにあるショートカットが羅列されています。
この状態のままEmEditorを終了し、再度起動すると「マイ コンピュータ」のツリーが一段階分展開され、H:My Documents(私の環境ではマイドキュメントの移動先がH:My Documentsになっている)にフォーカスが設定された状態になっています。
つまり特殊フォルダを意識して処理していないため、例えば「ゴミ箱」や「マイ ネットワーク」にフォーカスが当たっていたとしても次の起動時には「マイ ドキュメント」を指してしまいます。
これが仕様なのであれば特に要望があるわけでもないので良いのですが、気になったので書いておきました。
ちなみに特殊フォルダではなく、リモートPCのフォルダにフォーカスが当たっていたとしても次の起動時にはローカルの「マイ ドキュメント」を指してしまいます。おおっ・・・
言われてみると、その通りですね。
勘違いして三つ目の引数を与えてもSyntax Errorにならなかったばかりかある程度動いてしまったので、すっかりバグだと思いこんでしまっていました。
有り難うございます。どの文字が、どの文字の後のどの文字が、といった規則性はないのですか?
あとメモ帳でのフォント指定とEmEditorでのフォント指定、OSのバージョンなども書かれた方がよいかと思います。全部英字でも文字化けが生じるのか、フォント指定を変えても文字化けが生じるのか、プリンタドライバのバージョンを変えるとどうなるのかなどkettlemさんのほうでしか確認できないことはいろいろとありますね。
EmuraSoftには当該複合機が恐らくないでしょうから、どちらかといえばプリンタドライバを作っている側に調査させた方が早いかと思います。
うちの環境ではシステムレジストリのサイズが51MB, ユーザーが14MBありますから、そのうちの1MB強だと特別大きいという印象はありません。
なんでもかんでも数点のファイルに収めてしまうWindowsのレジストリ構造には利用拡大が明確になったWin95登場当初から設計が悪いと感じていましたが、MSの設計方針でもありますから。
これをローカルのファイルに書き込むと、どのような構造にするかでメリットデメリットも含め変わりますが、例えば起動時間や終了時間が今より遅くなったり、設定確認等の利便性が下がったり、バグが入り込む余地が増える、発明の再発明という無駄が生じるなどのデメリットが起こりえます。レジストリに書き込むと、対象のアプリが稼働していない状態でもそのアプリ用のレジストリエントリがメモリ上に置かれますし、他のアプリのエントリのオープンなどの際も検索比較対象として処理に関わることもありますから、当該アプリ以外からしてみれば言われるとおりマイナスの要素しかありません。
個人的には基本的にすべてINIファイルに保存し、INIファイルをバイナリ化したキャッシュの活用や一々INIファイルを展開し直す無駄に遅いWindow APIを利用せずにSTL等を利用し高速にINIファイルを処理するよう実装して欲しいと思ってます。
MS謹製のアプリやCOMを多用するアプリならこれ以上にレジストリを占有するものは沢山ありますね。
正式リリースでどのようなインストール方法になるのかわかりませんが、現在ポータブル版を使用していて、これをアップデートする際にiniファイルをパッケージに付属しているもので上書きしないようアーカイバにてiniファイル以外を選択してD&Dで既存の試用環境に上書きしています。
これは秀丸エディタなど、世間の製品でも考慮されていないものが結構存在しますが、デフォルトの設定ファイルとユーザー設定のファイルを分けるという事をEmEditorでも是非お願いしたいところです。
デフォルト用サブディレクトリを用意し、そこにiniファイルやテンプレート等のデフォルト定義ファイルを入れておき、EmEditorのカレントにファイルが見つからないときにはデフォルト用フォルダを参照し、保存時はカレントにおこなうという形へと修正されることを強く望みます。
こうすることで動作が怪しくなった際もユーザー設定のiniファイルをリネームしたり別の場所に移動するだけでデフォルト状態の動作確認が出来ます。
現在ですとiniファイルを消しても動作しますが新規インストール直後とは状態が異なります。また設定ファイルのデフォルトが変更されたとしても、デフォルト設定のファイルがないと何が変更されたのかわかりませんし、設定を従来通りにしたいのか、新しい設定にしたいのかという選択を自分で行いたい場合もあります。
UIで以て変更するのは時にはとても面倒ですし、何が変更されたのかについての個々の確認はいわずもながです。
具体例を挙げれば、C/C++の規格が更新され追加されたキーワードがデフォルトのキーワード強調に反映されたとしても、インストール時にユーザー設定ファイルを書き換えないようにしているだけなら既存ユーザーはそれに気付くことさえ出来ません。
テンプレートも同じです。
訳あってデフォルトを変更した方が良いような状況になった場合、既存のようにデフォルトもユーザー書き換えも同じパスであるとインストール時には書き換えないという選択しかできません。
例えユーザーに問い合わせたとしても何がどう変わるのか具体的なところがわからないために消極的な選択しかできないことでしょう。>beta 2 から beta 3 への移行で、保存パスが、絶対パスから相対パスに変更されました。
[snip]
>このあたりですが、もう少し検討して beta 4 でまた仕様を変更するかもしれません。個人的には昔からある流儀のひとつ、下記の方法を提案します。
@:EmEditorMyMacro
@:UserNameMyMacro
@:MacroFolderWelcome.jsee
「@:」とコロンを含んでいて既存パスとしては存在しませんので続く「EmEditor」や「UserName」に独自解釈のみを適用することに何ら不都合はないはずです。
これはEmEditorの内部環境変数指定(OSの環境変数とは直接関係なく独立したもの)という思考です。
それから
~:Program FilesEmEditor
「~:」と記述することでドライブレターのリロケータブル指定と解釈しEmEditor自身が置かれているUSBメモリのドライブレターに置き換える仕組みとします。このような方法なら既存のパス指定と記述でぶつかることはありませんし、今回のUSBメモリ対応と従来通りの絶対パス指定との併存が出来ると思います。
またマクロでのパス指定にも利用できると利便性の向上に繋がると思います。portable版を試用しています。
v6でも同じ現象ですが、ここに書き込ませてください。v6では気付かず、v7をインストールして単にEmEditorを起動し直したところ、表示内容が変化したことで気付いた小さな事です。
これは恐らくMy Documentsの場所を「%System Drive%/Documents and Settings/%UserName%/My Documents」
以外の場所に移動している場合だけの挙動かと思われますが、v7をインストールした直後、EmEditorを起動すると
「マイドキュメント」がエクスプローラプラグインのデフォルトのパスになりますが、2回目以降の起動時には「マイコンピュータ」
下の移動先パスがツリーが展開された状態で表示されます。「マイドキュメント」にカーソルキーでもってフォーカスを移し直し、EmEditorを起動し直しても同じでした。
