[スレッド全体]

2015/9/20 (日) 23:34:17 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2282] プロポーショナル版の変更点について
■ステータスバーの桁数ですべての文字が1桁扱いになります。
いままではTAB=タブ幅,全角=2桁,半角1桁(=以降旧桁数)扱いでした。
■GetSelectColmFrom,GetSelectColmTo
の各値がpx単位になります。いままでは旧桁数と同じ値でした。
■LineColumnToIndex,LineIndexToColumn,MoveCursorLayout,GetStrLayoutLength,SetViewLeft,GetViewColumn
レイアウト桁がpx数になります。今までは旧桁数でした。
■GetDefaultCharLength
ルーラー1文字分の幅が返ります。この幅はA〜Za〜zの幅の平均値px数です。
折り返し桁数やタブ幅はこの幅を基準に計算されます。今までは1でした。
等幅フォントの場合GetStrLayoutLength/GetDefaultCharLengthで旧桁数とほぼ同等の値を取得することができます。
■左右移動の改行以降の移動がpx単位の移動になります。
いままでは1文字幅単位でした。
■単語の左端に移動で改行以降の移動がルーラーの1文字分移動になります。
いままでは改行位置に移動していました。
■単語の右端に移動はルーラー1文字分右移動でいままでと変わりません。
■改行コードは内部幅は1px扱いで表示だけ1ルーラー文字分+4pxになっています。
改行コードを表示しない場合は表示幅は2pxです。
いままでは内部1文字幅表示2文字幅(旧バージョン・反転選択では表示1文字幅)でした
■TAB幅の計算は、最低でもルーラー1文字幅分以上の隙間が確保される状態での次のタブ位置までです。
最大で1文字幅-1px+タブ幅分確保されるので最大値は以前より約1文字分大きくなります。
■等幅フォントの場合であっても以前は幅が固定されていたコードポイントがありましたが、
コントロールコードを除くすべての文字がフォントを基準に可変長になります。
また最低幅は1px以上なのでUnicodeの0幅文字でも1px幅の文字として扱われて
等幅フォントであったとしても文字幅が1px単位でずれることがあります。

2015/9/20 (日) 23:53:14 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
[2283] Re:プロポーショナル版の変更点について
▼ もかさん
> ■ステータスバーの桁数ですべての文字が1桁扱いになります。
> いままではTAB=タブ幅,全角=2桁,半角1桁(=以降旧桁数)扱いでした。


これはちょっとリリースはストップですね。ご指摘ありがとうございました。
プロポーショナル修正をコミットしてしまったので戻した状態で再チャレンジします。


2015/9/21 (月) 02:40:13 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2284] Re2:プロポーショナル版の変更点について
やっぱだめかな?(判断はお任せします)
桁表示にcol(px数をルーラー幅で整数割りした物)を使うとプロポーショナルフォントでガタガタになるので、
そうなるのなら計算コストの一番安いCLogicInt+1で表示するようにしようと考えてました。
これは$xとかタグジャンプの桁表示と同じものです。
メモ帳はじめほとんどのエディタ・開発環境は1文字で1つづ表示するのが今は主流みたいですし。
今までの実装はすごく長い行の後ろ側で1文字づつの修正を繰り返すような動作のときに顕著に重いです。
表示上のタブを中途半端に含めた桁数が知りたいときはルーラーを見ればある程度は分かるかなと。
なお矩形選択時は、colとpxが表示されます。
昔のように正確でない表示もどうかと思いますし、かといって無意味に重いのもどうかと思います。
 もしいままでと同じような値にしたい場合は、タブ幅を含め文字幅固定で計算してやる必要があります。
折り返し単位で表示のときも、今までは低コストで表示するだけでしたが1レイアウト行分計算が必要になります。
レイアウト行の行頭インデントがある場合は1行目のインデント分を固定文字幅で先に計算しておく必要もありそうです。
そういえばCNativeW::GetKetaOfCharはサロゲートペアに固定で2を返す等の理由により、厳密には実際の表示幅と同じになりません。
もうちょっと改造が必要かもしれないです。
TabToSpace/SpaceToTabに似たような処理がありますが、こちらはサロゲートペアにそもそも未対応のようです。
色々な人の意見も聞いてみたいですがあんまり人いないんですよね。

2015/9/21 (月) 03:22:50 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2285] Re3:プロポーショナル版の変更点について
色々書いたけどF_GETSTRWIDTHをコピペだけである程度いい気がしてきた

2015/9/21 (月) 23:20:49 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
[2286] Re4:プロポーショナル版の変更点について
▼ もかさん
パッチとして整合性とれてるからいけるかな、と思ったのですが、既存の動きから大きく変わってしまうのは躊躇してしまいます。
内部の計算はプロポーショナル版のでよいので、マクロ関数と桁数表示のような外部と接する部分に旧Verとの互換性を持たせられるとよいと思いました。

2015/9/22 (火) 01:01:20 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2287] Re5:プロポーショナル版の変更点について
▼ syatさん
> パッチとして整合性とれてるからいけるかな、と思ったのですが、既存の動きから大きく変わってしまうのは躊躇してしまいます。
> 内部の計算はプロポーショナル版のでよいので、マクロ関数と桁数表示のような外部と接する部分に旧Verとの互換性を持たせられるとよいと思いました。

全角だから2とか決め打ちせずLogicLayout変換関数群をちゃんと使ってあるマクロは互換性があります。
例えばこれ
http://sakura.qp.land.to/?Macro%2F%C5%EA%B9%C6%2F222
あとはSimpleCmdの切り取り・貼り付けコマンドとかです。
既存マクロ関数を等幅専用にされると既存マクロのプロポーショナル対応(作者が意図的でないのも含む)で書かれたものが等幅フォントを選ばないとちゃんと動かないものになります。
もっとも互換性があるように書いた人が私以外にいるかどうかはあやしいところです。
あとマクロのヘルプでSetViewLeft,GetViewColumns等でプロポーショナル対応の記述が既にあります。
ANSI->Unicodeのときも座標系の相違はすでにあり特に目立った混乱も観測していないので影響は限定的かなという印象です。
AUのときは罫線マクロとURLエンコードマクロが動かないなどの例はありました(PPAは除く)。
0.0.1バージョン上げで切り替えるにはちょっと乱暴だとは正直思いました。

2015/9/24 (木) 21:38:09 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.99 Safari/537.36
[2288] Re6:プロポーショナル版の変更点について
プロポーショナル対応の動きを整理しますと、
・旧レイアウト桁・・・半角1、全角2の桁
・新レイアウト桁・・・ピクセル単位のx座標
・新ルーラー桁・・・半角文字の平均幅を1桁とする

として、

【論理桁(変化なし)】
ExpandParameter('$x')

【旧レイアウト桁→論理桁】
ステータスバーの桁

【旧レイアウト(変化なし)】
GetStrWidth()

【旧レイアウト桁→新レイアウト桁】
GetSelectColmFrom()、GetSelectColmTo()、GetStrLayoutLength()、GetViewColumns()

【旧レイアウト桁→新ルーラー桁】
ルーラー、右端折り返し、タブ、指定桁縦線

みたいになっています。レイアウト座標が桁からピクセルに変更されたと考えれば全体的に辻褄があっています。

一案ですが、ステータスバーの桁とマクロ関数が返す桁は、ピクセル座標をルーラー桁幅で割り算したものを返せば、等幅フォントを使う人には互換性が保たれて良いんじゃないでしょうか?
レイアウト〜ロジックの正確な計算をするにはピクセル座標が必須なので、GetSelectColmFrom2()などでピクセル座標を返せるようにするとか。
個人的には、マクロ関数はどっちでもよいですが、ステータスバーの桁は変わらないでくれるとありがたいです。

2015/9/25 (金) 01:51:31 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2289] Re7:プロポーショナル版の変更点について
>【旧レイアウト桁→論理桁】
>ステータスバーの桁、GetStrWidth()

GetStrWidthは旧レイアウト桁のままです。

>一案ですが、ステータスバーの桁とマクロ関数が返す桁は、ピクセル座標をルーラー桁幅で割り算したものを返せば、等幅フォントを使う人には互換性が保たれて良いんじゃないでしょうか?
ステータスバーの桁についてプロポーショナルの時もその表示にするんですか?
ABCとかは1桁進んでWとかは2桁進んで.とかでは桁は増えないみたいな動きになり実質無意味な値が表示されるようになりますけど。
>個人的には、マクロ関数はどっちでもよいですが、ステータスバーの桁は変わらないでくれるとありがたいです。
等幅版と変わらない感じに表示するものをweeklyの下のところにアップしておきました(パッチ付き)。
M案1は、改行単位のときは旧レイアウト互換計算、折り返し単位のときは新ルーラー桁で表示します。
M案2は、改行単位のときも新ルーラー桁(折り返しインデント抜き)で表示します。
以前はあった行が長い時のキャッシュはとりあえずなので復活させてません。
用途とか好みの都合だから選択できるようにすりゃあいいんじゃないかという気もしますが。
マクロのほうは意見保留。

2015/9/30 (水) 01:06:37 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2293] Re8:プロポーショナル版の変更点について
▼ もかさん
> GetStrWidthは旧レイアウト桁のままです。
そうでしたね。修正しました。


> 等幅版と変わらない感じに表示するものをweeklyの下のところにアップしておきました(パッチ付き)。
> M案1は、改行単位のときは旧レイアウト互換計算、折り返し単位のときは新ルーラー桁で表示します。
> M案2は、改行単位のときも新ルーラー桁(折り返しインデント抜き)で表示します。

M案2のほうが私のイメージでした。
M案2か物理桁かのオプションがあると良いかもしれません。
M案1はあまりいらないかな。プロポーショナルでは全角半角あまり気にしない気がします。


> マクロのほうは意見保留。
GetSelectColmFrom()、GetSelectColmTo()、GetStrLayoutLength()、GetViewColumns() は、プロポーショナル対応にともない仕様が変わったってことで、このままで良いんじゃないでしょうか。

[▼次のスレッド]
INCM/CMT
Cyclamen v3.81
[ut:0.010][st:0.000]