; "Transaction" choises are ; Bug report. ; Patch for Bug Fix. ; Patch for New feature. ; Request for New feature. ; "Status" choises are ; pending. ; working. ; done. ; confirmed. ; ------------------------------------------------------------ Submitter: Mito Subject: abort at MARK_INTERVAL_TREE Transaction: Bug report. X-ML-COUNT: 2456 Status: pending ------------------------------------------------------------ 現象: At Wed, 27 Jun 2001 13:40:47 +0900, #2456 mit@nines.nec.co.jp wrote: > 以前 spd で作った "Meadow-1.14 (AWSAKA:62)" で alloc.c の > mark_object() で何度かアボートしたので、デバッグ版で暮らして > いたところ、しばらくは起こらなかったのですが、先ほどやっと再 > 現しました。 > > 手元の alloc.c では2075行目の、以下の MARK_INTERVAL_TREE の > 部分です。 > > | switch (SWITCH_ENUM_CAST (XGCTYPE (obj))) > | { > | case Lisp_String: > | { > | register struct Lisp_String *ptr = XSTRING (obj); > | > | assert(ptr); > | if (!ptr) { > | break; > | } > | MARK_INTERVAL_TREE (ptr->intervals); ←ここ 再現方法: At Wed, 27 Jun 2001 13:40:47 +0900, #2456 mit@nines.nec.co.jp wrote: > 前に起こったときは、C のコメントの部分で、ESC DEL > (backward-kill-word) した時に発生し、今回は lookup の検索結 > 果を見ているときに発生しました。 > > 関係あるかどうかわかりませんが、.emacs で > > (setq font-lock-support-mode 'lazy-lock-mode) > (global-font-lock-mode t) > > してあります。 > > フォントは BDF のみです。 > > ロードしている非標準的なパッケージは、Mule-UCS, bitmap-mule, > APEL, FLIM, SEMI, Wanderust, mime-w3m, Lookup くらいです。 > > OS は Windows2000 SP2 です。 > > 現在 Visual Studio が起動しており、MARK_INTERVAL_TREE の部分 > で break したままの状態です。 > > ソースを追っても私にはデバッグできそうにないので、何か調べる > ことがありましたら教えてください。 > > ＃ 数日はこのままの状態でいれると思います。 > > ptr は以下のようになっています。ptr->intervals に変な値が入っ > ているのが、アボートの原因だと思われます。 > > | - ptr 0x0242da18 > | ├ size 1852404852 > | ├ size_byte 774778471 > | ├+ intervals 0x2e2e2e2e > | └+ data 0x0242da24 ")" > > 最後にコールスタックを載せておきます。 > ご指導よろしくお願いします。(_ _) > > | mark_object() line 2075 + 69 bytes > | mark_object() line 2292 + 9 bytes > | mark_object() line 2292 + 9 bytes > | Fgarbage_collect() line 1827 + 16 bytes > | Ffuncall() line 2409 > [...] コメント: At Fri, 03 Aug 2001 01:03:47 +0900 (JST), #2471 gotoh@taiyo.co.jp wrote: > 水> 2456(abort at MARK_INTERVAL_TREE)は、他で起こっていないのな > 水> ら取り下げます。 > > 2456の件はちょっとツブすのに手間がかかるかもしれません。 > なので、必須としないまでも覚えておくべきかと。 > > 他のところで起こってないか？といわれると、私のところでも > たまーにMeadowがお亡くなりになることはあります。 > でも、そういうときってたいてい忙しい状態で、 > meadowのデバッグどころではなかったりするため、 > 原因が同じか否かさえつかんでません。 > > # こういう症例は死後検証ではちょっと特定できなさそう。 > > > 水> あれから、まっさらな状態から環境を作り直したら頻度が下がりま > 水> したし、ウィルスチェッカなんかも影響しているのかもしれないし、 > 水> W2K WS で何週間も立ち上げっぱなしな状態が悪いのかもしれませ > 水> んので。 > > 環境によって左右される、というのもヘンですよね。 > となるとalloc.cにまつわるシビアなタイミングによるバグと見るべきか。 > > たとえば emacs 20.7 のalloc.c と比較してみると、唯一、2001/02/08 > に堀口さんによって1行変更されただけしか違いません。 > > 2001-02-08 Kyotaro HORIGUCHI > > * alloc.c(make_string): Use multibyte_chars_in_text to create > multibyte string correctly for parameter 'contents' containing > multibyte characters. > > しかし、emacs-21ではalloc.cは結構変更が入っていて、 > make_string()も変更されています。その修正を見る限り上記は > 上記修正も不十分のようです。 ------------------------------------------------------------ Submitter: Suzuki Keiichi Subject: IME font control on Windows2000. Transaction: Request for New feature. X-ML-COUNT: 1821 Status: done ------------------------------------------------------------ 現象: >>>>> meadow-develop No. 1818 >>>>> Message-Id: 圭一> ずいぶん前に meadow-users-jp の方で出た話なのですが、 Windows2000 圭一> + MS-IME2000 という環境で IME で変換中の font の制御がうまくいかな 圭一> いという話があったのですが、これを直すのは大変(or まだ手をつけたく 圭一> ない)でしょうか? 再現方法: >>>>> meadow-develop No. 1819 >>>>> Message-Id: <20000615144917V.gotoh@taiyo.co.jp> 後藤> うちだと、辞書登録しようと登録ダイアログを出すと、それ以降小さくなっ 後藤> ちゃいます。いまは egg を使うのが主なのでさほど困ってませんが、やっ 後藤> ぱそういう状態になると、気になりますよね。 ------------------------------------------------------------ Submitter: Shun-ichi Goto Subject: Bug of kill-ring action with NULL byte in string. Date: Fri Jun 09 11:42:28 2000 X-ML-COUNT: 1812 Transaction: Bug report. Status: done ------------------------------------------------------------ 現象 NULL 文字 ^@ (== 0 : null byte) を含むリージョン指定をして kill-ring-save あるいは kill-region して取り込んだデータを yank すると、 NULL 文字の直前までしか挿入されない。(あたかも ASCIZ 文字列ハンドリン グ不備かのごとく) 具体的には "abc^@abc" => "abc" となってしまうというもの。 これは望まれた 見えないだけかと思い、バッファ上で(point) を調べてみると、確かに3文字 分しかバッファ上にないのでそういう事ではない。 試験環境 (1) Meadow 1.13b1 + Windows 2000 pro (2) NTEmacs 20.6 + WIndows 2000 pro (比較用) Emacs 20.6 + BSD/OS 4.0.1 + Astec-X (X-server on Win2000) 再現手順 具体的には適当なバッファ内で abc^@abc と入力する(キーストロークとして は a b c C-q C-SPC a b c)。最初の "a" の直前にてset-markし最後の"c" の 後ろにて C-w (kill-region) あるいは M-w (kill-ring-save) する。次の行 に移るなどして適当に C-y (yank) すると、"abc" だけが挿入される。 比較 meadow 1.13b1 と NTEmacs 20.6、 UNIX (BSD/OS)上の emacs 20.6 で試して みました。結論からいえば Windows 用コード(Meadow & NTEmacs) の問題であ り、なおかつWindow を使用する(not -nw)状態で現象が出るようです。 Execute | Meadow | NTEmacs | Emacs options | result | result | result ---------+--------+---------+-------- (none) | NG | NG | ok -q | NG | NG | ok -nw | ok | ok | ok -q -nw | ok | ok | ok ※ emacs 20.6 は BSD-OS 上で動作させ、Win2000 上の X-Server (Astec-X) に表示させました。 調査 件の文字列を (setq str (buffer-substring (mark) (point))) すると、 正しく保持されており、mini-buffer にも正しく報告される。 (length str) も7で正しい。 (insert str) も正しく挿入する。 ring の中を見ると "abc" と "abc^@abc" があり、C-u 2 y すると、 今度は正しく挿入される。つまり (current-kill 0) => "abc" (current-kill 1) => "abc^@abc" となっている。 ちなみにその操作の後、別の文字列を C-w すると、 (current-kill 0) => "hello" (current-kill 1) => "abc" (current-kill 2) => "abc^@abc" となっており、件の操作を行なうと、どういうわけか"abc" 余計にkill-ring に突っ込んでる処理がどこかにある、という事かと。 しかも (null window-system) の状態に限って... ------------------------------------------------------------ Submitter: Suzuki Keiichi Subject: face-property-put (Re: mw32faces.el - set-face-underline-p) Transaction: Patch for Bug Fix. X-ML-COUNT: 1722 Status: done ------------------------------------------------------------ >>>>> meadow-develop No. 1712 >>>>> Message-Id: <20000303.151924.68472384.shirai@rdmg.mgcs.mei.co.jp> 白井> だめですね。新しく作る face からみんな italic, bold などの属性が 白井> 消えてしまいます。 白井> dispextern.h の himi> FACE_PROPERTY_MERGEあたりの処理で引っかかっているのかな。 白井> 周辺が要注意。 白井> ではなくて、mw32faces.el の face-property-put() が悪さをしていま 白井> した。 >>>>> meadow-develop No. 1718 >>>>> Message-Id: 2000-03-03 Keiichi Suzuki * mw32faces.el (face-property-put): Remove only the specified property, when `val' is nil. -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- --- mw32faces.el.orig Fri Mar 03 17:01:00 2000 +++ mw32faces.el Fri Mar 03 17:02:00 2000 @@ -85,7 +85,24 @@ (defun face-property-put (plist prop val) (if (null val) - val + (cond + ((null plist) + nil) + ((eq (car plist) prop) + (cdr (cdr plist))) + (t + (let ((x (cdr plist))) + (and (cdr x) + (while + (cond + ((eq (car (cdr x)) prop) + (setcdr x (cdr (cdr (cdr x)))) + nil) + ((not (string< (symbol-name prop) + (symbol-name (car (cdr x))))) + nil) + ((setq x (cdr (cdr x)))))))) + plist)) (let ((x plist) (y plist)) (while (cond -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- ;; plist が長くなるようなものでなければ、 string< のところは、削った方が ;; コストが小さくなるように思います。(どちらにしてもそれほど呼ばれる頻度 ;; は高くないと思いますので、どうでもいいような気はします。 -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- 8>< -------- ------------------------------------------------------------ Submitter: Hideyuki SHIRAI Subject: copy-face() can't keep OLD-FACE's typeface. Transaction: Bug report. X-ML-COUNT: 1703 Status: done ------------------------------------------------------------ (copy-face 'italic 'old-face) (set-face-underline-p 'old-face nil) (copy-face 'old-face 'new-face) を順に評価したとき、本来 'new-face は italic face になることが期 待されるが、default face になってしまう。また、'bold, 'bold-italic でも同様である。 なお、(set-face-underline-p 'old-face nil) を実行しないか、 (set-face-underline-p 'old-face t) なら、期待する結果となる。 dispextern.h の himi> FACE_PROPERTY_MERGEあたりの処理で引っかかっているのかな。 周辺が要注意。 解決済み。X-ML-COUNT:1722参照 ------------------------------------------------------------ Submitter: Kyotaro HORIGUCHI Subject: str_cmpchar_id() make the pointer of display_text_line() in xdisp.c invalid Transaction: Bug report. X-ML-COUNT: 1337 Status: done ------------------------------------------------------------ 堀口です. 原因は完全にわかった..と思います. とりあえず 1.06b1 へのパッチもいれましたが, 副作用が"もしかして 重いかも^^;" とういことでおそらくお蔵入りでしょう. ;_; 問題は byte-character の不整合とかではなく, バッファの中のポイン トのしかたの間違いです. というか当初予期していなかったところで xmallocが使われるようになってしまったというか.. 起きていることは簡単に言うと以下の通りです. (まえにも似たような ことを書きましたが..) 「再配置可能なメモリである(emacsの)バッファのなかをさしているポ インタを使っているときに xmalloc を使ったせいでもとのバッファ のメモリが移動してしまうため, そのポインタが無効な領域を指す ようになってしまう」 これに対して, おいてけぼりを食らっていたポインタもバッファの移動 に追従させてしまうようにするパッチを添付しました. 下記の(B)の方法です. ちょっと見ていただたいのですがいいでしょう か? > himiさん? or 半田さん? A) 結構アドホック 関連の関数がすべて current_buffer に対する操作しかしないなら, 呼び出しを上位側にたどって行きながらすべての呼び出し元でバッ ファ内へのポインタを str_cmpchar_id を通る前後で使いつづけな いように修正する. 当然関数のパラメータにはポインタではなくバ イトオフセットを使うようにする. 感想: うーん, どうなんですか? これでできればそれはそれでいい と思うのですが.. B) もうちょっとスマートに, でもちょっと大胆かも r_alloc_sbrk でそのブロックの先頭を指すポインタひとつだけで なく, 複数のポインタのブロック先頭からのオフセットを保存する ように変更する機構をつける. ある意味汚い. r_alloc_relate_pointer(&pointer) // 名前がダサいけど堪忍 とかやって複数のポインタを登録できて, それらのポインタは r_alloc_sbrk の時に自動的に修正される. これでパフォーマンスに 影響するほど sbrk は使われるものではないですよね. 結果: とりあえず深く考えずに実装してみました. 結果はとりあえ ず問題はなくなりました. (問題の場所の通過をデバッガで確 認しています) ただし, 例のテストプログラムでは結構細か い単位で変数自体の登録と削除が繰り返されるのか重いよう な気がします^^; 企画倒れっぽいですね ;_; C) その他. アンマリなので書きません. ============================================================ 今回私が出したいじめ関数で起きたことは具体的には以下の通りです. display_text_line@xdisp.c: バッファ内の位置は int pos で表現. 途中で BYTE_POS_ADDR(CHAR_TO_BYTE(pos)) した結果のポインタを STRING_CHAR_AND_LENGTH(ここでは結果として string_to_non_ascii_char)に引き渡している. string_to_non_ascii_char@charset.c display_text_line で作られたバッファ内を指すポインタをそのまま str_cmpchar_id に引き渡している. str_cmpchar_id@charset.c:1496 string_to_non_ascii_char から引き渡されたポインタの場所にある composite character を検索するが, なかった場合は composite character id のためのハッシュテーブルの拡張, キャラクタテーブ ルの拡張で xmalloc が行われる#ことがある#. さらにこのときに一旦領域が足りないと r_alloc_sbrk でバッファが 移動する#ことがあり#そのせいでポインタが"死んで"しまって, 最終p 的に charset.c:1632 if (*bufp == 0xA0) のところで SEGV となる. ============================================================ 以下の変更はよさそうだが、そもそもstr_cmpchar_id()がxmallocを やたら大量に呼び出し、しかもそれがreallocである点が問題である。 ralloc.cにはreallocationをfreezeする機構があり、 display_text_line()のGLYPH組み立て部分ではこのfreezeを行えば 問題は解決することはわかっている。しかし、str_cmpchar_id()は おおきなreallocを行うので、このfreezeの為には、非常に大きな blockのallocateを必要とし、結果として、速度低下を招く。 まあ、これは、str_cmpchar_id()の見直しが 良いのではないだろうか。 ============================================================ 追記 あらかじめcmpchar_idを登録し、str_cmpchar_id()をreallocationから 守るように変更してこの問題には一応の決着をつけた。 from himi ============================================================ [3 Patch for bitmap problem. ] --- ralloc.c.org Sat Aug 22 12:27:22 1998 +++ ralloc.c Fri Aug 13 22:17:50 1999 @@ -180,4 +180,6 @@ while the arena is frozen. Very inefficient. */ +#define BLOC_RELVARS_SIZE 4 + typedef struct bp { @@ -185,4 +187,5 @@ struct bp *prev; POINTER *variable; + POINTER *related_variables[BLOC_RELVARS_SIZE]; // Oops!! POINTER data; SIZE size; @@ -420,4 +423,5 @@ register bloc_ptr new_bloc; register heap_ptr heap; + register int i; if (! (new_bloc = (bloc_ptr) malloc (BLOC_PTR_SIZE)) @@ -437,4 +441,7 @@ new_bloc->new_data = 0; + for (i = 0 ; i < BLOC_RELVARS_SIZE ; i++) + new_bloc->related_variables[i] = (POINTER*) NIL; + /* Record in the heap that this space is in use. */ heap = find_heap (new_bloc->data); @@ -505,7 +512,8 @@ while (tb != NIL_BLOC) { + register int i; + if (tb->variable) s += tb->size; - tb = tb->next; } @@ -524,4 +532,5 @@ if (b->variable) address += b->size; + b = b->next; } @@ -683,6 +692,14 @@ else { + register int i; + int diff = b->new_data - b->data; + safe_bcopy (b->data, b->new_data, b->size); *b->variable = b->data = b->new_data; + + for (i = 0 ; + i < BLOC_RELVARS_SIZE && b->related_variables[i] ; + i++) + *(b->related_variables[i]) += diff; } } @@ -694,7 +711,13 @@ else { + register int i; + int diff = b->new_data - b->data; + safe_bcopy (bloc->data, bloc->new_data, old_size); bzero (bloc->new_data + old_size, size - old_size); *bloc->variable = bloc->data = bloc->new_data; + + for (i = 0 ; i < BLOC_RELVARS_SIZE && b->related_variables[i]; i++) + *(b->related_variables[i]) += diff; } } @@ -710,6 +733,14 @@ else { + register int i; + int diff = b->new_data - b->data; + safe_bcopy (b->data, b->new_data, b->size); *b->variable = b->data = b->new_data; + + for (i = 0 ; + i < BLOC_RELVARS_SIZE && b->related_variables[i] ; + i++) + *(b->related_variables[i]) += diff; } } @@ -734,5 +765,11 @@ if (r_alloc_freeze_level) { + register int i; + bloc->variable = (POINTER *) NIL; + + for (i = 0 ; i < BLOC_RELVARS_SIZE ; i++) + bloc->related_variables[i] = (POINTER*) NIL; + return; } @@ -782,4 +819,57 @@ /* Interface routines. */ +/* Register variables should be modified according to movement of blocs */ +int +r_alloc_relate_pointer(ptr) + POINTER *ptr; +{ + register bloc_ptr p = first_bloc; + register int i; + + while (p != NIL_BLOC) + { + if (p->data <= *ptr && p->data + p->size > *ptr) + { + for (i = 0 ; i < BLOC_RELVARS_SIZE ; i++) + { + if (p->related_variables[i] == ptr) + return 0; + if (p->related_variables[i] == (POINTER*) NIL) + { + p->related_variables[i] = ptr; + return 0; + } + } + return -1; /* cannot register */ + } + p = p->next; + } + return -1; /* ptr is not bloc ? */ +} + +int +r_alloc_unrelate_pointer(var) + POINTER *var; +{ + register bloc_ptr p = first_bloc; + register int i; + + while (p != NIL_BLOC){ + for (i = 0 ; i < BLOC_RELVARS_SIZE && p->related_variables[i] ; i++){ + if (p->related_variables[i] == var) + { + memmove(p->related_variables + i, + p->related_variables + i + 1, + sizeof(*(p->related_variables)) * + (BLOC_RELVARS_SIZE - i - 1)); + p->related_variables[BLOC_RELVARS_SIZE - 1] = (POINTER*) NIL; + return 0; + } + } + p = p->next; + } + return -1; +} + /* Obtain SIZE bytes of storage from the free pool, or the system, as necessary. If relocatable blocs are in use, this means relocating @@ -865,6 +955,14 @@ for (b = last_bloc; b != NIL_BLOC; b = b->prev) { + register int i; + int diff = b->new_data - b->data; + safe_bcopy (b->data, b->new_data, b->size); *b->variable = b->data = b->new_data; + + for (i = 0 ; + i < BLOC_RELVARS_SIZE && b->related_variables[i] ; + i++) + *(b->related_variables[i]) += diff; } @@ -911,6 +1009,14 @@ for (b = first_bloc; b != NIL_BLOC; b = b->next) { + register int i; + int diff = b->new_data - b->data; + safe_bcopy (b->data, b->new_data, b->size); *b->variable = b->data = b->new_data; + + for (i = 0 ; + i < BLOC_RELVARS_SIZE && b->related_variables[i]; + i++) + *(b->related_variables[i]) += diff; } } @@ -1046,7 +1152,11 @@ if (new_bloc) { + register int i; + new_bloc->variable = ptr; *ptr = new_bloc->data; bloc->variable = (POINTER *) NIL; + for (i = 0 ; i < BLOC_RELVARS_SIZE ; i++) + bloc->related_variables[i] = (POINTER*) NIL; } else --- charset.c.org Wed Jul 28 10:27:54 1999 +++ charset.c Fri Aug 13 22:08:28 1999 @@ -213,4 +213,5 @@ const unsigned char *begp = str; + r_alloc_relate_pointer(&str); c = *str++; bytes = 1; @@ -258,4 +259,6 @@ if (actual_len) *actual_len = exclude_tail_garbage ? str - begp : bytes; + + r_alloc_unrelate_pointer(&str); return c; } @@ -1505,4 +1508,6 @@ struct cmpchar_info *cmpcharp; + r_alloc_relate_pointer(&str); + /* The second byte 0xFF means compostion rule is embedded. */ embedded_rule = (str[1] == 0xFF); @@ -1514,7 +1519,10 @@ while (endp < lastp && ! CHAR_HEAD_P (*endp)) endp++; - if (endp - str < 5) - /* Any composite char have at least 5-byte length. */ - return -1; + if (endp - str < 5) + { + /* Any composite char have at least 5-byte length. */ + r_alloc_unrelate_pointer(&str); + return -1; + } chars = 0; @@ -1526,5 +1534,8 @@ p++; if (p >= endp) - return -1; + { + r_alloc_unrelate_pointer(&str); + return -1; + } } /* No need of checking if *P is 0xA0 because @@ -1534,6 +1545,9 @@ } if (p > endp || chars < 2 || chars > MAX_COMPONENT_COUNT) - /* Invalid components. */ - return -1; + { + /* Invalid components. */ + r_alloc_unrelate_pointer(&str); + return -1; + } len = p - str; } @@ -1550,11 +1564,17 @@ if (len == cmpcharp->len && ! bcmp (str, cmpcharp->data, len)) - return CMPCHAR_HASH_CMPCHAR_ID (hashp, i); + { + r_alloc_unrelate_pointer(&str); + return CMPCHAR_HASH_CMPCHAR_ID (hashp, i); + } } /* We have to register the composite character in cmpchar_table. */ if (n_cmpchars >= (CHAR_FIELD2_MASK | CHAR_FIELD3_MASK)) - /* No, we have no more room for a new composite character. */ - return -1; + { + /* No, we have no more room for a new composite character. */ + r_alloc_unrelate_pointer(&str); + return -1; + } /* Make the entry in hash table. */ @@ -1704,4 +1724,5 @@ cmpchar_table[n_cmpchars] = cmpcharp; + r_alloc_unrelate_pointer(&str); return n_cmpchars++; } --- xdisp.c.org Sun Jul 18 01:19:36 1999 +++ xdisp.c Fri Aug 13 22:10:42 1999 @@ -3224,5 +3224,5 @@ register GLYPH *p1; int pause, limit_byte; - register unsigned char *p; + unsigned char *p; GLYPH *endp; register GLYPH *leftmargin; @@ -3306,4 +3306,5 @@ default_invis_vector[0] = default_invis_vector[1] = default_invis_vector[2]; + r_alloc_relate_pointer(&p); get_display_line (f, vpos, WINDOW_LEFT_MARGIN (w)); if (tab_width <= 0 || tab_width > 1000) tab_width = 8; @@ -4177,4 +4178,6 @@ val.ovstring_chars_done = ovstr_done; val_display_text_line = val; + + r_alloc_unrelate_pointer(&p); return &val_display_text_line; } ------------------------------------------------------------ Submitter: KOSEKI Yoshinori Subject: directory psudo i-node. Transaction: Bug report. X-ML-COUNT: 1192 Status: working ------------------------------------------------------------ 小関 吉則 (KOSEKI Yoshinori) writes: > Emacs20.3.6 以降の startup.el の > normal-top-level-add-subdirs-to-load-path では > inode を見て load-path に追加するかどうか判断しているようで > す。 > > Meadow の場合 > > (nthcdr 10 (file-attributes "h:/Meadow/site-lisp")) > (0 30675305) > > (nthcdr 10 (file-attributes "h:/Meadow/site-lisp/apel")) > (0 30675305) > > (nthcdr 10 (file-attributes "h:/Meadow/site-lisp/bbdb")) > (0 30675305) > > なので追加しないようなのです。 うーむ、昔は、Meadowは独自のinode生成機構を持っていたんだけど、 NTEmacsの方でもきちんと書いたと信じていたんだけどなぁ。;_;(涙) こりゃ、しばらくして直ってなかったら、Meadow.plan行きですな。 ## 前のモジュールを見直してみやふ。 --- w32-get-true-file-attributeがnon-nilのとき directoryのi-nodeを 生成するように変更(1.05b1)。しかし、Windows9xでは、directoryを CreateFile()できないので、この方法ではできない。 1 ... Windows9xでどうするか？ 2 ... w32-get-true-file-attributeの値はdefaultでnil or non-nil? とりあえず、NTではほぼ問題ないfile_attribute_stat()をMeadow 1.05b1で 実装済み。あとは、testerの人に意見を聞くことにする。 ;; i-node生成にはCRC-16 likeな生成多項式 x^(n-1) + x^(n-2) + x^2 + x^0を ;; 使用。 ------------------------------------------------------------ Submitter: Shun-ichi GOTO Subject: Menu bar is not refreshed when it is activated. Transaction: Bug report. X-ML-COUNT: 1197 Status: confirmed ------------------------------------------------------------ Shun-ichi GOTO writes: > というのも、Xtの場合はメニューバーをクリックした時点で > prepare_menu_bars()が実行され、その時点でkeymap評価が行われますが、 > Meadowでは(Win32のmenuの事情かとは思いますが)このタイミングでは評価され > ません。elsp-manual-20.2.5 の Menu keymapsあたりを*ざざっと*読む限りは > popup時に評価されなければいかないような*気がする*のですが。。。このへん > の動作タイミングは本当のところは「Emacsの仕様」として決められているので > しょうか。。。よくわからん。 うーん、そういう「仕様」が、あるとなると考えますけど。...;_; で、上には少し間違いが含まれています。prepare_menu_barはEmacsの状態が 変更するたびに呼ばれ、その度ごとにkeymapの評価が行われます。 > これがどういう影響があるかというと、例えばMewのdraftモードでmulti-part > メッセージの編集をしているときあらわれます。draftモードではpartを追加し > たり、partをencriptしたりするいくつかのコマンドがメニューから選択できま > すが、これはカーソル位置に応じてダイナミックにenable/disableをしています。 > そして、Xtの場合は期待通りの動作をしますが、Meadowの場合はmenu itemの > enable/disable の変化が期待したものと違ったものになってしまっています。 うーむ、なるほど、なんのことはなく、menu_bar_activate_eventを MENU描画前に送り、描画を遅らせれば良いだけの事のようです。 忘れていただけです。Meadow.plan行きですね。1.04a2で直しましょう。 ------------------------------------------------------------ Submitter: Suzuki Keiichi Subject: Color name(like X Window System) Transaction: Request for New feature. X-ML-COUNT: 1089 Status: confirmed ------------------------------------------------------------ この辺は環境に依存していると思いますので、要望の部類に入るのかも知れませ んが... 色の指定時に "rgb:ff/ff/ff" という形式を使用できるようにお願いします。 ;; X の世界では #FFFFFF という形式は obsolete になっているという話を聞い ;; た覚えがあるのですが、出典を忘れてしまいました。 ------------------------------------------------------------ Submitter: Kyotaro HORIGUCHI Subject: IME control across frames. Transaction: Bug report. Status: working ------------------------------------------------------------ > IMEの状態が違う別のフレームからフォーカスが移って来た時に元のフ > レームのIMEの状態を引きずってしまって, その後は変換ウインドウでな > いところにに1文字でも入力されれば正しい状態に戻るという現象が起き > ています. この問題は MM API が片付くまではペンディングという状態になってい ます. > もう少し細かく説明すると以下のようになります. > > 二つのフレームがあって, 片方が IME が ON, 他方が OFF だったとし > ます. > > まず, IME が ON であるフレームから OFF であるフレームにフォーカ > スが移ったときにはなぜか変換ウインドウが出てきてそちらに文字が入 > 力されてしまいます. カーソルを移動させるか, 変換文字列を確定させ > てしまうかすれば, 次からは直接入力になっています. > > 逆に IME が OFF であるフレームから ON であるフレームにフォーカス > を移したときは最初の一文字が直接バッファに入力されます. 以降の文 > 字はIMEに入力されます. これは、IMMのContext切り替えを適切に行わないとどうしても正確には 対処できない問題です。すなわち、IMM APIを使用する必要があります。 参考 : 却下されている修正方法一覧 1) WM_SETFOCUS の処理の中 から Fselect_window を呼び出す これはかなりAd-hoc な解です。この時点でFselect_windowを呼ぶの は少々危ういものがあります。(xterm.cでも消されてますなぁ。) 2)frame 構造体に ime の status を記録して WM_SETFOCUS の処理の中 でこれに基づいて ime の status を切り替える. これも ad-hoc な解である. 3) WM_SETFOCUS の処理の中から Qswitch_frame を送出する. read_filterd_event@lread.c の中で "switch-frame events are put off until after the next ASCII character." と書かれている. Qswitch_frameが特殊な処理を受けている事は事実ですが 解決策は、これをベースにworking statusに入れます。(himi) ============================================================ 追記 meadow_private_eventを導入。WM_EMACS_ACTIVATEからQswitch_frameを 発行させるために、このeventを使用。完全な解決策にはIMM APIの 整備が必要であるが、とりあえずの対策にはなっている。 ============================================================ ------------------------------------------------------------ Submitter: himi Subject: font menu selection list. Transaction: Request for New feature. Status: done ------------------------------------------------------------ SHIFT+mouse-1で表示されるメニューレイアウトを変更したい。 問題はfontの方で、頭から次のhyphenまでを一つのメニューにまとめる。 ------------------------------------------------------------ Submitter: himi Subject: call-process cannot be quit by C-g Transaction: Bug report. Status: done ------------------------------------------------------------ C-gでもprocess入力などの待ちに応答できない。 ------------------------------------------------------------ Submitter: Kobayashi Subject: Meadow hung up. X-ML-COUNT: 1111, 1179 Transaction: Bug report. Status: done ------------------------------------------------------------ こばやしです。 昨日、再現性のあるmeadowの落しかたを経験(発見)しました。 　1.ediff-files等でediffのframeを表示する。 　2.ediffのframeの最大化ボタンを押す。 　3.ediffのframeのresizeボタンを押す。 　　ここで、僕の設定では文字が豆腐表示になってしまいます。 　4.meadowのframeをマウスでつつく。 　5.ワトソン先生の登場 -------- もりさん、ありがとうございます。 mouse faceの扱いは、確かに少し変わっていたみたいです。 xterm.cからsync upして、以下のように変更しました。 ## mergin分のはみ出しが起きたときに発生するんですな。 from himi Index: mw32term.c =================================================================== RCS file: g:/repdev/Meadow/src/mw32term.c,v retrieving revision 1.6 diff -c -r1.6 mw32term.c *** mw32term.c 1999/04/30 19:01:31 1.6 --- mw32term.c 1999/05/12 00:28:01 *************** *** 2266,2277 **** FRAME_PTR f = XFRAME (WINDOW_FRAME (w)); int i; int row = 0; ! int left = w->left; int top = XFASTINT (w->top); int height = XFASTINT (w->height) - ! MINI_WINDOW_P (w); int width = window_internal_width (w); int *charstarts; int lastcol; /* Find the right row. */ for (i = 0; --- 2266,2278 ---- FRAME_PTR f = XFRAME (WINDOW_FRAME (w)); int i; int row = 0; ! int left = WINDOW_LEFT_MARGIN (w); int top = XFASTINT (w->top); int height = XFASTINT (w->height) - ! MINI_WINDOW_P (w); int width = window_internal_width (w); int *charstarts; int lastcol; + int maybe_next_line = 0; /* Find the right row. */ for (i = 0; *************** *** 2281,2286 **** --- 2282,2294 ---- int linestart = FRAME_CURRENT_GLYPHS (f)->charstarts[top + i][left]; if (linestart > pos) break; + /* If the position sought is the end of the buffer, + don't include the blank lines at the bottom of the window. */ + if (linestart == pos && pos == BUF_ZV (XBUFFER (w->buffer))) + { + maybe_next_line = 1; + break; + } if (linestart > 0) row = i; } *************** *** 2299,2305 **** else if (charstarts[left + i] > pos) break; else if (charstarts[left + i] > 0) ! lastcol = left + i; } *rowp = row + top; --- 2307,2322 ---- else if (charstarts[left + i] > pos) break; else if (charstarts[left + i] > 0) ! lastcol = left + i + 1; ! } ! ! /* If we're looking for the end of the buffer, ! and we didn't find it in the line we scanned, ! use the start of the following line. */ ! if (maybe_next_line) ! { ! row++; ! lastcol = left; } *rowp = row + top; *************** *** 2330,2343 **** for (i = mouse_face_beg_row; i <= mouse_face_end_row; i++) { ! int column = (i == mouse_face_beg_row ? mouse_face_beg_col : w->left); ! int endcolumn = (i == mouse_face_end_row ? mouse_face_end_col : w->left + width); endcolumn = min (endcolumn, FRAME_CURRENT_GLYPHS (f)->used[i]); /* If the cursor's in the text we are about to rewrite, turn the cursor off. */ if (i == curs_y ! && curs_x >= mouse_face_beg_col - 1 && curs_x <= mouse_face_end_col) { w32_display_cursor (f, 0); cursor_off = 1; --- 2347,2363 ---- for (i = mouse_face_beg_row; i <= mouse_face_end_row; i++) { ! int column = (i == mouse_face_beg_row ? mouse_face_beg_col ! : WINDOW_LEFT_MARGIN (w)); ! int endcolumn = (i == mouse_face_end_row ? mouse_face_end_col ! : WINDOW_LEFT_MARGIN (w) + width); endcolumn = min (endcolumn, FRAME_CURRENT_GLYPHS (f)->used[i]); /* If the cursor's in the text we are about to rewrite, turn the cursor off. */ if (i == curs_y ! && curs_x >= column - 1 ! && curs_x <= endcolumn) { w32_display_cursor (f, 0); cursor_off = 1; ------------------------------------------------------------ Submitter: Horiguchi Kyotaro Subject: Frame and input event synclonization. X-ML-COUNT: Transaction: Bug report Status: done ------------------------------------------------------------ At Tue, 06 Apr 1999 22:53:28 +0900 (JST), kyota@po.ntts.co.jp (Kyotaro HORIGUCHI) wrote in <19990406225328M.kyota@po.ntts.co.jp> > なんとなくですがフレームを新しく作る瞬間にナニかすると起きること > があるような気がします. まさにこのまんまでした. 新しいフレームの初期設定かなにかをしてい るときに async_handle_message (だったかな?)が WM_MOVE とかを処理 してしまうのが原因のようです. ちなみに新しいフレームのメニューバー をつついても固まります. で固める手順は以下の通りです. 他の方はこれで固められますか? 1) とりあえず meadow を起動して, C-x 5 f でたとえば ~/.emacs な んかを読みこもうとします. 2) 新しいフレーム(Windows のウインドウ)が出てきた瞬間を狙ってそ の新しいフレームのタイトルバーをつつきます. (WM_MOVE ですね多 分) これで全フレームが真っ白です. コレだけだとなんだかわたしがケンシ ロウみたいに聞こえかねないのでコツを言っておきますと. a) 最初に出てきたフレームをタイトルバー一つ分だけ下にずらしておく. b) これで新規のフレームはフレームの上側のすぐ外に現れることがわ かっているので, C-x 5 f ~/.emacs でリターンを押す前にマウスカー ソルをそこに持って行く. c) あとはリターンを押してマウスカーソルの下の景色が変わった瞬間 にクリック. タイミングはそんなにシビアじゃありません. シビア なときもありますが, そのときはバッファとフレームを消して再度 やり直せば何回かやるうちに引っかかると思います. わたしがこれを試した環境は NT on P-II 266 です. meadow -q で立ち上げた時でも同じことができます. # そもそもなんで普通に操作しているときにこんなタイミングでウィン # ドウをつつけるんだ? > 自分 # それもちょくちょくやるらしい. せっかちなのか.. ============================================================ X-ML-COUNT:1478, 1479などを参照。 Message送出の手段を変更することにより解決。 ============================================================ ------------------------------------------------------------ Submitter: Suzuki Keiichi Subject: Select-Frame problem X-ML-COUNT: Transaction: Bug report Status: pending ------------------------------------------------------------ 圭一です。 ;; いくらなんでもこれは Semi-gnus の問題ではないと思いますので。 ^^;;; 実害はそれほどないのですが、動きが怪しいところがありますので報告します。 具体的な操作の方がわかりやすいと思いますので、手順を説明します。 1. Frame が一つの状態で gnus の *Group* を表示する。 2. C-x 5 2 で frame を作る。 3. 新しい frame に表示する buffer を *scratch* に切り替える。 4. WINDOW(MS-Windowの ^^;;;)の右上の (compose-chars ?□ ?Ｘ) を click し て WINDOW を閉じる。(Do not use C-x 5 0) 5. q を入力する。 6. Buffer is read-only: # となる。 ;; そのほかに WINDOW の focus が変った直後の、一発目のキー入力処理がおか ;; しいような気がします。 ------------------------------------------------------------ Submitter: Mori Kesuke Subject: registry configuration X-ML-COUNT: Transaction: Request for new feature. Status: done ------------------------------------------------------------ > で、もう一つ、急ぎではありませんが、環境変数を設定しておくレジス > トリの位置も、バージョン毎に分けませんか? 複数バージョンを使い分 > けるときに共有できないので、今のところ片方は必ずバッチファイルを > 使わざるを得ないので。 よさげなので、1.04で入れます。 ------------------------------------------------------------ Submitter: HORIGUCHI Kyotaro Subject Drag and Drop X-ML-COUNT: Transaction: Patch for New Feature. Status: done ------------------------------------------------------------ == src/ChangeLog.Meadow ============================== 1999-04-22 Horiguchi Kyotaro * w32term.c (w32_drag_n_drop_handler, W32read_socket [case WM_EMACS_CREATE_WINDOW, WM_DROP_FILES], keyboard.c (make_lispy_event [case drag_n_drop]) Added support for Drag and Drop. * w32term.c (w32read_socket [case WM_EMACS_POPUP_MENU]) Bug Fix: Fix handling of messages not to fall into infinite loop when releasing mouse button out of pop-up menu. == lisp/ChangeLog.Meadow ============================= 1999-04-22 Horiguchi Kyotaro * term/w32-win.el (w32-drag-n-drop): Set target window with event object. --- mw32term.c.org Sun Feb 21 07:41:00 1999 +++ mw32term.c Fri Mar 26 20:18:54 1999 @@ -27,4 +27,6 @@ #include "blockinput.h" #ifdef MEADOW +#include +#include #include "mw32sync.h" #endif @@ -2539,4 +2541,29 @@ #endif +#ifdef MEADOW +int +w32_drag_n_drop_handler (frame, msg, emacs_event) + FRAME_PTR frame; + MSG* msg; + struct input_event* emacs_event; +{ + HDROP hDrop; + POINT pt; + + hDrop = (HANDLE)msg->wParam; + DragQueryPoint(hDrop, &pt); + /* DragQueryPoint returns position based on window coordination */ + emacs_event->kind = drag_n_drop; + emacs_event->code = (int)hDrop; + emacs_event->modifiers = W32GETMODIFIER; + XSETINT (emacs_event->x, pt.x); + XSETINT (emacs_event->y, pt.y); + XSETFRAME (emacs_event->frame_or_window, frame); + emacs_event->timestamp = msg->time; + + return 1; +} +#endif + /* Scroll bar support. */ @@ -2986,5 +3013,5 @@ emacs_event->part = scroll_bar_handle; #if 0 - printf("Scroll Bar Tracking...%d\n", y); + printf("Scroll Bar Positioning...%d\n", y); fflush(stdout); #endif @@ -3522,4 +3549,5 @@ POST_THREAD_INFORM_MESSAGE(main_thread_id, WM_EMACS_CREATE_WINDOW_REPLY, (WPARAM) hwnd, (LPARAM) 0); + DragAcceptFiles(hwnd, TRUE); break; } @@ -3586,4 +3614,5 @@ UINT track_flag; LPPOINT lppos; + MSG msg2; lppos = (LPPOINT)msg.lParam; @@ -3602,23 +3631,22 @@ WM_EMACS_POPUP_MENU_REPLY, (WPARAM) 0, (LPARAM) 0); - while(1) + + if (!PeekMessage(&msg2, msg.hwnd, 0, 0, PM_REMOVE)) { - MSG msg2; - - if (!PeekMessage(&msg2, msg.hwnd, 0, 0, PM_REMOVE)) - { - POST_THREAD_INFORM_MESSAGE (main_thread_id, - WM_EMACS_POPUP_MENU_REPLY, - (WPARAM) 0, (LPARAM) 0); - break; - } - if ((msg2.message == WM_COMMAND) && (HIWORD(msg2.wParam) == 0)) - { - POST_THREAD_INFORM_MESSAGE (main_thread_id, - WM_EMACS_POPUP_MENU_REPLY, - (WPARAM) msg2.wParam, (LPARAM) 0); - break; - } + POST_THREAD_INFORM_MESSAGE (main_thread_id, + WM_EMACS_POPUP_MENU_REPLY, + (WPARAM) 0, (LPARAM) 0); + } + else if ((msg2.message == WM_COMMAND) && + (HIWORD(msg2.wParam) == 0)) + { + POST_THREAD_INFORM_MESSAGE (main_thread_id, + WM_EMACS_POPUP_MENU_REPLY, + (WPARAM) msg2.wParam, (LPARAM) 0); } + else + POST_THREAD_INFORM_MESSAGE (main_thread_id, + WM_EMACS_POPUP_MENU_REPLY, + (WPARAM) 0, (LPARAM) 0); break; } @@ -3640,4 +3668,16 @@ LOWORD(msg.wParam)); } + break; + + case WM_DROPFILES: + { + if(f && !f->iconified && f->visible && + (w32_drag_n_drop_handler(f, &msg, bufp))) + { + bufp++; + count++; + numchars--; + } + } break; --- keyboard.c.org Wed Mar 03 10:38:48 1999 +++ keyboard.c Fri Mar 26 20:36:56 1999 @@ -41,4 +41,6 @@ #include "blockinput.h" #ifdef MEADOW +#include +#include #include "mw32sync.h" #endif @@ -4583,9 +4585,38 @@ which the event occurred and a list of the filenames dropped. */ + +#ifdef MEADOW + f = XFRAME (event->frame_or_window); +#else if (! CONSP (event->frame_or_window)) abort (); f = XFRAME (XCONS (event->frame_or_window)->car); +#endif + +#ifdef MEADOW + { + HDROP hDrop; + char fname[MAXPATHLEN+1]; + int nfiles, i; + + hDrop = (HDROP)event->code; + nfiles = DragQueryFile(hDrop, 0xffffffff, fname, MAXPATHLEN+1); + if (nfiles > 0) + { + DragQueryFile(hDrop, 0, fname, MAXPATHLEN+1); + files = Fcons(build_string(fname), Qnil); + for(i = 1 ; i < nfiles ; i++){ + DragQueryFile(hDrop, i, fname, MAXPATHLEN+1); + files = Fcons(build_string(fname), files); + } + } + else + files = Qnil; + DragFinish(hDrop); + } +#else files = XCONS (event->frame_or_window)->cdr; +#endif /* Ignore mouse events that were made on frames that --- w32-win.el.org Thu Feb 18 01:21:28 1999 +++ w32-win.el Fri Mar 26 20:29:18 1999 @@ -157,4 +157,5 @@ Switch to a buffer editing the last file dropped." (interactive "e") + (select-window (car (car (cdr event)))) (mapcar 'find-file (car (cdr (cdr event)))) (raise-frame)) ------------------------------------------------------------ Submitter: HORIGUCHI Kyotaro Subject: for argument editing and m17n filename. X-ML-COUNT: Transaction: Patch for Bug fix. Status: done ------------------------------------------------------------ *** callproc.c.org Wed Feb 24 18:49:48 1999 --- callproc.c Mon Mar 08 21:59:54 1999 *************** *** 383,388 **** --- 383,389 ---- display = nargs >= 4 ? args[3] : Qnil; + infile = ENCODE_FILE (infile); filefd = open (XSTRING (infile)->data, O_RDONLY, 0); if (filefd < 0) { *************** *** 393,409 **** struct gcpro gcpro1; GCPRO1 (current_dir); openp (Vexec_path, args[0], EXEC_SUFFIXES, &path, 1); UNGCPRO; } if (NILP (path)) { - #ifndef MEADOW /* For argument editing, check it later. */ close (filefd); report_file_error ("Searching for program", Fcons (args[0], Qnil)); - #else - path = args[0]; - #endif } new_argv[0] = XSTRING (path)->data; if (nargs > 4) --- 394,412 ---- struct gcpro gcpro1; GCPRO1 (current_dir); + #ifndef MEADOW openp (Vexec_path, args[0], EXEC_SUFFIXES, &path, 1); + #else + /* for script execution on MSWindows, not apply exec_only for openp */ + /* openp without exec_only returns fd not used, free it immediately */ + close(openp (Vexec_path, args[0], EXEC_SUFFIXES, &path, 0)); + #endif UNGCPRO; } if (NILP (path)) { close (filefd); report_file_error ("Searching for program", Fcons (args[0], Qnil)); } new_argv[0] = XSTRING (path)->data; if (nargs > 4) *************** *** 511,516 **** --- 514,520 ---- else if (STRINGP (error_file)) { #ifdef DOS_NT + error_file = ENCODE_FILE (error_file); fd_error = open (XSTRING (error_file)->data, O_WRONLY | O_TRUNC | O_CREAT | O_TEXT, S_IREAD | S_IWRITE); *** process.c.org Thu Feb 04 15:43:36 1999 --- process.c Mon Mar 08 21:52:00 1999 *************** *** 1162,1168 **** --- 1162,1174 ---- tem = Qnil; GCPRO4 (name, program, buffer, current_dir); + #ifndef MEADOW openp (Vexec_path, program, EXEC_SUFFIXES, &tem, 1); + #else + /* for script execution on Windows, not apply exec_only for openp */ + /* openp without exec_only returns fd not used, free it immediately */ + close(openp (Vexec_path, program, EXEC_SUFFIXES, &tem, 0)); + #endif UNGCPRO; if (NILP (tem)) report_file_error ("Searching for program", Fcons (program, Qnil)); ### This patch is needless, ### because this checks the programs that will be executed. *** w32proc.c.org Sat Feb 27 19:36:26 1999 --- w32proc.c Mon Mar 08 21:54:16 1999 *************** *** 859,864 **** --- 859,865 ---- struct gcpro gcpro1; GCPRO1 (program); + #ifndef MEADOW openp (Vexec_path, program, EXEC_SUFFIXES, &full, 1); UNGCPRO; if (NILP (full)) *************** *** 868,875 **** errno = ENOEXEC; return -1; } } ! unixtodos_filename(cmdname); } #else /* not MEADOW */ --- 869,883 ---- errno = ENOEXEC; return -1; } + #else + /* for script execution on Windows, not apply exec_only for openp */ + /* openp without exec_only returns fd not used, free it immediately */ + close(openp (Vexec_path, program, EXEC_SUFFIXES, &full, 0)); + UNGCPRO; + if (NILP (full)) + return -1; } ! #endif unixtodos_filename(cmdname); } #else /* not MEADOW */ *** lread.c.org Thu Feb 04 15:43:28 1999 --- lread.c Mon Mar 08 21:45:06 1999 *************** *** 35,40 **** --- 35,41 ---- #include "commands.h" #include "keyboard.h" #include "termhooks.h" + #include "coding.h" #endif #ifdef lint *************** *** 882,887 **** --- 883,889 ---- continue; } + filename = ENCODE_FILE (filename); /* Calculate maximum size of any filename made from this path element/specified file name and any possible suffix. */ want_size = strlen (suffix) + XSTRING (filename)->size + 1; *** ChangeLog.Meadow.org Sat Feb 27 01:17:24 1999 --- ChangeLog.Meadow Mon Mar 08 22:06:48 1999 *************** *** 1,3 **** --- 1,18 ---- + 1999-03-08 Horiguchi Kyotaro + + * callproc.c (Fcall_process), process.c (Fstart_process) + w32proc.c (sys_spawnve), + PROGRAM, INFILE, STDERR-FILE and cmdname are allowed to be a + string containing mutibyte characters (Using ENCODE_FILE to encode + string) + For argument editing, any program pathes are allowed to pass + argument editing program. (Addition to changes on 1999-02-24.) + + * lread.c (openp) + str is allowed to be a string containig multibyte characters. This + change allows to check files correctly whose names are such strings. + 1999-02-28 Miyashita Hisashi * w32.c (w32_get_long_filename):