V8.90β3No.10015
秀丸担当 さん 19/10/24 09:54
 

V8.90β3を公開しました。

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
https://hide.maruo.co.jp/software/hidemaru.html

32bit版:
https://hide.maruo.co.jp/software/bin3/hm890b3_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hm890b3_x64_signed.exe

[ ]
RE:10015 V8.90β3 フィードバックNo.10016
ohtorii さん 19/10/25 20:15
 
お疲れさまです。
ご対応ありがとうございます。

私がお送りした分に関してフィードバックをお送りします。



> loadhilightを実行した後に、ステータスバーの「ファイルタイプ別の設定の状
>態」に「(一時)」が付かない問題修正。

修正を確認しました。



> 自動スペルチェックが働くタイミングでclosehidemaruforcedで閉じるとdumpを出
>力している場合があった問題の対策。

クラッシュを引き起こすすマクロを10回試してクラッシュしないことを確認しました。



> DLL側から秀丸エディタの関数呼び出しに、Hidemaru_AnalyzeEncoding関数追加。

*APIの定義について
(現)int WINAPI Hidemaru_AnalyzeEncoding( WCHAR* pwszFileName, DWORD_PTR lP
aram1, DWORD_PTR lParam2 );
(望)int WINAPI Hidemaru_AnalyzeEncoding( const WCHAR* pwszFileName, DWORD_
PTR lParam1, DWORD_PTR lParam2 );

pwszFileNameが差す文字列を書き換えないことを明示した方が良いと思いました。
(最悪、ドキュメント補足でも良いと思います。)


*返値について
「存在しないファイル、読み込み禁止で共有されているファイル」を指定したときの
返値は?
→全ビット1が立っている(-1)とかですかね?


*マルチスレッドについて
メインスレッド以外から呼び出して正しいencodeを取得できていますが、
そもそも安全でしょうか?

「目次− DLL側から秀丸エディタの関数呼び出し」には、
関数の呼び出しは、メインスレッドと同じスレッドから呼び出す必要があります

とありますし・・・

秀丸マクロの処理を高速動作させる目的でC++プラグインを作成しているのでスレッ
ド安全がベストです。

よろしくお願いいたします。

[ ]
RE:10016 V8.90β3 フィードバック(追記No.10017
ohtorii さん 19/10/26 07:55
 
追記です。

> DLL側から秀丸エディタの関数呼び出しに、Hidemaru_AnalyzeEncoding関数追加。

更にHidemaru_AnalyzeEncodingを使ったのでその感想です。


ファイル読み込み処理(※)は利用者に任せて、
秀丸エディタ側は文字コード判別に集中してもいいかもしれません。

(関数の例)
int WINAPI Hidemaru_AnalyzeEncoding( const CHAR* buffer, DWORD_PTR byte_size );



(※)ファイル読み込み処理
ファイルの読み込みにも色々あるので、
 ・ファイルサーバ(\\server\hoge.txt とか)
 ・WEBから(https://...)
 ・同期、非同期
バッファを受け取る関数の方が筋が良いと思いました。


よろしくお願いいたします。

[ ]
RE:10017 V8.90β3 フィードバック(追記No.10018
秀丸担当 さん 19/10/28 10:18
 

いろいろご確認ありがとうございます。
Hidemaru_AnalyzeEncodingはconstを書いておきます。
存在しないファイルのときは、intでマイナス値を返すようにしています。
最上位ビットが1で、もしかしたらエラーの意味でマイナスの値を変えるかもしれな
いです。
今は-1だけです。
grepでマルチスレッドで呼ばれることを想定しているので、スレッドセーフです。ヘ
ルプにも書いておきます。
ファイル名ではなくメモリにするといい場面もあると思いますが、従来からある処理
をだいぶん変えないといけないので、けっこう複雑な割には実績が無いような処理に
なってしまうかもしれないです。基本的にはファイル名で、lParam1とかで将来の選
択の余地を残しておこうと思います。


[ ]
RE:10018 V8.90β3 フィードバック(追記No.10019
ohtorii さん 19/10/28 19:54
 
お疲れさまです。

こちらこそ、いろいろとありがとうございました!!

メモリ版は将来でかまいません、
ドキュメントへの補足をお願いいたします。

[ ]
RE:10015 V8.90β3 すべての候補を一覧表No.10020
ohtorii さん 19/10/28 20:39
 
お疲れ様です。
ベータ版で発生した現象なのでこちらのスレッドに投稿します。


「すべて検索 - 一覧表示」のウインドウでフォントが2重表示される文字があります。
ご確認をお願いいたします。


(再現手順)
・dict.txt(後述を参照してください)を開きます。
・「メニュ→検索→すべての候補を一覧表示」を選択します。
・検索文字列にTexasと入力します。



(状況)
・私の環境では必ず再現します。
・フォントの種類をいくつか変えてみましたが(MSゴシックなどへ)同じ現象が発生
します。



(ファイル)
https://github.com/ohtorii/test/tree/master/20191028

アップしたファイル
 dict.txt
 readme.png



よろしくお願いいたします。

[ ]
RE:10020 V8.90β3 すべての候補を一覧表No.10021
秀丸担当 さん 19/10/29 09:43
 

バグ情報ありがとうございます。
[その他]→[動作環境]→[環境]→[高度な環境]で、ダイアログのフォントをMeiryo U
Iにすると再現することがわかりました。
なぜかExtTextOutで全角と一緒に描画するとカーニングが働くようで、その動作は謎
ですが、別の描画方法だといいようなので、問題無いほうに修正させていただきます。

[ ]
RE:10015 V8.90β3No.10022
あべのり さん 19/10/29 12:48
 
replayが正しい値にならないことが起こりました.以下のマクロを連続実行してもre
playが1になりません.

if(replay)message "replay!";
searchdown "a";

環境は秀丸8.90β3 32bit,Windows 10です.

[ ]
RE:10022 V8.90β3No.10023
秀丸担当 さん 19/10/29 14:32
 

確かにその通りでした。
V8.89β5での問題でした。
次のβ版で従来通りとなるように修正させていただきます。

[ ]
RE:10018 V8.90β3 フィードバック(追記No.10024
vscode-life さん 19/10/31 00:29
 
こちら、中身が確認できていなくて申しわけないのですが、
返ってくる値が、秀丸マクロのいうところの encode と同じ値だとすると、

(秀丸マクロでいう) codepage に変換した値も得られるようにしておいたほうがよ
いのではないでしょうか。

Windows系でVisualStudioにてよく使われる言語なら、秀丸のencode値以上に codepa
ge 値の方が便利にとりまわせますし。

ご検討ください。

[ ]
RE:10024 V8.90β3 フィードバック(追記No.10026
秀丸担当 さん 19/10/31 12:47
 

いずれencode相当の値を使って、Hidemaru_LoadFile( ..., nEncode );みたいな関数
で読み込みもできたらいいと考えていますが、現状無いです。
自前で変換するとしたらコードページの値があったらいいと思います。
決め打ちで変換してもらってもいいです。
encodeとcodepageの対応関係は以下のようになっています。
ヘルプに書いておこうと思います。

Shift-JIS encode=1 codepage=932
Unicode encode=2 codepage=1200
EUC encode=3 codepage=51932
JIS encode=4 codepage=50221
UTF-7 encode=5 codepage=65000
UTF-8 encode=6 codepage=65001
Unicode (Big-Endian) encode=7 codepage=1201
欧文 encode=8 codepage=1252
簡体字中国語 encode=9 codepage=936
繁体字中国語 encode=10 codepage=950
韓国語 encode=11 codepage=949
韓国語(Johab) encode=12 codepage=1361
中央ヨーロッパ言語 encode=13 codepage=1250
バルト語 encode=14 codepage=1257
ギリシャ語 encode=15 codepage=1253
キリル言語 encode=16 codepage=1251
シンボル encode=17 codepage=42
トルコ語 encode=18 codepage=1254
ヘブライ語 encode=19 codepage=1255
アラビア語 encode=20 codepage=1256
タイ語 encode=21 codepage=874
ベトナム語 encode=22 codepage=1258
Macintosh encode=23 codepage=0
OEM/DOS encode=24 codepage=0
その他 encode=25 codepage=0
UTF-32 encode=27 codepage=1200
UTF-32 (Big-Endian) encode=28 codepage=1201

Macintosh, OEM/DOS, その他というのは、Windows3.x時代からフォントの文字セット
としてあるので選択があるだけで、TranslateCharsetInfoによる文字セットからコー
ドページへの変換値で0になるみたいです。MultiByteToWideCharとかで変換する場合
はCP_MACCP(=2)とかCP_OEMCP(=1)なのかもしれないです。
UTF-32は、本当は12000, 12001らしいですが、Windowsはサポートしていないという
ことだったので、UTF-16と同じ値にしています。
今後12000, 12001に変更するかもしれません。

コードページもそうですが、メモリ上のデータや、解析方法など追加するとしたらlP
aram1とかlParam2とか使って将来的な余地としておこうと思います。


[ ]
RE:10026 V8.90β3 フィードバック(追記No.10029
秀丸担当 さん 19/11/01 12:41
 

encodeの値を使って読み込むのは、Hidemaru_GetTotalTextUnicodeにならって、Hide
maru_LoadFileUnicodeとして作ろうと思います。
全体を1つのHGLOBALで返すだけのもので、Hidemaru_GetTotalTextUnicode同様にで
きるだけ簡単にしようと思います。

元の話題のスレッド:
https://www.maruo.co.jp/hidesoft/4/x09090_.html
ファイルの断片を読み込むバージョンの関数は、やめておこうと思います。
やるとしても、先頭から連続したデータでないといけないので、呼ぶ側はどのみちそ
こそこ凝ったことをしないといけないので、現状でコードページを得てから変換しな
がら読み込むのと大差ないことになると思います。

[ ]