Re: proposed Eistring interface

Here is a typical example (er ... the first fun converted to Eistrings): static WIN32_FIND_DATA * mswindows_get_files (Lisp_Object dirfile, int nowild, Lisp_Object pattern, int hide_dot, int hide_system, int *nfiles) { WIN32_FIND_DATA *files; int array_size; struct re_pattern_buffer *bufp = NULL; int findex; Eistring (win32pattern); HANDLE fh; /* * Much of the following code and comments were taken from dired.c. * Yes, this is something of a waste, but we want speed, speed, SPEED. */ files = NULL; array_size = *nfiles = 0; while (1) { if (!NILP (pattern)) { /* PATTERN might be a flawed regular expression. Rather than catching and signalling our own errors, we just call compile_pattern to do the work for us. */ bufp = compile_pattern (pattern, 0, 0, 0, ERROR_ME); } /* Now *bufp is the compiled form of PATTERN; don't call anything which might compile a new regexp until we're done with the loop! */ /* Initialize file info array */ array_size = 100; /* initial size */ files = xnew_array (WIN32_FIND_DATA, array_size); /* for Win32, we need to insure that the pathname ends with "\*". */ eicpy_str (win32pattern, dirfile); if (!nowild) { Charcount len = eilen (win32pattern) - 1; if (!IS_DIRECTORY_SEP (eiref (win32pattern, len))) eicat_c (win32pattern, "\\"); eicat_c (win32pattern, "*"); } eito_external (win32pattern, Qmswindows_tstr); /* * Here, we use FindFirstFile()/FindNextFile() instead of opendir(), * stat(), & friends, because stat() is VERY expensive in terms of * time. Hence, we take the time to write complicated Win32-specific * code, instead of simple Unix-style stuff. */ findex = 0; fh = INVALID_HANDLE_VALUE; while (1) { Bytecount len; Eistring (filename); int result; if (fh == INVALID_HANDLE_VALUE) { fh = FindFirstFile (eiextdata (win32pattern), &files[findex]); if (fh == INVALID_HANDLE_VALUE) { report_file_error ("Opening directory", list1 (dirfile)); } } else { if (!FindNextFile (fh, &files[findex])) { if (GetLastError () == ERROR_NO_MORE_FILES) { break; } FindClose (fh); report_file_error ("Reading directory", list1 (dirfile)); } } eicpy_ext (filename, files[findex].cFileName, Qmswindows_tstr); if (!NILP (Vmswindows_downcase_file_names)) { eilwr (filename); } len = eilen (filename); result = (NILP (pattern) || (0 <= re_search (bufp, eirawdata (filename), len, 0, len, 0))); if (result) { if ( ! (eiref (filename, 0) == '.' && ((hide_system && (eiref (filename, 1) == '\0' || (eiref (filename, 1) == '.' && eiref (filename, 2) == '\0'))) || hide_dot))) { if (++findex >= array_size) { array_size = findex * 2; XREALLOC_ARRAY (files, WIN32_FIND_DATA, array_size); } } } } if (fh != INVALID_HANDLE_VALUE) { FindClose (fh); } *nfiles = findex; break; } return (files); } I wager that the above would be significantly harder w/o Eistrings. Keep in mind that a lot of current code that is Mule-compliant according to the current rules will become less so once we start allowing multiple encodings, and much less so if we consider changing the default internal encoding to something that's not ASCII-compliant, e.g. UCS2. Properly written Eistring code will remain fully compliant in both cases. Hrvoje Niksic wrote: -- 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.