July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

Hrvoje Niksic

"William M. Perry" <wmperry(a)aventail.com> writes: > It also uses it to make 'dingbats' characters, and only ever uses > that on things like ?j ?i, etc, which are safe. If (make-char ...) > can take something other than an int, You misunderstand. `make-char' is kosher. `int-char' is not, and neither is `char-int'. (Except in internal code, or if you really know what you're doing.) Why do you need int-char and char-int in SOCKS?

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "William M. Perry" <wmperry(a)aventail.com> writes: > > > It also uses it to make 'dingbats' characters, and only ever uses > > that on things like ?j ?i, etc, which are safe. If (make-char ...) > > can take something other than an int, > > You misunderstand. `make-char' is kosher. `int-char' is not, and > neither is `char-int'. (Except in internal code, or if you really know > what you're doing.) I have to make the letter 'j' in a funky character set that I define, and the table I make them from has real chars in it because ?j is easier to read, and make-char will not take a char as an argument. > Why do you need int-char and char-int in SOCKS? Because I like to write things that will be reasonably sane looking like (if (= (char-int x) 5) ... ) instead of (if (= ?\005 x) ... ) At least, that looks better to me. :) -Bill P.

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: > > Hrvoje> But who cares about that? You're not supposed to be > Hrvoje> relying on the value char-int returns, right? Right. The > >> Well, yes, but in practice people do rely on that value; > > Hrvoje> Who, and what for? > > The byte-compiler uses it in couple of places, subr.el uses it I > think, w3.el uses it a lot. (I'm upgrading the system where my > notes are, I can't say more off hand.) You haven't answered the "what for" part, which was the more important bit. That the byte-compiler uses it is of no consequence because it is an integral part of the system and can be fixed by us. As for subr.el, the only mention of char-int I can find is: (define-function 'char-int 'char-to-int) Ditto for char-to-int. I haven't looked at w3 sources. > ucs-conv has a file or two that don't use much of anything else. Please don't get me started on ucs-conv.

2 participants
1 comments

Re: efs-hang on NT 24 years, 9 months

Simon Josefsson

Michael Sperber [Mr. Preprocessor] <sperber(a)informatik.uni-tuebingen.de> writes: > >> Having EFS just implementing the FTP protocol or just shipping a > >> sane FTP client with the NT port sound more and more attractive now. > > Hrvoje> Implementing FTP is impossible without support for listening sockets > Hrvoje> -- we would have to rely on the "passive" transfer mode always being > Hrvoje> available. > > Also, you'd have to implement all that gateway crap low-level. And all security extensions (kerberos 4/5 etc), which also require bignums btw. ;)

1 participants
0 comments

Bug in cua-mode.el 24 years, 9 months

Jim Horning

A while ago a ported version of cua-mode.el was sent out on this list. ;; Author: Kim F. Storm <storm(a)olicom.dk> ;; Adapted-By: SL Baur <steve(a)altrasoft.com> ;; Maintainer: SL Baur <steve(a)altrasoft.com> ;; Keywords: emulations ;; Revision: 1.3 It has worked very well in most regards but has one bug that I occasionally run into. I didn't find it in the last sumo I downloaded and I can't get to the CVS site this morning to see if a newer version is available there. This is reproducible on both my NT and Sun builds of 21.1.3 and 21.2.14 on the Sun. It also is repeatable using -vanilla, at least on the NT version. Recipe: After having loaded and activated cua-mode, select a region in an editable file and begin to perform a query-replace in it. Either after you begin typing in characters into the query replace (NT) or when you hit enter after entering the first argument (Sun) you will get an error: (1) (error/warning) Error in `pre-command-hook' (setting hook to nil): (wrong-type-argument integer-or-marker-p nil) A backtrace looks like: Signaling: (wrong-type-argument integer-or-marker-p nil) delete-region(1 nil) (if killp (if (listp killp) (copy-region-as-kill ... ...) (kill-region ... ...)) (delete-region (point) (mark))) ) CUA-delete-active-region(nil) (cond ((eq type ...) (CUA-delete-active-region t)) ((eq type ...) (setq supersede ...)) ((eq type ...) (if ... ...) (CUA-delete-active-region nil)) ((eq type ...) (setq supersede ...)) ((eq type ...) (CUA-delete-active-region nil)) ((eq type ...) (setq supersede ...)) ((eq type ...) (setq supersede ...)) (t (setq ro t))) ) (if (not ro) (cond (... ...) (... ...) (... ... ...) (... ...) (... ...) (... ...) (... ...) (t ...))) ) (progn (if (not ro) (cond ... ... ... ... ... ... ... ...)) (if ro (cond ... ...))) ) (if zmacs-region-active-p (progn (if ... ...) (if ro ...))) ) (if (eq type (quote move)) (if (memq ... ...) (and ... ...)) (if zmacs-region-active-p (progn ... ...))) ) (let ((type ...) (ro buffer-read-only) (supersede nil)) (if (eq type ...) (if ... ...) (if zmacs-region-active-p ...)) (if supersede (setq this-command ...))) ) (if (and CUA-mode (symbolp this-command)) (let (... ... ...) (if ... ... ...) (if supersede ...))) ) CUA-pre-hook() read-minibuffer-internal("Query replace: ") byte-code("..." [recursion-depth minibuffer-depth t standard-input standard-output read-minibuffer-internal prompt] 2) read-from-minibuffer("Query replace: " nil nil nil query-replace-history) query-replace-read-args("Query replace" nil) call-interactively(query-replace) delete-region is getting called with a nil for end, yet the region was active when entering query-replace so (mark) should have been defined. Sorry, I don't know where to take it from there, it looks to me like it should have worked. Regards, Jim Horning -- Jim Horning Senior Engineering Specialist, Computer Architecture Lockheed Martin Vought Systems P.O. Box 650003, M/S L14-01, Dallas, TX 75265-0003 (972)603-1560 mailto:jim.horning＠lmco.com

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >> Unfortunately, probably not true. Current Mule representation > >> has probably reached the end of the line; we're running out of > >> code space. > > Hrvoje> But who cares about that? You're not supposed to be > Hrvoje> relying on the value char-int returns, right? Right. The > > Well, yes, but in practice people do rely on that value; Who, and what for? > often that value being more reliable than a true character is the > reason they use it. How can it be more reliable than the "true character"? If there is something our API is lacking which makes Lisp coders use char-int where it's not appropriate, we should by all means improve the API. > I would be happy to break char-int and int-char beyond repair, > personally, and spend the effort to make characters reliable. I understand and concur with the latter sentiment, but not with the former. Sorry. > People who care about efficiency and transparency (ie, extensibility > and maintainability) care about internal representation. I'm sure > you could cobble up a big-buffer package out of Lisp code, but you > would rightly consider that unacceptably fragile and complicated. > It's not quite so bad with UCS-4, I admit; we could get half of that > space with a not too horrible hack. But it would be a hack, it > would hurt transparency, All of Mule is a non-transparent horrible hack. Hacking internal representation of characters is ideologically acceptable because it is not visible to the user. The same goes for the internal representation of Lisp objects, and for a bunch of other things. Simplicity of interface over simplicity of implementation! > So it really comes down to whether your "rest of us" is bigger than > mine. Hey, are now going to say that the Chinese need UCS-4, which will effectively end the discussion? :-) Seriously, it's not only about numbers, but about principles. I would hate to see Mule screwing us all by taking the bit from integers. As I said before, I don't like seeing Mule as an all-important aspect of XEmacs. > That's my last word in this thread on what we "should" do; we (both > of us) are just going in circles. When I have something usable to > show, I'll be back, of course. It's easy to come up with "something usable to show". What's *really* hard is to come up with a good design and a good implementation to match it. And I can't provide a definite answer to that any more than you can. :-(

2 participants
1 comments

move-to-column modification 24 years, 9 months

Didier Verna

I'd like to change a bit `move-to-column' to get a finer control on the FORCE argument. Sometimes, you may want to go to the precise column if that's possible (by converting tabs into characters), but not if the line is too short. My plan is to allow the FORCE argument a value special of 'coerce which means exactly that. Any other value will behave as usual. This way I don't think we break any existing code. Comments ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

Hrvoje Niksic

SL Baur <steve(a)xemacs.org> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > ... > > Note that no editor on 32-bit systems can grok a >2G buffer because of > > limited pointer size. Thus a 1G limit is just one step below the > > "theoretical" limit. You can argue that being two steps below it is > > not much worse, but I am not really convinced. > > O.K. Since size matters to you, how about another alternative? > What would/could we gain or lose by using long long as EMACS_INTs on > 32 bit architectures? We would lose portability and speed. Quite unacceptable, unfortunately. :-(

1 participants
0 comments

Re: Athena-3D scrollbars broken in 21.2.17 24 years, 9 months

SL Baur

Charles G Waldman <cgw(a)fnal.gov> writes in xemacs-beta(a)xemacs.org: > Just noticed that if you ./configure --with-scrollbars=athena3d, the > resizing of the scrollbar thingamajig (what's the right name for > that?) doesn't work. With regular Athena scrollbars it seems OK. Can you explain this in more detail? > Anybody else see this? I'm actually using the XawXpm widgets, > "posing" as Athena3d. This always worked for me with earlier versions > of XEmacs. Which version of XawXpm (I don't think it has been updated in quite a long time)? I just did my first build with XawXpm on Dec OSF, XEmacs 21.2.17/InfoDock and it looks fine to me. I will try in Linux with fresh sources this weekend. TurboLinux comes with a different flavor of 3d Athena that doesn't quite work with the `athena3d' option. uname -a: OSF1 miho.m17n.org V4.0 1091 alpha ../../xemacs-21.0/configure '--with-infodock' '--debug=no' '--error-checking=none' '--verbose' '--with-gcc' '--with-gnu-make' '--srcdir=../../xemacs-21.0' '--cflags=-g -O3' '--prefix=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../..' '--bindir=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../../bin/alpha-dec-osf' '--with-mule' '--with-scrollbars=athena3d' '--with-dialogs=athena3d' '--site-prefixes=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../..:/usr/local:/usr/decfw40' '--site-includes=/usr/decfw40/canna/include' '--site-libraries=/tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../../lib/alpha-dec-osf' '--with-pop' '--mail-locking=file' '--with-system-malloc' InfoDock 4.0.7 configured for `alphaev56-dec-osf4.0e'. Where should the build process find the source code? /tmp_mnt/project/xemacs/infodock/xemacs-21.2 What installation prefix should install use? /tmp_mnt/project/xemacs/infodock/infodock/build/alpha-dec-osf/../.. What operating system and machine description files should InfoDock use? `s/decosf4-0.h' and `m/alpha.h' What compiler should InfoDock be built with? gcc -g -O3 Should InfoDock use the GNU version of malloc? no (User chose not to use GNU allocators). Should InfoDock use the relocating allocator for buffers? yes What window system should InfoDock use? x11 Where do we find X Windows header files? /usr/dt/include Where do we find X Windows libraries? /usr/dt/lib Additional header files: /usr/decfw40/canna/include Additional libraries: /tmp_mnt/project/InfoDock/infodock/infodock/build/alpha-dec-osf/../../lib/alpha-dec-osf Additional prefixes: /tmp_mnt/project/InfoDock/infodock/infodock/build/alpha-dec-osf/../.. /usr/local /usr/decfw40 Runtime library search path: /usr/local/lib:/usr/decfw40/lib:/usr/dt/lib:/usr/shlib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in EXPERIMENTAL support for Drag'n'Drop ( CDE ). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Athena-3d scrollbars. Using Athena-3d dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access. -- 善は急げ (strike while the iron is hot)

2 participants
1 comments

Re: Patch: Promoting characters to 31 bits (for discussion) 24 years, 9 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > O.K. Since size matters to you, how about another alternative? What > would/could we gain or lose by using long long as EMACS_INTs on 32 bit > architectures? 1. Portability. Presumably gcc version < 2.8 generates awfull code for long long. Older Solaris compilers don't support it. 2. Speed. Even on a 64-bit processor a 64-bit XEmacs is much slower than a 32-bit one. 3. Yet another versioning headache. I would want 32-bit + UCS4. Jan

2 participants
1 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 July 1999