[xemacs-hg @ 2002-04-14 12:41:59 by ben] latest changes TODO.ben-mule-21-5: Update. make-docfile.c: Add basic support for handling ISO 2022 doc strings -- we parse the basic charset designation sequences so we know whether we're in ASCII and have to pay attention to end quotes and such. Reformat code according to coding standards. abbrev.el: Add `global-abbrev-mode', which turns on or off abbrev-mode in all buffers. Added `defining-abbrev-turns-on-abbrev-mode' -- if non-nil, defining an abbrev through an interactive function will automatically turn on abbrev-mode, either globally or locally depending on the command. This is the "what you'd expect" behavior. indent.el: general function for indenting a balanced expression in a mode-correct way. Works similar to indent-region in that a mode can specify a specific command to do the whole operation; if not, figure out the region using forward-sexp and indent each line using indent-according-to-mode. keydefs.el: Removed. Modify M-C-backslash to do indent-region-or-balanced-expression. Make S-Tab just insert a TAB char, like it's meant to do. make-docfile.el: Now that we're using the call-process-in-lisp, we need to load an extra file win32-native.el because we're running a bare temacs. menubar-items.el: Totally redo the Cmds menu so that most used commands appear directly on the menu and less used commands appear in submenus. The old way may have been very pretty, but rather impractical. process.el: Under Windows, don't ever use old-call-process-internal, even in batch mode. We can do processes in batch mode. subr.el: Someone recoded truncate-string-to-width, saying "the FSF version is too complicated and does lots of hard-to-understand stuff" but the resulting recoded version was *totally* wrong! it misunderstood the basic point of this function, which is work in *columns* not chars. i dumped ours and copied the version from FSF 21.1. Also added truncate-string-with-continuation-dots, since this idiom is used often. config.inc.samp, xemacs.mak: Separate out debug and optimize flags. Remove all vestiges of USE_MINIMAL_TAGBITS, USE_INDEXED_LRECORD_IMPLEMENTATION, and GUNG_HO, since those ifdefs have long been removed. Make error-checking support actually work. Some rearrangement of config.inc.samp to make it more logical. Remove callproc.c and ntproc.c from xemacs.mak, no longer used. Make pdump the default. lisp.h: Add support for strong type-checking of Bytecount, Bytebpos, Charcount, Charbpos, and others, by making them classes, overloading the operators to provide integer-like operation and carefully controlling what operations are allowed. Not currently enabled in C++ builds because there are still a number of compile errors, and it won't really work till we merge in my "8-bit-Mule" workspace, in which I make use of the new types Charxpos, Bytexpos, Memxpos, representing a "position" either in a buffer or a string. (This is especially important in the extent code.) abbrev.c, alloc.c, eval.c, buffer.c, buffer.h, editfns.c, fns.c, text.h: Warning fixes, some of them related to new C++ strict type checking of Bytecount, Charbpos, etc. dired.c: Caught an actual error due to strong type checking -- char len being passed when should be byte len. alloc.c, backtrace.h, bytecode.c, bytecode.h, eval.c, sysdep.c: Further optimize Ffuncall: -- process arg list at compiled-function creation time, converting into an array for extra-quick access at funcall time. -- rewrite funcall_compiled_function to use it, and inline this function. -- change the order of check for magic stuff in SPECBIND_FAST_UNSAFE to be faster. -- move the check for need to garbage collect into the allocation code, so only a single flag needs to be checked in funcall. buffer.c, symbols.c: add debug funs to check on mule optimization info in buffers and strings. eval.c, emacs.c, text.c, regex.c, scrollbar-msw.c, search.c: Fix evil crashes due to eistrings not properly reinitialized under pdump. Redo a bit some of the init routines; convert some complex_vars_of() into simple vars_of(), because they didn't need complex processing. callproc.c, emacs.c, event-stream.c, nt.c, process.c, process.h, sysdep.c, sysdep.h, syssignal.h, syswindows.h, ntproc.c: Delete. Hallelujah, praise the Lord, there is no god but Allah!!! fix so that processes can be invoked in bare temacs -- thereby eliminating any need for callproc.c. (currently only eliminated under NT.) remove all crufty and unnecessary old process code in ntproc.c and elsewhere. move non-callproc-specific stuff (mostly environment) into process.c, so callproc.c can be left out under NT. console-tty.c, doc.c, file-coding.c, file-coding.h, lstream.c, lstream.h: fix doc string handling so it works with Japanese, etc docs. change handling of "character mode" so callers don't have to manually set it (quite error-prone). event-msw.c: spacing fixes. lread.c: eliminate unused crufty vintage-19 "FSF defun hack" code. lrecord.h: improve pdump description docs. buffer.c, ntheap.c, unexnt.c, win32.c, emacs.c: Mule-ize some unexec and startup code. It was pseudo-Mule-ized before by simply always calling the ...A versions of functions, but that won't cut it -- eventually we want to be able to run properly even if XEmacs has been installed in a Japanese directory. (The current problem is the timing of the loading of the Unicode tables; this will eventually be fixed.) Go through and fix various other places where the code was not Mule-clean. Provide a function mswindows_get_module_file_name() to get our own name without resort to PATH_MAX and such. Add a big comment in main() about the problem with Unicode table load timing that I just alluded to. emacs.c: When error-checking is enabled (interpreted as "user is developing XEmacs"), don't ask user to "pause to read messages" when a fatal error has occurred, because it will wedge if we are in an inner modal loop (typically when a menu is popped up) and make us unable to get a useful stack trace in the debugger. text.c: Correct update_entirely_ascii_p_flag to actually work. lisp.h, symsinit.h: declarations for above changes.

	   Protect Your Freedom to Write Programs
	   Join the League for Programming Freedom
	       (Version of February 3, 1994)

Ten years ago, programmers were allowed to write programs using all
the techniques they knew, and providing whatever features they felt
were useful.  This is no longer the case.  New monopolies, known as
software patents and interface copyrights, have taken away our freedom
of expression and our ability to do a good job.

"Look and feel" lawsuits attempt to monopolize well-known command
languages; some have succeeded.  Copyrights on command languages
enforce gratuitous incompatibility, close opportunities for
competition, and stifle incremental improvements.

Software patents are even more dangerous; they make every design
decision in the development of a program carry a risk of a lawsuit,
with draconian pretrial seizure.  It is difficult and expensive to
find out whether the techniques you consider using are patented; it is
impossible to find out whether they will be patented in the future.

The League for Programming Freedom is a grass-roots organization of
professors, students, businessmen, programmers and users dedicated to
bringing back the freedom to write programs.  The League is not
opposed to the legal system that Congress expressly established for
software--copyright on individual programs.  Our aim is to reverse the
recent changes that prevent programmers from doing their work.

The League works to abolish the new monopolies by publishing articles,
talking with public officials, denouncing egregious offenders, and
filing amicus curiae briefs, most notably against Lotus in its suit
against Borland.  We testified twice at the recent Patent Office
hearings on software patents.  We welcome suggestions for other
activities, as well as help in carrying them out.

Membership dues in the League are $42 per year for programmers,
managers and professionals; $10.50 for students; $21 for others.
Please give more if you can.  The League's funds will be used for
filing briefs; for printing handouts, buttons and signs; whatever will
persuade the courts, the legislators, and the people.  You may not get
anything personally for your dues--except for the freedom to write
programs.  The League is a non-profit corporation, but not considered
a tax-exempt charity.  However, for those self-employed in software,
the dues can be a business expense.

The League needs both activist members and members who only pay their
dues.  We also greatly need additional corporate members; contact us
for information.

If you have any questions, please write to the League, phone
+1 617 621 7084, or send Internet mail to lpf@uunet.uu.net.

		       Chris Hofstader, President
		       Dean Anderson, Secretary
		       Aubrey Jaffer, Treasurer

Chris Hofstader can be reached at (617) 492-0023; FAX (617) 497-1632.
To join, please send a check and the following information to:

    League for Programming Freedom
    1 Kendall Square #143
    P.O.Box 9171
    Cambridge, Massachusetts 02139

(Outside the US, please send a check in US dollars on a bank 
having a US correspondent bank, to save us check cashing fees.)

Your name:


The address for League mailings, a few each year; please indicate
whether it is your home address or your work address:



The company you work for, and your position:


Your phone numbers (home, work or both):


Your email address, so we can contact you for demonstrations or for
writing letters.  (If you don't want us to contact you for these
things, please say so, but please give us your email address anyway
so we can save paper and postage by sending you the newsletter by email.)


Is there anything about you which would enable your endorsement of the
LPF to impress the public?  For example, if you are or have been a
professor or an executive, or have written software that has a good
reputation, please tell us.



Would you like to help with LPF activities?




The corporate charter of the League for Programming Freedom states:

    The purpose of the corporation is to engage in the following
    activities:

    1. To determine the existence of, and warn the public about
    restrictions and monopolies on classes of computer programs where such
    monopolies prevent or restrict the right to develop certain types of
    computer programs.

    2. To develop countermeasures and initiatives, in the public interest,
    effective to block or otherwise prevent or restrain such monopolistic
    activities including education, research, publications, public
    assembly, legislative testimony, and intervention in court proceedings
    involving public interest issues (as a friend of the court).

    3. To engage in any business or other activity in service of and
    related to the foregoing paragraphs that lawfully may be carried on
    by a corporation organized under Chapter 180 of the Massachusetts
    General Laws.

The officers and directors of the League will be elected annually by
the members.