Aidan> Ar an séiú lá de mí na Nollaig, scríobh Uwe Brauer: Aidan> The state of the art is annoyingly bad; we don’t support Aidan> Quail’s Hebrew input method. So wait, there are two questions: - is there quail in xemacs 21.4.17 (debian) if so I can't find them. If there are no quail pkg anymore which pkg is responsible for the input? - how difficult would it be to write a quail (or else) pkg for Hebrew input. One could not just take the one of GNU Emacs? Uwe

Aidan> Ar an seachtú lá de mí na Nollaig, scríobh Uwe Brauer: Aidan> Quail is part of the leim XEmacs package. Ah, ok, I found it, grr in Debian there are only the elc files I have to search for the el files. Strange strange I thought I had seen once such a quail Hebrew pkg, my memory. Aidan> One could probably do so. I loaded it in 21.5 out of Aidan> curiosity while writing an answer to your last mail, and it Aidan> seems our ISO 2022 Hebrew character set identifier doesn’t Aidan> match theirs, so you would need to load it in GNU Emacs, Aidan> change the coding cookie and save it as iso-8859-8 instead Aidan> of iso-2022-7. What do you mean by changing the coding cookies? Aidan> (If and when you have experience with GNU Emacs and their Aidan> BiDi support, I’d love if you’d post a summary of the Aidan> situation here. I’d like to know what’s happening there.) Ha, do you know about nntp+news.gmane.org:gmane.emacs.bidi? The situation is roughly like this. As early as 19.34 the (then not merged) mule emacs had Hebrew Bidi support, (and visual cursor movement which I loved). However searching did not work, since there where problems with the minibuffer. Then there started a discussion of how to implement that BIDI alg for emacs 20. (I think 5 years ago there was a conference in Japan about that I tried (successfully) to encourage Stephen Turnbull to participate), however sadly enough, the xemacs team was left out in the following discussions about the implementation. Unfortunately GNU emacs had then also a chance in its Display engine which made most of the old 19.34 code obsolete. It is also sad to note, that not one single Hebrew hacker participated, besides Eli Z. (and Ehud Karni which has written some lisp pkg for visual hebrew). So finally the algorithm which was agreed upon was implemented by Eli. It was then decided to leave it in non-ready 21.3 http://www.m17n.org/emacs-bidi/ And not to include in into the current development. So in short there is some code which does things better than 19.34, searching for example, even supports nikkud, but still lacks visual cursor movement and worst of all is not included in any kind of development. Hope this helps Uwe

Aidan> No, I didn’t. It’s not an _immediate_ concern for me, but Aidan> if I keep up the Tajik I’ll need BiDi late next year to Aidan> deal with Persian, with which it is mutually Aidan> intelligible. So thank you for the summary :-) . Please keep me (and Ben, for that matter) in the loop. I have only an academic interest in it (I believe the same is true for Ben), but we do care. Basically what happened at the M17N conference was that Karni made it plain that he had no interest whatsoever in working with XEmacs (I don't recall any hostility, just he was happy enough with Emacs and didn't feel like exerting any effort to work on portablity), so we would have had to do it all ourselves. At that time Eli Z didn't really care if Emacs got bidi (he was using some other editor for that). And we had other issues to worry about, so it got shelved for a while. I still have the R2L ASCII charset and the r2l and l2r faces I played with back then around somewhere. :-) -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Aidan Kehoe wrote: i think it's more that some r2l features were inherited from mule 2.3; whatever it had, we still have.

Aidan Kehoe <kehoea(a)parhasard.net&gt; writes: You'd have to ask Eli, but as far as I remember, the state is not fit for general consumption, there are crashes and performance vortices and stuff, development is pretty much dormant and it is not slated for inclusion in Emacs 23.1 (and yes, I can count). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum