April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: 21.2.32 (CVS updated 4/19) crashes spontaneously 24 years, 7 months

Jan Vroonhof

Yoshiaki Kasahara <kasahara(a)nc.kyushu-u.ac.jp> writes: > Also, I noticed that there is something wrong with line wrapping in a > tty frame. When I lengthen a line longer than the width of the frame, > the tail of the line is disappeared and doesn't display on the next > line until I hit ^L. It never occurs in a X frame. It happens everywhere the continutation-glyph is a text glyph. I just commit Tomonori's fix into cvs. Jan

1 participants
0 comments

Re: proposed Eistring interface 24 years, 7 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > 2. With a little luck we may be able to use system-provided facilities > in some cases. IMO it is highly likely that Microsoft et al will > provide highly-optimized patented (eg) versions of some of the > algorithms. Much as I hate software patents (etc), I think users > should have the advantage of their platform. Or at the very least we can tap into all the conversions provided by libiconv (and if all its changes are merged back into glibc just those by glibc). Jan

1 participants
0 comments

proposed Eistring interface 24 years, 7 months

Ben Wing

i've created a new api for simplifying mule-correct string operations. it'll take awhile to fully implement; perhaps i could get some help, e.g. hrvoje? i will be implementing piece by piece, as necessary. here's what i have so far, and i'd like comments: (E) For working with Eistrings: ------------------------------- NOTE: An Eistring is a structure that makes it easy to work with internally-formatted strings of data. It provides operations similar in feel to the standard strcpy(), strcat(), strlen(), etc., but (a) it is Mule-correct (b) it does dynamic allocation so you never have to worry about size restrictions (and all allocation is stack-local using alloca(), so there is no need to explicitly clean up) (c) it knows its own length, so it does not suffer from standard null byte brain-damage (d) it provides a much more powerful set of operations and knows about all the standard places where string data might reside: Lisp_Objects, other Eistrings, char * data with or without an explicit length, etc. (e) it provides easy operations to convert to/from externally-formatted data, and is much easier to use than the standard TO_INTERNAL_FORMAT and TO_EXTERNAL_FORMAT macros. The idea is to make it as easy to write Mule-correct string manipulation code as it is to write normal string manipulation code. We also make the API sufficiently general that it can handle multiple internal data formats (e.g. some fixed-width optimizing formats and a default variable width format) and allows for *ANY* data format we might choose in the future for the default format, including UCS2. (In other words, we can't assume that the internal format is ASCII-compatible and we can't assume it doesn't have embedded null bytes.) All of this is hidden from the user. #### It is really too bad that we don't have a real object-oriented language, or at least a language with polymorphism! Eistring (name): Declare a new Eistring. This is a standard local variable declaration and can go anywhere in the variable declaration section, but note that you *MUST* supply the parens. ----- Initialization ----- eicpy_* (eistr, ...): Initialize the Eistring from somewhere: eicpy_ei (eistr, eistr2): ... from another Eistring eicpy_str (eistr, lisp_string): ... from a Lisp_Object string eicpy_str_off (eistr, lisp_string, charpos, charlen): ... from a section of a Lisp_Object string eicpy_str_off_byte (eistr, lisp_string, bytepos, bytelen): ... from a section of a Lisp_Object string, with offset and length specified in bytes rather than chars eicpy_buf (eistr, lisp_buf, charpos, charlen): ... from a Lisp_Object buffer eicpy_buf_byte (eistr, lisp_buf, bytepos, bytelen): ... from a Lisp_Object buffer, with offset and length specified in bytes rather than chars eicpy_raw (eistr, intdata, intlen, intfmt): ... from raw internal-format data in the specified format eicpy_c (eistr, c_string): ... from an ASCII null-terminated string. Non-ASCII characters in the string are *ILLEGAL* (read abort() with error-checking defined). eicpy_c_len (eistr, c_string, len): ... from an ASCII string, with length specified. Non-ASCII characters in the string are *ILLEGAL* (read abort() with error-checking defined). eicpy_ext (eistr, extdata, coding_system): ... from external null-terminated data, with coding system specified. eicpy_ext_len (eistr, extdata, extlen, coding_system): ... from external data, with length and coding system specified. eicpy_lstream (eistr, lstream): ... from an lstream; reads data till eof. Data must be in default internal format; otherwise, interpose a decoding lstream. ----- Getting the data out of the Eistring ----- eirawdata (eistr): eimake_string (eistr): eimake_string_sect (eistr, charpos, charlen): eimake_string_sect_byte (eistr, bytepos, bytelen): eicpyout_raw_alloca (eistr, intfmt, intlen_out): eicpyout_raw_malloc (eistr, intfmt, intlen_out): eicpyout_c_alloca (eistr): eicpyout_c_malloc (eistr): eicpyout_c_len_alloca (eistr, len_out): eicpyout_c_len_malloc (eistr, len_out): ----- Moving to the heap ----- eito_malloc (eistr): eifree (eistr): eito_alloca (eistr): ----- Retrieving the length ----- eilen (eistr): eilen_byte (eistr): ----- Working with positions ----- eicharpos_to_bytepos (eistr, charpos): eibytepos_to_charpos (eistr, bytepos): ----- Getting the character at a position ----- eiref (eistr, charpos): eiref_byte (eistr, bytepos): ----- Concatenation ----- eicat_* (eistr, ...): Concatenate onto the end of the Eistring, with data coming from the same places as above. (All functions that take string sources allow only two possibilities: Another Eistring and a simple C string. In the general case, create another Eistring from the source.) eicat_ei (eistr, eistr2): eicat_c (eistr, c_string): ----- Replacement ----- eisub_* (eistr, charoff, charlen, ...): eisub_*_byte (eistr, byteoff, bytelen, ...): Replace a section of the Eistring. eisub_ei (eistr, charoff, charlen, eistr2): eisub_ei_byte (eistr, byteoff, bytelen, eistr2): eisub_c (eistr, charoff, charlen, c_string): eisub_c_byte (eistr, byteoff, bytelen, c_string): ----- Converting to an external format ----- eito_external (eistr, coding_system): eiextdata (eistr): eiextlen (eistr): ----- Searching in the Eistring for a character ----- eichr (eistr, chr): eichr_byte (eistr, chr): eichr_off (eistr, chr, charpos): eichr_off_byte (eistr, chr, bytepos): eirchr (eistr, chr): eirchr_byte (eistr, chr): eirchr_off (eistr, chr, charpos): eirchr_off_byte (eistr, chr, bytepos): ----- Searching in the Eistring for a string ----- eistr_ei (eistr, eistr2): eistr_ei_byte (eistr, eistr2): eistr_ei_off (eistr, eistr2, charpos): eistr_ei_off_byte (eistr, eistr2, bytepos): eirstr_ei (eistr, eistr2): eirstr_ei_byte (eistr, eistr2): eirstr_ei_off (eistr, eistr2, charpos): eirstr_ei_off_byte (eistr, eistr2, bytepos): eistr_c (eistr, c_string): eistr_c_byte (eistr, c_string): eistr_c_off (eistr, c_string, charpos): eistr_c_off_byte (eistr, c_string, bytepos): eirstr_c (eistr, c_string): eirstr_c_byte (eistr, c_string): eirstr_c_off (eistr, c_string, charpos): eirstr_c_off_byte (eistr, c_string, bytepos): ----- Comparison ----- eicmp_* (eistr, ...): eicmp_off_* (eistr, charoff, charlen, ...): eicmp_off_*_byte (eistr, byteoff, bytelen, ...): eicasecmp_* (eistr, ...): eicasecmp_off_* (eistr, charoff, charlen, ...): eicasecmp_off_*_byte (eistr, byteoff, bytelen, ...): Compare the Eistring with the other data. Return value same as from strcmp. eicmp_ei (eistr, eistr2): eicmp_off_ei (eistr, charoff, charlen, eistr2): eicmp_off_ei_byte (eistr, byteoff, bytelen, eistr2): eicasecmp_ei (eistr, eistr2): eicasecmp_off_ei (eistr, charoff, charlen, eistr2): eicasecmp_off_ei_byte (eistr, byteoff, bytelen, eistr2): eicmp_c (eistr, c_string): eicmp_off_c (eistr, charoff, charlen, c_string): eicmp_off_c_byte (eistr, byteoff, bytelen, c_string): eicasecmp_c (eistr, c_string): eicasecmp_off_c (eistr, charoff, charlen, c_string): eicasecmp_off_c_byte (eistr, byteoff, bytelen, c_string): ----- Case-changing the Eistring ----- eilwr (eistr): eiupr (eistr): And the implementation: /* ------------------------------ */ /* (E) For working with Eistrings */ /* ------------------------------ */ typedef struct { void *data; Bytecount bytelen; Charcount charlen; int mallocp; void *extdata; Extcount extlen; } Eistring_; Eistring_ the_eistring_zero_init; #define Eistring(name) Eistring_ name = the_eistring_zero_init #define EI_ALLOC_(ei, charlen_, bytelen_) do { ei.charlen = charlen_; ei.bytelen = bytelen_; if (ei.mallocp) ei.data = xmalloc (ei.bytelen + 1); else ei.data = alloca (ei.bytelen + 1); } while (0) #define EI_ALLOC_AND_COPY_(ei, data_, charlen_, bytelen_) do { EI_ALLOC_ (ei, charlen_, bytelen_); memcpy (ei.data, data_, ei.bytelen + 1); } while (0) #define eicpy_ei(ei, ei2) do { Eistring__ *ei__ = &ei2; EI_ALLOC_AND_COPY_ (ei, ei__->data, ei__->charlen, ei__->bytelen); } while (0) #define eicpy_str(ei, lisp_string) do { Lisp_Object ei__ = lisp_string; EI_ALLOC_AND_COPY_ (ei, XSTRING_DATA (ei__), XSTRING_CHAR_LENGTH (ei__), XSTRING_LENGTH (ei__)); } while (0) -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

3 participants
25 comments

RE: proposed Eistring interface 24 years, 7 months

Bill Tutt

> From: Stephen J. Turnbull [mailto:turnbull＠sk.tsukuba.ac.jp] > > >>>>> "Bill" == Bill Tutt <billtut(a)microsoft.com> writes: > > Bill> You might indeed. I'm not exactly sure why you'd want to do > Bill> that, but that's you call. :) Seems like a waste of a large > Bill> chunk of memory if you make it your internal representation > Bill> without a fairly compelling reason.... > > _Default_ internal representation. UCS-2 is a massive waste of space > if an ISO-8859 set will do. > We plan to allow at least 1-byte and > variable width internal representations, and then extend to 2-byte and > 4-byte internal representations. The default internal representation > being discussed here would be used for internal buffering etc, and > would not (as planned, anyway) be imposed on editing buffers or Lisp > strings. > > See my other message for further discussion. > >From an earlier note of yours: > So what happens if you have > data that is not representable in the default internal > representation? Do we just tell those users to get lost? Why do you want more than one internal representation? Is it so you can handle displaying those CJK character s that Unicode still hasn't specified slots for? (Family names, or company specific characters come to mind) Why couldn't you simply define a mapping from the appropriate non-UTF-16 format into some part of the Unicode private use space until such a time as the problem in Unicode is either fixed or Unicode encourages use of the private use space for these characters? > It would be kind of weird if the default internal representation > that Eistrings dealt with was UCS-2 but UTF-8 representation was > available in buffers, which you don't rule out. My personal opinion is that you pick one internal representation and stick with it. It would definately make life simpler. > You may not consider it compelling, but looking at the history of Mule > over the last 12 years, I think it is nearly certain that some people, > probably including Ken'ichi Handa, will want access to a language-tag- > in-character representation. I don't disagree. See (http://www.unicode.org/unicode/reports/tr7/) for where those proposed notations exist. They're in plane-14 which certainly is encodeable by UTF-16. (via surrogate pairs) I'm sure the folks in MS Word will eventually want to do something along those lines so they can spell/grammar check multi-language documents. > Unlike Henry Ford, we do not plan to > allow people to use any character set they like "as long as it's > black." I'm pretty sure that some of the people we would most like to > have using XEmacs (Japanese Mule developers) would be quite adamently > opposed to UTF-16. > I'm not sure what the point of this is. The way the encoding the source code is stored under doesn't mean that it doesn't make some sense to only use one internal encoding. I'm just saying that I think UTF-16 seems to make some sense as a candidate. If you're referring to the Japanese Mule developers disliking having to deal with a UTF-16 internal representation then you kind of have a problem. Getting back to Ben's proposed Eistring interface. I don't think I saw any functions related to helping you iterate sequentially over characters in the internal encoding. (whatever it is) Those would certainly be necessary if you were to use UTF-16, or indeed for some reason needed to change your internal encoding to take up even more space. Bill

2 participants
1 comments

Re: UCS-4 private use spave 24 years, 7 months

Bill Tutt

Just as an FYI on the UCS-4 private use space: On 2000-03-07, the Unicode Technical Comitte submitted document "N2175" to ISO/IEC JTC1/SC2/WG2 titled: "Proposal to restrict the range of code positions to the values up to U-0010FFFF" Summary: The Unicode consortium requests a remedy to this situation: the publication of a technical corrigendum to ISO/IEC 10646-1:2000 which excludes values above U-0010FFFF. In this corrigendum, * The private use characters from U-60000000 to U-7F000000 and from U-00E00000 to U-00FFFFFF would be removed from the standard. * A note would be added stating that for interoperability between UTF-8, UTF-16 and UCS-4, it is not expected that any code positions will ever be allocated above U-0010FFFF. URL: http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm On 2000-03-24 WG2 accepted the proposal: (from the minutes of the meeting: http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2204.doc) WG2 accepts the proposal in document N2175 towards removing the provision for Private Use Groups and Planes beyond Plane 16 in ISO/IEC 10646, to ensure internal consistency in the standard between UCS-4, UTF-8 and UTF-16 encoding formats, and instructs its project editor prepare suitable text for processing as a future Technical Corrigendum or an Amendment to 10646-1: 2000. FYI, Bill

2 participants
1 comments

Re: XEmacs frame as a glyph instantiator? 24 years, 7 months

William M. Perry

Andy Piper <andy.piper(a)bea.com> writes: > At 02:26 PM 4/19/00 -0500, William M. Perry wrote: > >Would it be possible to create a 'xemacs' glyph type? This way you could > >put a XEmacs 'frame' inside a layout with the new stuff andy has done. > > You should already be able to do this by using the subwindow support. Jan > tried this and it crashed I believe. > > I'm currently trying to extend the glyph stuff to support tabs in the way > Ben wants. This may make it easier to do this as well. I was just thinking that if you combine the gtk stuff, your glyph stuff, and a xemacs-window as a widget, you could just specify the look of the main emacs frame as a glyph set. You create the menubar, toolbar, etc, stick them where you want, and voila. -bp

1 participants
0 comments

please answer the dialog box 24 years, 7 months

Michael Harnois

I've seen now in a couple of contexts that actions which pop up a dialog box hang my XEmacs, no matter what answer I give to the box. I just had to kill to get out; no number of C-g would break out. Lisp backtrace follows: next-command-event(#<empty-event>) byte-code("..." [next-command-event event misc-user-event-p event-object yes throw ynp-done t no nil abort menu-no-selection-hook signal quit button-release-event-p beep message "please answer the dialog box"] 3) # (catch ynp-done ...) # bind (echo-keystrokes event prompt) yes-or-no-p-dialog-box("Buffer *sent reply to BRIAN STOFFREGEN* modified; kill anyway? ") # bind (prompt) yes-or-no-p("Buffer *sent reply to BRIAN STOFFREGEN* modified; kill anyway? ") kill-buffer(#<buffer "*sent reply to BRIAN STOFFREGEN*">) #<compiled-function nil "...(4)" [kill-buffer] 2 991415 nil>() call-interactively(kill-this-buffer) funcall(call-interactively kill-this-buffer) # bind (widget-callback-current-channel) (let ((widget-callback-current-channel #<x-frame "emacs" 0x27ca>)) (funcall (quote call-interactively) (quote kill-this-buffer))) ) eval((let ((widget-callback-current-channel #<x-frame "emacs" 0x27ca>)) (funcall (quote call-interactively) (quote kill-this-buffer)))) # (condition-case ... . error) # (catch top-level ...) uname -a: Linux mharnois.workgroup.net 2.3.99-pre6 #6 Sun Apr 16 08:34:31 CDT 2000 i686 unknown ../xemacs-21.2/configure '--srcdir=/usr/src/xemacs-21.2' '--with-mule' '--extra-verbose' '--with-gpm=no' '--site-includes=/usr/include/postgresql' '--site-libraries=/usr/lib/postgresql' '--with-athena=xaw' '--cflags=-g -O6 -march=i686' '--use-union-type' '--with-clash-detection' '--error-checking=none' '--with-xfs' '--with-menubars=lucid' '--with-modules' XEmacs 21.2-b32 "Kastor & Polydeukes" configured for `i686-pc-linux'. Compilation / Installation: Source code location: /usr/src/xemacs-21.2 Installation prefix: /usr/local Additional header files: /usr/include/postgresql Additional libraries: /usr/lib/postgresql Operating system description file: `s/linux.h' Machine description file: `m/intel386.h' Compiler: gcc -g -O6 -march=i686 Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11R6/include - X Windows libraries location: /usr/X11R6/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Compiling in support for ESD (Enlightened Sound Daemon). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL V7 bindings. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. - Using XFontSet to provide bilingual menubar. Compiling in support for Canna on Mule. Compiling in support for the WNN input method on Mule. - Using WNN version 6. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Compiling in support for dynamic shared object modules. Clash detection will use "${statedir}/${inststaticdir}/lock" for locking files. Using the union type for Lisp_Objects. Compiling in support for extra debugging code. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org God made everything out of nothing, but the nothingness shows through. -- Paul Valery

4 participants
3 comments

RE: proposed Eistring interface 24 years, 7 months

Bill Tutt

> From: Ben Wing [mailto:ben＠666.com] > > there are numerous reasons we want our own internal char > points -- handling of > precomposed chars, non-char objects in the buffer, etc. not > only eudc's. > Hrm. Those are certainly possibilities, I'm afraid I don't know enough about how the current small crop of complex script Unicode rendering engines work to say whether or not this (precomposed chars) makes any sense or not. I would tend to lean towards not though. There are so many composable character combinations that fall out of Unicode that its not even funny. In fact the rendered appearance of some character combinations in Unicode may depend on its surrounding context as opposed to a sequence of composable Unicode code points. Arabic, and the Indian family of languages are especially nasty in this regard. Examples of nasty rendering problems: Character shaping: (Arabic) http://www-4.ibm.com/software/developer/library/hindi-thai/sld005.htm Required use of ligatures (Arabic and Devanagari): http://www-4.ibm.com/software/developer/library/hindi-thai/sld006.htm Bizarre repositioning of multiple combining marks over a single base character: http://www-4.ibm.com/software/developer/library/hindi-thai/sld007.htm There are also a couple other problems that make rendering generic Unicode text a pain in the ass. The beginning of the slide deck (Arabic, Hebrew, Hindi, and Thai support in IBM's Java 2) is at: http://www-4.ibm.com/software/developer/library/hindi-thai/sld001.htm Non-character objects in the buffer: Hrm. This seems like the best reason I've heard so far. (Remembering that I have no idea how XEmacs currently exposes these beasts to ELisp code scrounging through the buffer) Although I think I'd rather have some other way to access non-character objects in a buffer, other than walking through the internal representation. Of course there might be a need to keep these bits of info hidden from ELisp completly which wouldn't be so bad. Bill > use of an internal representation mostly compatible with > unicode is *purely* for > convenience. there is no real necessity in doing it, and we > certainly don't > need to contort things to agree with some outside interfaces, > because the > internal representation never escapes. we could just as > easily define a rot13 > transformation of unicode values for our representation! > > Bill Tutt wrote: > > > > From: Ben Wing [mailto:ben＠666.com] > > > > > > portability? > > > > > > > I'm not quite sure what you mean here. Why isn't the > concept/mapping that > > the registry setting values embody portable to some other > configuration > > state on other OSes? > > Heck, you could even combine the concept with the Plane 14 > languages tags to > > tell you which codeset mapping to use for a certain run of > characters. > > > > Bill > > > > > Bill Tutt wrote: > > > > > > > > From: Ben Wing [mailto:ben＠666.com] > > > > > > > > [cool mappings yanked for space] > > > > > > > > Ah, ok, then its most likely a simple 1-1 mapping based > on the EUDC > > > > CodeRange data in the registry. In which case you can't > depend on a > > > > hardwired mapping. > > > > > > > > > > > (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodeP > > > age\EUDCCodeRa > > > > nge) > > > > > > > > Is there any particular reason this method of encoding > > > isn't a good enough > > > > extension for unassigned UTF-16 safe ranges, or do you just > > > not want to > > > > bother touching the code when we discover the loads of > > > alien races that are > > > > out there? > > > > > > > > Bill > > > > > > -- > > > Ben > > > > > > In order to save my hands, I am cutting back on my mail. > I also write > > > as succinctly as possible -- please don't be offended. > If you send me > > > mail, you _will_ get a response, but please be patient, > especially for > > > XEmacs-related mail. If you need an immediate response > and it is not > > > apparent in your message, please say so. Thanks for your > > > understanding. > > > > > > See also http://www.666.com/ben/typing.html. > > > > > > > > -- > Ben > > In order to save my hands, I am cutting back on my mail. I also write > as succinctly as possible -- please don't be offended. If you send me > mail, you _will_ get a response, but please be patient, especially for > XEmacs-related mail. If you need an immediate response and it is not > apparent in your message, please say so. Thanks for your > understanding. > > See also http://www.666.com/ben/typing.html. > >

1 participants
0 comments

RE: proposed Eistring interface 24 years, 7 months

Bill Tutt

> From: Ben Wing [mailto:ben＠666.com] > > portability? > I'm not quite sure what you mean here. Why isn't the concept/mapping that the registry setting values embody portable to some other configuration state on other OSes? Heck, you could even combine the concept with the Plane 14 languages tags to tell you which codeset mapping to use for a certain run of characters. Bill > Bill Tutt wrote: > > > > From: Ben Wing [mailto:ben＠666.com] > > > > [cool mappings yanked for space] > > > > Ah, ok, then its most likely a simple 1-1 mapping based on the EUDC > > CodeRange data in the registry. In which case you can't depend on a > > hardwired mapping. > > > > > (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodeP > age\EUDCCodeRa > > nge) > > > > Is there any particular reason this method of encoding > isn't a good enough > > extension for unassigned UTF-16 safe ranges, or do you just > not want to > > bother touching the code when we discover the loads of > alien races that are > > out there? > > > > Bill > > -- > Ben > > In order to save my hands, I am cutting back on my mail. I also write > as succinctly as possible -- please don't be offended. If you send me > mail, you _will_ get a response, but please be patient, especially for > XEmacs-related mail. If you need an immediate response and it is not > apparent in your message, please say so. Thanks for your > understanding. > > See also http://www.666.com/ben/typing.html. > >

2 participants
1 comments

Re: please answer the dialog box 24 years, 7 months

Michael Harnois

I'd be absolutely delighted to have anyone fix it, myself. It causes serious fuckage when I'm reading mail ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org A free society is one where it is safe to be unpopular. -- Adlai Stevenson

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 April 2000