sigurd(a)12move.de (Karl Pflästerer) writes: You are right. I guess the solution is to change blowfish.el so it uses decimal integers, but it makes the array quite difficult to compare with other tables. Is it difficult to make XEmacs understand that ?\x243f means 9279? And other integers too, of course. I'd prefer that. Other elisp packages may use it too.

On 19 Jun 2003, Stephen J. Turnbull <- stephen(a)xemacs.org wrote: I thought that. But does it then make sense to include that file longer in the official XEmacs packages? So in that form the code is b0rked. It always annoyed me that Gnus stores plain passwords and does not encode them. I had hoped to be able to use blowfish to find a solution for that problem. It is a Mule build. But as I learned at the moment it doesn't make sense to speak about Mule in 21.5. bye Karl -- "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." -- Eric S. Raymond

Simon> ?\xCAFE to work in the core could be useful in itself, and No, it's more trouble than it's worth; this is precisely what we call "Ebola" in the code. Anyway, XEmacs already has a perfectly good hexadecimal notation for integers: #xCAFE. Rationale: it's standard, even Common: http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/sec_2-4-8... Simon> then the ecrypto maintainer wouldn't have to do work. As I wrote before, Ken Handa is talking about an XEmacs-style separation of character and integer in the near future of GNU Emacs. I suspect this abuse will stop working in GNU Emacs, too, within a year or two. Simon> One way of defining useful semantic would be to have it Straining our brains to define useful semantics for erroneous constructs is not considered Righteous by XEmacs developers. Simon> translate into the hex integer 4E03. Declaring a character Simon> using its hex code seems like nonsense, What about http://www.unicode.org/Public/UNIDATA/? It _will_ make sense to resurrect this notation in the near future, for precisely that purpose. However, the reader will signal on code points that are not assigned characters. Simon> you must know the coding system too, and in that case you Simon> use 'make-char'. Apart from the ASCII subset and perhaps Simon> also the entire <256 space, for legacy reasons. So using Simon> it for integer constants seems useful, but I may be missing Simon> something. Yes. The unbridgable technical difference between the two Emacsen. :-þ This is really the "abstract data types" issue in a nutshell. When faced with the need for a hexadecimal notation for integers, GNU says "let's use a notation designed for characters because it's already there; who cares about error-checking and clarity anyway?" But XEmacs adopts a standard notation intended for integers, allowing the Lisp reader to check for non-character-valued "characters". -- Institute of Policy and Planning Sciences 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.

Simon> non-problem and will even be fixed once the elisp parser in Simon> Emacs understands ?#xCAFE. Thanks. Er, XEmacs doesn't understand that either. XEmacs understands ?\x00 for a 1-byte character, and #xCAFE for an integer (in fact, up to #7FFFFFFF). Simon> IMHO this should use a different syntax. Maybe ?\U4711 or Simon> something. Why? When it happens, Unicode will be the native character representation for XEmacs. -- Institute of Policy and Planning Sciences 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.