berryzplus
berryzplus
@beru さん > プロポーショナルフォント対応のニーズってどこにあるのか自分は理解していません…。対応するにしても等幅フォント使用時の操作性を損ねてしまうと困るなぁと思います。逆もまた然りなんでしょうけど。 経緯はよく分っていません。 文字を綺麗に表示したい要求から来たものと思っていますが、もしかしたら「使えないフォントがある」への対策なのかも知れません。単に「使えないフォント」への対策だとすれば、variadicに描画する必要はないので、「文字を綺麗に表示したかった」の方がよりしっくり来る予想です。 では、文字を綺麗に見せるためには可変ピッチにしないとダメなのか？ということですが・・・。 「日本語」を主眼においた場合「そうでもないんじゃね？」と思っています。 「英語」を主眼においた場合、可変ピッチで単語間を離したほうが読みやすいと思います。 「コード」を主眼においた場合、可変ピッチで描画されたらちゃぶ台返ししたくなります。 さて、ここからどうするか・・・。
> > 「ルーラー」(非表示にできない) > > 嘘ですよ。そんな使い道のないものに自分がスペースを与えることはありません。 え、どうやって？ 共通設定⇒ウインドウ⇒ルーラーの高さを0にすると、表示されなくなる・・・ と見せかけてルーラーの高さが2pxに制限されるようになるっぽいです。 利用バージョンはこれ。 > サクラエディタ Ver. 2.3.2.0 > (GitHash 3cea1c325490604087a6bf08bd55fa622535e35a) なんか壊してるかしら・・・
ご提案ありがとうございます。 導入できるか検討していきたいと思います。 当座「正規表現」が意味する仕様を、例示から読み取れなかったので反応を躊躇っていた感じです。 設定項目 | 指定値 | 解釈(PCRE正規表現) -- | -- | -- szLineComment | `//` | `m!^[\t ]*(//).*$!` szLineComment2 | `/#\|＃/` | `m!^[\t ]*(#\|＃).*$!` szLineComment3 | `※` | `m!^[\t...
issue立てありがとうございます。 > ※以降、目的 -> 手段(目的2) -> 手段2(目的3) -> のように階層が深くなり、記述の重複が発生することをご容赦ください ぶっちゃけると、書きづらければ書きやすいように組み立てて頂いて大丈夫です。 プロジェクト側としても「どうしたら分かりやすく提案できるか」を手探りしている過程です。 要望内容は タグジャンプコマンドの操作結果が欲しい。 ですよね。 なんで操作結果が欲しいか？って、 タグジャンプに失敗しても「それっぽく動く」ようにカスタムしたい。 ということなわけです。 で、可能かどうかというと、おそらく可能だと思います。 根拠はこの関数のシグニチャです。 https://github.com/sakura-editor/sakura/blob/8588683cbc79d395c17002f9c570898c8510d3cb/sakura_core/cmd/CViewCommander_TagJump.cpp#L74 戻り値boolで宣言されていますし既存コードに利用箇所もありますから、ほぼそのまま使えるでしょう。 ここまで来たらほぼ実装できるじゃないですか！と思ったんですが、 サクラエディタ特有の文化に引っ掛かってしまったようで・・・。 > m_MacroFuncInfoCommandArr に定義されているものは、いずれも戻り値が VT_EMPTY です。 > 設計思想としてそこをみだりに変更できない、という可能性があるのか、...
実装で言うとこの辺ですな。 https://github.com/sakura-editor/sakura/blob/a950d23b435a87b3a2cbe79048ed2d48e01152b1/sakura_core/view/CTextDrawer.cpp#L453-L459 たぶんですが、ここ削ったらうまく動くんじゃね？という雰囲気です。 これは、まったく検証しとらん無責任発言なので鵜呑みにしないでくださいね:smile:
どうなんでしょう。 上記実装の存在理由は、行情報が未生成の場合におかしなことにならないための対策と考えられます。でも、elseパートの行情報取得のところを見ると「行情報がないケース」への対策が入っています。 https://github.com/sakura-editor/sakura/blob/a950d23b435a87b3a2cbe79048ed2d48e01152b1/sakura_core/view/CTextDrawer.cpp#L488-L492 削ったらうまいこと動くんじゃね？の根拠はこのへんでした。 （対策入ってるから大丈夫じゃないかなぁ、という期待ｗ）
ああ、ダメかｗ うまいことは動かなそう（`" "`になる）
このissueに関連して気付いたことがあります。 https://github.com/sakura-editor/sakura/blob/b2178a2e9710774b5383b96e451d22541c2e1934/sakura_core/env/CShareData.cpp#L736-L743 738行目、739行目がこのissueの議題です。 見たら分かると思いますが、書き込みした後に「有効性チェック」っぽいことをしています。
大変難しい話題なので放置していました。 「問題内容」に対して「ん？」と思った点が3つありました。 > マクロ引数のうち文字列型を扱うものの一部で、ファイルパスなど内部仕様による制限が存在しているにもかかわらず、一切チェックされずバッファがコピーされたり強制終了したりする現状の動作を改善したいです。 1. `マクロ引数のうち文字列型を扱うもの` BSTR型のマクロ引数は、「文字列」か「バッファ」のどちらかを想定している認識です。 `C/C++`での「文字列」とは `NULで終端される「文字」のシーケンス` です。 「バッファ」とはメモリー上のアドレス範囲を指す用語です。 サクラエディタはバイナリファイルを編集できることになってるので、`InsText`などのドキュメントデータ挿入系関数には「バッファ」が渡される構えがあったほうが良いと思います。 2. `ファイルパスなど内部仕様による制限が存在している` 内部仕様には「意図的に仕様化してあるもの」と「既存実装を追認したもの」がある認識です。 ファイルパスの260文字制約は後者で、[CreateFileA](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)がMAX_PATHを超えるパスを扱えないことに起因した制約です。 issueの雰囲気から「内部仕様に合わせてチェック入れようぜ！」が結論に見えるんですが、「内部仕様＝正しい」ではなさそうなので入れようとするチェックによっては「ん？」になる気がします。 3. `一切チェックされずバッファがコピーされたり強制終了したりする` `チェックしてエラーになったらどうするか？`を決める（＝レビュアーに理解してもらう）のが大変そうです。 `どうするか？`の選択肢を2つ以上思いつかないので、決められないんじゃないかと思います。 選択肢＝コピーする前にメッセージボックスを出して中断し、関数呼出を失敗させる。 意図的に放置していたわけですが、3週間誰も反応してないことが対応の難しさを物語っている気がします。
Draftのままですが、残課題とかありましたっけ？