ページ:[≪ <] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [> ≫]
■ 2315 ■
▼ 2015/11/21 (土) 01:26:32 さめたすたす  
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
[2315] 特定文字を入力&操作後に Runtime Error
また、怪しい動きを見つけました。

再現できないなどあれば教えてください。

OS: Windows 8.1
ver: 後述
現象:

特定文字を入力&操作後に Runtime Error! で落ちる。

■ 手順

1. 設定→「タイプ別設定一覧」→「C/C++」を選び一時適用
2. スペース1文字とスラッシュ2文字を入力
     ________________
   1| //[EOF]
   ↑みたいな状態
3. 3文字左に戻り「Enter」を入力
     ________________
   1|↲
    | //[EOF]
   ↑みたいな状態

で↓

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:\*****\sakura.exe

abnormal program termination
---------------------------
OK
---------------------------

■ 問題なし

v2.2.0.0

■ Runtime Error!

v2.2.1.0 r4029+プロポーショナル
※ http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=unicode&tree=r2279 で公開されている物

v2.3.0.0

▼ 2015/11/23 (月) 16:56:32 ds14050  
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
[2316] Re:特定文字を入力&操作後に Runtime Error
スマートインデント関連で無限ループに入ってメモリを食いつぶしている感じです。

n = 0 から n = nLineLen2-1 までのループの中で n に k を代入してるのがこちらです。
http://sourceforge.net/p/sakura-editor/code/4035/tree/sakura/trunk2/sakura_core/types/CType_Cpp.cpp#l1427
デバッガでは n = 1; k = 0; nLineLen2 = 3 に見えますので、n = 1 のターンが永遠に続きます。

行コメントを見つけたときに通るパスのようなので、行末までスキップ、という
コードなのかなと思いますが、n = k の k に何を期待しているのか、k という
ほとんど無名に等しい変数が何者なのか、よくわかりません。

▼ 2015/11/23 (月) 20:10:23 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
[2317] Re2:特定文字を入力&操作後に Runtime Error
n=k
↓
n=nLineLen2 でよさそうですね。
だいぶ前に書いたので忘れたけどループの処理を見た感じだと
for(n=0;n<k;n++)にしたほうが若干無駄が少ないかもしれません

▼ 2015/11/24 (火) 17:24:00 ds14050  
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
[2318] Re3:特定文字を入力&操作後に Runtime Error
> for(n=0;n<k;n++)
についてはコメントできるほど知りませんが、

> n=nLineLen2
については、ループ継続判定の前に n++ されることを考えると
n=nLineLen2-1 の方が適切ではないかなと思います。
結果は同じですけどね。

■ 2309 ■
▼ 2015/11/2 (月) 20:22:06 mike  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2309] アウトライン解析で「@quoted string」以降が表示されない
C#でアウトライン解析を使用していた所、
「@quoted(クォート) string」が含まれていると、
それ以降の部分が出力されないようです。

以下のような、行があると、
それ以降の解析がうまく言っていないようです。
var dir = @"log\";

「@quoted(クォート) string」を使用しない表記の
こちらは大丈夫でした。
var dir = "log\\";

v2.1.1.1、v2.3.0.0で発生していました。

▼ 2015/11/3 (火) 13:49:37 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
[2310] Re:アウトライン解析で「@quoted string」以降が表示されない
▼ mikeさん
組み込みの「C/C++」アウトライン解析のことだと思いますが、現時点では@文字列に対応していません。
(C++11の R"()"には対応しているけど)
タイプ別設定にある文字列エスケープの設定は、強調色分け表示にのみ効いています。

▼ 2015/11/18 (水) 23:16:51 mike  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
[2314] Re2:アウトライン解析で「@quoted string」以降が表示されない
レスありがとうございました。
(こちらのレスが遅くて申し訳ありません。)

現時点では"@文字列"は未対応との事、
ご回答頂きありがとうございます。

レスにもあります通り、"C/C++”アウトライン解析を
C#に流用して使用していた中で気が付いた次第です。
将来的に、これらも利用できる様になったらうれしいです。

メンテナーさんに感謝しつつ、
サクラエディタの一ファンとして、
今後も使って行きたいとおもいます。

■ 2306 ■
▼ 2015/10/24 (土) 19:42:11 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2306] CアウトラインでK&R関数定義がおかしい
K&Rの
int func(arg,length)
char* arg;
int length;
{
        int i;
        func2();
        i = test(arg, length);
        return (i);
}
みたいな記述でいつからかはわからないのですがfunc2, returnが関数宣言扱いになってます。

▼ 2015/10/24 (土) 21:28:42 novice  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
[2307] Re:CアウトラインでK&R関数定義がおかしい
▼ もかさん
> K&Rの
> みたいな記述でいつからかはわからないのですがfunc2, returnが関数宣言扱いになってます。


調べてみたら、
r2995 o
r2996 x
でした。

https://sourceforge.net/p/sakura-editor/code/2996/


▼ 2015/10/24 (土) 21:45:03 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2308] Re2:CアウトラインでK&R関数定義がおかしい
C++の関数宣言の後ろに何かくっついてる状態と、
K&Rの関数定義は、マクロまで考えると両方同時にサポートするのは
かなり厳しそうです。
class,publicなどのキーワードやstruct内関数,::の使用や、
ファイル拡張子などでC++かC(K&R)かを識別して処理を分ける方法ぐらいしか思いつきません。
他にはK&Rの場合は、引数リストのところが変数名のみになっていて、
それ以外では型と変数名の2つ以上のキーワードからできてるはずなので
それで識別可能かもしれません。
void func_k_and_r
(arg1, arg2)←これが変数名のみである
int arg1;

void func_cpp
(int arg1, int arg2)←これが必ず型名を含む(2つ以上の単語でできてる)
_THROW2((hoge, fuga));
とりあえず私はすぐに対応するのは無理そうです。

▼ 2015/11/14 (土) 01:27:00 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
[2312] Re3:CアウトラインでK&R関数定義がおかしい
拡張子が.cの時のC言語モードのときK&R定義を読めるようにしたパッチを登録しました。
patchunicode:1012

▼ 2015/11/17 (火) 00:39:47 novice  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
[2313] Re4:CアウトラインでK&R関数定義がおかしい
▼ もかさん
> 拡張子が.cの時のC言語モードのときK&R定義を読めるようにしたパッチを登録しました。
> patchunicode:1012


サンプルコードを貼り付けて、
Eclipse CDTの動作を見てみましたが、
拡張子がcのときは問題なし、
拡張子がcppのときはsyntax errorが表示されます。
ということで、今回のパッチのように
自動判定&手動設定もできれば問題ないと思います。

■ 2311 ■
▼ 2015/11/13 (金) 22:20:54 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
[2311] テキスト・ルールアウトラインで落ちる
ファイルの内容が
・行頭にスペース4000文字等
・その後ろにマッチ文字列
・1行のみ等ファイルサイズが小さい

この状態でアウトライン解析をすると落ちます。

wmemcpy( pszText, &pLine[i], nLineLen );
と+iしているのに後ろの長さがiを引いていないため
範囲外のデータをコピーしようとします。
patchunicode:1010
とりあえずパッチを登録したので焼くなり煮るなりしてください

■ 2303 ■
▼ 2015/10/19 (月) 12:29:56 さめたすたす  
Mozilla/5.0 (Linux; Android 4.1.2; L-01E Build/JZO54K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.94 Mobile Safari/537.36
[2303] 特定のソースでC++のアウトライン解析を実行すると落ちます
OS: Windows 8.1
ver: 2.2.0.1 / 2.3.0.0
現象:

題名の通りなのですがC++のとあるソースを開き「アウトライン解析」を
したところ落ちました。

該当ソースから落ちる現象が再現する部分のみを抜き出しましたが、
ちょっとタブとかが崩れるかもだったので再現するソースは pastebin
に投稿しました。

http://pastebin.com/EjzYiics

再現できないなどあったらお知らせください。

▼ 2015/10/20 (火) 20:53:35 ds14050  
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
[2304] バージョン別再現結果(※網羅はしていません)
2.0.6.0 C++ メソッドツリーが表示されました。
2.0.7.1 C++ メソッドツリーが表示されました。
2.1.0.0 エディタがフェードアウト(終了)しました。
2.1.1.2 エディタがフェードアウト(終了)しました。
2.3.0.0 エディタがフェードアウト(終了)しました。

▼ 2015/10/20 (火) 21:51:51 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2305] Re:バージョン別再現結果(※網羅はしていません)
template対応がらみの変更を入れた後からですね。
この件のパッチを登録しました。
https://sourceforge.net/p/sakura-editor/patchunicode/1007/

■ 2263 ■
▼ 2015/4/10 (金) 23:17:24 teru  
Mozilla/5.0 (Windows NT 5.1; Wine 1.7.31; rv:25.1) Gecko/20100101 Firefox/25.1
[2263] wineで使うと落ちる場合があります。
/* 間違って一般の方に投稿していたので、投稿しなおしました。すみません。 */

OS: Debian + wine 1.7.40
ver: 2.2.0.1
現象:タブを表示する設定にした状態でファイルを開き、
内容を編集するとサクラエディタが落ちます。
原因:sakura_core/window/CTabWnd.cpp で、 TabCtrl_GetItem に渡す
 TCITEM 構造体のメンバを適切に指定していないためと思われます。

自分でMingGWでビルドしたら(適用前でも)再現しなかったので確認できてませんが、
コードが足りてないのは確かなので、パッチを置いておきます。
Index: sakura_core/window/CTabWnd.cpp
===================================================================
--- sakura_core/window/CTabWnd.cpp      (revision 4017)
+++ sakura_core/window/CTabWnd.cpp      (working copy)
@@ -1831,6 +1831,7 @@
                        tcitem.mask    = TCIF_TEXT | TCIF_IMAGE;
                        TCHAR   szNameOld[1024];
                        tcitem.pszText = szNameOld;
+                       tcitem.cchTextMax = _countof(szNameOld);
                        TabCtrl_GetItem( m_hwndTab, nIndex, &tcitem );
                        if( 0 != auto_strcmp( szNameOld, szName )
                                || tcitem.iImage != GetImageIndex( p ) ){

▼ 2015/4/13 (月) 01:25:03 ds14050  
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
[2264] Re:wineで使うと落ちる場合があります。
▼ teruさん
パッチ提供ありがとうございます。<(_ _)>

F1ヘルプによりますと
> cchTextMax
>   Size in TCHARs of the buffer pointed to by the pszText member. If the structure is not receiving information, this member is ignored.

1.バイト数ではなくTCHARで数えた文字数をセットすること
2.情報を受け取るので *なければ* 無視される
と書いてありました。否定文で注意書きを書くなって言いたくなりますね。

TCITEMで GREPしたところ、TCIF_TEXTをセットして Getしているのは
指摘された1か所だけでした。コミットはこちらです。

 http://sourceforge.net/p/sakura-editor/code/4018/

WINEでテストはできていませんが、ブレークポイントをセットして
問題なく処理が通過していくのを確認しています。

▼ 2015/10/13 (火) 22:51:58 teru  
Mozilla/5.0 (Windows NT 5.1; Wine 1.7.31; rv:25.1) Gecko/20100101 Firefox/25.1
[2302] Re2:wineで使うと落ちる場合があります。
ver 2.3.0.0 で直っていることを確認しました。
ご対応ありがとうございました。

■ 2300 ■
▼ 2015/10/13 (火) 18:28:51 LR4  
Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
[2300] USE_CRASHDUMPが有効になっていない?
2.3.0.0 の CProcess.h ですが、

 22:#ifdef MINIDUMP_TYPE
 23:#define USE_CRASHDUMP
 24:#endif

これでは USE_CRASHDUMP は有効になっていないように見受けられますが、どうなのでしょうか。
MINIDUMP_TYPE というシンボルは ImageHlp.h で定義されてますが、
#defineではなくenum変数なので…

▼ 2015/10/13 (火) 21:18:06 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2301] Re:USE_CRASHDUMPが有効になっていない?
▼ LR4さん
すみません。これはバグ(あまり緊急度の高くない)ですので、次版で直します。
MinGWでImageHlp.hが無いことの対策でしたが、#ifdef _IMAGEHLP_ とするべきかもしれません。

■ 2298 ■
▼ 2015/10/7 (水) 00:37:06 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2298] スクロールできないときマウスキャプチャされたままになる
1. 空白画面で縦も横もスクロールできないように折り返しする
2. マウスの中ボタンを押してオートスクロールにする
3. するとキャプチャされたままになる
4. 右クリックなどで解除可能
パッチはキャプチャされたままになるのを解放するようにします
https://github.com/mocaskr/sakura/commit/0550649

▼ 2015/10/12 (月) 11:37:43 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2299] Re:スクロールできないときマウスキャプチャされたままになる
パッチを登録、コミットしました。
patchunicode:1005

■ 2282 ■
▼ 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() は、プロポーショナル対応にともない仕様が変わったってことで、このままで良いんじゃないでしょうか。

▼ 2015/9/30 (水) 03:57:22 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2294] Re:プロポーショナル版の変更点について
すっかり忘れていた変更点
文字の間隔が半角1:全角2だったのが、文字毎に1になったので
等幅フォントで文字の間隔を設定すると全角と半角の混ざった表示が等幅じゃなくなる
これはすっかり忘れてた暫定仕様だった。
直すのは結構大変

▼ 2015/9/30 (水) 21:55:24 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2295] Re2:プロポーショナル版の変更点について
▼ もかさん
> 直すのは結構大変

等幅の互換性を優先して、全角文字だったら2倍にするのは難しいでしょうか?
CTextMetirics.cppとCMemoryIterator.hを直せばいけそうな気がするのですが。

▼ 2015/10/1 (木) 01:24:11 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2296] Re3:プロポーショナル版の変更点について
▼ syatさん
> 等幅の互換性を優先して、全角文字だったら2倍にするのは難しいでしょうか?
> CTextMetirics.cppとCMemoryIterator.hを直せばいけそうな気がするのですが。

大変かと思っていたのですがそうでもなかったです。
その2つとCLayoutMgr::GetLayoutXOfCharを直せばだいたいいけました。
→patchunicode:1003
関連バグ2件をパッチに含んでいます。(状況によってパッチから分離して適用してください)
修正・適用はご自由にどうぞ。

プロポーショナル的にはCSSのletter-spacingプロパティと同じ挙動のほうが
見た目が良いような気もしますが私はいつも0にしているのでどういうのが正解かいまいちわかりません。

それともう1点、ASCII以外の半角文字(半角カナ等)で印刷に使われるフォントが
全角から半角のものに変更になっています。
フォントサイズ指定が幅から高さに変更になっているので場合によっては今までと
微妙に文字の大きさが異なるかもしれません。

▼ 2015/10/7 (水) 00:23:08 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2297] Re4:プロポーショナル版の変更点について
中ボタンによるマウススクロールで、左右移動が等幅版と比べて遅いみたいです。
等幅版3文字分移動、PP版3px移動になってる気がする。
他にもまだあるかも。うむむ

■ 2279 ■
▼ 2015/9/6 (日) 22:58:33 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36
[2279] リリース予告
前回リリースから少し経ってしまいましたが、1〜2週のうちに 2.2.1.0 をリリースしたいと思います。

内容は今コミットされているもの + プロポーショナル対応 + バグ修正 になる予定です。

現時点のテストバイナリを作ってみました。
http://ux.getuploader.com/sakura_editor/download/130/sakura.zip


▼ 2015/9/29 (火) 17:35:51 tn  
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2290] Re:リリース予告
▼ syatさん
> 現時点のテストバイナリを作ってみました。
> http://ux.getuploader.com/sakura_editor/download/130/sakura.zip


このテストバイナリで気づいたことがあります.
1. フォントは「MS ゴシック」(等幅フォント)で,
 右端で折り返す設定にしておきます.
2. 改行せずに何回か折り返す長い文字列(全角文字
 ばかりがわかりやすい)を記述します.
3. タイプ別設定→カラー で,折り返し記号の表示を
 やめる設定にします.
4.【現象1】折り返し記号が残ったままです.
5. 行頭に半角文字を次々と打ってゆくと,徐々に
 折り返し記号が消えてゆくとともに,
6.【現象2】右端に,半角サイズ分だけ,前回描画した
 文字が消えずに残ることがあります.

【現象1】【現象2】ともに,最新リリース2.2.0.1 では
発現しません.プロポーショナル対応による弊害では
ないかと思います.等幅フォントを選択したときは
従来の仕様が踏襲されるようにはできませんでしょうか?

▼ 2015/9/29 (火) 22:49:27 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
[2291] Re2:リリース予告
> 【現象1】【現象2】ともに,最新リリース2.2.0.1 では
> 発現しません.プロポーショナル対応による弊害では
> ないかと思います.等幅フォントを選択したときは
> 従来の仕様が踏襲されるようにはできませんでしょうか?

さすがにこれはバグだと思うので、直してもらえると思うです。

▼ 2015/9/29 (火) 23:22:52 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
[2292] Re2:リリース予告
▼ tnさん

ご報告ありがとうございます。
修正パッチを作成しました。
PatchUnicode:1002

■ 2275 ■
▼ 2015/8/13 (木) 03:05:55 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
[2275] Mingwのダンプ
Mingwは構造化例外処理(__try)をサポートしてなかった気がする
ので、無条件にダンプを有効にすると、コンパイルできないかも。
未確認。

▼ 2015/9/20 (日) 19:38:40 syat  
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.93 Safari/537.36
[2281] Re:Mingwのダンプ
▼ もかさん

MinGWだとそもそも DbgHelp.h が含まれておらずコンパイルできなかったので、必要な定義がない場合はダンプ無効になるようにしました。

patchunicode:#955

■ 2280 ■
▼ 2015/9/10 (木) 00:20:27 ryoji  
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2280] バグ修正パッチ
>>unicode:2278 を含む4件の修正パッチを登録しました。

999 Undo/Redo時にキャレットが期待する位置に移動しない
998 キーワードヘルプの表示位置不正
997 「ミニマップを隠す」メニュー/ツールバーのアイコンが窪んだ状態にならない
996 入力補完中のIME動作がおかしい

■ 2278 ■
▼ 2015/8/27 (木) 02:08:51 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2278] IME+入力補完
入力補完中にIMEをONにするか、IMEをONにしてから入力補完候補を表示すると
IMEの入力枠が変なところに表示されます。
また補完候補が表示された状態でIMEで入力をEnterで確定してもそれが消えて何も起こりません。

■ 2276 ■
▼ 2015/8/19 (水) 21:37:15 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2276] ミニマップが印刷プレビューで表示されたまま
ミニマップが印刷プレビューで表示されたままになります
この状態になると再描画以降で全角半角判定がミニマップ側のフォントで計算されてしまいます
そのため一部文字で印刷設定通りに印刷されない可能性があります
このバグに対するコミット:
https://github.com/mocaskr/sakura/commit/1484f034

▼ 2015/8/21 (金) 00:40:08 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
[2277] Re:似たような箇所のバグたち
印刷+操作回りを色々テストしてみたところ、まだ細かいバグがありましたので報告します。

印刷プレビュー中に共通設定を変更するとプレビューにメインメニューが表示される
https://github.com/mocaskr/sakura/commit/1d96b217

印刷プレビュー中にミニマップを表示するとプレビューにも表示され、文字幅がミニマップのものになる
https://github.com/mocaskr/sakura/commit/5434a993
文字幅(trunk2では全半角判断)がミニマップになるのは、ほかのウィンドウでツールバー類をON/OFFした場合です。

終了時にアクセス違反が発生する(ミニマップ)
https://github.com/mocaskr/sakura/commit/348974fb
これはミニマップの~CEditViewから呼び出されるCEditView::Close()内の
        if(m_hAtokModule)
                FreeLibrary(m_hAtokModule);
が未初期化のアドレスを解放しようとします。
私の環境ではデバッグのログに表示されますが処理はなぜか続行されていました。

同日の他3件はパッチ依存です
6029c238 印刷フォントがミニマップ用になることがある(私用版固有)
upatchid:837 フォントスタイルに斜体(仮)と取り消し線を追加 のパッチの不具合
未初期化の変数による条件分岐により印刷フォント名の1dot版で印刷されることがあります
たまたま該当変数がfalseだった場合は発生しません

4a52b261 印刷プレビュー中にミニマップをONにするとフォント幅がミニマップ用になる
TSVとりあえず対応プロポーショナル版のみの不具合

b57bed38 印刷プレビュー(中)に終了させるとアクセス違反が発生する
upatchid:949 印刷のレイアウト作成でCColorStrategyの設定をしていない のパッチの不具合
シングルトンのCEditWnd,CColorStrategyPoolは仕様上どちらが先に消えるかはっきりしないはず。
~CPrintPreview()内に追加したCColorStrategyPool::OnChangeSettingでアクセス違反になっていた
~CEditWnd()内のdelete m_pPrintPreviewより先に~CColorStrategyPool()が呼ばれていて変数が削除されていたため
該当処理はデストラクタでなくてもいいので外へ移動

■ 2273 ■
▼ 2015/8/13 (木) 02:04:34 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
[2273] JIS/UTF-7の選択のバイト数表示
範囲選択のカウントをバイト数にして
ファイルをJIS/UTF-7にする
日本語を含む行を行単位などで選択(↓キーや行選択を使う)
1文字づつ範囲選択を減らしていくと、バイト数がマイナスになったりします
もちろん範囲を増やすと余分に増えます

コード見ればあたりまえですが「123あいう」
がUTF-7(例はもどき)では「123+aaabac-」
みたいになるのに対して「う」単体でも「+ac-」のようになり
プレフィックス等が余分にカウントされるからです

▼ 2015/8/13 (木) 02:16:04 もか  
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
[2274] Re:JIS/UTF-7の選択のバイト数表示
あと本家/turnk2の場合は、UTF-7でPS,LS,NELと次の行に日本語等を並べて使うと、
ファイル書き込み時に行ごとに分割されるはずの場所が連続してエンコードされるので
バイト数が書き込みと一致しなくなります

■ 2272 ■
▼ 2015/8/5 (水) 00:39:26 ななし  
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36
[2272] CSV/TSVモードのセル幅
タイプ別変更でのTSVモードについて
・元のタイプと新しいタイプで両方とも同じTSVモードのとき
・タイプ別フォントが有効な場合で、

 記号類などの半角・全角幅がフォントによって異なる
上記時に、レアケースですがセル幅が正しく変更されない場合があるような気がします。

■ 2253 ■
▼ 2015/2/11 (水) 20:06:24 もか  
INCM1.23a
[2253] Grep置換の単語単位
Grep置換での単語単位と、通常のすべて置換の単語単位の動作が異なることに気が付きました。
テキスト「ABCあいうABCあいうABCあいう」
置換前「ABCあいう」
置換後「DEF」
通常の全置換は「DEFDEFABCDEFABCDEF」
Grep置換では「DEFDEFDEFDEFDEFDEF」
になります。
すべて置換の単語単位は、置換ごとの繰り返しで、2こ目以降の置換前文字列が異なるためです。
すべて置換
「[ABC]あいうABCあいうABCあいう」
「DEF[あいう]ABCあいうABCあいう」
「DEFDEFABC[あいう]ABCあいう」
「DEFDEFABCDEFABC[あいう]」
「DEFDEFABCDEFABCDEF」
Grep置換
「[ABC]あいうABCあいうABCあいう」=>「DEFあいうABCあいうABCあいう」
「ABC[あいう]ABCあいうABCあいう」=>「DEFDEFABCあいうABCあいう」
「ABCあいう[ABC]あいうABCあいう」=>「DEFDEFDEFあいうABCあいう」
「ABCあいうABC[あいう]ABCあいう」=>「DEFDEFDEFDEFABCあいう」
「ABCあいうABCあいう[ABC]あいう」=>「DEFDEFDEFDEFDEFあいう」
「ABCあいうABCあいうABC[あいう]」=>「DEFDEFDEFDEFDEFDEF」

どうします?

▼ 2015/2/12 (木) 15:49:49 サクラエディタ利用者  
Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko
[2255] Re:Grep置換の単語単位
> どうします?

個人的には、「すべて置換」の挙動に統一してもらえると
ありがたいです。でも他のユーザは、どう思っているのかな?

▼ 2015/2/12 (木) 15:56:36 サクラエディタ利用者  
Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko
[2256] Re2:Grep置換の単語単位
×:個人的には、「すべて置換」の挙動に統一してもらえると
○:個人的には、「Grep置換」の挙動に統一してもらえると

間違って書き込みしました、申し訳ありません。
「Grep置換」の挙動に統一して欲しいです。
理由としては、「Grep置換」の挙動の方が
より直感的な置換処理な気がするからです。

▼ 2015/2/21 (土) 22:31:35 もか  
INCM1.23a
[2260] Re3:Grep置換の単語単位
>「Grep置換」の挙動に統一して欲しいです。
>理由としては、「Grep置換」の挙動の方が
>より直感的な置換処理な気がするからです。

私もそう思うので、
「とりあえず 2.2.0.0では現状維持とする」
に1票入れておきます。
REPLACEALLをいじるのはかなり面倒なので。

▼ 2015/3/7 (土) 01:18:32 もか  
INCM1.23a
[2261] Re:Grep置換がなんか違う
違うパターンその2です。
正規表現で^と改行までを改行を削除して置換するような処理
置換前「^hoge\n」
置換後「hoge」
みたいな場合の動作が、「すべて置換」と「Grep置換」で違います。
hogeはあまりないかもしれませんが、
<br>
<br>
みたいなのを置換する場合に影響すると思われます。
データが
「hoge\n
hoge\n
hoge\n
x」
の場合に、すべて置換:
「hogehoge\n
hogex\n
」
Grep置換:
「hogehogehogex」

▼ 2015/3/7 (土) 16:09:52 サクラエディタ利用者  
Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko
[2262] Re2:Grep置換がなんか違う
> 違うパターンその2です。

こういうケースでも、Grep置換の挙動に統一して欲しいです。
・・・他のユーザは、どうして意見を言ってくれないのかなあ?

▼ 2015/7/23 (木) 17:05:21 ななし  
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36 OPR/30.0.1835.125
[2271] Re3:Grep置換がなんか違う
> ・・・他のユーザは、どうして意見を言ってくれないのかなあ?
掲示板を見てないとか、挙動の変更に繋がる質疑だと思ってないとか、
バージョンアップをさぼっててGrep置換について触ったことがないとか(←私)

Grep置換の挙動のほうが良いと思いますけど、余り手軽に直せないようなら保留でも良い気がします。
そして(いつかきっときてほしい)複数行対応の時にまとめて改良されたりすればとっても嬉しい。
# 複数行対応する時がこないなら…鬼雲諦めて、特殊ケースは全てWSH/JSで誤魔化し続けます…orz

ページ:[≪ <] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [> ≫]
INCM/CMT
Cyclamen v3.81
[ut:0.070][st:0.010]