September 1999 - XEmacs-Beta - XEmacs Mailing List Archives

UTF-2000 Version 0.5 (天王寺) 25 years, 2 months

守岡知彦 / MORIOKA Tomohiko

[主な変更点] ・メンテナンス上の理由から --with-ucs4 を、一旦、廃止した・configure で --with-utf-2000 を指定した時、message を出すようにした・charset ができるだけ leading-byte に依存しないようにした（つもり）・128×128 文字集合と 256×256 文字集合を追加（ただし、まだ利用者は定義できない）・BMP に対する charset である ucs-bmp を追加した・00群E0面〜00群FF面の割り当て法を変更し、94文字集合80×4面、96文字集合80×4面、94×94文字集合80面分、96×96文字集合80面分の領域を確保した・Latin Extended-A に含まれている文字は BMP のを使うようにした(*1) ・Charset_ID 型を導入し、unsigned char や Bufbyte, int になっていた部分をこれで書き換えた（つもり、でも、まだ残っているような気がする）・UTF-2000 では charset の direction 属性を廃止することにした [注意] ・内部表現を一部変更したので以前の版で compile した非 ASCII 文字を含む *.elc は動きません [今週のバッタモン] ・(*1) latin_a_char_to_*: 将来的には一般的かつ編集可能な形にする予定・ucs4, big5 等の coding-system は動かない・ExCCL は一切動かない [今回採用した私的領域割り当て法の概要] 00E00000 | compatibility zone (= 00EC1F00 〜 00EE0237) 00E1E337 00E20000 | 中華字海コード 00E3FFFF 00E40000 | 京大康煕コード 00E4FFFF 00E50000 | 諸橋大漢和番号 + 文字鏡 00E5FFFF 00E60000 | 文字鏡 00E7FFFF 00E80000 | reserved 00E8FFFF 00E90940 | private 94-set 00E90F1F 00E90F20 | official 94-set 00E92641 00E92642 | reserved for 94-set 00E9269F 00E926A0 | private 96-set 00E92C9F 00E92CA0 | official 96-set 00E9443F 00E94440 | reserved for 96-set 00E9449F 00E944A0 | second 94-set 00E961FF 00E96200 | second-96 00E97FFF 00E98000 | third 94- and 96-set 00E9BB5F 00E9BB60 | forth 94- and 96-set 00E9F6BF 00E9F6C0 | private 94x94 00EC1EFF 00EC1F00 | official 94x94 00F49D7B 00F49D7C | reserved for 94x94 00F4BFFF 00F4C000 | private 96x96 00F6FFFF 00F70000 | official 96x96 00FFDBFF 00FFDC00 | reserved for 96x96 00FFFFFF [前回の予告に関して] MAKE_CHAR および BREAKUP_CHAR で table を引くようにする。とりあえず、database 機能を使うつもりです。また、最初の版は多分 cache なしにすると思います。と述べたが、これを実現するためには charset を手なづける必要があった。即ち、内部表現を UTF-2000 (UTF-8) 方式に変更したにも関わらず、charset が leading-byte (charset-id) に強く依存し、128 個以上に増やせなかったり、charset と文字表現の関わりを自由に定義することができなかった。このため、まず、この問題を解決する必要があった。このため、今回はこの問題に取り組んだ。 [次回の予定] charset を手なづける上で、なお問題として残っているのが char-table と regexp.c である。いつかは手をつけないといけない問題なので、次回は char-table の再実装を行うことにする。個人的には char-table は永続的な実装を基本としたいが、現在の実装からの移行の容易さを考慮すると、結局、まず半田 UTF-8 方式の char-table 実装を行うのが良いと考えられるので、これを試してみることにする。 -- ┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━ ││ ─ │ ─ ／ ─ ┼─ ┬ ─ ─┼ ┬┴─ ┼┼─┼|〓━─┼ 守岡知彦 (MORIOKA Tomohiko) <tomo(a)etl.go.xn--jp>-8r4a ─┬ ┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3 participants
2 comments

Re: Knee-deep in the isearch 25 years, 2 months

Hrvoje Niksic

"Charles Hines" <chuck_hines(a)VNET.IBM.COM> writes: > Since you're wading through isearch-mode, if you happen to run > accross a fix for the problem with using it's history mechanism, > that'd be real cool. :) You don't follow xemacs-patches, do you? :-) I fixed that bug last week. It's been annoying me for ages. If you're curious, I can tell you where the bug was.

3 participants
2 comments

Re: Knee-deep in the isearch 25 years, 2 months

Hrvoje Niksic

"Charles Hines" <chuck_hines(a)VNET.IBM.COM> writes: > Actually, so as not to waste more of your time I just searched the > xemacs-patches archive and believe I found it - your "Isearch: C-s > M-p brought to order" posting, right? That's the one. However, I made more changes to isearch.el before and after that, and I'm not sure if the patch can stand on its own.

2 participants
1 comments

Searching invisible text 25 years, 2 months

Hrvoje Niksic

I think FSF's feature for (not) searching invisible text sucks the way they currently implement it. Because of this, I've redone it. To see what I mean, start FSFmacs, make an invisible overlay in *scratch*, put the `isearch-open-invisible' property, and play. 1) If the current match only partially overlaps the overlay, it is not opened. 2) If isearch-hide-immediately is t (the default), the overlay is closed when you advance the match. However, if you press backspace to restore the match back into the overlay, it is not reopened. 3) The interface for "modes [that] would want to open the overlays temporary during isearch in their own way" (the `isearch-open-invisible-temporary' property) is simply splendid. Just look at the difference between opening and closing funcall. 4) The function names are totally weird, including spelling mistakes. Damn me if I can understand why isearch-open-necessary-overlays is called thus. Opinions?

1 participants
0 comments

Emergency patch: mswindows completely hosed 25 years, 2 months

Andy Piper

The portable dumper changes have completely hosed mswindows, I think its something to do with the opaque_ptr changes. mswindows uses these to store menu item ids in a hash table. It looks like that emacs is unable to get the items out of the hash table. The following patch fixes things although I do not understand the code enough to know whether this is the correct patch. I'll apply this tomorrow unless someone comes up with a correct patch. andy 1999-08-31 Andy Piper <andy(a)xemacs.org> * opaque.c (equal_opaque_ptr): define. (hash_opaque_ptr): define. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
4 comments

Knee-deep in the isearch 25 years, 2 months

Hrvoje Niksic

Isearch is shaggadelic! Yeah baby yeah!

2 participants
1 comments

Re: Hash table implementation merge with Gerd's for GNU Emacs 25 years, 2 months

Gerd Moellmann

Martin Buchholz <martin(a)xemacs.org> writes: > These changes are the result of a API compromise between myself and > Gerd Moellman, who has implemented hash tables for the FSF. > > Basically, we both agreed to implement the keyword > > :weakness nil or t or 'key or 'value > > for make-hash-table. > Thanks, Martin. I've also done what we talked about. - make-hash-table with :weakness - copy-hash-table - hash-table-weak -> hash-table-weakness

1 participants
0 comments

Re: "different size in shared object" message when running 25 years, 2 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > There doesn't seem to be an xaw-dev package, only an xaw3dg-dev > package. If you don't have xaw3dg-dev installed, you could try > installing that. If you do, you could try uninstalling that. I don't have it; I'll now try to install it and return the 3D stuff to ld.so.conf. > I don't recommend uninstalling either xaw3dg itself or the > xaw-wrappers package; I suspect that a lot of Debian's stock X stuff > is linked against xaw, and presumably xaw3d. Some of it might give > you the same headache in reverse. I don't think that would be a problem; I've removed the 3D stuff from ld.so.conf, and everything still worked. But maybe I didn't try the right things.

4 participants
6 comments

VM 6.72, XE 21.2.19, mime: vm-scroll-forward problem 25 years, 2 months

Giacomo Boffi

my setup: (insert (emacs-version)) XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i586-pc-linux) of Fri Jul 30 1999 on boffi95.stru.polimi.it (insert (vm-version)) 6.72 when i read a mime message (e.g., andy piper's messages to xemacs-beta), SPACE (bound to vm-scroll-forward) doesn't work correctly any more, i.e., when i hit the end of the message, VM does not advance to the following message, and i have to use 'n', or the mouse, to advance to the next message i'm not using tm (as far as i can tell), and the message is displayed in an "INBOX Presentation" buffer

1 participants
0 comments

Re: Merge. 25 years, 2 months

Hrvoje Niksic

Craig Main <CraigM(a)afa.co.za> writes: > I find it annoying that there are two versions of essentially the > same resource. I don't understand why legal papers should be > required for code that nobody claims ownership to. For what it's worth, Stallman says he needs them to be able to defend the GPL in court. That argument comes from the now-legendary legal advice that the FSF allegedly received a long time ago and that created the basis for the whole assignment mess. There are people who dispute the validity of the claim ("advice"), but the point is moot, as none of it has been tested in a court of law. > It just makes so much sense to me to have one emacs. Since the X > version is more modern etc etc, it should be the obvious choice. Eh, if only it were that simple! FSF's Emacs is also X-aware. > If this is a vaguely democratic process, my vote goes with one > Xemacs. Keep up the good work. You guys are doing a fantastic job. Thanks.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta September 1999