usagisita

WikipediaやRFCなどを見ても、シングルクォート自体は、ローカルパート(ユーザー名)のところに直書きしていい文字として指定されているので、これはちょっと複雑な問題だと思います。 RFC原理主義、定義を尊重するとするなら、当然セパレータではなくちゃんと認識されるべきです。 日和見主義というか現実主義をもって、シングルクォートはセパレータとみなすように変更するというなら、それでもいいかと。 そういえば、ワークアラウンドとして、正規表現でURLを指定するとメールアドレスもカスタマイズ対象だみたいな、コメントをしたような記憶があります。 下のリストをこのissueeの表示と同じような感じにしたいだけなら、ローカルパートの許容文字リストwcschr？からシングルクォートを外せばいいんじゃないでしょうか。 秀丸もシングルクォートはローカルパートとは認識しないようです。 もしシングルクォートを人間みたいに処理したいなら、例えば、下記のリストのうち、どれをどう処理すべきか、色々と考える必要があるんじゃないでしょうか。 [email protected] Lets'[email protected] Lets'[email protected]'宛先' "Lets'go"@example.com "Lets'[email protected]" 'Lets'[email protected]'

少なくとも、英語版リソースのほうで、WS_THICKFRAMEの対応が漏れてる気がします。

「sakura(デバッグ版)」になるのは、`_GSTR_APPNAME_`ですね。 `_APP_NAME(_T)`　は `_T("sakura")` で固定でデバッグ版でも同じです。 ただし、 2018年12月 ad01d9dc 「fixes #709: GSTR_APPNAME の実体をグローバル変数に変える」 でマクロ定義が sakura_core/config/app_constants.h から sakura_core\_main\WinMain.cpp に移動しており、これ以降`_APP_NAME`マクロがCProcess.cppのコンパイル時には見つからないためにクラッシュダンプがコンパイルエラーになります。 クラッシュダンプは2013年4月の 07cf7fbb の時点ではデフォルトで無効です。 2015年5月 d627eb2a patchunicode#2268 r4023 でリリースビルドでも有効化されていますが 2015年9月 9ca9366e patchunicode#2268(同上) r4036 でmingwでのヘッダ定義不足のためにifdefが定義されてmingwを除外しようとしています(が少しおかしいようです)...

ちょっと調べて見ました。 https://sakura-editor.github.io/bbslog/sf/ansi/1743.html げんた氏とberryzplusさんの「物理行＝論理行＝ロジック行」というのは誤解でしょう。 でもやざき氏の発言の「論理行」と「レイアウト行」で統一というのはソース履歴を見ると反映されていない気がします。 ので、このコメントを鵜呑みにしては危ういです。 https://sourceforge.net/p/sakura-editor/code/2322/tree/sakura/trunk/sakura_core/CLayoutMgr.h#l128 https://sourceforge.net/p/sakura-editor/code/HEAD/tree/sakura/trunk/sakura_core/CEditWnd.h#l207 古いサクラエディタでは`CaretPos_Phys2Log`、`CaretPos_Log2Phys`とCEditWndに`SavePhysPosOfAllView`、`RestorePhysPosOfAllView`関数があり Phys=フィジカル=物理行=レイアウト行=CLayout=折り返し単位 Log=ロジカル=論理行=ロジック行=CDocLine=改行単位 という風に建前上はなっているようです。 ただ非常にややこしいのは事実でありPhysは変更されて`LayoutToLogic`などに改名されています。 現在のソースコードのコメントは、さっと見た感じ物理行はどちらの意味でも混在していて、正しく使われていない場所がたくさんある、みたいです。 ヘルプ上の記述もどれだけ正しいかは、神のみぞ知るって感じでしょう。

クラッシュの検証をしたのは数か月前以上だったので、最近の修正で最新masterでは_TRUNCATEになっている、という可能性は大いにあります。 前から_TRUNCATEでしたっけ？ _TRUNCATEになるならなるで、出力内容がちょん切れて正しくなくて、実行時に問題になるはず可能性が高いので、直さなきゃならないという点では、一緒ではあります。 その辺も含めて、ご考慮よろしくおねがいします。

ファイルツリーからファイルツリー設定を開いた後に閉じてファイルツリーも閉じるとエディタじゃないウィンドウに切り替わる #708

ソースコード上のコメントの表記については態度保留です。 一点「ヘッダー」「フォルダー」など長音が付加される場合について、ダイアログ上の表示を修正することがあったら見切れてしまわないかの確認だけは、したほうがいいかな、と思います。 修正の際には考慮していただきたく、よろしくお願いします。 欲をいえば可能であればDPIが120%のとき限定で見切れることもあるため、注意してほしいです。

>長音記号が増減（特に付加）する場合は UI が崩れないかの確認が必要になります。 一応、名誉のために書いておきますが、最初から提案者のRukotoさんがこのように書いてあるので、既出でした。すみません、見逃してました。

腹案があります。 サクラエディタのCookieについて某所で記事を書いたので思いついたのですが、 Cookieに新しいスコープを導入して、Cookieに結果を書き込んでおけば、 ```JavaScript Editor.TagJump(): var jump_result = Editor.GetCookieDefault('sysytem', 'LastResult', '-1'); if(jump_result == '1'){ // Jump成功 }else{ // Jump失敗 } ``` みたいに手軽に実装できるんじゃないかな、と思った次第です。どうでしょう？ errorlevelみたいな感じで。 Functionをプロシージャにしてしまうと、VBScriptの書き方によっては、既存のマクロがエラーになってしまうような気がしています。 デメリットは、クッキーは文字列型なので、結果の0や1だけもしくは-1とかも、文字列になってしまいます。 あとは10万回とかループする場合には、文字列の解釈とコピーでちょっと遅いかもしれないです。

文字列を引数に取る関数 対策が必要そうな関数の一覧暫定版 FileOpen BSTR I4 I4 BSTR FileSaveAsDialog BSTR I4 I4 FileSaveAs BSTR I4 I4 PutFile BSTR I4 I4 InsFile BSTR I4 I4 Diff BSTR I4 ExecExternalMacro BSTR BSTR ExecCommand...