プロポーショナルフォントのBOX選択範囲を - 秀丸エディタβ版 - スレッド07706, 2013/01/29

プロポーショナルフォントのBOX選択範囲を

IKKI さん　13/01/29 18:15

こんにちは。IKKI です。
皆さんのお知恵を貸してください。

BOX選択範囲の各行に対して何かする (例: カラーマーカーで着色する) マクロを作
ろうと思ったのですが、
プロポーショナルフォントの場合、BOX範囲に含まれる行それぞれの選択開始／終了
カーソル位置を取得する方法はあるでしょうか。
文字列が欲しいならクリップボードにコピーすればいいですが、座標が欲しいときは??

左上から右下へBOX選択したときに左下の x 座標が、
右下から左上へBOX選択したときに右上の x 座標が、
それぞれ取得できないので、手詰まっています。
これらが取れれば、あとは xpixel を見ながら境界を探っていけば何とかなると思う
のですが…。

秀丸エディタ v8.30β20 + HMJRE.DLL v3.50

RE:07706 プロポーショナルフォントのBOX

IKKI さん　13/01/29 18:29

すみません、自己解決しそうです。

プロポーショナルフォントのBOX選択は、カーソル位置と、その対角線上の頂点の座
標だけに依存しているようでした。
左下から右上へBOX選択した場合に selopenx で左下のx座標さえ取得できれば何とか
なりそうです。

RE:07706 プロポーショナルフォントのBOX

IKKI さん　13/01/30 01:29

自己レスです。
BOX選択範囲の各行に対して何かするサブルーチンができたっぽいので、貼り付けて
おきます。

プロポーショナルの場合は xpixel を頼りに二分探索してみましたが、これって横ス
クロールが発生するとダメですよね。(^^;
ウィンドウ左端に現在表示されている文字の x 座標が取れないので、やっぱり手詰
まりな感じです。

CSVの選択カラムの各値をゴニョゴニョするようなマクロを作りたい場合もあると思
うんだけど、どうすればいいんだろう…。

秀丸エディタ v8.30β20 + HMJRE.DLL v3.50

RectSelected:
if (!freecursor) {
freecursorswitch;
##freecursorswitched = true;
}
##ax = selopenx;
##ay = selopeny;
##bx = seltopx;
##by = seltopy;
##dx = selendx;
##dy = selendy;
##cxp = xpixel;
escape;
moveto ##ax, ##ay;
##axp = xpixel;
moveto ##ax, ##dy;
while (true) {
call MovetoX ##dx, ##axp, true;
beginsel;
call MovetoX ##bx, ##cxp, false;
endsel;
colormarker 0x000000, 0x00FFFF, 11, 2; // 何かする
escape;
if (y <= ##by) break;
moveto #ax, y - 1;
}
if (##freecursorswitched) freecursorswitch;
return;

MovetoX: // 横移動
// ##1 = x (等幅)
// ##2 = xpixel (プロポーショナル/CSV/TSV) 左寄せ
// ##3 = false:左寄せ, true:右寄せ (等幅)
if (fontmode & 0x1 == 0) {
moveto ##1, y;
if (x < ##1 && ##3) {
if (unicode != 0x0D) right;
}
} else {
##left = 0; // 横スクロールを考えるとウィンドウ左端の x 座標であるべき
##right = windowwidth;
while (true) {
if (xpixel < ##2) ##left = x;
else if (xpixel > ##2) ##right = x;
else break;
moveto (##left + ##right) / 2, y;
if (x == ##left) break;
}
}
return;

RE:07712 プロポーショナルフォントのBOX

秀丸担当 さん　13/01/30 13:31

言われている通り、現状のキーワードなどでやるには無理があるように思います。
何らかの新しいキーワードや関数があったらいいと思います。

とりあえず横スクロールを含む xpixel2 のようなキーワードと、二分法で探す
のも何なので #x=pixeltox(...)のような関数があったらいいと思いますがどう
でしょう。
（やってみないとうまくいくかわからないので１つの案として）

RE:07715 プロポーショナルフォントのBOX

K'zawa さん　13/01/30 15:31

秀丸担当さん、こんにちは。
K'zawaです。

> #x=pixeltox(...)のような関数があったらいいと思いますがどうでしょう。
>（やってみないとうまくいくかわからないので１つの案として）

CSV/TSVモードなどで、タブストップ幅が文字列幅より狭くて、文字列が重なっ
ているとき、ピクセル値にたいして複数の文字があることになる、という話が
以前まるお氏との間でありました。今回とは目的が違ったのでそれっきりになり
ました、参考まで。

RE:07716 プロポーショナルフォントのBOX

IKKI さん　13/01/31 12:56

秀丸担当さん、こんにちは。
ご返信ありがとうございます。

> とりあえず横スクロールを含む xpixel2 のようなキーワードと、二分法で探す
> のも何なので #x=pixeltox(...)のような関数があったらいいと思いますが
この件はもうちょっと考える必要がありそうです。

K'zawa さんのおっしゃる問題もありますし、そもそも、「選択範囲の文字位置が知
りたい」という欲求に対して「ピクセルから文字位置を計算できるようにします」と
いうのは、アプローチとしてあまりに迂遠な感じがします。
もし関数を追加するなら、もっと直接的なアプローチを取った方が、みんなが幸せに
なれるのではないかと…。

というわけで、以下私案です:
…と書こうと思ったのですが、ちょっと時間が取れませんで、あとでまた書きたいと
思います。
要点としては、
　・選択範囲を構造体のように扱って、保管／復元／取得／変更ができる関数群を整備
　・その一環として、BOX範囲の各部分を順次取得するイテレータを作る
という妄想です。

RE:07720 プロポーショナルフォントのBOX

秀丸担当 さん　13/01/31 16:27

>要点としては、
>　・選択範囲を構造体のように扱って、保管／復元／取得／変更ができる関数群を整
>備
>　・その一環として、BOX範囲の各部分を順次取得するイテレータを作る
>という妄想です。

構造体のように、となると、いわゆるオブジェクトのような感じになると思いま
すが、秀丸マクロの考え方そのものを見直すということになってきてしまうかと
思います。
秀丸ファイラーClassicでやっているようにvbs/jsで書けるようにすると楽かも
しれませんが、いままでのマクロを捨てるわけにもいかないので両方サポートと
いうのは難しそうです。

現状の文法のままで上記の要点をできるようにしたとして、今回の色付けをしよ
うとする場合、色付けのための範囲選択するとBOX選択は解除されるので、選択
オブジェクト(?)をどこかに保管してやる必要があると思います。
その際、選択オブジェクトの情報は全行のテキスト位置や内容を記憶すると複雑
で効率も悪いので、単純にピクセル位置を覚えておくだけになるかと思います。

すると、ピクセル位置から文字の位置を取得する、という関数が必要になってく
ると思いますが、そうなると、当初の案とあまり変わらない気がします。
何か勘違いしていたらすみません。

RE:07722 プロポーショナルフォントのBOX

IKKI さん　13/02/04 00:08

秀丸担当さん、ありがとうございます。返信が遅くなり失礼しました。

実装上の苦労はいったん脇に置いて、ユーザー (マクロ作者) の視点から言うと、
「選択範囲を扱うにあたり、ユーザーにピクセル位置を意識させるべきではない」
ということが要点です。
というか、CSV/TSVモードで列幅を縮めた場合を考えると、ユーザーにピクセル位置
からテキスト位置を取得させるアプローチは無理なのでは…?

等幅モードとプロポーショナル/CSV/TSVモードにそれぞれBOX選択と通常選択があり、
座標とテキストの関係も昔のように単純ではなくなってきていますから、ここらでひ
とつ、選択範囲を統一的に扱える簡単な方法を作ってもいいと思います。

というわけで、以下私案です。

●マクロ例

// 範囲を扱う
#region = selection(); // 選択部分を範囲として取得
#region = region(#x1, #y1, #x2, #y2); // 座標から範囲を取得 ※1
select #region; // 範囲を選択

// BOX範囲を扱う
#box = selection(); // BOX選択部分をBOX範囲として取得
#i = count_subregion(#box); // BOX範囲に含まれる副範囲の個数を取得
while (#i > 0) {
#region = subregion(#box, #i); // BOX範囲に含まれる#i番目の副範囲を取得
select #region; // 副範囲を選択
#i = #i - 1;
}
#box = region(#x1, #y1, #x2, #y2, 1); // 座標からBOX範囲を取得
select #box; // BOX範囲を選択
clear_region #box; // BOX範囲記憶をクリア ※2

●関数と文

selection() 関数: 現在選択中の範囲を範囲オブジェクトとして返す。範囲オブジェ
クトには範囲形状 (通常/BOX/etc.) の情報も含まれる。

region() 関数: 座標を指定して範囲オブジェクトを返す。第5引数で範囲形状を指定
する (0=通常, 1=BOX, etc.)。

count_subregion() 関数: 範囲オブジェクトに含まれる副範囲の個数を返す (通常選
択なら0個、BOX選択なら行数、etc.)。

subregion(r, i) 関数: 範囲オブジェクト r に含まれる i 番目の副範囲を範囲オブ
ジェクトとして返す。

select 文: 範囲オブジェクトの範囲を選択する。範囲形状も再現される。

clear_region 文: 範囲オブジェクトを解放する。

> 現状の文法のままで上記の要点をできるようにしたとして、今回の色付けをしよ
> うとする場合、色付けのための範囲選択するとBOX選択は解除されるので、選択
> オブジェクト(?)をどこかに保管してやる必要があると思います。
はい。内部的に範囲オブジェクトを保持しておいて、そのポインタ?を数値として
ユーザーに返す、というのが第一案として順当だと思います。
ただ、この実装だと ※2 のようにユーザーの責任で記憶領域を解放しなきゃいけな
いわ、解放を忘れて ※1 のようなことをするとメモリリークが起きるわで、あまり
嬉しくないかもしれません。

そこで、オブジェクトの内容を適当な形にエンコードして、それを文字列としてユー
ザーに返す、というのが第二案として浮かんできます。
上記の例の #region, #box がそれぞれ $region, $box になって、clear_region が
要らなくなるイメージです。
この実装だと内部にオブジェクトを保管しておく必要がなく、現在の秀丸マクロの枠
組みにうまく収まりそうです。

> その際、選択オブジェクトの情報は全行のテキスト位置や内容を記憶すると複雑
> で効率も悪いので、単純にピクセル位置を覚えておくだけになるかと思います。
いえ。テキスト内容を記憶するかどうかはともかく、少なくとも全行のテキスト位置
は記憶せざるを得ないのではないでしょうか。
CSV/TSVモードで列幅を縮めた場合を考えると、ピクセル位置を覚えておくだけでは
情報が足りない気がします。

全行のテキスト位置を記憶するといっても、仮に1行あたり16バイト必要として、100
万行のテキストに対して16メガバイトですよね。「マクロ全体で 1MB」の制限に引っ
かかるのが問題でしょうか?
だとしたら、全行分の位置を記憶するのはあきらめて、選択範囲を画定するのに最低
限必要な情報を (内部的に都合のいい形で) オブジェクトに格納しておき、上記の例
の subregion() が呼び出されるたびに、格納されている情報からテキスト位置を再
計算する、という実装もアリだと思います。
「内部的に都合のいい形」というのは、桁位置でもピクセル位置でも列番号でも、選
択モードに応じて適切な形で記憶しておけばOK。
とにかく、内部的なゴタゴタをユーザーに見せないことが肝要です。

…というようなことを考えてみたのですが、いかがでしょうか?
ご検討いただければ幸いです。

RE:07723 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/04 16:08

詳しい解説ありがとうございます。
具体的な方法がよく理解できました。

まずCSVモードで切れるときはありますが、マクロでなくても普通にBOX選択する
ときでも同じだと思います。
ユーザーから見えないようにしてもどのみちピクセルから算出することになるの
で、CSVモードがピクセルを見せない理由というのは弱い気がします。

具体的な方法としては、位置情報だけの場合、編集を加えると使えない情報にな
ってしまうということが気になります。
せっかくオブジェクトを取得しても、編集が加わると意味を持たなくなり、範囲
のテキストを得ると期待とは違うテキストが得られてしまい、ブラックボックス
になっているとなぜ違うテキストが取得されたのか分からないことがあると思い
ます。

ピクセルだと単純で、理解もしやすい気がします。
編集を伴う場合は下から処理することがあると思いますが、選択オブジェクトの
場合、下から処理するという暗黙のルールみたいのが出てきて、ブラックボック
スの中を想像しながら作ることになると思いますが、ピクセル算出の場合は何が
起きているのかを理解しながら作ることができると思いますが、どうでしょうか。

RE:07726 プロポーショナルフォントのBOX

IKKI さん　13/02/04 18:45

秀丸担当さん、ありがとうございます。

> ユーザーから見えないようにしてもどのみちピクセルから算出することになるの
> で、CSVモードがピクセルを見せない理由というのは弱い気がします。
ん?　あれ?
えー、すみません、前提として現在の実装を確認させてください。

CSVモードで切れている (列同士が重なり合っている) 場合でも、列を選択してクリ
ップボードにコピーすると、ちゃんとその列の内容が全部 (隠れている部分も含め
て) コピーされますよね。
このとき、内部的には、範囲内の各行に対して
(1) 選択範囲からテキスト位置 (始終点の桁位置) を画定
(2) テキスト位置からテキスト内容を取得
(3) テキスト内容に改行を付けてクリップボードに追加
という処理をしているのだと思っていましたが、もしかして違ったでしょうか。
もし列同士が重なり合っていたら、外見上のピクセル位置からはテキスト位置を画定
できないはずなので、内部的に何か別の方法でテキスト位置を計算しているのではな
いでしょうか。

私が言っていることは、要するに
「(1)の位置情報をマクロで取れるようにしてほしい」
ということで終始一貫しているのですが、もしかして根本的に勘違いしていたら申し
訳ありません。

> 具体的な方法としては、位置情報だけの場合、編集を加えると使えない情報にな
> ってしまうということが気になります。
はい、私も気になります。
記憶容量と利便性のトレードオフで、落としどころを見つけるしかないですね。
たとえば…

(a) 範囲オブジェクトは位置情報に加えてテキスト内容を保持する。テキスト内容は
編集の影響を受けない。容量超過はユーザーの責任。

(b) 範囲オブジェクトは位置情報だけを保持する。編集の影響を受ける場合は位置情
報を自動的に補正する (カラーマーカーのように)。

(c) 範囲オブジェクトは位置情報だけを保持する。編集の影響は無視する。

…とか。ユーザーとしては(a)が一番うれしいですね。

# (b)相当の処理をマクロで作ったことがありますが、正直すごく面倒でした。
# http://hide.maruo.co.jp/lib/macro/altcom110.html
# こんな処理はもう二度と書きたくない (^^;

> せっかくオブジェクトを取得しても、編集が加わると意味を持たなくなり、範囲
> のテキストを得ると期待とは違うテキストが得られてしまい、
ピクセルでも編集を加えると使えなくなってしまうことは変わらないです。

> ブラックボックスになっているとなぜ違うテキストが取得されたのか分からない
> ことがあると思います。
「範囲オブジェクトはブラックボックスで、ピクセルはホワイトボックスだ」という
のは、多分に感覚的な話で、誰もがそのように理解しているとは限らず、理由として
は弱い気がします。
ヘルプに「範囲オブジェクトは位置情報を持っているだけなので、編集するとずれま
す」と書いておけば済む程度の話かなと思います。

> 編集を伴う場合は下から処理することがあると思いますが、選択オブジェクトの
> 場合、下から処理するという暗黙のルールみたいのが出てきて、ブラックボック
> スの中を想像しながら作ることになると思いますが、ピクセル算出の場合は何が
> 起きているのかを理解しながら作ることができると思いますが、どうでしょうか。
何が起きているのか理解しながら作るという点では、ピクセルでも範囲オブジェクト
でも、途中で範囲選択して message; すれば何が起きているのかを可視化できるし、
そうしながら作るのが普通であって、「範囲オブジェクトだとブラックボックスの中
を想像しながら作らざるを得ない」という話にはならないと思います。

#region = subregion(#box, #i);
select #region; // 副範囲を選択
$text = gettext(seltopx, seltopy, selendx, selendy, true);
message $text; // 何が起きているのか確認

範囲オブジェクト的な抽象化案を推しているのには、そんな細かい話よりももっと大
きな理由がありまして…。
将来、秀丸 v10 あたりで、Word のように飛び飛びに複数の範囲が選択できるように
なるのではないかと予想しています。(^^)
そのような、桁位置でもピクセル位置でも表現できないような範囲形状が登場したと
きに、またぞろ新しいキーワードが追加されて、マクロを改造して、…というのは、
想像するだにげんなりする光景です。

範囲オブジェクトの中に副範囲を含み、副範囲の中に孫範囲を含み、…という入れ子
構造を扱うことができるインターフェイスを整備しておけば、将来にわたって (たと
え内部実装が変化したとしても) マクロを大幅に改造することなく利便性を保つこと
ができると思われます。

選択範囲が始終点の桁位置とBOXフラグだけで表現できるならば、ユーザー側も単一
の方法で扱えるので内部的な値をそのまま見せてもらえれば十分ですが、
プロポーショナルか否か／BOX選択か否かによってユーザーが複数の方法を使い分け
なければならないとなると、これは直観ですが、何らかの抽象化を施すべきタイミン
グなのではないかと思います。

いかがでしょうか。

RE:07727 プロポーショナルフォントのBOX

IKKI さん　13/02/04 19:09

すみません、セルフツッコミです。

> 桁位置とBOXフラグだけで表現できるならば、ユーザー側も単一の方法で扱える
すでにBOXフラグの有無で場合分けが発生して、2つの方法を使い分けていますね。

内心ゲンナリしているけれど、2通りなら何とか頑張って場合分けを書ける範囲と思
います。
ここへさらにピクセルが登場するとなると、堪忍袋の強度が怪しくなってくるのでは
ないかと…。(^^;

RE:07728 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/05 13:03

>もし列同士が重なり合っていたら、外見上のピクセル位置からはテキスト位置を画定
>できないはずなので、内部的に何か別の方法でテキスト位置を計算しているのではな
>いでしょうか。

CSVモードにおけるカラム選択時の特殊な状態というのは確かに存在しますが、
テキスト位置算出ではピクセルから算出できます。
普通にマウスでクリックして移動先が不定ということにはならないので、重複し
ているところは目に見えているところが優先されていると思います。
カラム選択時でフリーカーソルでない場合は、必ずしも対応するselendx等があ
るとは限らないので、ピクセルはカラムの幅を元にして計算しています。

現状でプロポーショナルフォントかどうか、BOX選択かどうかということがある
のに、さらにピクセルも、ということになるのは確かに面倒だと思います。

抽象化する場合気がかりになるのが、とても行数が多いときのこともあります。
最低限に必要な情報はあとピクセルがあればよくて、文字列の方法を使うとすれ
ば、
例えばx=1,y=3からx=100,y=30までの選択して、

$a=selection();

としたら$aの内容は

"0,1,3,100,30,8,800"

という感じの少ない情報で済ますこともできそうです。
最初の数字がBOX選択かどうかで、最後の数字２つはピクセルです。

>私が言っていることは、要するに
>「(1)の位置情報をマクロで取れるようにしてほしい」
>ということで終始一貫しているのですが、もしかして根本的に勘違いしていたら申し
>訳ありません。

そういうことで理解しています。
ようは手法の問題で、とにかくできればいいということであれば、抽象化しても
ピクセルから算出でもどちらでも可能だと思います。
上に書いた文字列の方法では情報は少ないので、ピクセルであってもサブルーチ
ンで抽象化することも一応可能だと思います。

>将来、秀丸 v10 あたりで、Word のように飛び飛びに複数の範囲が選択できるように
>なるのではないかと予想しています。(^^)

複数の範囲を選択できるようにするかというのはちょっとわかりませんが、もし
やるとしたら、カラーマーカーを何重にでもできるようなレイヤーを持たせて、
選択用のレイヤーにするといい気がします。

BOX選択は複数選択の対象とするのはややこしいことになるので、BOXについては
唯一１つの存在にしたほうがいい気がします。
BOXの複数が必要な場合はBOXを分解して複数選択に変換するような手法があると
よさそうです。
それは内部的なこととして、表面的には見せないようにすることも考えられると
思います。

それを視野に入れると、本体側でBOXから複数選択への変換を用意することにな
って、そもそもピクセルとか考えるよりマクロ側は楽かもしれません。

複数選択は将来いつするかわからないとしても、それを見据えてBOX選択をカ
ラーマーカーに変換するという文をとりあえず用意してしまうというのもありか
もしれないです。

RE:07729 プロポーショナルフォントのBOX

IKKI さん　13/02/06 04:52

カラーマーカーをマルチレイヤ化して、選択範囲の内部表現をカラーマーカー (「選
択マーカー」?) にするというのは、すごくいいアイディアだと思います。
編集しても範囲がずれないという点が特に素晴らしいです。

仰るように、BOXは分解して複数選択として扱うべきだと私も思っていました。
各副範囲ごとに開始位置と終了位置の情報を持っていれば、それぞれ編集して長さが
違ってしまっても、編集前後で範囲の一貫性を保てますし。

抽象化するにしても、内部表現が選択マーカーであれば、副範囲の列挙はカラーマー
カーの検索と同じなので、行数が非常に多くても新たな問題は発生しなさそうです。

> 複数選択は将来いつするかわからないとしても、それを見据えてBOX選択をカ
> ラーマーカーに変換するという文をとりあえず用意してしまうというのもありか
> もしれないです。
それって要するに、colormarker 文をBOX選択に対応させるということですよね。
なるほど…それができれば、とりあえず目的を達するのに十分かもしれません。
ただ、ユーザーが付けたカラーマーカーをマクロが勝手に消してしまってはまずいの
で、いずれにせよカラーマーカーのマルチレイヤ化は必要になるかと思います。

> 普通にマウスでクリックして移動先が不定ということにはならないので、重複し
> ているところは目に見えているところが優先されていると思います。
ああああ、わかりました。やはり私が勘違いしていました。すみません。
選択範囲を右へ広げていったとき、右隣のカラムの「下へ潜り込んでいく」ような挙
動をするのは通常選択の場合だけなんですね。
BOX選択の場合は、選択範囲が見た目的に右隣のカラムに接した時点で、「下に隠れ
ている」文字列を含めてカラム末尾まで全部選択される、という挙動で理解しました。

となると、たしかにピクセル位置からテキスト位置を算出できます。
できますが…、仮にピクセル位置をマクロで取れるようにしたとして、ユーザーの責
任でピクセル位置からテキスト位置を算出するというのは、つまり上述のような細か
い挙動をユーザーに実装させるという意味であって、どう考えてもウマくない気がし
ます。
将来、たとえば何か要望があって上述の挙動を変えようと思っても、マクロの互換性
に引きずられておちおち仕様変更できない…という、おなじみの罠にハマる光景が目
に浮かんできます。
# もしくは、仕様変更によってマクロと本体の挙動に齟齬が生じるかですね。
仕様変更の自由度とマクロの互換性を将来にわたって確保するという意味でも、やは
り細かい挙動は本体側に隠蔽しておくのが良いのではないでしょうか。

> 現状でプロポーショナルフォントかどうか、BOX選択かどうかということがある
> のに、さらにピクセルも、ということになるのは確かに面倒だと思います。
はい。面倒だということもありますし、上述の互換性の問題もありますので、範囲選
択の取扱いの抽象化については、引き続きご検討いただけたらと思います。

> 抽象化する場合気がかりになるのが、とても行数が多いときのこともあります。
とりあえず最低限の情報なら、仰るように "0,1,3,100,30,8,800" 程度で済むので問
題ないですし、将来的に内部表現を選択マーカーにしたなら、大量の位置情報はテキ
スト側が持つことになるので問題ないと思われます。
ただ、編集の影響を受けて範囲がずれるかずれないかという点で両者は挙動が違って
くるので、将来的なマクロの互換性についてはよく考える必要がありそうです。

RE:07730 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/06 11:04

>それって要するに、colormarker 文をBOX選択に対応させるということですよね。
>なるほど…それができれば、とりあえず目的を達するのに十分かもしれません。
>ただ、ユーザーが付けたカラーマーカーをマクロが勝手に消してしまってはまずいの
>で、いずれにせよカラーマーカーのマルチレイヤ化は必要になるかと思います。

そういうことになりますね。
レイヤーもできたらいいですが、とりあえずcolormarkerのBOX対応は現状のまま
文やキーワードを追加せずにできるので、しておいたほうがよさそうです。
そうすると最初の主題が一文ですんでしまいますが…
できるように検討したいと思います。

RE:07731 プロポーショナルフォントのBOX

IKKI さん　13/02/07 02:55

> レイヤーもできたらいいですが、とりあえずcolormarkerのBOX対応は現状のまま
> 文やキーワードを追加せずにできるので、しておいたほうがよさそうです。
> できるように検討したいと思います。
よろしくお願いします。

シングルレイヤのままだと「選択範囲を扱うために、ユーザーが付けたカラーマー
カーを記憶／復元する」という、それはそれでまた迂遠なことになってしまうので、
BOX対応とセットでマルチレイヤの方も実装を検討してほしいところではあります。
現状のカラーマーカーの「ユーザーデータ」をそのまま「レイヤID」と読み替えてし
まえば、文やキーワードを追加せずにできるという意味ではうまくいくかと思います。

# ユーザーデータが異なる複数のカラーマーカーを重ね塗りして、かつ、重ね塗りし
たら古い方が消えるという挙動に依存しているマクロがあったらダメかもしれません
が。そんなのあるのか…?

>そうすると最初の主題が一文ですんでしまいますが…
シンプルかつ包括的なアイディアが出て良かったと思っています。ありがとうござい
ます。

抽象化については、カラーマーカーのBOX対応ができた段階で、とりあえずサブルー
チンで一通り実装してみて、課題を洗い出してみようと思います。

RE:07732 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/07 12:12

># ユーザーデータが異なる複数のカラーマーカーを重ね塗りして、かつ、重ね塗りし
>たら古い方が消えるという挙動に依存しているマクロがあったらダメかもしれません
>が。そんなのあるのか…?

似た懸念として、秀丸エディタの機能である比較のカラーマーカーは重ね塗りし
てしまっていて、１つ１つにユーザーデータが付いてしまっています。
ユーザーデータがそのままレイヤーになると何かしら不都合がありそうな気もす
るので、レイヤーをするとしたら別にしたほうがよさそうです。
レイヤーはすぐやるのは難しそうですが、とりあえずBOXのカラーマーカーは簡
単にできるので修正します。

RE:07734 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/07 15:53

V8.30β22でBOXのカラーマーカーの対応をしてみました。
レイヤーについては仕様を練りつつ考えたいと思います。

RE:07737 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/08 17:08

レイヤーについて手元のバージョンではそれなりに見通しがついてきて、概ねの
イメージを書いておきます。

・レイヤーは数値ではなく名前でする。
colormarker #text, #back, #style, #type, #userdata, $layername;
・レイヤーはものすごく多く持たせるようにはしない。
（例えば１万個のレイヤーがという使い方はできないように上限を付ける）
・通常の「一時的なカラーマーカー」系コマンドは全て名前なしのレイヤー。
・比較のカラーマーカーは別レイヤーにする。
・任意のレイヤーはcolormarker文などのマクロでのみを使えるようにする。

RE:07737 プロポーショナルフォントのBOX

IKKI さん　13/02/08 17:35

>V8.30β22でBOXのカラーマーカーの対応をしてみました。
ご対応ありがとうございます。

早速ですが、バグ?報告です。
https://dl.dropbox.com/u/861457/130208/hm830b22.png
↑この状態で黄色のカラーマーカーを全部検索しようとして、ファイル先頭から順次
nextcolormarker 0x3;
をしていったところ、カーソルの位置で止まってしまうようです。
BOX範囲が折り返しより後にかかるとまずいのかもしれません。
ご確認お願いします。

RE:07738 プロポーショナルフォントのBOX

IKKI さん　13/02/08 17:42

>レイヤーについて手元のバージョンではそれなりに見通しがついてきて、概ねの
>イメージを書いておきます。
毎度素早いお仕事で恐れ入ります。

>・レイヤーは数値ではなく名前でする。
> colormarker #text, #back, #style, #type, #userdata, $layername;
>・レイヤーはものすごく多く持たせるようにはしない。
> （例えば１万個のレイヤーがという使い方はできないように上限を付ける）
>・通常の「一時的なカラーマーカー」系コマンドは全て名前なしのレイヤー。
>・比較のカラーマーカーは別レイヤーにする。
>・任意のレイヤーはcolormarker文などのマクロでのみを使えるようにする。
良さげな感じですね。
ひとつ気になるのは、レイヤーの上下関係を設定／変更できるようにするのかどうか、
するとしたら方法をどうするか、という点です。

引き続きよろしくお願いします。

RE:07739 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/12 09:29

>↑この状態で黄色のカラーマーカーを全部検索しようとして、ファイル先頭から順次
>nextcolormarker 0x3;
>をしていったところ、カーソルの位置で止まってしまうようです。

その通りでした。改行より後ろでは存在できない場所にカラーマーカーが付いた
ことになってしまっておかしかったです。
修正させていただきます。

RE:07740 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/12 09:31

>ひとつ気になるのは、レイヤーの上下関係を設定／変更できるようにするのかどうか、
>するとしたら方法をどうするか、という点です。

レイヤーを前面に持ってくるなどの操作は、現状の文のパラメータ追加だけでは
うまくできないので、やるとすれば新たな文を追加などが必要だと思います。
必要性に応じて考えたいと思います。

RE:07742 プロポーショナルフォントのBOX

IKKI さん　13/02/18 04:05

秀丸担当さん、こんにちは。毎度素早い対応ありがとうございます。

さっそくマクロを組んでみたところ、BOX範囲の扱いをカラーマーカーで代用するには
あと2つ、下記の機能追加が必要なことがわかりました。

(1) ゼロ幅のカラーマーカーを可能にする
(2) nextcolormarker, prevcolormarker でカーソル位置を含めて検索する

BOX選択ではゼロ幅の選択範囲が意味を持つので(1)は必須です。
もし互換性が心配なら、BOX選択時のみゼロ幅可能としてもよいかと思います。
そして、ゼロ幅のカラーマーカーを検索するには(2)も必要になります。

ご検討のほどよろしくお願いいたします。

RE:07755 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/18 10:55

>(1) ゼロ幅のカラーマーカーを可能にする

ゼロ幅のカラーマーカーは、V8.00以降では比較のカラーマーカーのために可能
になっていますが、「一時的なカラーマーカー」コマンドやcolormarker文では
その状態は作ることはできませんでした。
V8.00より前は着色されなかったのでできないようにしていましたが、V8.00以降
は着色されるので、これをできるようにしてしまってもいいと思うので、そのま
まできるように修正させていただきます。

>(2) nextcolormarker, prevcolormarker でカーソル位置を含めて検索する

こちらはパラメータの指定で0x80を付けるとカーソル位置を含めてできるように
修正したいと思います。

RE:07756 プロポーショナルフォントのBOX

IKKI さん　13/02/23 03:07

秀丸担当さん、ありがとうございます。

>>(1) ゼロ幅のカラーマーカーを可能にする
v8.30β24で試してみました。
ゼロ幅のBOX選択でカラーマーカーが付いていないように見えます。
ご確認ねがいます。

>>(2) nextcolormarker, prevcolormarker でカーソル位置を含めて検索する
ヘルプにも加筆よろしくお願いします。

RE:07737 プロポーショナルフォントのBOX

IKKI さん　13/02/23 13:47

秀丸担当さん、こんにちは。

BOXカラーマーカーがEOFを含むときの動作が微妙な感じです。

https://dl.dropbox.com/u/861457/130223/hm830b24.png
この状況で EOF にカーソルを置いて nextcolormarker 0x02; をすると result == 1
になりますが、これは result == 0 になるべきな気がします。
というか、そもそもEOFにはカラーマーカーが塗られないようにするのが正しいかも
しれません。

ご検討ください。

秀丸エディタ v8.30β24

RE:07762 プロポーショナルフォントのBOX

IKKI さん　13/02/23 13:51

あと getcolormarker 関数のヘルプですが、見出しの第2引数が抜けてますね。

getcolormarker( n1 ) 関数　　←「, s1」がない
目次－関数－ getcolormarker( n1, s1 ) 関数

RE:07764 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/25 09:49

ご指摘ありがとうございます。
通常選択のときのゼロ幅だけで、BOX選択のときゼロ幅はしていませんでした。
修正させていただきます。
ヘルプも修正します。

RE:07763 プロポーショナルフォントのBOX

秀丸担当 さん　13/02/25 09:50

確かにEOFで変でした。
そもそもEOFには色付けされるべきではないと思います。
修正させていただきます。

RE:07712 プロポーショナルフォントのBOX

IKKI さん　13/03/24 20:13

こんにちは。

v8.30β25でカラーマーカーによるBOX選択範囲の処理が可能になりました。秀丸担当
さん、ありがとうございました。

だいぶ時間が経ってしまいましたが、それ用のサブルーチンを作ったので貼り付けて
おきます。
転載・加工・再配布自由です。ご参考までに。

RectSelected:
$$w = currentmacrobasename + "#selection";
colormarker 0xFFFFFF, 0xFF6666, 11, 2, 0, $$w;
##bx = seltopx;
##by = seltopy;
moveto seltopx, seltopy;
nextcolormarker 0x09, 0, $$w;
while (result) {
beginsel;
nextcolormarker 0x0A, 0, $$w;
endsel;
colormarker -1, -1, 11, 2, 0, $$w;
call DoSomething;
nextcolormarker 0x01, 0, $$w;
}
moveto selendx, selendy;
beginrect;
moveto ##bx, ##by;
endsel;
return;

// 選択範囲を処理する。処理後の当該範囲を選択して返す
DoSomething:
##bx = seltopx;
##by = seltopy;
insert "■■■"; // 何らかの処理
beginsel;
moveto ##bx, ##by;
endsel;
return;

RE:07765 プロポーショナルフォントのBOX

IKKI さん　13/03/24 20:19

ヘルプでもう一点、マクロヘルプの colormarker 文のページで、
「既にカラーマーカーがある位置にカラーマーカーを付けた場合は上書きされます」
のところは
「同じレイヤーで」
という文言を足した方がよさそうです。

細かい話ですが、よろしくお願いいたします。

RE:07841 プロポーショナルフォントのBOX

秀丸担当 さん　13/03/25 09:26

ご指摘ありがとうございます。
ヘルプを修正させていただきます。